Po co nam UML?

1. analiza i rozwiązanie problemu przed kodowaniem aplikacji
2. jednoznacznie rozumiana wymiana wiedzy o problemie i o jego rozwiązaniu

Opis Szkolenia

(terminy szkoleń otwartych organizowanych przez eduFuturo)

Prowadzący: Jarosław Żeliński (autor tego bloga).

Zakres: szkolenie przygotowuje do samodzielnej pracy w roli inżyniera oprogramowania metodami opartymi o proces ICONIX.

1. Historia UML
2. ?Road map?
3. 2012 – Czy Agile zabije planete?
4. Wykorzystanie UML?a – cele
5. Wykorzystanie UML?a – diagramy
6. Dokumentacja jako kanał komunikacyjny
7. Od analizy do implementacji – modelowanie
8. Modelowanie – definicje
9. Modelowanie – semantyka i syntaktyka notacji
10. Przez modelowanie osiągamy?
11. Zasady modelowania
12. MOF, MDA
13. MOF – Poziomy modelowania
14. MDA ? Model Driven Architecture
15. Elementy notacji UML wymagane do tworzenia modeli PIM – Notacja |UML 2.5.1.
16. Trójkąt semiotyczny
17. Podstawowe elementy notacji UML
18. Zakres
19. Dostosowanie do architektury
20. Obszary semantyczne (konteksty)
21. Jak korzystać ze specyfikacji UML
22. Modelowanie struktury
    • Pojęcia podstawowe (budowa diagramu)
      • Przykład
    • Przestrzeń pojęciowa
    • Ograniczenie
      • Przykłady
    • Zależność
    • Wartości
    • Klasyfikacja (klasyfiaktor)
    • Cechy: elementy struktury klasyfikatora
    • Generalizacje (taksonomia)
    • Związki pojęciowe vs. strukturalne
    • Zestawy generalizacji
      • Przykłady typów taksonomii i jej użycia
    • Asocjacja
    • Instancja
    • Proste klasyfikatory
    • Klasyfikatory strukturalne
    • Część i rola elementu
      • Przykład struktury
    • Klasy
    • Asocjacje
    • Strukturalny klasyfikator i jego wnętrze
    • Współpraca
    • Pakiety
23. Modelowanie zachowania
    • Zachowania – czym są
    • Maszyna stanowa (automat stanowy)
    • Aktywności i Czynności
    • Aktywność i Zadanie
    • Scenariusz i model jednej z czynności
    • Interakcje
24. Elementy uzupełniające
    • Przypadki użycia
    • Wdrożenie
    • Przepływ informacji
25. Diagramy
    • Taksonomia diagramów
26. Paradygmat obiektowy
    • Model-Dependent Realism
    • Object Oriented Programming is not what I thought (2020)
    • ?Object Oriented Programming vs Functional Programming? (2022)
    • Paradygmat obiektowy: OOAD
    • Wyjaśnienie podstawowych pojęć dot. strategii obiektowych
    • System vs. Obiektowy paradygmat
27. Analiza i projektowanie obiektowe
    • ICONIX
    • Struktura projektu zorientowanego obiektowo
    • Pryncypia projektowania komponentowego
      • Loose coupling and high cohesion
      • Open-close principle
      • Contract model
28. MVC, Boundary, Controll, Entity
    • MVC ? Model View Controller
    • Modelowanie ? komponenty i mikro-aplikacje
    • Modelowanie struktur danych
29. Przykład projektu
    • Analiza Biznesowa
    • Umowa na zakres czyli wymagania
    • Model pojęciowy dziedziny systemu a architektura: dwa różne diagramy klas
    • Dokumentowanie przypadków użycia
    • Dokumentowanie danych – Formularze
    • Architektura Komponentu Zarzadzanie Wizytami realizującego usługę
    • Model operacji: przywołaj wizytę()
    • Statusy obiektu Wizyty
    • Scenariusz realizacji Usługi
    • Architektura Systemu
    • Zobrazowanie integracji wewnętrznych komponentów
30. Pytania?
31. Literatura źródłowa

UWAGA! Szkolenia prowadzone są w trybie wykładowo-konwersacyjnym, omawiane są między innymi praktyczne przykłady procesów biznesowych. Do udziału w szkoleniu nie jest potrzebny komputer ani specjalistyczne oprogramowanie. Użycie komputerów i oprogramowania wspomagającego tworzenie diagramów jest wymaga wyłącznie w przypadku zamówienia dodatkowych warsztatów. W toku szkolenia mogą nastąpić odstępstwa od agendy, jeżeli uczestnicy wyrażą oczekiwanie przedyskutowania określonych zagadnień, kosztem innych, o czym prowadzący poinformuje a uczestnicy wyrażą zgodę. Szkolenie prowadzone jest zdalnie.

Wsparcie po szkoleniu dla uczestników: W ramach opłaty za szkolenie uczestnicy mają 60 dni na korespondencyjne konsultacje treści omawianych na szkoleniu. Prowadzący odpisuje w ciągu trzech dni roboczych.