6 Diagramy aktywności

6 Diagramy aktywności 6.1 Wstęp Diagramy aktywności słuŝą przede wszystkim do modelowania przepływów operacji wykonywanych w celu realizacji zadań zlecanych systemowi przez jego aktorów. Diagramy te łączą idee pochodzące z trzech źródeł: diagramów zdarzeń J. Odell a, technik modelowania stanów oraz sieci Petri ego, nie posiadają natomiast wyraźnego pierwowzoru w poprzednich pracach trzech przyjaciół (Jacobson a, Booch a i Rumbaugh a). 6.2 Graf aktywności podstawowe pojęcia Diagram aktywności jest grafem skierowanym, którego wierzchołki stanowią aktywności odpowiadające operacjom wyróŝnianym w trakcie przetwarzania, a łuki opisują przejścia pomiędzy aktywnościami. MoŜna powiedzieć, Ŝe graf aktywności to maszyna stanów, której podstawowym zadaniem nie jest przedstawianie stanów obiektu, jak to ma miejsce w przypadku diagramu stanów, ale modelowanie przepływów sterowania. Pojedynczy stan grafu aktywności aktywność moŝe być interpretowana róŝnie, w zaleŝności od przyjętej perspektywy: z perspektywy pojęciowej jako zadanie do wykonania i to zarówno przez człowieka, jak i przez komputer; z perspektywy projektowej jako grupa metod, pojedyncza metoda czy teŝ nawet fragment metody. Przejścia pomiędzy aktywnościami są związane z zakończeniem przetwarzania wyspecyfikowanego dla danej aktywności. Podstawowe pojęcia wykorzystywane w diagramach aktywności wraz z objaśnieniem ich znaczenia i odpowiednią notacją przedstawione są w Tab. 1. Pojęcie Znaczenie Notacja aktywność stan wyróŝniany w trakcie przetwarzania Activity name wierzchołek danych wierzchołek wykorzystywany do określania danych przesyłanych w trakcie przetwarzania Data name przejście (przepływ sterowania) przepływ danych pojęcie związane z zakończeniem przetwarzania określonego dla jednej aktywności i rozpoczęciem przetwarzania wyspecyfikowanego dla drugiej; przejście rzadko jest opisywane nazwą zdarzenia ale moŝe być opatrzone warunkiem i/lub symbolem iteracji; w etykiecie przejścia nie naleŝy umieszczać akcji lepiej jest dołączyć je albo do aktywności, która jest kończona albo do aktywności, która jest rozpoczynana pojęcie związane z przesyłaniem danych w trakcie przetwarzania

romb decyzyjny rozdziela jedno przejście na kilka innych (opatrzonych warunkami) lub łączy kilka alternatywnych przejść w jedno sztabka synchronizacyjna typu fork rozdzielenie jednego przejścia na kilka przebiegających współbieŝnie sztabka synchronizacyjna typu join aktywność początkowa aktywność końcowa zakończenie przepływu złączenie kilku przejść współbieŝnych w jedno stan oznaczający początek przetwarzania stan oznaczający koniec przetwarzania dla całego grafu stan oznaczający zakończenie jednego przepływu przetwarzania Tab. 1 Pojęcia wykorzystywane w diagramach aktywności 6.3 Wierzchołek z danymi Na diagramach aktywności, oprócz przepływów sterowania, moŝna takŝe oznaczać przepływy danych, gdzie wierzchołek z danymi oznacza taki wierzchołek w grafie aktywności, w którym dostępne jest wystąpienie/wystąpienia określonego klasyfikatora; Wierzchołek z danymi moŝe stanowić daną wejściową dla aktywności (linia przejścia prowadzi wtedy od wierzchołka z danymi do aktywności), albo daną wyjściową (linia przejścia prowadzi od aktywności do wierzchołka z danymi). Na Rys. 1 zilustrowano róŝne sposoby prezentowania wierzchołka z danymi wybranie konkretnego rozwiązania jest uzaleŝnione od poŝądanego stopnia szczegółowości diagramu. Data name Data name : type Data name [state, state,...] Data name Data name Set of data names {upperbound=2} {ordering=lifo} Rys. 1 RóŜne sposoby prezentowania wierzchołka z danymi Dla prezentowania wierzchołków z danymi obowiązują poniŝsze reguły: w czasie run-time u wierzchołek z danymi moŝe zawierać tylko takie dane, które są zgodne z typem danych określonych dla wierzchołka; jeśli typ danych dla wierzchołka nie został określony, wierzchołek moŝe zawierać dane dowolnego typu; wystąpienie/wystąpienia mogą mieć wyspecyfikowane stany;

jest moŝliwe określenie maksymalnej liczby wystąpień, które moŝe zawierać dany wierzchołek; ograniczenie {upperbound=2}; moŝliwe jest wykorzystanie *; ograniczenie {ordering=lifo} jest umieszczane dla uporządkowania wystąpień w wierzchołku innego, niŝ uporządkowanie domyślne FIFO. 6.4 Konstruowanie przejść z wykorzystaniem rombu decyzyjnego i sztabki synchronizacyjnej Przejścia, czyli przepływy sterowania mogą być specyfikowane z wykorzystaniem rombu decyzyjnego (tzw. przejścia decyzyjne) lub sztabki synchronizacyjnej (zwane przejściami współbieŝnymi). Na Rys. 2 i Rys. 4 zilustrowano wykorzystanie rombu decyzyjnego do rozdzielania przejścia/przejść na kilka innych (opatrzonych warunkami; lewy operand wyraŝenia moŝe być umieszczony wewnątrz rombu decyzyjnego Rys. 5), z kolei Rys. 3 przedstawia wykorzystanie rombu decyzyjnego do łączenia kilku alternatywnych przejść w jedno. Sztabka synchronizacyjna moŝe być wykorzystana do rozdzielenie przejścia/przejść na kilka innych przebiegających współbieŝnie (Rys. 6 i Rys. 8) lub do złączenia kilku przejść współbieŝnych w jedno/kilka innych (Rys. 7 i Rys. 8). Przejścia decyzyjne przykłady [1st condition] [2nd condition] [1st condition] [2nd condition] [True] [3rd condition] [else] [False] Rys. 2 Wierzchołek typu decyzja Rys. 3 Wierzchołek typu złączenie [1st condition] [2nd condition] Rys. 4 Wierzchołek typu decyzja + złączenie

[ x = n ] [ = n ] = x [ x > n ] [ > n ] Rys. 5 Dwa sposoby specyfikowania warunków dla przejść decyzyjnych Przejścia współbieŝne przykłady Rys. 6 Wierzchołek typu rozwidlenie Rys. 7 Wierzchołek typu scalenie Rys. 8 Wierzchołek typu scalenie + rozwidlenie 6.5 Podział grafu aktywności na partycje Jedną z ciekawszych własności diagramu aktywności jest moŝliwość przypisania aktywności do osób, komórek organizacyjnych, itd., odpowiedzialnych za jej wykonanie, które z perspektywy pojęciowej odpowiadają klasom na diagramie klas. W tym celu diagram dzielony jest na specjalne regiony zwane partycjami graf moŝe być dzielony zarówno w pionie, jak i w poziomie. Przykładowy diagram aktywności zawierający omówione powyŝej elementy jest przedstawiony na Rys. 9.

Supplier Supply Dep. Depot Deliver assembles Send invoice Delvery [finalized] Book income Delivery [sent] Pick up delivery Delivery [unloaded] Send payment Delivery [received] Place assemblies in depot Rys. 9 Diagram aktywności z oznaczonymi partycjami 6.6 Modelowanie iteracji Iteracje na diagramach aktywności mogą być modelowane albo za pomocą tych samych środków, które są wykorzystywane w przypadku innych rodzajów diagramów dynamicznych, tzn. za pomocą symbolu gwiazdki i warunku specyfikującego zakończenie iteracji (Rys. 10 i Rys. 11), albo za pomocą symbolu rombu decyzyjnego (Rys. 12). ad Service (1) Find specialists, who can repair a given damage * [for all founded specialists] Find 1st available term Find specialist with the best term Make an appointment with chosen specialist Rys. 10 Modelowanie iteracji z wykorzystaniem symbolu gwiazdki i warunku, dla przetwarzania sekwencyjnego

ad Service (2) Find specialists, who can repair a given damage * [for all founded specialists] multiple trigger - all activities run simultaneously Find 1st available term Synchronization of simultaneously run activities Find specialist with the best term Make an appointment with chosen specialist Rys. 11 Modelowanie iteracji z wykorzystaniem symbolu gwiazdki i warunku, dla przetwarzania współbieŝnego, z podkreśleniem informacji o synchronizacji jednocześnie rozpoczętych aktywności

ad Service (3) Find specialists, who can repair a given damage Check, if specialist can repair the damage within the next week cannot/can/all specialist have been checked [cannot] solution with the use of decision diamond [all specialist have been checked] [can] Cancel service Make an appointment with chosen specialist Rys. 12 Modelowanie iteracji z wykorzystaniem symbolu rombu decyzyjnego 6.7 Konstruowanie diagramów aktywności dla wspomagania specyfikacji złoŝonych scenariuszy W celu ilustracji zaleŝności pomiędzy diagramem aktywności, scenariuszem a diagramem przypadków uŝycia rozwaŝmy przypadek uŝycia wypoŝyczenie egzemplarza ksiąŝki dla dziedziny problemowej związanej z organizacją bibliotek. PoniŜej przedstawiamy zapisany w języku naturalnym uproszczony scenariusz dla tego przypadku uŝycia (ściślej: scenariusz główny, wraz ze scenariuszami pobocznymi). Scenariusz jest uproszczony w tym sensie, Ŝe połoŝono tu nacisk na akcje realizowane przez system i nie specyfikowano całości interakcji zachodzących między aktorem a systemem w trakcie realizowania przypadku. Scenariusz: Pobranie danych czytelnika i ksiąŝki Sprawdzenie, czy moŝna wypoŝyczyć danemu czytelnikowi jeŝeli nie moŝna wypoŝyczyć, to Koniec przypadku uŝycia jeŝeli moŝna wypoŝyczyć, to: Sprawdzenie, czy ksiąŝka jest dostępna, tzn. czy jest wolny egzemplarz

jeŝeli Ŝaden egzemplarz ksiąŝki nie jest dostępny, to Koniec przypadku uŝycia jeŝeli egzemplarz ksiąŝki jest dostępny, to: Rejestracja wypoŝyczenia Koniec przypadku uŝycia Na Rys. 13 zamieszczono diagram przypadków uŝycia zgodny z powyŝszym scenariuszem. ud Register rental of a book copy Check, if a reader is allowed to rent a book copy «include» Library staff Rent a book copy «extend» «extend» Check, if any book copy is available Register rental Rys. 13 Diagram przypadków uŝycia dla wypoŝyczenia egzemplarza ksiąŝki Sekwencję aktywności specyfikowanych w scenariuszu moŝna i naleŝy opisywać wykorzystując diagramy aktywności (Rys. 14), które z natury rzeczy lepiej niŝ język naturalny nadają się do opisu złoŝonych przebiegów (z warunkami i/lub iteracjami) i są uŝytecznym narzędziem w procesie modelowania zachowań, zwłaszcza w początkowych etapach analizy.

ad Register rental of a book copy Get a reader and a book data Check, if a reader is allowed to rent a book copy [yes] Check, if any book copy is available [no] [unavailable] [available] Register rental Rys. 14 Diagram aktywności dla wypoŝyczenia egzemplarza ksiąŝki 6.8 Przykład z kancelarią prawniczą PoniŜej umieszczono scenariusz dla przypadku uŝycia Przydziel prawnika do sprawy, który skonstruowano w oparciu o tekst specyfikujący wymagania dla systemu wspierającego pracę kancelarii prawniczej (rozdział 2, podrozdział 2.10) Przepływ główny: 1. Przypadek uŝycia rozpoczyna aktor Szef kancelarii. 2. System odpytuje o dane prawnika i dane sprawy. Szef kancelarii wprowadza potrzebne dane. 3. System rejestruje przydzielenie prawnika do sprawy. Przepływy alternatywne: 2a) Jeśli format wprowadzonych danych jest niepoprawny, to system informuje o błędzie i powraca do punktu 2 przepływu głównego). 2b) Jeśli prawnik jest zleceniodawcą sprawy, do której ma być przydzielony, to system informuje o błędzie i ponownie odpytuje o dane prawnika. 2c) Jeśli prawnik nie jest zleceniodawcą sprawy, ale aktualnie został juŝ przydzielony do innej sprawy, to system informuje o zajętości wybranego prawnika i ponownie odpytuje o dane prawnika. 2d) Jeśli aktor rezygnuje z przydzielenia prawnika do sprawy, system kończy przypadek uŝycia. Diagram aktywności skonstruowany w oparciu o powyŝszy scenariusz jest prezentowany na Rys. 15.

ad Law office Inform about an error Get lawyer s and case s data [incorrect data format] [else] Check, if the selected lawyer is not a customer of the case [is a customer] Inform about an error [else] Register lawyer s assignment [else] Check, if the lawyer is currently assigned to any other case [is assigned] Inform about lawyer s assignment Rys. 15 Diagram aktywności dla przypadku uŝycia Przydziel prawnika do sprawy 6.9 Podsumowanie Diagramy aktywności obrazują przetwarzanie na wysokim poziomie abstrakcji, dlatego są uŝywane głównie jako punkt startowy dla procesu modelowania zachowań, podczas którego kaŝda aktywność jest rozpisywana na szereg operacji. Diagramy aktywności znajdują zastosowanie przede wszystkim w następujących obszarach: Do analizowania przypadków uŝycia gdy bardziej interesują nas operacje niezbędne do realizacji danego przypadku czy teŝ wzajemne zaleŝności między tymi operacjami, niŝ to kto jest odpowiedzialny za przeprowadzenie tych operacji. Operacje są przypisywane do obiektów na etapie późniejszym, z wykorzystaniem diagramów interakcji. Do zrozumienia interakcji zachodzących pomiędzy przypadkami uŝycia. Do modelowania przetwarzania wielowątkowego. Diagramy aktywności nie powinny być uŝywane do opisywania współpracy między obiektami w trakcie realizacji przypadku uŝycia (gdyŝ do tego lepiej nadają się diagramy interakcji), ani do przedstawiania zachowań obiektów w trakcie ich Ŝycia (wtedy powinno się wykorzystywać diagramy stanów). 6.10 Przykładowe pytania i problemy do rozwiązania 1. Krótko omów zasadniczy cel konstruowania diagramów aktywności. 2. Podaj definicje dla następujących pojęć: aktywność, przejście, sztabka synchronizacyjna, romb decyzyjny. 3. Omów, jakie elementy mogą pojawić się w etykiecie przejścia. 4. Omów róŝnicę w wykorzystaniu przepływu sterowania i przepływu danych. Co moŝna ilustrować w oparciu o przepływy danych? 5. Do czego mogą być wykorzystywane partycje w diagramach aktywności?. 6. W jaki sposób moŝna modelować wątki wykorzystując diagramy aktywności?

7. W oparciu o tekst specyfikujący wymagania dla systemu wspierającego pracę wypoŝyczalni płyt dvd (rozdział 2, podrozdział 2.12), wykonaj następujące zadania: Napisz scenariusz dla przypadku uŝycia: zwrot płyty dvd. W oparciu o skonstruowany scenariusz, zbuduj graf aktywności.