Wykład 5 UML - Unified Modeling Language

Prezentacja na temat: "Wykład 5 UML - Unified Modeling Language"— Zapis prezentacji:

1 Wykład 5 UML - Unified Modeling Language

2 Treść wykładu wprowadzenie do UML cele UML zakres UML
diagramy definiowane przez UML diagramy klas oraz diagramy pakietów diagramy przypadków użycia diagramy sekwencji diagramy współpracy diagramy stanów diagramy wdrożeniowe

3 UML - wprowadzenie Rational Software Corporation
Grady Booch, Ivar Jacobson, James Rumbaugh wykorzystanie metodyk OOAD - Booch OMT - Rambaugh Fusion - Coleman OOSE - Jacobson

4 UML - wprowadzenie c.d. nie jest metodyką analizy i projektowania
nie definiuje procesu rozwoju oprogramowania nie jest wyłącznie składnicą diagramów jest językiem specyfikacji, konstruowania, wizualizacji i dokumentowania dla systemów wykorzystujących oprogramowanie

5 Wady i zalety metodyk poprzedzających UML
OMT - Rumbaugh dobre modelowanie dziedziny przedmiotowej nie modelowane są aspekty użytkowników systemu oraz aspekty implementacji OOAD - Booch dobrze rozwiązane kwestie projektowania, konstrukcji oraz związki z implementacją nie obejmowane są aspekty fazy analizy oraz wymagań użytkowników OOSE - Jacobson dobrze rozwiązane modelowanie związane z użytkownikami oraz zagadnienia związane z cyklem życia systemu nie obejmowane są aspekty związane z z modelowaniem dziedziny przedmiotowej oraz aspekty implementacyjne

6 Cele UML podstawowym celem jest modelowanie systemów z użyciem pojęć obiektowych język modelowania użyteczny zarówno dla ludzi jak i „maszyn” jest notacją pośrednią pomiędzy ludzkim rozumieniem struktury i działania programów a właściwym kodem programów notacja pośrednia jest wymagana do specyfikacji, konstrukcji, wizualizacji i dokumentacji działań związanych z systemami wykorzystującymi oprogramowanie

7 Cele UML c. d. diagramy UML stanowią bezpośrednie powiązanie modelu konceptualnego z wykonywalnymi programami duża skala problemu, modelowanie systemów złożonych utworzenie języka podobnego do języka programowania

8 Zakres UML specyfikacja, konstrukcja, wizualizacja i dokumentacja działań związanych z systemami wykorzystującymi oprogramowanie łączy metodyki Boocha, OMT i OOSE w postaci wspólnego, szeroko stosowanego języka dla użytkowników tych i poprzednich metod systemy współbieżne i rozproszone skupia się na standardzie języka do modelowania a nie na standardzie procesów tworzenia oprogramowania wspólny metamodel unifikacji semantyki oraz wspólna notacja odbioru semantyki przez ludzi

9 Diagramy definiowane przez UML
wiele perspektyw spojrzenia na projektowany system diagram przypadków użycia - use case diagramy klas oraz diagramy pakietów diagramy zachowania - behaviour diagramy stanów diagramy aktywności diagramy sekwencji diagramy współpracy - collaboration diagramy implementacyjne diagramy komponentów diagramy wdrożeniowe - deployment

10 Metamodel oraz semantyka UML
duża uwaga na semantykę notacji wada poprzednich modeli analitycznych wyobrażenie niż formalna konstrukcja modele odwołujące się do wyobrażenia nie mogą być precyzyjne UML wprowadza składnię ograniczenia topologiczne klasyfikację pojęć związki pomiędzy pojęciami

11 UML - stereotypy nazwy umożliwiające meta-klasyfikacje modelu
wspólne nazwy własności klas deklaracja meta-klasy wewnątrz modelu element modelu może mieć co najwyżej jeden stereotyp dla każdego rodzaju elementu UML istnieje lista stereotypów istnieją predefiniowane stereotypy stereotypy mogą mieć implikacje semantyczne tj. ograniczenia

12 Stereotypy - przykłady
klasy i obiekty zdarzenie, wyjątek, interfejs, metaklasa, typy obiektów obiekt istniejący, obiekt sterujący, interfejs zadania proces wątek węzły pakiety

13 Diagram hierarchii procesów – Select Enterprise

14 Diagram wątków procesów

15 Diagram wątków procesów c.d.

16 Diagramy klas odmiana klasycznych diagramów encji
podstawowe oznaczenia klasa - prostokąt hierarchia dziedziczenia - strzałki związki asocjacji - linie związki agregacji - romby oznaczenia przejęte z OMT wprowadzone są rozszerzenia poprawiające czytelność dla konkretnej dziedziny przedmiotowej w postaci stereotypów

17 Wykorzystanie diagramu klas
opis modelu konceptualnego reprezentacja pojęć w dziedzinie przedmiotowej nie musi być związany z oprogramowaniem sformalizowana specyfikacja danych i metod dotyczy oprogramowania zewnętrzny opis interfejsów bez szczegółów implementacyjnych - hermetyzacja określenie zewnętrznych obiektów programistycznych oraz metod implementacja graficzny środek reprezentujący szczegóły implementacji

18 Konstruowanie diagramu klas
identyfikacja obiektów i klas przygotowanie słownika danych identyfikacja związków między obiektami identyfikacja atrybutów obiektów zorganizowanie klas w hierarchie dziedziczenia analiza ścieżek dla zapytań grupowanie klas w moduły

19 Diagram klas

20 Diagramy pakietów zestawy elementów modelu wraz z zachodzącymi między nimi zależnościami odwzorowują przekazywanie informacji z pakietu do pakietu istotne dla dużych projektów składających się z wielu modułów funkcjonalnych ze złożonymi właściwościami między modułami pakiety mogą być zagnieżdżane pakiety mogą być traktowane jako obiekty należące do swoich klas, podlegają związkom dziedziczenia

21 Diagramy pakietów - przykład

22 Diagramy przypadków użycia
przedstawienie użycia systemu będącego przedmiotem projektowania odwzorowują strukturę systemu jak go widzą użytkownicy sprecyzowanie celów tworzenia systemu utworzenie pomostu między użytkownikami a projektantami systemu weryfikacja poprawności i kompletności projektu przedstawienie strukturalnych i funkcjonalnych własności systemu ustalenie składowych systemu i związanego z nim planu budowy systemu podstawa do sporządzenia planu testów systemu

23 Diagram przypadków użycia c. d.
dostarcza abstrakcyjnego poglądu na system tak jak go używają aktorzy nie włącza szczegółów co pozwala wnioskować o systemie na bardzo ogólnym poziomie

24 Dodatkowe elementy diagramu przypadków użycia
jak przypadek użycia się rozpoczyna, jak kończy i w którym momencie opis interakcji przypadku użycia z aktorami, kiedy interakcja ma miejsce i co jest przesyłane kiedy i do czego przypadek potrzebuje danych z systemu a w którym momencie zapamiętuje dane w systemie opis wyjątków przy przepływie zdarzeń jak i kiedy używane są pojęcia z dziedziny przedmiotowej

25 Dokumentacja przypadków użycia
krótki opis przypadku użycia nieformalny opis zdarzeń w systemie opis związków pomiędzy przypadkami użycia obiekty uczestniczące w przypadku użycia specjalne wymagania np. czas odpowiedzi, wydajność obrazy interfejsu użytkownika diagram powiązań przypadków użycia diagramy interakcji dla każdego aktora

26 Wyszukiwanie aktorów na podstawie wymagań funkcjonalnych
grupa użytkowników wspomagana przez system wymagani użytkownicy aby system realizował funkcje z jakim z zewnętrznych źródeł powinien korzystać system aby sprawnie wykonywał swoje funkcje

27 Diagram przypadków użycia – przykład

28 Modele i diagramy dynamiczne
diagramy uwzględniające czas, zdarzenia, następstwo czynności, synchronizację czynności, transakcje, stany procesów, interakcje systemu z otoczeniem, dialogi stosowane notacje diagramy przepływu sterowania diagramy automatów skończonych sieci Petrie’ego powiązane są z innymi modelami poprzez wspólne oznaczenia obiektów oraz procesów uzupełnienie diagramu klas

29 Diagramy sekwencji podobne do diagramów sekwencji zdarzeń
rozbudowane o możliwość wprowadzenia ograniczeń czasowych oraz skali czasowej brak precyzji języków programowania słaby środek specyfikowania programów

30 Diagram sekwencji - przykład

31 Diagram sekwencji – przykład c. d.

32 Diagram sekwencji – przykład c. d.

33 Diagramy współpracy przedstawienie przepływów komunikatów pomiędzy obiektami współpraca między obiektami struktura uczestniczących obiektów sekwencja komunikatów wymienianych między obiektami nie odwzorowywany jest czas lecz powiązania pomiędzy obiektami

34 Diagram współpracy - przykład

35 Diagram stanów automat skończony
stany pewnego procesu istotne z punktu widzenia modelu konceptualnego tego procesu powiązanie pomiędzy stanami wymuszane przez pewne zdarzenia stany są wzbogacone o akcje wykonywane wewnątrz stanów zdarzenia mogą być wykonywane pod pewnymi warunkami

36 Diagram stanów - przykład

37 Diagramy implementacyjne
pokazują niektóre aspekty implementacji systemu informacyjnego struktura kodu źródłowego struktura czasu wykonywania diagram komponentów (component diagram) struktura fizyczna kodu widziana jako komponenty komponent zawiera informację o klasach w nim zaimplementowanych zależności pomiędzy komponentami oprogramowania włączając komponenty kodu źródłowego, kodu binarnego oraz kodu wykonywalnego przeznaczony głównie dla programistów

38 Diagramy implementacyjne c.d.
diagramy organizacji fizycznej (deployment diagram) fizyczne rozmieszczenie komponentów systemu w konkretnych węzłach – komputerach lub innych urządzeniach używanych przez system łączny aspekt systemu opisujący programy i sprzęt końcowe stadium prac projektowych prowadzące do wdrożenia systemu struktura systemu dla czasu wykonywania konfiguracja elementów czasu wykonania: komponentów sprzętowych, komponentów oprogramowania, procesów i związanych z nimi obiektów graf, w którym węzły są elementami czasu wykonywania, połączone poprzez linie odwzorowujące ich połączenia komunikacyjne

39 Proces projektowania aplikacji - SELECT