UML rozszerzenie Seminarium magisterskie

Prezentacja na temat: "UML rozszerzenie Seminarium magisterskie"— Zapis prezentacji:

1 UML rozszerzenie Seminarium magisterskie
„Zagadnienia programowania obiektowego” Marzena Szałas

2 Statyczna struktura systemu
diagram klas; diagram obiektów; diagram komponentów; diagram wdrożenia.

3 Diagram klas

4 Diagram klas - notacja KLASA
pole nazwy klasy (rzeczownik w liczbie pojedynczej). Nazwa klasy może być poprzedzona nazwą pakietu (wtedy nazwa ścieżkowa) pole atrybutów (opcjonalne). Można podać typ, wartość początkową oraz dostępność (czyli: ‘+’ – publiczny, ‘-’ – prywatny, ‘#’ – chroniony). pole operacji (opcjonalne) – czasownik lub wyrażenie opisujące pewne zachowanie danej klasy. Można dokładniej określić podając domyślne wartości wszystkich parametrów, a także (w przypadku funkcji) z typu przekazywanej wartości. ZWIĄZEK jest relacją między elementami; najważniejsze rodzaje to: zależność, uogólnienie i powiązanie.

5 ASOCJACJA/POWIĄZANIE
Diagram klas – notacja ASOCJACJA/POWIĄZANIE nazwa krotność/liczebność kierunek nazwy nazwa roli reprezentuje związki między instancjami klas; posiada dwa punkty końcowe (często nazywane rolami), które mogą być opisane etykietą, która określa nazwę roli; może mieć nazwę. Nazwy powinny być nadawane tylko wtedy, gdy diagram jest dzięki temu bardziej zrozumiały. Można również podać kierunek odczytu; punkt końcowy ma krotność (określa ile obiektów może brać udział w danym związku). Przykładowa liczebność: 1, 0..1, 0..n, 1..n, 5; nawigowalność (jednokierunkowa lub dwukierunkowa). Asocjacji bez strzałek należy traktować jako dwukierunkowe bądź o nieznanej nawigowalności (kwestia umowna); klasy asocjacyjne pozwalają na dodanie atrybutów, operacji i innych elementów do asocjacji. Między dwoma obiektami połączonymi asocjacją może istnieć tylko jedna instancja klasy asocjacyjnej

6 AGRAGACJA I ZAWIERANIE
Diagram klas - notacja AGRAGACJA I ZAWIERANIE agregacja to szczególny przypadek asocjacji, wyrażającym zależność całość–część między agregatem (całością) a składnikiem (częścią); nie istnieje powszechnie akceptowana definicja agregacji. UML zawiera agregację, ale nie mówi wiele na jej temat; zawieranie (inaczej: kompozycja, agregacja całkowita) jest silniejszą wersją agregacji; kompozycja: cykl życiowy składowej zawiera się w cyklu życiowym całości (czyli: części żyją i umierają wraz z całością) i składowa nie może być współdzielona (czyli: obiekt będący częścią mogą należeć wyłącznie do jednej całości); całość agregacja całkowita agregacja część

7 Diagram klas - notacja ZALEŻNOŚĆ związek użycia;
należy używać kiedy chce się podkreślić, że jeden element używa drugiego; przedstawia się jako linia przerywana za grotem skierowanym na element, od którego coś zależy; może posiadać nazwę (gdy model ma wiele zależności – konieczne, wpp nie).

8 Diagram klas - notacja UOGÓLNIENIE
klasa podstawowa uogólnienie relacja/związek między klasą ogólną a szczegółową („podklasa-nadklasa” lub „potomek-przodek”); potomek dziedziczy wszystkie właściwości przodka (w szczególności atrybuty i operacje). Może posiadać również własne cechy; operacja potomka mająca tę samą sygnaturę co operacja przodka jest ważniejsza – jest to POLIMORFIZM; przedstawiane jest jako linia ciągła zakończona zamkniętym, niewypełnionym grotem wskazującym przodka; jeśli klasa ma jednego przodka – dziedziczenie pojedyncze, wpp – wielodziedziczenie; używa się w celu przedstawienia dziedziczenia; może posiadać nazwę (gdy model ma wiele uogólnień – konieczne). liść

9 Diagram obiektów

10 Diagram obiektów - notacja
przedstawia egzemplarze elementów z diagramu klas; obrazuje zbiór obiektów i ich związków w danej chwili; często nazywany jest diagramem instancji (przedstawia instancje klas a nie same klasy); zawiera na ogół: obiekty, wiązania, notatki, ograniczenia, pakiety, podsystemy, klasy. Diagram klas elementów struktury organizacyjnej Diagram obiektów pokazujący instancje elementów struktury organizacyjnej

11 Diagram komponentów

12 Diagram komponentów - notacja
komponent – reprezentuje jeden fizyczny moduł kodu. Często jest to jeden pakiet, ale nie zawsze istnieje taka jednoznaczna odpowiedniość. Komponent musi posiadać nazwę, wyróżniającą go spośród pozostałych (gdy jest poprzedzony nazwą otaczającego pakietu, wtedy jest to nazwa ścieżkowa, wpp nazwa prosta). Można je grupować w pakiety. Dostępne są również wszystkie rozszerzenia, w tym: metki (definiujące nowe właściwości komponentu, np. określające numer wersji) oraz stereotypy (definiują nowe rodzaje komponentów. W UML zdefiniowane są następujące stereotypy komponentów: executable – określa komponent, który można wykonać na węźle; library – określa dynamiczną lub statyczną bibliotekę obiektów; table – określa komponent reprezentujący tabelę bazy danych; file – określa komponent reprezentujący dokument zawierający kod źródłowy lub dane; document – określa komponent reprezentujący dokument; zależność – występuje między komponentami. Pokazuje jak zmiany dotyczące jednego komponentu wpływają na inne. Można używać zarówno zależności komunikacyjnych, jak i kompilacyjnych;

13 Diagram komponentów - notacja
interfejs nazwany zależność Komponent opatrzony stereotypem „database” interfejs bez nazwy komponent diagram komponentów jest przedstawiany jako graf, gdzie węzłami są komponenty, zaś strzałki (z przerywaną linią - zależności) prowadzą od klienta pewnej informacji do jej dostawcy; dobrze skonstruowany komponent korzysta z innych komponentów wyłącznie za pośrednictwem ich interfejsów, co z założenia ułatwia przyszłe modyfikacje.

14 Diagram wdrożenia

15 Diagram wdrożenia pokazuje konfigurację elementów czasu wykonania:
komponentów sprzętowych, czyli fizycznych jednostek posiadających co najmniej pamięć, a często i możliwości obliczeniowe; komponentów oprogramowania; związanych z nimi obiektów; jest grafem, gdzie wierzchołki (węzły) połączone są przez linie odwzorowujące połączenia komunikacyjne komponentów sprzętowych. Węzły, podobnie jak połączenia komunikacyjne, mogą być opatrzone stereotypami, np.: «CPU», «pamięć», «inne_urządzenie». Węzły przechowują wystąpienia obiektów i komponentów. Mogą brać udział w związkach generalizacji; zwany jest też diagramem instalacji;

16 Dynamiczne zachowania systemu
diagram przypadków użycia; diagram interakcji: diagram sekwencji; diagram współdziałania; diagram czynności; diagram stanów.

17 Dynamiczne zachowania systemu
Prosta reguła na wykorzystywanie diagramów dynamicznych w procesie modelowania zachowań: jeden obiekt, wiele przypadków użycia - diagramy stanu; wiele obiektów, jeden przypadek użycia - diagramy interakcji; wiele obiektów, wiele przypadków użycia - diagramy aktywności;

18 Diagram przypadków użycia

19 Diagram przypadków użycia - notacja
Przypadek użycia – musi mieć nazwę unikalną, wyróżniającą go spośród innych przypadków. Jeśli jest tylko nazwa, wtedy mówimy o ‘nazwie prostej’, wpp o ‘nazwie ścieżkowej’ (nazwa jest poprzedzona nazwą pakietu: Nazwa_pakietu::nazwa). Problem: czy lepiej używać nazwę opisującą czynność (dodanie odbiorcy) czy polecenie (dodaj odbiorcę)? Aktor – musi mieć unikalną nazwę. Można zdefiniować zarówno ogólne rodzaje aktorów, jak i uszczegółowienia. Aktorem może być osoba, organizacja lub system komputerowy. Związek – pokazuje związek między przypadkiem użycia a aktorem Blok ponownego użycia - przedstawia fragment systemu, który jest używany przez kilka przypadków użycia. Może być oznaczony jako samodzielny przypadek użycia. weryfikacja klienta

20 Diagram przypadków użycia - notacja
Relacja (typu «include» lub «extend») - pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia. «include» - wskazuje na wspólny fragment wielu przypadków użycia. Wykorzystywane w przebiegach podstawowych (operacje zawsze wykonywane) «extend» - strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (operacje nie zawsze wykonywane) System obsługi klienta Nazwa systemu wraz z otoczeniem systemu - pokazuje granicę pomiędzy systemem a jego otoczeniem. wnętrze systemu

21 Diagram interakcji

22 Diagram interakcji opisują jak współpracują ze sobą grupy obiektów;
zazwyczaj przedstawia zachowanie systemu dotyczące jednego przypadku użycia; przedstawia kilka przykładowych obiektów i komunikaty przez nie wymieniane w ramach przypadku użycia; istnieją dwa rodzaje: diagram sekwencji (przebiegu) – lepiej przedstawiają zależności czasowe, bardziej niż diagramy kolaboracji nadają się do modelowania systemów czasu rzeczywistego i złożonych scenariuszy; diagram współdziałania (współpracy, kolaboracji) – lepiej przedstawiają związki między obiektami biorącymi udział w realizacji danego przypadku użycia. Łatwiej też można tu odwzorować efekty oddziaływania na pojedynczy obiekt; niektóre narzędzia CASE potrafią wykorzystać te diagramy do generacji kodu;

23 Diagram sekwencji - notacja
obiekty ośrodek sterowania C Z A S utworzenie linia życia powrót komunikat usunięcie

24 Diagram sekwencji - notacja
na diagramach sekwencji możliwe jest (w przeciwieństwie do diagramów współdziałania) graficzne zaprezentowanie przepływu czasu, a nawet podawanie ograniczeń czasowych, czy też skali czasowej. Taka możliwość może mieć duże znaczenie dla opisu systemów czasu rzeczywistego; czasami przydaje się uwidocznienie wartości zwracanej przez komunikat, poprzez instrukcję przypisania (np.: ‘wMagazynie:=sprawdz()’). Umożliwia to późniejsze wykorzystanie tej wartości, np. jako argumentu dla innego komunikatu. Może też być wykorzystana do specyfikowania warunku czy iteracji; musi być wyspecyfikowane, kto jest odpowiedzialny za usuwanie obiektów;

25 Diagram współdziałania - notacja
wiązanie obiekt stereotyp ścieżki komunikat kolejność współpracujące obiekty są połączone liniami, które odpowiadają powiązaniom, czyli wystąpieniom asocjacji z diagramu klas, a to oznacza, że odpowiednia asocjacja musi istnieć na diagramie klas; komunikaty mogą być numerowane, albo kolejnymi liczbami naturalnymi (jak na poprzednim diagramie), albo stosując tzw. numerację zagnieżdżoną. W obu przypadkach, z reguły, nie bierze się pod uwagę komunikatu wysyłanego od aktora; Obiekt, adresat komunikatu, musi go rozumieć, co oznacza, że klasa której jest wystąpieniem musi dostarczyć (definiować) tę operację;

26 WSPÓŁBIEŻNOŚĆ NA DIAGRAMACH INTERAKCJI
Diagram interakcji WSPÓŁBIEŻNOŚĆ NA DIAGRAMACH INTERAKCJI dla interakcji sekwencyjnych nadawca komunikatu oczekuje na odpowiedź odbiorcy zawieszając własną działalność w trakcie oczekiwania. W danym momencie czasu działa tylko jeden obiekt i wysyłany może być tylko jeden komunikat. Takie systemy nazywane są też czasami proceduralnymi lub jednowątkowymi; notacja dla oznaczenia współbieżności: interakcja synchroniczna – nadawca zawiesza działanie, dopóki odbiorca nie zwróci sterowania. Można to oznaczyć wykorzystując symbol powrotu; powrót – nie jest komunikatem. Oznacza zakończenie komunikatu i przekazanie sterowania do nadawcy; interakcja płaska – nadawca komunikatu przekazuje sterowanie do odbiorcy oraz kończy własną działalność nie oczekując na odpowiedź; interakcja asynchroniczna – nadawca komunikatu nie oczekuje na odpowiedź odbiorcy, ale też i nie kończy własnej aktywności, co oznacza, że nadal przetwarza i może wysyłać komunikaty;

27 Diagram czynności

28 Diagram czynności kiedy używać:
do analizowania przypadków użycia - gdy interesują nas bardziej operacje niezbędne do realizacji danego przypadku (czy też wzajemne zależności między tymi operacjami), a nie to, kto jest odpowiedzialny za ich przeprowadzenie; do zrozumienia interakcji zachodzących między przypadkami użycia; do modelowania przetwarzania wielowątkowego; kiedy nie używać: do pokazywania współpracy między obiektami w trakcie realizacji przypadku użycia – do tego bardziej nadają się diagramy interakcji; do pokazywania zachowań obiektów w trakcie ich życia, w tym celu powinno się wykorzystywać diagramy stanów;

29 Diagram czynności - notacja
czynność (stan czynności) – stan działania lub działalności, wykonanie pewnego rzeczywistego procesu lub wykonywanie procedury programistycznej; przejście – z reguły oznacza zakończenie aktywności, może być opatrzone warunkiem, może też być oznaczone symbolem iteracji. Akcje opisujące przejścia powinny być raczej dołączone do którejś z aktywności; rozgałęzienie który może rozdzielać jedno przejście na kilka innych (opatrzonych warunkami) lub łączyć kilka alternatywnych przejść w jedno; rozwidlenie rozwidlenie lub złączenie– rozwidlenie ma jedno wejście i kilka wyjść. Kiedy jest odpalane wejście, to są wybierane równolegle wszystkie wyjścia. Czynności mogą zachodzić współbieżnie, ich kolejność jest nieważna złączenie stan początkowy stan końcowy

30 Diagram czynności - notacja
TOR tor służą do dzielenia stanów czynności na grupy, z których każda reprezentuje jednostkę odpowiedzialną za przydzielone czynności; każdy tor ma nazwę, unikatową w obrębie jednego diagramu; na diagramie podzielonym na tory każda czynność należy do dokładnie jednego toru, ale przyjścia mogą przecinać granice torów;

31 Diagram stanu

32 Diagram stanu - notacja
opisuje wszystkie możliwe stany, do których może przejść dany obiekt oraz jak zmienia się stan obiektu pod wpływem zdarzeń do niego docierających; stan obiektu trwa w czasie aż do momentu zajścia zdarzenia, które spowoduje zmianę aktualnego stanu na inny; stan może mieć nazwę, ale często jest charakteryzowany jedynie poprzez wewnętrzne operacje; STAN stan estry – każda akcja stowarzyszona ze zdarzeniem entry jest wykonywana przy każdym wejściu do stanu exit - akcja stowarzyszona ze zdarzeniem exit jest wykonywana przy każdym wyjściu ze stanu do/czynność – wykonanie czynności w trakcie, wskazanej za pomocą etykiety

33 Diagram stanu - notacja
Różne rodzaje stanów: stan prosty – stan nie posiadający substruktury złożony sekwencyjnie – złożony z jednego lub więcej podstanów, z których tylko jeden jest aktywny, gdy aktywny jest stan złożony podzielony na dwa lub więcej współbieżnych podstanów; wszystkie podstany są jednocześnie aktywne, gdy aktywny jest stan złożony (jako całość) pseudostan służący do oznaczenia punktu startowego pseudostan służący do oznaczenia punktu finalnego

34 Diagram stanu - notacja
PRZEJŚCIA przejście zewnętrzne przejście wewnętrzne zdarzenie [warunek] / akcja samoprzejście przejście automatyczne (wszystkie operacje wyspecyfikowane po słowach kluczowych ‘entry’, ‘exit’ i ‘do’ zostały ukończone) Rodzaje zdarzeń: otrzymanie przez obiekt synchronicznego żądania wykonania operacji – podstawowe; wygenerowane po upływie pewnego czasu, oznaczane słowem kluczowym ‘after’; wygenerowane po spełnieniu pewnego warunku, oznaczane słowem kluczowym ‘when’; otrzymania przez obiekt asynchronicznego żądania wykonania operacji – sygnał;

35 Diagram stanu - notacja
STAN ZŁOŻONY SEKWENCYJNIE każdy z podstanów dziedziczy przejścia nadstanu; tylko jeden z podstanów może być aktywny w danym momencie.

36 Diagram stanu - notacja
STAN ZŁOŻONY WSPÓŁBIEŻNIE rodzajem stanów złożonych są stany składające się ze współbieżnych podstanów; synchronizacja wewnętrzna: Wyjście ze stanu - w typowej sytuacji - następuje wtedy, gdy we wszystkich podstanach został osiągnięty ich stan końcowy Oba diagramy są równoważne synchronizacja zewnętrzna:

37 Organizacja modelu diagram pakietów; diagram podsystemów.

38 Diagram pakietów

39 Diagram pakietów stosowanie pakietów znacząco ułatwia zarządzanie przechowywaniem, konfiguracjami czy modyfikowaniem elementów systemu; dobrze przeprowadzony podział na pakiety może znacząco ułatwić zarządzanie procesem konstrukcji produktu programistycznego; pakiety są zestawami elementów danego modelu wraz z zachodzącymi pomiędzy nimi zależnościami; każdy element modelu musi być przypisany do jednego pakietu; dany model może być opisany przez zbiór pakietów; pakiety zawierają elementy tzw. wysokiego poziomu, takie jak np.: klasy i ich związki, maszyny stanu, grafy przypadków użycia, itp.; gdy pakiet jest niszczony, giną również wszystkie jego składniki;

40 Diagram pakietów pakiety mogą być zagnieżdżane;
zależności pomiędzy pakietami (wynikające z zależności między elementami w nich zawartymi) są przedstawiane na diagramach pakietów w postaci strzałki z przerywaną linią. Strzałki zaznaczają przepływ informacji pomiędzy pakietami; pakiety mogą brać udział w związkach dziedziczenia; pakiety mogą być opatrywane stereotypami i listami własności etykietowanych; diagramy pakietów są istotne przede wszystkim dla dużych projektów, składających się z wielu jednostek funkcjonalnych (ze złożonymi zależnościami pomiędzy tymi jednostkami) oraz tworzonych przez grupę współpracujących osób;

41 Diagram pakietów - notacja
każdy pakiet musi mieć nazwę, wyróżniającą go spośród pozostałych. Jeśli jest poprzedzona nazwą pakietu otaczającego ten pakiet, to jest to ‘nazwa ścieżkowa’, wpp ‘nazwa prosta’; widoczność składników pakietu: byt będący własnością danego pakietu jest publiczny, czyli dostępny dla zawartości dowolnego pakietu importującego ten pakiet (ozn. ‘+’); byt chroniony może być widziany jedynie przez potomków (ozn. ‘-’); byt prywatny nie może być w ogóle widziany na zewnątrz pakietu, w którym jest zadeklarowany (ozn. ‘#’);

42 Diagram pakietów - notacja
wszystkie mechanizmy rozszerzenia (metki, stereotypy) dotyczą również pakietów. Pięć zdefiniowanych, standardowych stereotypów pakietów: facade – zawiera wyłącznie odwołania do elementów zdefiniowanych w innych pakietach; framework – określa pakiet składający się głównie ze wzorców; strub – określa pakiet będący pełnomocnikiem publicznej zawartości innego pakietu; subsystem – określa pakiet reprezentujący niezależną część całego modelowanego systemu; system – określa pakiet reprezentujący cały modelowany system; są zdefiniowane dwa rodzaje związków między pakietami: uogólnienia – służą do budowania rodzin pakietów; zależności ‘import’ i ‘access’ – używane do importowania do jednego pakietu bytów eksportowanych z innego pakietu;

43 Literatura oraz źródła diagramów
G.Booch, J.Rumbaugh, I.Jacobson – „UML przewodnik użytkownika”; M. Fowler, K.Scott – „UML w kropelce”; E. Stemposz – wykłady z sieci; strony WWW.