Unified Modeling Language Tomasz Pawlak
2 Plan prezentacji Wprowadzenie i historia UML Modelowanie z użyciem UML Wybrane diagramy struktury i zachowania Narzędzia wspierające UML
3 Unified Modeling Language (UML) Język modelowania systemów na etapie projektu i rozwoju Różne aspekty systemów Nie tylko oprogramowanie Inżynieria systemów Procesy biznesowe Struktury organizacyjne Wykorzystuje diagramy i schematy Standard przemysłowy (ISO/IEC 19505-1 oraz 19505-2)
4 Historia UML 1990: Istnieje wiele niezwiązanych, niezależnie rozwijanych metod modelowania o różnym zastosowaniu Źródło: Guido Zockoll, Axel Scheithauer & Marcel Douwe Dekker (Mdd) - Translation and update of File:OO-historie-2.svg by AxelScheithauer, Okt 6, 2009, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=23052855
5 Historia UML Najpopularniejsze metody Metoda Grady Boocha Object-modeling technique (James Rumbaugh) Object-oriented software engineering (Ivar Jacobson) Grady Booch: vonguard from Oakland, Nmibiaderivative work: YMS - This file was derived from Grady Booch, CHM 2011 2.jpg:, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=26328892 James Rumbaugh http://si.utia.cas.cz/rse/omt_96_1.htm Ivar Jacobson: By English Wikipedia user Mikemacd, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=6377157
6 Historia UML 1994: Rational Software Corporation Zatrudnienie Boocha, Rumbaugha, Jacobsona (1995) Pakiety oprogramowania dla metod Boocha, OMT i OOSE 1996: UML Partners konsorcjum założone przez w/w Cel: standaryzacja Później dołączyli: HP, DEC, IBM, Microsoft
7 Historia UML 01.1997: Object Management Group (OMG) otrzymało wersję roboczą UML 1.0 08.1997: OMG otrzymało wersję 1.1 11.1997: OMG przyjęło wersję 1.1 jako standard 1998-2003: Rozwój wersji 1.3 1.5 2005: UML 1.4.2 standardem ISO/IEC 19501
8 Historia UML
9 Krytyka UML 1.x UML 1.1 powstał w rok! Standard niejednoznaczny, niespójny, niekompletny Brak precyzyjnego opisu znaczenia elementów diagramów Brak uwzględnienia przypadków brzegowych Brak standardu wymiany informacji Brak możliwości wymiany plików modeli między programami Złożoność Niezrozumiały dla osób decyzyjnych i klientów (nie informatyków) Spójność Trudność w utrzymaniu spójności kodu i projektu
10 Historia UML 2005: UML 2.0 2007 2015: UML 2.1.1 2.5 2012: UML 2.4.1 standardem ISO/IEC 19505-1 i ISO/IEC 19505-2
11 Elementy standardu UML 2.x Infrastruktura Metamodel baza superstruktur Superstruktury Definicja notacji i semantyki diagramów i ich elementów Object Constraint Language (OCL) Służy definiowaniu reguł dla elementów modelu UML Diagram Interchange Format plików/wymiany informacji
12 Rodzaje diagramów UML Diagramy strukturalne Modelują elementy systemu konieczne do jego pracy Diagramy zachowania Modelują dynamikę zmiany stanu systemu Warunki początkowe i końcowe, ograniczenia
13 Źródło: http://www.uml-diagrams.org/uml-25-diagrams.html
14 Modelowanie z użyciem UML
15 Wysokopoziomowa specyfikacja wymagań Kluczowe pytania Czym aplikacja powinna być? Co aplikacja powinna robić? Jakie powinny być główne pakiety systemu? Jakie komponenty należą do poszczególnych pakietów? W jakim środowisku system będzie działać? Kto ma dostęp do aplikacji i w jakim celu?
16 Diagram aktywności Opis procesu biznesowego Odpowiedź na pytanie czym aplikacja powinna być Specyfikacja Głównych komponentów biorących w procesie Zadań tych komponentów Modelowanie Wysokopoziomowych interakcji między komponentami Procesów decyzyjnych
17 Elementy diagramu aktywności Partycja (partition) Organizacja powiązanych elementów przez grupowanie Węzeł początkowy (initial node) Węzeł końcowy (activity final node) Zakończenie całej aktywności Wyjście z systemu (flow final node) Zakończenie pojedynczej ścieżki przetwarzania Węzeł decyzyjny (decision node) Wpływa na dalszy kierunek przetwarzania Węzeł łączący (merge node) Grupuje wiele ścieżek przepływu sterowania
18 Elementy diagramu aktywności Węzeł podziału (fork node) Rozpoczyna wiele równoległych ścieżek przetwarzania Węzeł połączenia (join node) Kończy wiele równoległych ścieżek przetwarzania Przejście możliwe jeśli wszystkie wchodzące ścieżki zakończą się Stan aktywności (activity state) Inaczej akcja: Stan wykonywania elementarnej akcji w ramach aktywności Wywołanie nazwanej akcji (call operation action)
19 Elementy diagramu aktywności Parametr aktywności (activity parameter) Parametr procesu biznesowego Trwały magazyn danych (data store)
20 Elementy diagramu aktywności Parametr akcji (input pin) Wyjście akcji (output pin)
21 Kontrola przepływu sterowania Definicja przepływu przetwarzania Następstwo akcji Bez informacji o przekazanych danych Na ogólnym poziomie modelowania wystarczające Przepływ danych Następstwo akcji Informacja o przekazaniu danych
22
23 Diagram przypadków użycia Odpowiada na pytanie kto ma dostęp do systemu i w jakim celu Opis interfejsów zewnętrznych systemu Specyfikacja Aktorów / ról użytkowników systemu Dostępnych dla nich aktywności i modułów systemu
24 Elementy diagramu przypadków użycia Aktor (actor) Użytkownik systemu Człowiek lub inny system Przypadek użycia (use case) Aktywność możliwa do wykonania przez użytkownika Komponent (subject) Odpowiedzialny za dostęp do aktywności Np.: klasa, interfejs, typ danych itp.
25 Kontrola związków Związek (relationship) Zakres aktywności dostępnych dla aktora Uogólnienie (generalization) Specjalizacja ma dostęp do wszystkich przypadków użycia generalizacji
26 Kontrola związków Rozszerzenie (extend) Opcjonalny przypadek użycia wykonywany wraz z innym Rozszerzenie może być zastosowane do wielu przypadków użycia Rozszerzenie może nie być samodzielne Zawieranie (include) Obligatoryjne zawieranie przypadków użycia Służy dekompozycji złożonych przypadków użycia
27 Diagram przypadków użycia przykład
28 Diagram pakietów Odpowiada na pytanie jakie są główne pakiety systemu Definicja Organizacji komponentów Zależności między pakietami i komponentami
29 Elementy diagramu pakietów Pakiet (package)
30 Relacje diagramu pakietów Zawieranie (contained in) Pakiet jest zbiorem innych pakietów Definiuje hierarchę Import nazw (import) Umożliwia odwołanie do elementów innego pakietu bez pełnej nazwy Jak import w Javie / using w C#
31 Relacje diagramu pakietów Użycie (usage) Pakiet jest klientem funkcjonalności innego pakietu Zależność (dependency) Pakiet jest zależny od funkcjonalności innego pakietu Nawet jeśli nie zachodzi bezpośrednie użycie Np.: Zależność typu producent konsument
32 Relacje diagramu pakietów Łączenie (merge) Pakiet staje się częścią innego pakietu Wielodziedziczenie lub kopiowanie kodu
33 Diagram pakietów przykład
34 Diagram komponentów Odpowiada na pytanie jakie komponenty należą do jakich pakietów Definicja Organizacji komponentów Powiązań między komponentami Uwaga! Bardzo podobny do diagramu struktury komponentów Główna różnica: poziom detaliczności
35 Elementy diagramu komponentów Komponent (component) Moduł systemu Podkomponent (component into a component) Klasa (class) Klasa w komponencie (class into a component)
36 Elementy diagramu komponentów Port w komponencie (port on a component) Służy interakcji komponentu ze środowiskiem Np.: komponentami zewnętrznymi względem systemu Port w klasie (port on a class) jw. ale interakcja z klasą Interfejs (interface) Kontrakt spełniony przez implementujące klasy
37 Relacje diagramu komponentów Użycie (usage) Komponent wykorzystuje funkcjonalność innego Zależność (dependency) Komponent jest zależny od funkcjonalności innego Nie musi to być bezpośrednie użycie
38 Relacje diagramu komponentów Realizacja komponentu (component realization) Delegacja realizacji funkcjonalności komponentu do innych komponentów Przykład: Component4 realizuje funkcjonalność Component5 Realizacja interfejsu (interface realization) Delegacja realizacji funkcjonalności interfejsu do innych komponentów
39 Relacje diagramu komponentów Generalizacja (generalization) Wykorzystywane w dziedziczeniu Redefinicja (redefined) Wskazanie na port klasy korzystający z portu komponentu
40 Uniwersalne zastosowanie interfejsów Jako interfejsów portów Żądanie komponentu o interfejsie Implementacja interfejsu Jako interfejsów komponentów
41 Uniwersalne zastosowanie klas Jako samodzielny komponent Jako element komponentu
42 Powiązania między komponentami Na poziomie komponentów
43 Powiązania między komponentami Przez delegację do podkomponentów i klas
44 Diagram komponentów przykład
45 Diagram wdrożenia Odpowiada na pytanie, jak wygląda docelowe środowisko pracy systemu Definiuje Zewnętrzne komponenty i systemy Ich interfejsy dostępowe Powiązania z komponentami systemu
46 Elementy diagramu wdrożenia Węzeł (node) Fizyczny element systemu Urządzenie (device) Fizyczne urządzenie posiadające zdolność do przetwarzania informacji Środowisko uruchomieniowe (execution environment) Miejsce wdrożenia artefaktów Artefakt (artifact) Informacja używana lub utworzona przez system
47 Relacje diagramu wdrożenia Połączenie (link) Zależność (dependency)
48 Relacje diagramu wdrożenia Generalizacja między artefaktami Generalizacja między węzłami
49 Relacje diagramu wdrożenia Wdrożenie (deployment) Umieszczenie artefaktu w środowisku obliczeniowym
50 Relacje diagramu wdrożenia Manifestacja (manifestation) Publikacja manifestu (opisu) komponentu/artefaktu Interfejsy Żądania interfejsów Dostępna funkcjonalność Zawartość
51
52 Przygotowanie do implementacji Wysokopoziomowa specyfikacja systemu jest gotowa Kolej na specyfikacje szczegółów implementacyjnych Jak zorganizować logikę przetwarzania? W jakich stanach elementy logiki mogą się znaleźć?
53 Diagram klas Odpowiada na pytania Jakie klasy znajdują się w poszczególnych komponentach? Za co są one odpowiedzialne? Jakimi relacjami są powiązane? Najlepiej rozpoznawalny/najpopularniejszy typ diagramu Dużo narzędzi do automatyzacji tworzenia z kodu Lub tworzenia kodu na podstawie diagramu
54 Elementy diagramu klas Typ danych (datatype) Wyliczenie (enumeration) Typ danych o skończonym, ustalonym zbiorze wartości nominalnych Typ prosty (primitive type) Liczba, struktura itp.
55 Elementy diagramu klas Klasa (class) Reprezentacja typu obiektu Nazwy klas abstrakcyjnych zapisane kursywą Klasa generyczna (generic class) Klasa parametryzowana przez inny typ Interfejs (interface) Kontrakt służący Żądaniu określonej funkcjonalności Zapewnieniu określonej funkcjonalności Pakiet (package) Przestrzeń nazw Służy grupowaniu klas o zbliżonym zastosowaniu
56 Specyfikacja pól klasy/interfejsu Format deklaracji pola: # name : type [multiplicity] Modyfikator widoczności: + public # protected - private / derived (read only) ~ package (internal) Nazwa pola Typ pola Multiplikatywność: [1] stała wartość [0..5] zakres [*] * oznacza dowolnie wiele [0..*] jw.
57 Specyfikacja metod klasy/interfejsu Format deklaracji metody: # name (argument: type) : type Modyfikator widoczności: Nazwa argumentu Typ zwracany + public # protected - private Nazwa metody Typ argumentu / derived (read only) ~ package (internal)
58 Relacje diagramu klas Źródło: Yanpas - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=48015014
59 Powiązanie (association) Specyfikacja Nazwy relacji Multiplikatywności relacji Rola/nazwa pola w klasie przechowującego obiekty drugiej klasy Opcjonalnego kierunku Nie należy osobno specyfikować pól w klasie! 1 lub więcej autorów Profesor napisał 0 lub więcej książek
60 Dziedziczenie/implementacja interfejsu Specyfikacja dziedziczenia między klasami Klasa dziedzicząca otrzymuje pola i metody klasy bazowej Implementacja interfejsu oznaczona przerywaną linią Źródło: Noodlez84 - Own work, Public Domain, https://commons.wikimedia.org/w/index.php?curid=659677
61 Ogólna zależność Wykorzystanie klasy przez inną klasę W sposób nieodpowiadający innym rodzajom relacji Np.: jako zmienna lokalna w metodzie Źródło: Samirsyed - Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=4667245
62 Agregacja (aggregation) Relacja typu część całość Obiekt jednej klasy (część) jest elementem innej klasy (całość) W implementacji nierozróżnialne z asocjacją Używane do modelowania sztucznych relacji Np.: Kolekcja instancji innych klas Brak silnego powiązania konkretnych instancji klas w kolekcji z kolekcją
63 Kompozycja (composition) Relacja typu część całość Cechy podobne do agregacji Ale: używane do modelowania powiązań między fizycznie istniejącymi obiektami, reprezentowanymi przez klasy
64 Diagram klas przykład
65 Diagram klas lepszy przykład Źródło: http://www.uml-diagrams.org/class-diagrams-overview.html
66 Diagram maszyny stanów Odpowiada w jakich stanach może znaleźć się element systemu Specyfikacja Stanów Możliwych przejść między stanami Warunków przejść między stanami
67
68 Diagram sekwencji Podobne zastosowania do maszyny stanów Ale (zasadniczo) prezentują jeden przebieg przetwarzania
69
70 Operacja opcjonalna Alternatywne przebiegi przetwarzania
71 Narzędzia wspierające UML UML Designer http://www.umldesigner.org/ Visual Studio Generowanie kodu na podstawie UML Generowanie UML na podstawie kodu Microsoft Visio
72 Wnioski UML umożliwia modelowanie systemu Z wielu perspektyw Diagramy struktury i zachowania Na wielu poziomach szczegółowości Każdy diagramu pozwala na pominięcie pewnych elementów Uproszczenia zapewniają elastyczność w implementacji, ale powodują, że specyfikacja wymagań jest niepełna Pewne elementy różnych diagramów są wizualnie zgodne Np.: relacje użycia, generalizacji, zależności itp.
73 Bibliografia Unified Modeling Language, Wikipedia, https://en.wikipedia.org/wiki/unified_modeling_language The Unified Modeling Language http://www.uml-diagrams.org/ UML Designer User Guide, Reference Documentation http://www.umldesigner.org/ref-doc/define-theapplication.html
74 Dziękuję za uwagę Proszę o pytania