Wykład 5 UML - Unified Modeling Language

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

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

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

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

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

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

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

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

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

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

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

Diagram hierarchii procesów – Select Enterprise

Diagram wątków procesów

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

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

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

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

Diagram klas

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

Diagramy pakietów - przykład

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

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

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

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

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

Diagram przypadków użycia – przykład

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

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

Diagram sekwencji - przykład

Diagram sekwencji – przykład c. d.

Diagram sekwencji – przykład c. d.

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

Diagram współpracy - przykład

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

Diagram stanów - przykład

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

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

Proces projektowania aplikacji - SELECT