Podstawy modelowania i UML

1. Co to są modele?

Model to kompletny opis systemu z konkretnego punktu widzenia i działa jako uproszczony obraz rzeczywistości. Budujesz modele, ponieważ złożone systemy nie mogą być w pełni pojęte w całości.

Cztery podstawowe cele modelowania:

1. Wizualizuj system tak, jak miał być zaprojektowany.

2. Określ strukturę lub zachowanie systemu.

3. Zapewnij szablon do kierowania budową systemu.

4. Dokumentuj decyzje projektowe.

Cztery zasady modelowania

• Model, który wybierasz, bezpośrednio wpływa na sposób podejścia do problemu.

• Każdy model można wyrazić na różnych poziomach dokładności.

• Najskuteczniejsze modele pozostają ściśle powiązane z rzeczywistością.

• Żaden pojedynczy model nie jest wystarczający; złożone systemy wymagają wielu perspektyw.

Co to jest UML?

Język Unified Modeling Language (UML) to standardowy język graficzny zarządzany przez Object Management Group (OMG). Jest wyraźnie nie metodologią ani procedurą, ale specyfikacją techniczną i graficzną używaną do:

„Wizualizuj, określ, zbuduj i zapisz artefakty systemu zdominowanego oprogramowaniem.“

UML zapewnia uniwersalny format projektu zarówno dla elementów koncepcyjnych (procesy biznesowe, funkcje systemu), jak i implementacji rzeczywistych (instrukcje kodu, schematy baz danych, komponenty ponownie używalne).

Cztery filary UML

Cel	Opis
Wizualizacja	Gwarantuje, że wszyscy zaangażowani mówią tym samym językiem. Jawne modele eliminują błędy komunikacji i ujawniają aspekty systemu, które są niewidoczne bez modelowania.
Określanie	Tworzy dokładne, jednoznaczne i kompletne definicje systemu.
Budowanie	Bezpośrednio odpowiada językom programowania (Java, C++, VB), tabelom RDBMS lub magazynom OODBMS. Obsługuje inżynierię wsteczną (model → kod) i inżynierię wsteczną (kod → model).
Dokumentowanie	Zapisuje architekturę systemu, wymagania, plany testów, harmonogramy projektów oraz zarządzanie wersjami.

---

2. Ekosystem diagramów UML

UML 2.2 definiuje 14 typów diagramów, podzielonych na dwa główne zbiory:

1. Modele strukturalne (architektura statyczna)

2. Modele zachowania i interakcji (procesy dynamiczne)

Różne diagramy służą różnym perspektywom zaangażowanych stron:

• Widok przypadków użycia: funkcjonalność użytkownika końcowego

• Widok logiczny: Analitycy i projektanci (struktura systemu)

• Widok procesu: Zarządzanie oprogramowaniem (wydajność, skalowalność, przepustowość)

• Widok implementacji: Programiści (konkretne składniki)

• Widok wdrażania: Integratorzy systemów (topologia, instalacja, komunikacja)

---

3. Omówienie podstawowych diagramów UML

🔹 Diagram przypadków użycia

• Cel: Modeluje zamierzone funkcje systemu oraz jego środowisko. Działa jako umowa między klientami a deweloperami.

• Składniki: Aktorzy, przypadki użycia oraz ich relacje.

• Diagramy wspierające: Działanie (przepływ w ramach przypadku użycia), Sekwencja (współpraca obiektów w celu zrealizowania przypadku użycia).

🔹 Diagram działania

• Cel: Wizualizuje krok po kroku przepływ zdarzeń w ramach procesu lub przypadku użycia.

• Główne elementy:

  • Akcja: Dyskretny krok w przepływie pracy.

  • Przepływ: Sekwencja działań.

  • Decyzja: Dzieli przepływ na podstawie warunku zabezpieczającego[warunek].

  • Rozgałęzienie: Rozpoczyna wątki współbieżne.

  • Połączenie: Kończy wątki współbieżne (synchronizacja).

• Przykład: Przepływ rejestracji kursu z kontrolami, rozwiązywaniem konfliktów i jednoczesnym aktualizowaniem harmonogramu.

🔹 Diagram sekwencji

• Cel: Pokazuje, jak obiekty współdziałają w czasie w celu spełnienia przypadku użycia.

• Główne elementy:

  • Linia życia: Pionowa linia pokazująca istnienie obiektu w czasie.

  • Obiekt/Klasa: Uczestnik interakcji.

  • Wiadomość: Dane lub wywołania metod wymieniane między obiektami.

  • Wystąpienie wykonania: Cienki prostokąt pokazujący, kiedy obiekt aktywnie przetwarza dane.

  • Fragmenty połączone: opt (wykonanie opcjonalne), loop (wykonanie powtarzane), ref (odnosi się do innej interakcji).

🔹 Diagram komunikacji

• Cel: Alternatywa dla diagramów sekwencji. Podkreśla relacje strukturalne między obiektami zamiast kolejności czasowej.

• Główne elementy:Obiekty połączone ze sobą, z numerowanymi komunikatami wskazującymi sekwencję interakcji wzdłuż połączeń.

🔹 Diagram składników

• Cel: Pokazuje strukturę czasu działania na poziomie składników oprogramowania.

• Kluczowe elementy: Modułowe części systemu ukryte za zewnętrznymi interfejsami. Często zawiera klasy, aby pokazać relacje implementacji.

🔹 Diagram wdrażania

• Cel: Mapuje artefakty oprogramowania na fizyczne urządzenia sprzętowe.

• Kluczowe elementy:

  • Węzeł: Reprezentuje fizyczny komputer lub środowisko wykonawcze.

  • Artefakt: Reprezentuje fizyczny plik lub jednostkę wdrażalną.

  • Element własności: Pokazuje relacje zagnieżdżone lub zawarte.

---

4. Opanowanie diagramów klas i relacji

Diagramy klas przedstawiają strukturę statyczną systemu. Są podstawą dla specyfikacji danych (np. INSPIRE) i nie nie pokazują informacje temporalne.

Anatomia klasy

Kompartament	Opis
Nazwa	Identyfikator klasy (np. CadastralParcel). Często zawiera stereotypy takie jak «FeatureType».
Atrybuty	Nazwane właściwości z typami danych (np. - Adres : char, - WiekDrzewa : int). Obsługiwane typy: Liczba całkowita, LongInt, Double, Char, Data, Logiczny, Ciąg znaków, Geometria, itd.
Operacje	Zachowania/konstrukcje klasy. Format: + nazwaOperacji(tipWejściowy) : typZwracany.

Typy relacji

Relacja	Symbol	Znaczenie
Powiązanie	───────	Ogólna linka między klasami. Zawiera nazwy ról, strzałki nawigacyjne oraz liczność (1..*, 0..*, 1..2, itd.).
Ogólnienie	─────▷	Dziedziczenie. Klasa pochodna (źródło) dziedziczy wszystkie cechy klasy nadrzędnej (docelowej).
Agregacja	◇─────	Relacja „część-tu”. Część może istnieć niezależniecałości. (Pusty diament)
Kompozycja	◆─────	Silna relacja „część-całość”. Istnienie części zależy całkowicieod całości. (Wypełniony diament)

Przykład z materiałów szkoleniowych:

• Osoba → Leśnik (Generalizacja: Leśnik dziedziczy Imię, Płeć)

• Las ◇─ Drzewo (Agregacja: Drzewa mogą istnieć bez konkretnego lasu)

• Leśnik ◆─ Pracownicy (Kompozycja: Pracownicy nie mogą istnieć niezależnie od encji Leśnik w tym kontekście)

---

5. Zastosowanie praktyczne: Modelowanie katastru INSPIRE

Materiały szkoleniowe wykorzystują Specyfikację danych INSPIRE dotyczącą katastru w celu przedstawienia praktycznego zastosowania UML.

Ćwiczenie 1: Modelowanie klasy podstawowej

Zadanie: Utwórz klasę ParcelaKatastralna klasę.
Struktura rozwiązania:

«featureType» ParcelaKatastralna
- Adres : char
- APN (numer parceli) : char
- Granica : GM_Surface
- Środek : GM_Point
- Etykieta : char
- NarodowyReferencjKatastralny : String
- WartośćPowierzchni : double (opcjonalnie)
- PunktOdniesienia : GM_Point (opcjonalnie)

Uwaga: Istnieje wiele poprawnych rozwiązań. Atrybuty powinny odzwierciedlać typowe cechy świata rzeczywistego.

Ćwiczenie 2: Modelowanie relacji

Zadanie: Połącz ParcelaKatastralna, GranicaKatastralna, oraz StrefaAdministracyjna.
Kluczowe decyzje modelowania:

• ParcelaKatastralna ──── GranicaKatastralna: Związek/Złożenie (granica definiuje parcelę; często 1..1 lub 1..* kardynalność). Role: +jestGranica / +maGranice.

• Parcela katastralna ◇── Strefa administracyjna: Agregacja/Asocjacja. Istnienie strefy nie zależy od parceli. Parcela należy do wielu stref hierarchicznych (1..* do 0..*).

• Lekcja: Wybieraj typy relacji na podstawie zależności cyklu życia i zasad biznesowych. Diagramy powinny odzwierciedlać rzeczywistość, a nie narzucać sztuczne ograniczenia.

---

6. Najlepsze praktyki efektywnego modelowania UML

1. Używaj diagramów strategicznie: Diagramy wizualizują konkretne perspektywy. Żaden złożony system nie może zostać zrozumiany na podstawie jednego diagramu.

2. Powtarzaj elementy na różnych diagramach: Jedna klasa może pojawiać się na diagramach klas, maszynach stanów, diagramach sekwencji i widokach wdrożenia, przy czym każdy z nich podkreśla inny aspekt.

3. Dostosuj dokładność do odbiorcy: Dostosuj złożoność diagramu w zależności od tego, czy odbiorcą jest użytkownik końcowy, programista, integrator systemu czy menedżer projektu.

4. Weryfikuj z rzeczywistością: Nieustannie sprawdzaj, czy elementy modelu, relacje i liczby kardynalne odzwierciedlają rzeczywiste zachowanie systemu i zasady domeny.

5. Wykorzystaj wsparcie narzędzi: Używaj narzędzi zgodnych z UML (np. Sparx Systems) do inżynierii wstecznej/wstecznej, sprawdzania spójności i generowania kodu.

---

Wnioski

UML to potężny, standardowy język do komunikowania się, projektowania i dokumentowania systemów oprogramowania oraz systemów intensywnie wykorzystujących dane. Opanowanie podstawowych diagramów (szczególnie Diagramu klas, Diagramu sekwencji, Diagramu aktywności i Diagramu przypadków użycia) oraz zrozumienie semantyki relacji (Asocjacja, Ogólnienie, Agregacja, Kompozycja) pozwala praktykom tworzyć dokładne, zgodne z rzeczywistością szkice, które zamykają lukę między wymaganiami koncepcyjnymi a implementacją techniczną.