Unified Modeling Language

Transkrypt

1 Unified Modeling Language Tomasz Pawlak

2 2 Plan prezentacji Wprowadzenie i historia UML Modelowanie z użyciem UML Wybrane diagramy struktury i zachowania Narzędzia wspierające UML

3 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 oraz )

4 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,

5 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 jpg:, CC BY-SA 2.0, James Rumbaugh Ivar Jacobson: By English Wikipedia user Mikemacd, CC BY-SA 3.0,

6 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 7 Historia UML : Object Management Group (OMG) otrzymało wersję roboczą UML : OMG otrzymało wersję : OMG przyjęło wersję 1.1 jako standard : Rozwój wersji : UML standardem ISO/IEC 19501

8 8 Historia UML

9 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 10 Historia UML 2005: UML : UML : UML standardem ISO/IEC i ISO/IEC

11 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 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 13 Źródło:

14 14 Modelowanie z użyciem UML

15 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 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 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 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 19 Elementy diagramu aktywności Parametr aktywności (activity parameter) Parametr procesu biznesowego Trwały magazyn danych (data store)

20 20 Elementy diagramu aktywności Parametr akcji (input pin) Wyjście akcji (output pin)

21 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 22

23 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 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 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 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 27 Diagram przypadków użycia przykład

28 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 29 Elementy diagramu pakietów Pakiet (package)

30 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 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 32 Relacje diagramu pakietów Łączenie (merge) Pakiet staje się częścią innego pakietu Wielodziedziczenie lub kopiowanie kodu

33 33 Diagram pakietów przykład

34 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 35 Elementy diagramu komponentów Komponent (component) Moduł systemu Podkomponent (component into a component) Klasa (class) Klasa w komponencie (class into a component)

36 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 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 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 39 Relacje diagramu komponentów Generalizacja (generalization) Wykorzystywane w dziedziczeniu Redefinicja (redefined) Wskazanie na port klasy korzystający z portu komponentu

40 40 Uniwersalne zastosowanie interfejsów Jako interfejsów portów Żądanie komponentu o interfejsie Implementacja interfejsu Jako interfejsów komponentów

41 41 Uniwersalne zastosowanie klas Jako samodzielny komponent Jako element komponentu

42 42 Powiązania między komponentami Na poziomie komponentów

43 43 Powiązania między komponentami Przez delegację do podkomponentów i klas

44 44 Diagram komponentów przykład

45 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 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 47 Relacje diagramu wdrożenia Połączenie (link) Zależność (dependency)

48 48 Relacje diagramu wdrożenia Generalizacja między artefaktami Generalizacja między węzłami

49 49 Relacje diagramu wdrożenia Wdrożenie (deployment) Umieszczenie artefaktu w środowisku obliczeniowym

50 50 Relacje diagramu wdrożenia Manifestacja (manifestation) Publikacja manifestu (opisu) komponentu/artefaktu Interfejsy Żądania interfejsów Dostępna funkcjonalność Zawartość

51 51

52 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 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 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 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 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 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 58 Relacje diagramu klas Źródło: Yanpas - Own work, CC BY-SA 4.0,

59 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 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,

61 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,

62 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 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 64 Diagram klas przykład

65 65 Diagram klas lepszy przykład Źródło:

66 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 67

68 68 Diagram sekwencji Podobne zastosowania do maszyny stanów Ale (zasadniczo) prezentują jeden przebieg przetwarzania

69 69

70 70 Operacja opcjonalna Alternatywne przebiegi przetwarzania

71 71 Narzędzia wspierające UML UML Designer Visual Studio Generowanie kodu na podstawie UML Generowanie UML na podstawie kodu Microsoft Visio

72 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 73 Bibliografia Unified Modeling Language, Wikipedia, The Unified Modeling Language UML Designer User Guide, Reference Documentation

74 74 Dziękuję za uwagę Proszę o pytania