diagrams) Diagramy czynności (Activity

Transkrypt

1 Diagramy czynności (Activity diagrams) Diagram czynności przedstawia przepływ sterowania od czynności do czynności. Czynność jest wieloetapowym działaniem wykonanym na maszynie stanowej. Wynikiem jest akcja, składająca się z niepodzielnych obliczeń prowadzących do zmiany stanu, lub przekazania wartości. Przykłady akcji: wywołanie operacji, wysłanie sygnału, utworzenie lub zniszczenie obiektu, wyznaczenie wartości wyrażenia arytmetycznego. Innymi słowy diagram czynności jest schematem blokowym przedstawiającym czynności wykonywane w miarę upływu czasu (pewna analogia do sieci PERT). (c) Radosław Klimek 1 (c) Radosław Klimek 2 Zawartość diagramów: 1. Stany akcji i czynności 2. Przejścia 3. Obiekty Akcja prosta Podaj cenę robót Index := modify(j) + k; Wyrażenie Rys. Stany akcji Przepływ sterowania w diagramie czynności składa się z wielu zdarzeń. Zdarzeniem może być obliczenie wartości wyrażenia (wartość przekazana do otoczenia lub wartość atrybutu), wywołanie operacji obiektu, wysłanie sygnału do obiektu, utworzenie lub zniszczenie obiektu. (c) Radosław Klimek 3 (c) Radosław Klimek 4 Turn On Machine Wynikiem czynności jest zdarzenie. matrix.invert(tolerance) Rys. Czynności drive to work Komentarz: akcje są niepodzielne, czynności wieloetepowe i mogą być realizowane przez podmaszyny (inny podgraf czynności). turnon Get Cups light goes out/defer light goes out Pour Coffee Nie pokazano adresu dla zdarzenia. Zazwyczaj ma charakter lokalny. Współbieżne z podgrzewaniem kawy w zewnętrznym obiekcie (coffeepot). Zakończenie czynności jest sygnalizowane przez light goes out. Jeśli to zdarzenie wystąpi przed zakończeniem (Get Cups), to będzie zgubione, stąd należy Je zapamiętać, aby było dostępne - możliwe do skonsumowania. Rys. Zdarzenie opóźnione (c) Radosław Klimek 5 (c) Radosław Klimek 6

2 collect query information współbieżność kopii czynności Calculate total cost [cost < $100] [cost $100] post to search engine * send to each web searcher Charge the account Get authorization sort results by priority Rys. Współbieżność Rys. Rozgałęzienie jako oddzielne przejścia oraz specyfikowane wprost Calculate total cost [cost $100] Get authorization [cost < $100] Charge the account (c) Radosław Klimek 7 (c) Radosław Klimek 8 Get customer name przejście automatyczne Klient Dział sprzedaży Hurtownia Zamów towary Verify customer data Rozwidlenie [existing customer] Verify customer data dozór Kontynuuj pracę Zrealizuj zamówienie Zgromadź towary Wyślij towary Scalanie Get order Odbierz zamówienie Wystaw rachunek Rys. Rozwidlenie (branch) i scalanie (merge) (c) Radosław Klimek 9 Zapłać rachunek Zakończ transakcję Rys. Tory w diagramie czynności (c) Radosław Klimek 10 Przepływ obiektów Tor (swimlanes) ma charakter organizacyjny, gdyż może odpowiadać pewnemu bytowi świata zewnętrznego (np. dział w przedsiębiorstwie), w którym są wykonywane określone czynności. Tory umożliwiają tym samym na symboliczne rozlokowanie tych czynności między poszczególne elementy (działy przedsiębiorstwa). Każdy tor ma nazwę, unikatową w obrębie jednego diagramu. Tor może zatem odpowiadać pewnemu bytowi świata rzeczywistego i może być modelowany przez co najmniej jedną klasę. Słownik czynności z rysunku (poprzedniego) zawiera również klasy Zamówienie Rachunek, których egzemplarze powstają w wyniku określonych czynności. Obiekty te można umieścić na diagramie czynności, łącząc je związkiem zależności z czynnością lub przejściem. Na diagramie można również umieścić zmianę roli, stanu i wartości każdego obiektu. Stan obiektu jest zapisywany w nawiasach kwadratowych tuż pod nazwą obiektu. Podobnie można wpisać wartości atrybutów - w dodatkowej sekcji poniżej nazwy. (c) Radosław Klimek 11 (c) Radosław Klimek 12

3 Klient Dział sprzedaży Hurtownia Zamów towary Zastosowanie Kontynuuj pracę Zrealizuj zamówienie z: Zamówienie [realizowane] Zgromadź towary Wyślij towary Związek zależności Zastosowanie - modelowanie dynamicznych aspektów systemu, w szczególności: 1. Modelowanie przepływu czynności - zwrócenie uwagi na czynności i ich analiza z punktu widzenia aktorów współpracujących z systemem. Odbierz zamówienie Wystaw rachunek z: Zamówienie [zrealizowane] 2. Modelowanie operacji - diagramy pełnią rolę schematów blokowych, w których przedstawia się szczegóły obliczeń. Otoczenie diagramu obejmuje parametry operacji i jej obiekty lokalne. Zapłać rachunek r: Rachunek [nie zapłacony] r: Rachunek [zapłacony] Zakończ transakcję Rys. Przepływ obiektów (c) Radosław Klimek 13 (c) Radosław Klimek 14 Modelowanie przepływu czynności 1. Ustal najważniejsze czynności - nie da się zazwyczaj przedstawić wszystkich. 2. Wybierz elementy przedsiębiorstwa, które winny realizować bardziej złożony przepływ. Mogą to być elementy rzeczywiste lub abstrakcyjne. Utwórz tor dla każdego takiego obiektu. 3. Zidentyfikuj warunki wstępne stanu początkowego i warunki końcowe stanu końcowego dla modelowanego przepływu. W ten sposób łatwiej będzie określić granice przepływu. 4. Wychodząc ze stanu początkowego przepływu zapisuj kolejne czynności i akcje. Obrazuj je odpowiednio w postaci stanów czynności i stanów akcji. 5. Dla akcji złożonych lub zbiorów akcji zdefiniuj stany czynności i dla każdego z nich skojarz oddzielny diagram czynności, który przedstawia zebrane w nim akcje. 6. Zobrazuj przejścia między stanami czynności i stanami akcji. Zacznij od przepływów sekwencyjnych, następnie określ rozgałęzienie, potem rozwidlenia i scalenia. 7. Jeśli w przepływie występują obiekty, to umieść je na diagramie czynności. Uwzględnij zmieniające się atrybuty i stany obiektów. (c) Radosław Klimek 15 (c) Radosław Klimek 16 Modelowanie operacji 1. Rozważ abstrakcje uczestniczące w modelowanej operacji: parametry, atrybuty klasy otaczającej i innych sąsiednich klas. 2. Zidentyfikuj warunki wstępne stanu początkowego i warunki końcowe stanu końcowego modelowanej operacji. Znajdź niezmienniki klasy otaczającej, które muszą być zachowane podczas realizacji operacji. 3. Począwszy od stanu początkowego zapisuj kolejne czynności i akcje oraz przedstawiaj je odpowiednio na diagramie. 4. W miarę potrzeby korzystaj z rozgałęzień do modelowania ścieżek warunkowych i iteracji. 5. Jeśli operacja należy do klasy aktywnej (i tylko wtedy), skorzystaj z rozwidleń i scaleń, modelując tym samym równoległy przepływ sterowania. (c) Radosław Klimek 17

4 Modelowanie z zastosowaniem języka UML Opracowano w Lab. Informatyki AGH (Kraków) Plan Plan 1. Wprowadzenie do UML. 2. Modelowanie struktury. Podstawowe konstrukcje. 3. Klasy i związki. 4. Diagramy i techniki modelowania. 5. Metodologie wytwarzania. 6. Przykłady. (c) Radosław Klimek 1 (c) Radosław Klimek 2 Literatura 1. Booch G., Rumbaugh J., Jacobson I.: The Unified Modeling Language User Guide. Addison-Wesley, 1998, tłum. Na język polski: UML przewodnik użytkownika. WNT Booch G., Rumbaugh J., Jacobson I.: The Unified Modeling Language Reference Manual. Addison-Wesley, Booch G., Rumbaugh J., Jacobson I.: The Unified Software Development Process. Addison-Wesley, G.Schneider, J.P.Winters: Stosowanie przypadków użycia. Wydawnictwa Naukowo-Techniczne, S.S.Alhir: UML. Wprowadzenie. Wydawnictwo Helion, J.Schmuller: UML dla każdego. Wydawnictwo Helion, D.Pilone: UML. Leksykon kieszonkowy. Wydawnictwo Helion, J.Warmer, A.Kleppe: OCL. Precyzyjne modelowanie w UML. Wydawnictwa Naukowo-Techniczne, Douglass B.P.: Doing Hard Time. UML. Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns. Addison- Wesley, Douglas B.D.: Real-Time Design Patterns. Robust Scalable Architecture for Real-Time Systems. Addison-Wesley, D Souza D.F., Wills A.C.: Objects, Components and Frameworks with UML: The Catalysis Approach. Addison-Wesley, Gomaa H.: Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison Wesley & Benjamin Cummings, Górski J. (red.), Inżynieria oprogramowania w projekcie informatycznym, Mikom, Jaszkiewicz A.: Inżynieria oprogramowania, Helion, 1997 (c) Radosław Klimek 3 (c) Radosław Klimek 4 UML 2.0 (2003) UML 1.4 (2000) UML 1.3 (styczeń 1999) UML 1.1 (wrzesień 1997) Modelowanie to najważniejsza czynność sprzyjająca wdrożeniu dobrego oprogramowania. UML 1.0 (styczeń 1997) Modele tworzymy w celu: Lepszego zrozumienia systemu. UML 0.9, 0.91 (1996) Specyfikacji pożądanej struktury i zachowanie systemu. Języki programowania Java Ada-95 C++ Eiffel Smalltalk Simula-67 Inne metody UML 0.8 (1995) Booch 93 OMT-2 Booch 91 OMT-1 OOSE Bazy danych ODMG SQL3 Model Chen a Opisania architektury systemu i panowania nad nią (dekompozycja, upraszczanie, ponowne użycie). Lepszego zarządzania ryzykiem. Rys. Ewolucja metod obiektowych (c) Radosław Klimek 5 (c) Radosław Klimek 6

5 Zasady modelowania [BRJ] Model jest uproszczeniem rzeczywistości. Uproszczenie pozwala pominąć nieistotne szczegóły (dla danego przedsięwzięcia). Z drugiej strony modelowanie winno uwypuklać te cechy, które są istotne z punktu widzenia realizowanego celu (struktura statyczna, własności dynamiczne, aspekty czasowe itp.). 1. Decyzja o wyborze modelu ma istotny wpływ na sposób i jakość rozwiązania problemu. 2. Każdy model może charakteryzować się różnym poziomem szczegółowości. 3. Najlepiej jeśli model odwzorowuje rzeczywistość. 4. Zazwyczaj jeden model nie jest wystarczający. Niewielka liczba możliwie niezależnych modeli jest najlepszym rozwiązaniem przy modelowaniu nietrywialnego systemu. (c) Radosław Klimek 7 (c) Radosław Klimek 8 Wprowadzenie do języka UML Wyróżnia się dwa zasadnicze podejścia do tworzenia modeli oprogramowania: 1. Algorytmiczne podstawowym blokiem jest procedura lub funkcja. Programiści koncentrują się na przepływie sterowania i podziale algorytmów. 2. Obiektowe podstawowym blokiem jest obiekt lub klasa. Język UML jest przeznaczony do: obrazowania dla komunikacji między członkami zespołu, śledzenia (język graficzny) i interpretacji oprogramowania. specyfikowania, tworzenia - inżynieria wprzód i wstecz, dokumentowania: wymagania, architektura, projekt, kod źródłowy, plany projektu, testy, prototypy, kolejne wersje artefaktów powstałych podczas budowania systemu informatycznego. (c) Radosław Klimek 9 (c) Radosław Klimek 10 Artefakt (Artifact) informacja użyta lub wytworzona w czasie produkcji oprogramowania. Podstawowe pojęcia w UML Istniejące zastosowania (dziedzinowo): 1. Systemy informacyjne przedsiębiorstw. 2. Usługi bankowe i finansowe. 3. Telekomunikacja. 4. Transport. 5. Przemysł obronny i lotniczy. 6. Sprzedaż detaliczna. 7. Elektronika i medycyna. 8. Nauka. 9. Rozproszone usługi internetowe. Bloki konstrukcyjne 1. Elementy. 2. Związki powiązania miedzy elementami. 3. Diagramy grupowanie istotnych elementów. (c) Radosław Klimek 11 (c) Radosław Klimek 12

6 Elementy strukturalne Rodzaje elementów w języku UML 1. Strukturalne. 2. Opisu dynamiki (behavioural things). 3. Grupujące. 4. Komentujące. Elementy strukturalne reprezentują składniki fizyczne lub pojęciowe. W modelach są one wyrażone rzeczownikami. Wyróżnia się 7 rodzajów elementów: 1. Klasy (Classes). 2. Interfejsy (Interfaces). 3. Kooperacje (Collaborations). 4. Przypadki użycia (Use cases). 5. Klasy aktywne (Active classes). 6. Komponenty (Components). 7. Węzły (Nodes). (c) Radosław Klimek 13 (c) Radosław Klimek 14 Klasy (Classes) Klasa jest opisem (specyfikacją) zbioru obiektów mających takie same atrybuty, operacje, związki i znaczenie. Klient nazwisko imię adres telefon Przykłady klas Nazwa klasy Atrybuty Operacje Transakcja operacje zatwierdź() wycofaj() powiodłasię() Czujnik wartość liniowa stosunek zmian Faktura Wysyłka pobieranie() raport() reset() zerowanie() włączanie() wyłączanie() Rys. Symbol graficzny klasy Odpowiedzialność Responsibilities - przechowuj informację o realizacji zamówienia dot. wysyłki - śledź stan i lokalizację wysyłanych towarów (c) Radosław Klimek 15 (c) Radosław Klimek 16 Interfejsy (Interfaces) Kooperacje ( (Collaborations) Interfejs określa zestaw operacji wyznaczających usługi oferowane przez klasę lub komponent. Interfejs określa zewnętrznie obserwowalne zachowanie elementu. Jest to zbiór deklaracji (sygnatur) tych obserwowalnych (dostępnych) operacji. Kooperacja określa interakcję, czyli zestaw ról i innych bytów współdziałających w celu wywołania pewnego zespołowego zachowania, niemożliwego do osiągnięcia w pojedynkę. Pojedyncza klasa może brać udział w wielu kooperacjach. Kooperacje reprezentują implementacje wzorców składających się na system. IntPisownia Hierarchia odpowiedzialności Rys. Kooperacja (c) Radosław Klimek 17 (c) Radosław Klimek 18

7 Przypadki użycia ( (Use cases) Klasy aktywne ( (active classes) Przypadek użycia (Use case) jest opisem zbioru ciągów akcji wykonywanych przez system w celu dostarczenia aktorowi obserwowalnego wyniku. Przypadki użycia są realizowane przez kooperacje. Klasa aktywna zawiera obiekty, przy czym w skład każdego z nich wchodzi przynajmniej jeden proces lub wątek. Oznacza, że dowolny obiekt klasy aktywnej może samodzielnie rozpocząć działanie. Wystaw zmówienie EventManager Rys. Przypadek użycia suspend() flush() Rys. Klasa aktywna (c) Radosław Klimek 19 (c) Radosław Klimek 20 Komponenty ( (Components) Komponent jest fizyczną, wymienną częścią systemu, która dostarcza i implementuje pewien zbiór interfejsów. Komponent jest zatem fizycznym opakowaniem elementów logicznych, takich jak klasy, interfejsy, kooperacje. W każdym systemie można w zasadzie spotkać wiele komponentów, np. COM+, Java Beans itp. Węzły ( (nodes) Węzeł jest fizycznym składnikiem działającego systemu. Reprezentuje zasoby systemowe, ma zazwyczaj pamięć i zdolność przetwarzania. Zbiór komponentów może znajdować się w węźle, może również przemieszczać się między węzłami. OrderForm.java Server Rys. Komponent Rys. Węzeł (c) Radosław Klimek 21 (c) Radosław Klimek 22 Opis dynamiki Interakcje (interactions( interactions) Elementy opisu dynamiki modelują zachowanie w czasie i przestrzeni. Są wyrażone czasownikami w opisie tekstowym. Wyróżnia się dwa podstawowe elementy. 1. Interakcje (interactions). 2. Maszyny stanowe (State machines). Interakcja jest działaniem (akcją) wymiany komunikatów między obiektami w pewnym otoczeniu i w określonym celu. Można w ten sposób zdefiniować zachowanie zespołu obiektów, jak również pojedynczą operację. Interakcja składa się z wielu elementów, w tym komunikatów, ciągów akcji (w odpowiedzi na komunikat) i połączeń między obiektami. send Rys. Komunikat z operacją (send) (c) Radosław Klimek 23 (c) Radosław Klimek 24

8 Maszyny stanowe ( (State machines) Maszyna stanowa określa ciąg stanów, jakie obiekt przyjmuje w odpowiedzi na zdarzenia zachodzące w jego otoczeniu. Maszyna stanowa składa się ze stanów (states), przejść (transitions) między stanami, zdarzeń (events), wyzwalających przejścia i czynności (activities) w odpowiedzi na zdarzenia. Elementy grupujące Elementy grupujące odgrywają role organizacyjną. Są to bloki, na które możemy rozłożyć (zdekomponować) dany model. Podstawowym rodzajem jest pakiet. Pakiet służy do grupowania elementów i może zawierać elementy strukturalne, dynamiczne i inne grupujące. Z wykorzystaniem maszyny stanowej można zdefiniować zachowanie pojedynczej klasy lub kooperacji. W odróżnieniu od komponentu (który istnieje w trakcie wykonywania programu), pakiet jest bytem pojęciowym, tzn. ma znaczenie jedynie w trakcie tworzenia oprogramowania. Waiting Rys. Stan Business rules Rys. Pakiet (c) Radosław Klimek 25 (c) Radosław Klimek 26 Elementy komentujące Związki (Relationships) Elementy komentujące (Annotational things) odgrywają w UML role objaśniającą. podstawowym elementem jest notatka (note). Notatka jest to element umożliwiający specyfikowanie dodatkowych ograniczeń i objaśnień skojarzonych z pojedynczym bytem lub grupą bytów. Wyróżnia się cztery rodzaje związków: 1. Zależność (Dependency). 2. Powiązanie (Association). 3. Uogólnienie (Generalization). 4. Realizacja (Realization). return to PID Rys. Notatka Związki służą w UML do łączenia elementów, są zatem podstawowymi elementami konstrukcyjnymi w budowaniu modeli. Wymieniono cztery podstawowe rodzaje związków. W UML są jeszcze inne warianty wspomnianych czterech: uściślenie (refinement), ślad (trace), zawieranie (include), i rozszerzenie (extend). (c) Radosław Klimek 27 (c) Radosław Klimek 28 Zależność (Dependency( Dependency) Powiązanie ( (association) Zależność (Dependency) jest związkiem między dwoma elementami, gdzie zmiany w definicji jednego z nich (niezależnego) mogą mieć wpływ na znaczenie drugiego (zależnego). Powiązanie (Association) jest związkiem strukturalnym, określającym zbiór wiązań między obiektami. Szczególnym przypadkiem powiązania jest agregacja (składanie), która oznacza relację między całością a częściami. Rys. Zależność 0..1 * pracownik pracodawca Rys. Powiązanie (c) Radosław Klimek 29 (c) Radosław Klimek 30

9 Uogólnienie ( (Generalization) Realizacja ( (Realization) Uogólnienie (Generalization) jest związkiem miedzy bytem ogólnym (przodek) a szczegółowym (potomek). Realizacja (Realization) jest to związek między klasyfikatorami, z których jeden określa kontrakt (specyfikację), natomiast drugi zapewnia wywiązanie się (realizację) kontraktu. Jest to związek uogólnienie-uszczegółowienie. Obiekt bytu szczegółowego może być używany w zastępstwie ogólnego. W takim przypadku potomek ma strukturę i zachowanie przodka. Związki tego typu (realizacje) występują najczęściej między interfejsami a klasami lub komponentami oraz między przypadkami użycia a kooperacjami. Rys. Uogólnienie Rys. Realizacja (c) Radosław Klimek 31 (c) Radosław Klimek 32 Diagramy w języku UML Diagram w języku UML jest grafem, gdzie najczęściej wierzchołkami są elementy, a krawędziami związki. Diagram jest pewnego rodzaju rzutem (projekcją) systemu. Pojedynczy diagram daje zatem niepełną informację dotyczącą elementów (bytów) tworzących system. Ten sam byt może występować we wszystkich diagramach. Poszczególne typy diagramów opisują oddzielne perspektywy (punkty widzenia) systemu (podsystemów). W języku UML wyróżnia się 9 rodzajów diagramów: 1. Diagram klas (class diagram). 2. Diagram obiektów (object diagram). 3. Diagram przypadków użycia (usecasediagram). 4. Diagram sekwencji (przebiegu) (sequence diagram). 5. Diagram kooperacji (collaboration diagrams). 6. Diagram stanów (statechart diagram). 7. Diagram czynności (activity diagram). 8. Diagram komponentów (component diagram). 9. Diagram wdrożenia (implementacji) (deployment diagram). (c) Radosław Klimek 33 (c) Radosław Klimek 34 Diagram klas ( (class diagram) W diagramie klas mogą znaleźć się klasy, interfejsy, kooperacje i związki miedzy nimi. Diagram klas odnosi się do statycznych aspektów perspektywy projektowej. Diagram klas uwzględniający klasy aktywne dotyczy statycznych aspektów perspektywy procesowej. Rys. Klasa Okno (c) Radosław Klimek 35 (c) Radosław Klimek 36

10 Diagram obiektów (object( diagram) Diagram przypadków użycia (use case diagram) Diagram obiektów przedstawia obiekty i związki między nimi. Diagram przedstawia statyczny rzut pewnych elementów występujących na diagramie klas. Podobnie jak diagram klas odnosi się do statycznych aspektów perspektywy projektowej lub procesowej. Diagram przypadków użycia przedstawia przypadki użycia, aktorów i związki między nimi. Diagram odnosi się do statycznych aspektów przypadków użycia. Korzystając z niego bierze się jednak pod uwagę przypadki rzeczywiste lub prototypowe. (c) Radosław Klimek 37 (c) Radosław Klimek 38 Biletomat System <<include>> sprzedaj bilety wykonaj zapłatę przypadki użycia <<include>> BiuroTeatru sprzedaż grupowa analizuj sprzedaż Aktor Urzędnik Obsługa bankowa Diagram przebiegu (sekwencji) i diagram kooperacji opisują interakcję. Diagram sekwencji pokazuje kolejność przesyłania komunikatów w czasie. W diagramie kooperacji kładzie się nacisk na organizację strukturalna obiektów wymieniających komunikaty. Oba diagramy są równoważne, tzn. jeden można przekształcać w drugi. Kierownik Rys. Diagram przypadków użycia (c) Radosław Klimek 39 (c) Radosław Klimek 40 : Klient Bankomat : Operator uruchomienie bankomatu ekran oczekiwania na klienta włożenie karty do czytnika zachęta wprowadzenia pinu wprowadzenie pinu identyfikacja klienta wyświetlenie opcji wyboru wybór kwoty do pobrania (stan konta większy niż kwota do pobrania) sprawdzenie stanu konta odpisanie kwoty od rachunku wysunięcie karty z czytnika wysunięcie banknotów przejście w stan oczekiwania ekran oczekiwania na klienta zatrzymanie pracy bankomatu Rys. Diagram kooperacji Rys. Diagram sekwencji (c) Radosław Klimek 41 (c) Radosław Klimek 42

11 Diagram stanów ( (statechart diagram) Stan_1 Stan_2 Diagram stanów przedstawia maszynę stanową składającą się ze stanów, przejść, zdarzeń i czynności. Przedstawia reakcje obiektów na ciągi zdarzeń, nadaje się zatem do modelowania systemów interakcyjnych. Stan_3 Stan_32 Stan_31 H Rys. Diagram stanów Składnia zdarzenia: Nazwa [dozór] / akcje ^ zdarzenia wysyłane Zdarzenie komunikat Przejście jeśli true Wykonanie w trakcie przejścia Wysłanie do innych maszyn w trakcie przejścia (c) Radosław Klimek 43 (c) Radosław Klimek 44 Diagram czynności ( (activity diagram) Akcja_1 Akcja_2 Diagram czynności może być traktowany jako pewna wersja diagramu stanów. Odnosi się do modelowania dynamicznych aspektów systemu. Kładzie się tu nacisk na przepływ sterowania między obiektami. Akcja_5 Akcja_6 Akcja_3 Akcja_7 Akcja_4 Akcja_W e1 Jest przydatny w modelowaniu funkcji systemu. e2 Akcja_S Akcja_8 Rys. Diagram czynności (activity diagram) (c) Radosław Klimek 45 (c) Radosław Klimek 46 Diagram komponentów (component diagram) Komponent_1 Komponent_2 Diagram komponentów pokazuje uporządkowanie komponentów i zależności między nimi. interfejs Odnosi się do statycznych aspektów perspektywy implementacyjnej. Wiąże się ściśle z diagramem klas, gdyż każdemu komponentowi są przypisane pewne klasy, interfejsy i kooperacje. Komponent_3 Rys. Diagram komponentów (c) Radosław Klimek 47 (c) Radosław Klimek 48

12 Diagram wdrożenia (implementacji) (deployment diagram) Węzeł_1 Komponent_2 Diagram wdrożenia opisuje konfigurację poszczególnych węzłów działających w czasie wykonania i zainstalowania na nich komponentów. Odnosi się do statycznych aspektów perspektywy wdrożeniowej. Wiąże się z diagramem komponentów, ponieważ każdy węzeł zawiera co najmniej jeden komponent. Węzeł_2 <<processor>> Komponent_3 Węzeł_3 <<sensor>> Rys. Diagram wdrożenia (c) Radosław Klimek 49 (c) Radosław Klimek 50 Podstawowe mechanizmy języka UML Wyróżnia się podstawowe mechanizmy: 1. Specyfikacje (specifications). 2. Dodatki (adornments). 3. Zasadnicze rozgraniczenia (common divisions). 4. Mechanizmy rozszerzania (extensibility mechanizms). Specyfikacje są znaczeniową platformą UML, która zawiera wszystkie części modeli odpowiednio powiązane ze sobą logicznie. Przyrostowe tworzenie systemu polega na tworzeniu diagramów i dodawaniu szczegółów (specyfikacji). Inżynieria wstecz polega na utworzeniu specyfikacji, a następnie rysowaniu odpowiednich diagramów. (c) Radosław Klimek 51 (c) Radosław Klimek 52 Dodatki ( (adornments) Symbol klasy zawiera nazwę, atrybuty i operacje. Dodatkowe szczegóły można podawać jako tekstowe uzupełnienia podstawowej reprezentacji klasy. Każdy element w notacji UML składa się zatem z symbolu podstawowego i charakterystycznych dla niego dodatków. Zasadnicze rozgraniczenia (common divisions) Z każdym blokiem konstrukcyjnym jest związane rozróżnienie: abstrakcja (klasa) - urzeczywistnienie abstrakcji (obiekt). Podobnie dla przypadków użycia i egzemplarzy przypadków użycia, komponentów, węzłów. Transaction +execute() +rollback() #priority() -timestamp() +operacja publiczna -operacja prywatna # operacja chroniona Rys. Dodatki Klient Nazwisko Imię telefon Kowalski: Klient Nowak Rys. Klasa i obiekty : Klient (c) Radosław Klimek 53 (c) Radosław Klimek 54

13 Podobnie z każdym blokiem konstrukcyjnym można skojarzyć dychotomię typu interfejs-implementacja, gdzie interfejs wyraża deklarację kontraktu (sygnaturę implementacji), natomiast implementacja jest realizacja tego kontraktu. Możemy zatem mówić o operacjach i metodach, które je realizują, jak również przypadkach użycia i realizujących je kooperacjach. Mechanizmy rozszerzania (extensibility mechanizms) lunknown lspelling spellingwizard.dll Rys. Interfejsy i ich implementacja przez komponent spellingwizard.dll UML jest językiem otwartym, jednak rozszerzenia są realizowane kontrolowany sposób. Wyróżnia się 3 mechanizmy rozszerzania: 1. Stereotypy (stereotypes). 2. Metki (tagged values). 3. Ograniczenia (constraints). (c) Radosław Klimek 55 (c) Radosław Klimek 56 Stereotyp umożliwia rozszerzanie słownictwa UML. Można zatem tworzyć nowe bloki wywodzące się z istniejących, lecz specyficzne dla danego zadania. Metka umożliwia rozszerzenie listy własności bloku konstrukcyjnego, np. podanie wersji i autora. Informacje te nie elementarnymi konstrukcjami języka. Przykładem mogą być wyjątki, które wprost nie istnieją jako wyróżnione bloki konstrukcyjne. Będą one traktowane jako standardowe bloki, jeśli będą oznaczone jako stereotypy. Ograniczenie umożliwia dodanie reguł lub modyfikację reguł istniejących. (c) Radosław Klimek 57 (c) Radosław Klimek 58 <<exception>> Overflow stereotyp Rys. Ilustracja rozszerzeń Queue {version = 2.0} put() get() clear() metka {ordered} ograniczenie Modelowanie architektury Słownictwo Funkcjonalność Efektywność Skalowalność Perspektywa projektowa Perspektywa procesowa Perspektywa przypadków użycia Perspektywa implementacyjna Perspektywa wdrożeniowa Rys. Modelowanie architektury systemu Scalanie systemu Zarządzanie konfiguracją Topologia systemu Rozmieszczenie Dostarczenie Instalacja (c) Radosław Klimek 59 (c) Radosław Klimek 60

14 Perspektywa przypadków użycia zachowanie systemu widziane oczyma użytkowników, analityków i osób wykonujących testy. Nie definiuje się rzeczywistej organizacji systemu, lecz opisuje się czynniki wpływające na kształt architektury systemu. Aspekty statyczne diagramy przypadków użycia. Aspekty dynamiczne diagramy interakcji, diagramy stanów, diagramy czynności. Perspektywa projektowa nacisk kładzie się na klasy, interfejsy i kooperacje, które składają się na słownictwo i rozwiązanie danego zadania. Perspektywa ta wspiera specyfikację funkcjonalną usług udostępnianych użytkownikom. Aspekty statyczne diagramy klas i diagramy obiektów. Aspekty dynamiczne diagramy interakcji, diagramy stanów i diagramy czynności. (c) Radosław Klimek 61 (c) Radosław Klimek 62 Perspektywa procesowa zwraca się uwagę na wątki i procesy kształtujące mechanizmy współbieżności w systemie. Dotyczy to głównie efektywności, skalowalności i przepustowości systemu. Aspekty statyczne i dynamiczne wyrażane są diagramami tego samego rodzaju jak w przypadku perspektywy projektowej, przy czym główny nacisk kładzie się na klasy aktywne reprezentujące procesy i wątki. Perspektywa implementacyjna -znaczenie mają komponenty i pliki użyte do scalania i udostępniania systemu fizycznego. Wiąże się z zarządzaniem konfiguracjami poszczególnych wersji systemu, złożonych z rozmaitych komponentów i plików, które można scalić na wiele sposobów, aby otrzymać działający system. Aspekty statyczne wyraża się tu przez diagramy komponentów, a dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności. (c) Radosław Klimek 63 (c) Radosław Klimek 64 UML Telelogic Tau G2 Perspektywa wdrożeniowa kładzie nacisk na węzły, specyfikujące sprzęt, na którym system będzie uruchamiany. Wiąże się głównie z rozmieszczeniem, dostarczeniem i instalacją części systemu fizycznego. Aspekty statyczne wyraża się tu za pomocą diagramów wdrożenia, dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności. (c) Radosław Klimek 65 W wersji UML w Telelogic Tau Generation2 wyróżnia się następujące diagramy: diagramy przypadków użycia (use case diagram) interakcja aktorzy-system, w kontekście pewnego tematu; elementy: aktorzy, przypadki użycia, relacje pomiędzy nimi oraz tematy; diagramy sekwencji (sequence diagram) sekwencja zdarzeń (komunikaty) dla przypadku użycia oraz operacji; diagramy klas (class diagram) - podstawowe klasy występujące w systemie i ich wzajemne relacje (także deklarowanie zawartości pakietów, diagramy pakietów); diagramy struktury (composite structure diagram) definiowanie wewnętrznej struktury klas poprzez ukazanie portów i połączeń pomiędzy nimi, także interfejsy (poprzednio diagramy architektury); diagramy aktywności (activity diagram) modelowanie zachowania poprzez ukazanie przepływu sterowania i danych pomiędzy elementami; (c) Radosław Klimek 66

15 UML Telelogic Tau G2 (c.d.) diagramy komponentów (component diagram) identyfikowanie kluczowych składników systemu (klasy aktywne) oraz modelowanie ich interfejsów (portów) uwaga, jest to pewna różnica w odniesieniu do klasycznego UML a; diagramy rozmieszczenia (deployment diagram) modelowanie architektury czasu wykonania projektowanego systemu, ukazanie fizycznych węzłów (elementów) systemu; diagramy stanowe (statechart diagram) zachowanie klas poprzez dynamikę maszyn stanowych i występujących operacji; diagramy tekstowe (text diagram) definiowanie tekstowe elementów, projektowanie szczegółowe. (c) Radosław Klimek 67