Wstęp do UML cz.3 - krótki przegląd diagramów i ich zastosowań

Projekt systemu w języku UML zbudowany jest z logicznie powiązanych ze sobą diagramów, które pozwalają na opisanie systemu począwszy od modeli ogólnych do bardzo szczegółowych. Standard UML 2.0 obejmuje 13 rodzajów diagramów charakteryzujących statykę i dynamikę tworzonego systemu. Oprócz tego, zbiór wszystkich diagramów można przedstawić za pomocą diagramów abstrakcyjnych, które są jedynie nazwami uogólniającymi w grupy 13 diagramów konkretnych. Diagramami abstrakcyjnymi są: diagramy struktury, dynamiki, interakcji, wdrożeniowe oraz sama kategoria diagramów UML.

Diagramy UML 2.0

Poniżej przedstawiony jest zestaw diagramów wchodzących w skład standardu UML 2.0.

Krótka interpretacja poszczególnych diagramów:

1. Diagram klas - prezentacja statycznych, deklaratywnych elementów dziedziny problemowej oraz związków między nimi.
2. Diagram obiektów - obrazuje instancje klas i związki między nimi, wyjaśnia znaczenie diagramów klas - odwzorowuje strukturę systemu w wybranym momencie jego działania.
3. Diagram pakietów - prezentuje logiczną strukturę systemu w postaci zestawu pakietów połączonych zależnościami i zagnieżdżeniami.
4. Diagram struktur połączonych - przedstawia wzajemnie współdziałające części modelu dla osiągnięcia pożądanej funkcjonalności współdziałania.
5. Diagram komponentów - pokazuje sposób organizacji i zależności między komponentami systemu (podsystemami).
6. Diagram rozlokowania - przedstawia sieć połączonych ścieżkami komunikowania węzłów z ulokowanymi na nich artefaktami.
7. Diagram przypadków użycia - przedstawia przypadki użycia systemu, aktorów systemu oraz związki między mini w aspekcie danej dziedziny problemowej.
8. Diagram czynności - przedstawia przepływ sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów.
9. Diagram maszyny stanowej - odzwierciedla dozwolone przejścia między stanami konkretnego obiektu.
10. Diagram sekwencji - opisuje interakcje między instancjami klasyfikatorów systemu w postaci sekwencji komunikatów wymienianych między nimi (klasyfikator to abstrakcyjna kategoria modelowania, która uogólnia kolekcję instancji o tych samych cechach).
11. Diagram komunikacji - specyfikuje strukturalne związki między instancjami klasyfikatorów będących w interakcji oraz wymianę komunikatów między nimi.
12. Diagram harmonogramowania - reprezentuje na osi czasu zmiany dopuszczalnych stanów, jakie może przyjmować instancja klasyfikatora w czasie interakcji.
13. Diagram sterowania interakcją - dokumentuje przepływ sterowania między logicznie powiązanymi diagramami i fragmentami interakcji z wykorzystaniem kategorii modelowania diagramów czynności.

Diagramy w różnych perspektywach opisu architektury systemu

Osoby tworzące system oraz te, które będą go w przyszłości użytkowały, mają różne na niego spojrzenia. Określony pogląd na oczekiwany produkt mają m.in. właściciele, menedżerowie, analitycy, projektanci, programiści, czy też testerzy. Każdy z tych spojrzeń ma znaczący wpływ na projektowaną architekturę systemu. Z tego względu zaproponowano pięć perspektyw architektury systemu informatycznego, z których każda może być zaprezentowana przy pomocy określonego zestawu diagramów UML. Perspektywami tymi są:

• Perspektywa przypadków użycia - kluczowa i dominująca wobec pozostałych, definiuje zakres i oczekiwaną funkcjonalność tworzonego systemu. Opisana może być za pomocą: diagramu przypadków użycia, diagramu pakietów.
• Perspektywa dynamiczna - wskazuje w jaki sposób jest realizowane zachowanie instancji klasyfikatorów w systemie. Opisana może być za pomocą: diagramu czynności, diagramu maszyny stanowej, diagramu struktur połączonych, diagramu pakietów.
• Perspektywa logiczna - opisuje aspekty statyczne systemu. Opisana może być za pomocą: diagramu klas, diagramu obiektów, diagramu struktur połączonych, diagramu pakietów.
• Perspektywa komponentów - specyfikuje oprogramowanie na poziomie komponentów. Opisana może być za pomocą: diagramu komponentów, diagramu pakietów.
• Perspektywa rozlokowania - specyfikuje sprzęt informatyczny niezbędny do funkcjonowania konkretnych komponentów systemu. Opisana może być za pomocą: diagramu rozlokowania, diagramu pakietów.

Diagramy w modelowaniu biznesowym i analitycznym

Proponowane są również inne techniki diagramowe ściśle związane ze standardem UML, np. diagramy modelowania analitycznego, czy też diagramy modelowania biznesowego. W przypadku modelu biznesowego najczęściej stosowane są następujące diagramy:

• biznesowy diagram przypadków użycia,
• biznesowy diagram klas,
• biznesowy diagram czynności,
• biznesowy diagram sekwencji,
• biznesowy diagram pakietów.

W modelowaniu biznesowym niezbędne stają się kategorie modelowania, które nie są elementami diagramów opisujących oprogramowanie. Kategorie te mają charakter stereotypów graficznych i dotyczą m.in. aktorów biznesowych, biznesowych przypadków użycia, czy też biznesowej klasy przechowującej (więcej o modelowaniu biznesowym w przyszłych wpisach).

Diagramy modelowania analitycznego zostały zaproponowane przez Ivara Jacobsona w celu wspomagania przejścia od diagramów przypadków użycia oraz ich scenariuszy do diagramów klas i diagramów interakcji na poziomie konceptualnym i implementacyjnym. Diagramy modelowania analitycznego stanowią zatem element pośredni i opcjonalny w procesie tworzenia systemu. Pozwalają zminimalizować lukę semantyczną pomiędzy zrozumiałą dla większości odbiorców terminologię przypadków użycia a technicznymi aspektami systemu informatycznego. 

Diagramy analityczne można traktować jako rodzaj wstępnego projektu, którego celem jest wspomaganie i identyfikacja klas. Podstawowym elementem tego typu diagramów są klasy analityczne, aktorzy i związki. Diagramy analityczne modelowane są jako diagramy klas i interakcji z zastosowaniem trzech stereotypowanych klas:

• granicznych (boundary),
• sterujących (control),
• przechowujących (entity).

Wykorzystując diagramy UML możemy spojrzeć na system z różnych perspektyw, modelując jego aspekty statyczne i dynamiczne. Możemy stosować zróżnicowany poziom abstrakcji konstruowanego modelu, pokazując tylko to co jest potrzebne dla jego odbiorcy na danym etapie. Możemy również wspomagać analizę biznesową będącą początkowym wkładem w projektowanie proponowanych rozwiązań.

Źródła