Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00181 007342 11068429 na godz. na dobę w sumie
UML 2.0. Wprowadzenie - książka
UML 2.0. Wprowadzenie - książka
Autor: , Liczba stron: 280
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-0632-7 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> uml - programowanie
Porównaj ceny (książka, ebook, audiobook).

Najtrudniejszym etapem każdego procesu tworzenia systemu informatycznego jest wykonanie odpowiedniego projektu. Umiejętność pogodzenia wymagań użytkowników i osób finansujących system z możliwościami oferowanymi przez technologię jest kluczowym elementem sukcesu. Im bardziej złożony system, tym bardziej zawiły staje się projekt. Konieczność ustandaryzowana technik projektowania systemów zaowocowała powstaniem narzędzi, dzięki którym nawet najbardziej skomplikowany projekt można przedstawić w prosty i czytelny sposób. Takim narzędziem jest notacja UML -- zestaw ikon tworzących diagramy opisujące system i jego elementy.

Książka 'UML 2.0. Wprowadzenie' w praktyczny sposób przedstawia techniki modelowania systemów informatycznych za pomocą języka UML 2.0. Czytając ją, nauczysz się graficznie przedstawiać otoczenie systemu, wymagania stawiane przez użytkowników i metody ich implementacji w systemie. Utworzysz diagramy klas, interakcji, komponentów, wdrożenia i inne, które opisują projekt w jednoznaczny oraz prosty sposób. Dowiesz się także, jak zaplanować proces wdrożenia produktu za pomocą UML.

Poznaj nowoczesne metody projektowania systemów informatycznych.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

UML 2.0. Wprowadzenie Russ Miles, Kim Hamilton T³umaczenie: Rafal Szpoton ISBN: 978-83-246-0632-0 Tytu³ orygina³u: Learning UML 2.0 Format: B5, stron: 280 Najtrudniejszym etapem ka¿dego procesu tworzenia systemu informatycznego jest wykonanie odpowiedniego projektu. Umiejêtnoœæ pogodzenia wymagañ u¿ytkowników i osób finansuj¹cych system z mo¿liwoœciami oferowanymi przez technologiê jest kluczowym elementem sukcesu. Im bardziej z³o¿ony system, tym bardziej zawi³y staje siê projekt. Koniecznoœæ ustandaryzowana technik projektowania systemów zaowocowa³a powstaniem narzêdzi, dziêki którym nawet najbardziej skomplikowany projekt mo¿na przedstawiæ w prosty i czytelny sposób. Takim narzêdziem jest notacja UML — zestaw ikon tworz¹cych diagramy opisuj¹ce system i jego elementy. Ksi¹¿ka „UML 2.0. Wprowadzenie” w praktyczny sposób przedstawia techniki modelowania systemów informatycznych za pomoc¹ jêzyka UML 2.0. Czytaj¹c j¹, nauczysz siê graficznie przedstawiaæ otoczenie systemu, wymagania stawiane przez u¿ytkowników i metody ich implementacji w systemie. Utworzysz diagramy klas, interakcji, komponentów, wdro¿enia i inne, które opisuj¹ projekt w jednoznaczny oraz prosty sposób. Dowiesz siê tak¿e, jak zaplanowaæ proces wdro¿enia produktu za pomoc¹ UML. • Elementy jêzyka UML • Modelowanie wymagañ za pomoc¹ przypadków u¿ycia • Diagramy czynnoœci i sekwencji • Modelowanie klas i powi¹zañ pomiêdzy nimi • Diagramy komponentów • Podzia³ modelu na pakiety • Modelowanie wdro¿enia systemu Poznaj nowoczesne metody projektowania systemów informatycznych Wydawnictwo Helion ul. Koœciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Spis treści Przedmowa .....................................................................................................................7 1. Wstęp ..............................................................................................................................11 2. Modelowanie wymagań: przypadki użycia ................................................................29 31 39 47 49 Wychwytywanie wymagań systemowych Zależności pomiędzy przypadkami użycia Przeglądowe diagramy przypadków użycia Co dalej? 3. Modelowanie przepływu czynności w systemie: diagramy aktywności .................. 51 52 54 55 58 59 60 61 63 65 65 67 68 70 Podstawy diagramów aktywności Czynności a akcje Węzły decyzyjne oraz połączenia Jednoczesne wykonywanie wielu zadań Zdarzenia czasowe Wywoływanie innych czynności Obiekty Nadawanie oraz odbieranie sygnałów Rozpoczynanie czynności Kończenie czynności oraz przepływów Partycje (tory pływackie) Zarządzanie złożonymi diagramami czynności Co dalej? 4. Modelowanie struktury logicznej systemu: klasy oraz ich diagramy ........................ 71 71 74 75 79 Czym jest klasa? Podstawy klas w języku UML Widoczność Stan klasy: atrybuty 3 Zachowanie klasy: operacje Statyczne części klas Co dalej? 83 85 88 5. Modelowanie struktury logicznej systemu: zaawansowane diagramy klas ............89 89 97 98 100 103 104 Związki pomiędzy klasami Ograniczenia Klasy abstrakcyjne Interfejsy Szablony Co dalej? 6. Powoływanie klas do istnienia: diagramy obiektów ............................................... 107 107 109 111 112 Instancje obiektów Połączenia Wiązanie szablonów klas Co dalej? 7. Modelowanie uporządkowanych interakcji: diagramy sekwencji ...........................113 114 115 116 117 118 119 123 129 133 Uczestnicy na diagramie sekwencji Czas Zdarzenia, sygnały oraz komunikaty Belki aktywacji Komunikaty zagnieżdżone Strzałki komunikatów Ożywianie przypadku użycia za pomocą diagramu sekwencji Zarządzanie złożonymi interakcjami za pomocą fragmentów sekwencji Co dalej? 8. Połączenia opisujące interakcję: diagramy komunikacji .......................................... 135 135 139 142 145 Uczestnicy, połączenia oraz komunikaty Uzupełnianie interakcji za pomocą diagramu komunikacji Diagramy komunikacji a diagramy sekwencji Co dalej? 9. Harmonogramowanie interakcji: diagramy czasowe .............................................. 147 147 149 150 150 151 153 155 Jak wyglądają diagramy czasowe? Tworzenie diagramu czasowego na podstawie diagramu sekwencji Umieszczanie uczestników na diagramie czasowym Stany Czas Linia stanu uczestnika Zdarzenia i komunikaty 4 | Spis treści Ograniczenia czasowe Rozmieszczanie uczestników na diagramie czasowym Notacja alternatywna Co dalej? 156 158 159 163 10. Uzupełnianie obrazu interakcji: przeglądowe diagramy interakcji ........................165 165 167 173 Części przeglądowego diagramu interakcji Modelowanie przypadku użycia za pomocą przeglądowego diagramu interakcji Co dalej? 11. Modelowanie struktury wewnętrznej klasy: struktury złożone ............................. 175 176 182 183 187 Struktury wewnętrzne Prezentacja sposobu użycia klasy Prezentacja wzorców przy użyciu diagramów współpracy Co dalej? 12. Zarządzanie częściami systemu oraz ich współużytkowanie: diagramy komponentów ............................................................................................189 189 Czym jest komponent? 190 Prosty komponent w języku UML Udostępniane oraz wymagane interfejsy komponentu 191 193 Prezentacja współdziałania komponentów 194 Klasy realizujące komponent 196 Porty oraz struktura wewnętrzna Widoki czarnej oraz białej skrzynki 199 200 Co dalej? 13. Porządkowanie modelu: pakiety ...............................................................................201 202 204 206 206 207 210 211 212 Pakiety Przestrzenie nazw oraz klasy odwołujące się do siebie Widoczność elementów Zależności pomiędzy pakietami Importowanie oraz używanie pakietów Zarządzanie zależnościami pomiędzy pakietami Stosowanie pakietów do porządkowania przypadków użycia Co dalej? 14. Modelowanie stanu obiektów: diagramy maszyny stanowej ................................. 213 214 215 216 219 220 Podstawy Stany Przejścia Stany programu Zaawansowane zachowanie stanu Spis treści | 5 Stany złożone Zaawansowane pseudostany Sygnały Maszyny stanowe protokołu Co dalej? 222 223 224 225 225 15. Modelowanie wdrożenia systemu: diagramy wdrożenia .......................................227 227 229 232 232 234 235 236 237 Wdrażanie prostego systemu Wdrażanie oprogramowania: artefakty Czym jest węzeł? Węzły sprzętowe oraz środowiska uruchomieniowego Komunikacja pomiędzy węzłami Specyfikacje wdrożenia Kiedy stosować diagram wdrożenia? Co dalej? A Język ograniczeń obiektowych ..................................................................................239 B Dostosowywanie UML-a: profile ...............................................................................247 C Historia UML-a ............................................................................................................253 Skorowidz ....................................................................................................................259 6 | Spis treści ROZDZIAŁ 3. Modelowanie przepływu czynności w systemie: diagramy czynności Przypadki użycia pokazują, co powinien robić system. Diagramy czynności umożliwiają określe- nie tego, w jaki sposób system będzie osiągał swoje zamierzone cele. Diagramy czynności przed- stawiają akcje zamodelowane na wysokim poziomie oraz połączone razem w łańcuch, repre- zentujące procesy zachodzące w systemie. I tak na przykład diagram czynności może zostać użyty do zamodelowania czynności koniecznych do utworzenia konta pamiętnika internetowego. Diagramy czynności są szczególnie przydatne w modelowaniu procesów biznesowych. Proces tego rodzaju jest zestawem skoordynowanych zadań, które trzeba wykonać, aby osiągnąć cel bizne- sowy, na przykład dostarczenie zamówień do klientów. Niektóre z narzędzi do zarządzania procesami biznesowymi (ang. business process management, w skrócie BPM — przyp. tłum.) umoż- liwiają zdefiniowanie procesów biznesowych przy użyciu diagramów czynności lub też podob- nej notacji graficznej, a następnie ich wykonanie. Pozwala to na przykład zdefiniować oraz wykonać przy użyciu prostej notacji graficznej zawierającej diagramy czynności proces zatwier- dzania płatności, którego jeden z etapów stanowić będzie wywołanie usługi sieciowej zatwier- dzającej transakcje wykonane przy użyciu kart kredytowych. Diagramy czynności są jedynym diagramem UML-a w widoku procesu modelowanego sys- temu, co wynika z rysunku 3.1. Rysunek 3.1. Widok procesu przedstawia wysoko poziomowe procesy w systemie, do modelowania których bardzo dobrze nadają się diagramy czynności Diagramy czynności są jednymi z najbardziej zrozumiałych diagramów UML-a, ponieważ używają symboli podobnych jak powszechnie stosowana notacja przepływu (ang. flowchart — przyp. tłum.). Dlatego też przydają się one do opisywania procesów dla szerszego audytorium. 51 W rzeczywistości diagramy czynności, podobnie jak diagramy stanów, pochodzą od diagramów przepływów. Podstawy diagramów czynności Przyjrzyjmy się podstawowym elementom diagramów czynności, modelując przy okazji proces napotkany wcześniej w tej książce, to znaczy czynności zdefiniowane w przypadku użycia opi- sującym tworzenie konta pamiętnika internetowego. Tabela 3.1 zawiera opis przypadku użycia o nazwie Utwórz nowe konto pamiętnika (oryginalnie była to tabela 2.2). Proces tworzenia konta pamiętnika internetowego opisują sekcje „Główny przepływ wykonania” oraz „Rozsze- rzenia”. Tabela 3.1. Opis przypadku użycia o nazwie Utwórz nowe konto pamiętnika Nazwa przypadku użycia Powiązane wymagania Kontekst zadaniowy Warunki wstępne Warunek pomyślnego zakończenia Warunek niepomyślnego zakończenia Aktorzy główni Aktorzy drugoplanowi Wyzwalacz Główny przepływ wykonania Rozszerzenia 5. 6. Krok 4.1. 4.2. Utwórz nowe konto pamiętnika Wymaganie A.1. Nowy lub już istniejący autor żąda od administratora utworzenia nowego konta pamiętnika internetowego. System dostępny jest dla rozpoznanych autorów. W związku z tym autor musi dysponować odpowiednim potwierdzeniem tożsamości. Dla autora tworzone jest nowe konto pamiętnika. Wniosek o nowe konto pamiętnika jest odrzucany. Administrator. Baza danych z danymi autorów. Administrator żąda od systemu CMS utworzenia nowego konta pamiętnika internetowego. Krok 1. 2. 3. 4. Akcja Administrator prosi system o utworzenie nowego konta pamiętnika. Administrator wybiera rodzaj konta. Administrator wprowadza szczegółowe dane autora. Szczegółowe dane autora są weryfikowane przy użyciu informacji pobranych z bazy danych autorów. Tworzone jest nowe konto pamiętnika. Podsumowanie informacji o nowym koncie pamiętnika jest przesyłane do autora pocztą elektroniczną. Rozgałęziona akcja Informacje uzyskane z bazy danych nie pozwalają na potwierdzenie danych autora. Wniosek o utworzenie nowego konta pamiętnika jest odrzucany. Na rysunku 3.2 przedstawiony został proces tworzenia konta pamiętnika internetowego zapi- sany przy użyciu notacji diagramu czynności. Diagram czynności przydaje się w tej sytuacji, ponieważ pozwala w lepszy sposób zobrazować akcje opisane w przypadku użycia (w porów- naniu z notacją tablicy zastosowaną w opisie przypadku użycia), a szczególnie te rozgałęzione, które zależą od tego, czy dane autora zostaną zweryfikowane. 52 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności Rysunek 3.2. Diagramy czynności modelują dynamiczne zachowanie systemu, koncentrując się na procesach. Podstawowe elementy diagramów czynności przedstawione zostały na podstawie procesu tworzenia konta pamiętnika internetowego Z rysunku 3.2 wynika, że wykonanie czynności rozpoczyna się w jej węźle początkowym (ang. ini- tial node — przyp. tłum.) przedstawionym pod postacią wypełnionego koła. Węzeł początkowy oznacza najzwyczajniej początek czynności. Na drugim końcu diagramu występuje węzeł koń- cowy czynności (ang. activity final node — przyp. tłum.) oznaczający jej koniec i przedstawiony pod postacią dwóch koncentrycznych kół, z których środkowe jest wypełnione. Pomiędzy węzłem początkowym a końcowym czynności występują akcje (ang. actions) obra- zowane za pomocą prostokątów o zaokrąglonych narożnikach. Akcje są ważnymi krokami w danej czynności, np. Wybierz rodzaj konta, Wprowadź dane autora itd. Akcją może być wykonane działanie, obliczenie lub dowolny kluczowy krok procesu. Przepływ czynności przedstawiony jest przy użyciu strzałek nazywanych krawędziami (ang. edges) lub ścieżkami (ang. pathes). Strzałka na końcu wskazuje kierunek przepływu od jednej akcji do kolejnej. Linia przychodząca do danego węzła nazywana jest krawędzią wchodzącą (ang. inco- ming edge), zaś wychodząca z niego nazywana jest krawędzią wychodzącą (ang. outgoing edge). Podstawy diagramów czynności | 53 Krawędzie łączą akcje ze sobą, określając całkowity przepływ czynności. Na początku aktywny staje się węzeł początkowy, następnie ten o nazwie Poproś system o utworzenie nowego konta pamiętnika internetowego i tak dalej. Pierwszy z węzłów zaprezentowanych w postaci rombu nazywany jest decyzyjnym (ang. decision) i odpowiada blokowi instrukcji typu if-else w kodzie programu. Należy zauważyć, że od węzła decyzyjnego na rysunku 3.2 odchodzą dwie krawędzie wychodzące, z których każda nazwana jest zgodnie z wynikiem warunku logicznego. W rzeczywistości wykonywana jest tylko jedna krawędź w zależności od tego, czy dane autora zostaną potwierdzone, czy nie. Drugi węzeł w postaci rombu nazywany jest połączeniem (ang. merge). Połączenie łączy ze sobą krawędzie wychodzące z węzła decyzyjnego, oznaczając w ten sposób koniec zachowania warunkowego. Słowo „przepływ” zostało już poprzednio użyte kilkukrotnie i czytelnik może sobie zadać pyta- nie, co w takim razie płynie. Odpowiedź zależy od kontekstu. Zazwyczaj jest to przepływ ste- rowania od jednej akcji do kolejnej. Kiedy jedna akcja kończy działanie, wtedy sterowanie jest przekazywane do drugiej. W kolejnych podrozdziałach przekonamy się jednak, że wraz ze ste- rowaniem w danej czynności mogą przepływać również obiekty. Czynności a akcje Akcje są aktywnymi krokami niezbędnymi do ukończenia procesu. Akcja może być obliczeniem, na przykład Oblicz podatek, lub zadaniem, jak na przykład Sprawdź dane autora. Słowo „czynność” jest bardzo często błędnie używane zamiast wyrazu „akcja” w celu opisania kroku na diagramie czynności. Nie są one jednak tożsame. Czynność jest modelowanym proce- sem, jak chociażby mycie samochodu. Akcja jest krokiem w danej czynności, jak na przykład Użycie piany, Spłukanie, Wysuszenie. Akcje występujące w tej prostej czynności mycia samochodu przedstawione zostały na ry- sunku 3.3. Rysunek 3.3. Trzy akcje: Użycie piany, Spłukanie oraz Wysuszenie tworzą na diagramie czynność o nazwie Umyj samochód Na rysunku 3.3 cała czynność umieszczona jest wewnątrz zaokrąglonego prostokąta nazywa- nego ramką czynności (ang. activity frame — przyp. tłum.). Ramka czynności wykorzystywana jest do umieszczania w niej akcji czynności i przydaje się w sytuacji, gdy na jednym diagramie 54 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności chcemy przestawić więcej niż jedną czynność. Nazwa czynności powinna zostać umieszczona w lewym górnym rogu ramki. Ramka czynności jest opcjonalna i często może być pomijana na diagramie czynności, tak jak ma to miejsce na alternatywnym diagramie Umyj samochód, zaprezentowanym na rysunku 3.4. Rysunek 3.4. Ramka czynności może zostać pominięta Chociaż w ten sposób tracimy nazwę czynności prezentowanej na diagramie, to jednak opusz- czenie ramki jest często wygodne w przypadku tworzenia prostych diagramów. Węzły decyzyjne oraz połączenia Węzły decyzyjne (ang. decisions — przyp. tłum.) używane są w przypadku, gdy w zależności od warunku chcemy wykonać inną sekwencję akcji. Węzły tego rodzaju są przedstawiane w postaci rombu z jedną krawędzią wchodzącą oraz wieloma wychodzącymi, tak jak pokazane zostało to na rysunku 3.5. Rysunek 3.5. Z węzła decyzyjnego sterowanie przekazywane jest tylko wzdłuż jednej krawędzi Każda rozwidlona krawędź zawiera warunek (ang. guard condition — przyp. tłum.) zapisany w nawiasach kwadratowych. Warunki określają, która krawędź zostanie wybrana w węźle decyzyjnym. Warunki przyjmują wartości logiczne prawda lub fałsz, na przykład: [Autoryzacja] Jeżeli zmienna authorized ma wartość true, podążaj zgodnie z krawędzią wychodzącą umieszczoną przy warunku. [wordCount = 100] Jeżeli zmienna wordCount ma wartość większą lub równą 1000, wtedy podążaj zgodnie z krawędzią wychodzącą umieszczoną przy warunku. Węzły decyzyjne oraz połączenia | 55 Rozwidlone przepływy łączą się ponownie w węźle połączenia (ang. merge node — przyp. tłum.) sygnalizującym koniec warunkowego zachowania rozpoczętego wcześniej w węźle decyzyjnym. Połączenia są również przedstawiane przy użyciu rombu, ale mają wiele krawędzi wchodzą- cych i tylko jedną wychodzącą, co widać na rysunku 3.6. Rysunek 3.6. Jeżeli liczba słów wynosi przykładowo 1200, wtedy wykonywana jest akcja o nazwie Poinformuj, że wpis do pamiętnika jest zbyt długi Diagramy czynności są najbardziej przejrzyste, jeżeli warunki w węzłach decyzyjnych są kom- pletne oraz wzajemnie rozłączne. Sytuacja, w której ścieżki nie są wzajemnie rozłączne, przed- stawiona została na rysunku 3.7. Rysunek 3.7. Uwaga na diagramy z wieloma warunkami przyjmującymi wartość prawda Jeżeli towar jest w magazynie i zamówienie jest ekspresowe, wtedy dwa warunki mają wartość logiczną prawda. Która więc krawędź powinna zostać wybrana? Według specyfikacji UML-a w przypadku, gdy wiele różnych warunków przyjmuje wartość prawda, wybierana jest tylko jedna krawędź, a jej wybór jest przypadkowy, chyba że określi się uporządkowanie krawędzi. Wystąpieniu tej skomplikowanej sytuacji można zapobiec, tworząc warunki wzajemnie roz- łączne. 56 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności Inną sytuacją, której należy zapobiec, są warunki niekompletne. Na przykład gdyby na rysunku 3.7 nie było warunku określającego przypadek braku towaru w magazynie, wtedy w razie zaistnienia takiej sytuacji nie można by było wybrać żadnej krawędzi węzła decyzyjnego. Ozna- cza to, że dana czynność zostanie zamrożona w węźle decyzyjnym. Osoby modelujące system niekiedy pozbywają się warunków, jeżeli dana sytuacja nie występuje (lub też jeżeli chcą się nad nią zastanowić później). Jednakże aby zminimalizować ryzyko nieporozumienia, powinno się zawsze umieszczać warunki pokrywające wszystkie możliwe sytuacje. Jeżeli jest to możliwe w danej czynności, wtedy przydatne bywa nadanie jednej ze ścieżek etykiety else1 (jak pokazano na rysunku 3.7), co pozwoli upewnić się, że wszystkie sytuacje są obsługiwane. Jeżeli czytelnik ma doświadczenie w pracy z językiem UML w wersji 1.x, może uważać, że przedstawianie węzłów połączeń nie jest konieczne. W językach z rodziny UML 1.x bardzo często można było ujrzeć wiele krawędzi rozpoczynających się w węźle decyzyjnym i biegną- cych bezpośrednio do akcji, tak jak ma to miejsce na rysunku 3.8. Oznaczało to, że przepływy były łączone niejawnie. Rysunek 3.8. W UML 2.0 lepiej jest stosować jak najbardziej przejrzysty zapis i jawnie zapisywać węzły połączenia Począwszy od wersji UML 2.0, w przypadku gdy wiele krawędzi prowadzi bezpośrednio do akcji, kontynuacja wszystkich wchodzących przepływów jest wstrzymywana. Można uniknąć nieporozumień, jawnie przedstawiając węzły połączeń. 1 Krawędź oznaczona etykietą else, tak jak w przypadku konstrukcji bloku warunkowego if-else występującego w wielu językach programowania, wybierana jest w przypadku, gdy żaden z warunków nie przyjmuje wartości logicznej prawda. Tak więc krawędź ta obsługuje domyślnie wszystkie sytuacje nieprzewidziane na diagra- mie — przyp. tłum. Węzły decyzyjne oraz połączenia | 57 Jednoczesne wykonywanie wielu zadań Rozważmy przepływ czynności związanych z montażem komputerów i obejmujących nastę- pujące kroki: 1. Przygotuj obudowę. 2. Przygotuj płytę główną. 3. Zainstaluj płytę główną. 4. Zainstaluj napędy. 5. Zainstaluj kartę graficzną, dźwiękową oraz modem. Jak dotąd opisaliśmy już wystarczająco dużo notacji diagramu czynności, aby możliwe było zamodelowanie tego sekwencyjnego przepływu zdarzeń. Załóżmy jednak, że cały przepływ mógłby zostać przyspieszony poprzez jednoczesne przygotowanie obudowy oraz płyty głów- nej, ponieważ obie te akcje nie zależą od siebie wzajemnie. Kroki, które zachodzą w tym samym czasie, są nazywane współbieżnymi (ang. concurrent) lub równoległymi (ang. parallel). Równoległe akcje prezentowane są na diagramach przy użyciu rozwidleń (ang. forks) oraz scaleń (ang. joins), w sposób zaprezentowany na fragmencie diagramu czynności przedstawionym na rysunku 3.9. Rysunek 3.9. Obie krawędzie wychodzące przetwarzane są w węźle rozwidlenia, w przeciwieństwie do węzłów decyzyjnych, które używają jedynie jednej krawędzi wychodzącej Po rozwidleniu na rysunku 3.9 następuje rozdzielenie na dwa lub więcej równoczesnych prze- pływów i akcje z nich wykonywane są równocześnie. Na rysunku 3.9 akcje Przygotuj obudowę oraz Przygotuj płytę główną rozpoczynane są jednocześnie. Scalenie oznacza, że wszystkie wchodzące akcje muszą zakończyć się, zanim będzie mógł być przetwarzany dalej przepływ za scaleniem. Rozwidlenia oraz scalenia wyglądają identycznie (oba są rysowane przy użyciu grubych linii), jednakże można je rozróżnić, ponieważ te pierw- sze mają wiele przepływów wychodzących, podczas gdy drugie — wchodzących. W szczegółowym modelu projektu rozwidlenia mogą zostać użyte w celu reprezentacji wielu procesów lub wielu wątków programu. 58 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności Rysunek 3.10 przedstawia dokończony diagram dla przepływu czynności zachodzących pod- czas montażu komputerów. Rysunek 3.10. Przepływ czynności zachodzących podczas montażu komputerów demonstruje, w jaki sposób rozwidlenia oraz scalenia działają w kompletnym diagramie Jeśli akcje zachodzą równolegle, nie musi to koniecznie oznaczać, że skończą się równocześnie. W rzeczywistości jedno z zadań najprawdopodobniej zakończy się przed innym. Jednakże sca- lenie nie pozwoli na kontynuację przepływu zdefiniowanego za nim do czasu, aż wszystkie wchodzące przepływy nie zostaną zakończone. Na przykład na rysunku 3.10 akcja występująca po scaleniu o nazwie Zainstaluj płytę główną zostanie wykonana jedynie po zakończeniu obu wcześniejszych akcji — Przygotuj obudowę oraz Przygotuj płytę główną. Zdarzenia czasowe Niekiedy również czas jest czynnikiem w danej czynności. Można chcieć zamodelować okres oczekiwania, na przykład na chociażby trzy dni, które muszą upłynąć po wysłaniu towaru, zanim będzie mógł zostać wysłany rachunek. Może również zaistnieć konieczność zamodelo- wania procesów, które uruchamiane są w regularnych odstępach czasu, jak chociażby cotygo- dniowe tworzenie kopii roboczej systemu. Zdarzenia czasowe (ang. time events — przyp. tłum.) przedstawiane są przy użyciu symbolu klep- sydry. Rysunek 3.11 prezentuje, w jaki sposób zdarzenie czasowe może zostać użyte do zamo- delowania okresu oczekiwania. Tekst umieszczony obok klepsydry (Czekaj 3 dni) określa ilość czasu, jaki musi upłynąć. Krawędź wchodząca do zdarzenia czasowego oznacza, że jest ono aktywowane tylko raz. Z rysunku 3.11 wynika więc, że rachunek jest wysyłany jedynie raz, a nie co trzy dni. Rysunek 3.11. Zdarzenie czasowe z wchodzącą krawędzią reprezentuje oczekiwanie Zdarzenie czasowe bez wchodzących przepływów jest cykliczne (ang. recurring — przyp. tłum.), co oznacza, że jest aktywowane w odstępach czasu podanych obok symbolu klepsydry. Z ry- sunku 3.12 wynika, że opisywany na nim pasek postępu jest uaktualniany co sekundę. Należy zauważyć, że na rysunku 3.12 brakuje węzła początkowego. Zdarzenie czasowe jest alternatywnym sposobem rozpoczęcia czynności. Notacja ta powinna być używana do mode- lowania czynności wykonywanej cyklicznie. Zdarzenia czasowe | 59 Rysunek 3.12. Zdarzenie czasowe bez wchodzących przepływów modelu reprezentuje zdarzenie cykliczne Wywoływanie innych czynności W miarę dodawania szczegółów do diagramu czynności może stać się on zbyt duży lub też ta sama sekwencja akcji może występować na nim więcej niż raz. W takiej sytuacji można zwięk- szyć czytelność diagramu głównego poprzez udostępnienie szczegółów akcji na oddzielnym rysunku. Umożliwi to mniejsze zaśmiecenie diagramu wysokiego poziomu. Na rysunku 3.13 przedstawiony został przepływ czynności, które zachodzą podczas montażu komputerów, przeniesionych z rysunku 3.10. Jednakże tym razem obok akcji o nazwie Przy- gotuj płytę główną umieszczony jest odwrócony do góry nogami symbol wideł sygnalizujący, że jest to węzeł wywołania czynności (ang. call activity node). Wywołuje on czynność powiązaną z jego nazwą. Przypomina to wywoływanie procedury w programie. Rysunek 3.13. Aby szczegóły akcji Przygotuj płytę główną nie zaśmiecały diagramu ogólnego, zostały przedstawione na kolejnym diagramie czynności Węzeł o nazwie Przygotuj płytę główną umieszczony na rysunku 3.13 wywołuje czynność Przygotuj płytę główną przedstawioną na rysunku 3.14. Węzeł wywołania czynności może zostać skojarzony z wywoływaną przez niego czynnością dzięki nadaniu im tej samej nazwy. Wywołanie czynności zasadniczo rozbija daną akcję na bardziej szczegółową bez konieczności przedstawiania wszystkich szczegółów na jednym diagramie. Rysunek 3.14. Diagram czynności o nazwie Przygotuj płytę główną rozwija proces przygotowywania płyty głównej Diagram czynności o nazwie Przygotuj płytę główną dysponuje swoim własnym węzłem początkowym oraz końcowym czynności. Ten ostatni węzeł oznacza koniec czynności o nazwie Przygotuj płytę główną, lecz nie oznacza zakończenia wywołującej go czynności. W momen- cie zakończenia czynności o nazwie Przygotuj płytę główną sterowanie zwracane jest do 60 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności czynności wywołującej, która kontynuuje swoje działanie. To kolejny powód, dla którego wywo- łanie czynności przypomina wywoływanie procedur w programie. Pominięcie ramki jest możliwe do zaakceptowania dla czynności ogólnych. Powinna ona jednak być zawsze używana dla czynności wywoływanych. Nazwa czynności umieszczona w ramce pomoże skojarzyć czynności wywoływane z wywołującą. Obiekty Niekiedy ważnym aspektem modelowanego procesu są obiekty. Przypuśćmy, że firma czytelnika zdecydowała o sprzedaży systemu CMS jako produktu komercyjnego, a on chciałby zdefinio- wać proces akceptacji napływających zamówień. Każdy krok w procesie akceptacji zamówień będzie potrzebował informacji o zamówieniu, takich jak dotyczące płatności oraz kosztów trans- akcji. Informacje tego rodzaju mogą zostać zamodelowane na diagramie czynności przy użyciu obiektu Order, który zawierać będzie informacje o zamówieniu wymagane w kolejnych krokach. Diagramy czynności oferują szereg sposobów modelowania obiektów w procesach. Obiekty nie muszą być programowe. Na przykład w przypadku czynności niezauto- matyzowanego montażu komputerów węzeł obiektu może być używany do reprezen- towania zamówienia pracy, które rozpoczyna cały proces. Obrazowanie obiektów przekazywanych pomiędzy akcjami W celu ukazania danych przepływających przez czynność można użyć na diagramach czynno- ści tak zwanych węzłów obiektów (ang. object nodes). Węzeł obiektu reprezentuje obiekt, któ- ry jest dostępny w określonym miejscu czynności. Może on zostać użyty w celu zaprezentowania faktu, że dany obiekt jest używany, tworzony lub modyfikowany przez dowolną z otacza- jących go akcji. Węzeł obiektu reprezentowany jest jako prostokąt, co zostało pokazane na diagramie przed- stawiającym proces zatwierdzania zamówienia na rysunku 3.15. Węzeł obiektu Order sygnali- zuje fakt jego przepływu od akcji Pobierz zamówienie do Zatwierdź płatność. Rysunek 3.15. Węzeł obiektu o nazwie Order podkreśla, że jest on istotną informacją w tej czynności, a także pokazuje, które akcje go wykorzystują Bardziej precyzyjny opis modelowania akcji Pobierz zamówienie w postaci węzła odbioru sygnału został umieszczony w podrozdziale zatytułowanym „Nadawanie oraz odbieranie sygnałów”. Obiekty | 61 Prezentacja danych wejściowych oraz wyjściowych akcji Rysunek 3.16 przedstawia poprzednią czynność z innej perspektywy, wykorzystującej przekaź- niki danych (ang. pins). Przekaźniki danych sygnalizują, że obiekt stanowi daną wejściową lub wyjściową akcji. Rysunek 3.16. Przekaźniki danych w tym procesie zatwierdzania zamówienia pozwalają na dokładniejszą specyfikację parametrów wejściowych oraz wyjściowych Przekaźnik danych wejściowych (ang. input pin) oznacza, że określony obiekt to dane wejściowe akcji. Przekaźnik danych wyjściowych (ang. output pin) oznacza, że określony obiekt to dane wyjściowe z akcji. Na rysunku 3.16 obiekt Order oznacza dane wejściowe dla akcji Zatwierdź płatność. Jest on również daną wyjściową akcji Pobierz zamówienie. Na rysunku 3.15 oraz 3.16 przedstawione są analogiczne sytuacje, jednak użycie przekaźników danych pomaga uwypuklić fakt, że obiekt stanowi wymagane dane wejściowe oraz wyjściowe. Użycie węzła obiektu oznacza zwyczajnie, że obiekt jest dostępny w konkretnym punkcie czyn- ności. Niemniej węzły obiektu posiadają swoją własną mocną stronę — pomagają w uwypukle- niu przepływu danych w czynności. Jeżeli akcja Zatwierdź płatność wymaga jedynie części obiektu Order, a nie całego, wtedy można użyć przekształcenia (ang. transformation) w celu pokazania, które części są wymagane. Przekształcenia pozwalają na pokazanie, w jaki sposób dane wyjściowe z jednej akcji stanowią dane wejściowe dla innej. Z rysunku 3.17 wynika, że akcja o nazwie Zatwierdź płatność wymaga jako danej wejściowej obiektu reprezentującego koszt o nazwie Cost, który uzyskiwany jest z obiektu Order, co sygna- lizuje przekształcenie określone w notatce. Rysunek 3.17. Przekształcenie pokazuje, skąd pochodzą parametry wejściowe Prezentacja zmiany stanu obiektów w czynności Istnieje również możliwość ukazania zmiany stanu obiektu w trakcie jego przepływu przez czynność. Z rysunku 3.18 wynika, że obiekt o nazwie Order jest w stanie nazwanym oczekuje przed akcją Zatwierdź płatność oraz zmienia swój stan na zatwierdzone zaraz po niej. Stan obiektu przedstawiany jest w nawiasach kwadratowych. 62 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności Rysunek 3.18. Ten diagram koncentruje się na opisie zmiany stanu obiektu Order w trakcie procesu zatwierdzania zamówienia Prezentacja danych wejściowych oraz wyjściowych czynności Oprócz stanowienia danych wejściowych oraz wyjściowych akcji węzły obiektów mogą być również danymi wejściowymi oraz wyjściowymi czynności. Dane wejściowe oraz wyjściowe czynności przedstawiane są w postaci węzłów obiektów leżących na granicy jej ramki, tak jak to widać na rysunku 3.19. Tego rodzaju notacja przydatna jest do podkreślenia faktu, że cała czynność wymaga danych wejściowych oraz udostępnia wyjściowe. Rysunek 3.19 przedstawia obiekt Order w charakterze danych wejściowych oraz wyjściowych czynności o nazwie Zatwierdź płatność. W sytuacji gdy przedstawiane są parametry wejściowe oraz wyjściowe, węzeł początkowy oraz końcowy czynności jest usuwany z jej diagramu. Rysunek 3.19. Węzły obiektów mogą być stosowane w celu podkreślenia danych wejściowych oraz wyjściowych z czynności Nadawanie oraz odbieranie sygnałów Czynności mogą wymagać interakcji z zewnętrznymi osobami, systemami lub procesami. Na przykład w momencie dokonywania płatności przy użyciu karty kredytowej konieczne jest sprawdzenie danych karty przy użyciu usługi jej autoryzacji udostępnianej przez jej wystawcę. Na diagramach czynności sygnały (ang. signals) reprezentują interakcje z zewnętrznymi uczest- nikami. Sygnały są komunikatami, które mogą być nadawane oraz odbieranie, tak jak ma to miej- sce w następujących sytuacjach: • Program wysyła żądanie do wystawcy karty kredytowej w celu zaakceptowania transakcji przy jej użyciu, a następnie odbiera od niego odpowiedź (sygnał został wysłany oraz ode- brany z punktu widzenia czynności określającej akceptację karty płatniczej). • Otrzymanie zgłoszenia zamówienia powoduje rozpoczęcie procesu jego obsługi (z punktu widzenia czynności obsługi zamówienia sygnał został odebrany). • Kliknięcie przycisku powoduje wykonanie skojarzonego z nim kodu (z punktu widzenia czynności obsługi zdarzenia naciśnięcia przycisku sygnał został odebrany). • System informuje klienta, że jego zamówienie jest opóźnione (z punktu widzenia czynności obsługi zamówienia sygnał został wysłany). Nadawanie oraz odbieranie sygnałów | 63 Węzeł sygnału odbieranego (ang. receive signal node) może spowodować uruchomienie akcji przed- stawionej na diagramie czynności. Odbiorca sygnału wie, w jaki sposób ma na niego zareago- wać, i oczekuje nadejścia sygnału w pewnym momencie, choć nie wie, kiedy to dokładnie na- stąpi. Węzeł sygnału nadawanego (ang. send signal node) wysyła go do zewnętrznych uczestników. W chwili gdy zewnętrzny (w stosunku do systemu — przyp. tłum.) człowiek lub system otrzyma komunikat, w odpowiedzi na niego wykona prawdopodobnie pewną czynność, która nie jest jednak modelowana na diagramie. Rysunek 3.20 zawiera uszczegółowione kroki z rysunku 3.19 w celu pokazania, że akcja autory- zacji karty kredytowej wymaga komunikacji z zewnętrznym programem. Węzeł sygnału wycho- dzącego oznacza, że sygnał jest wysyłany do zewnętrznego uczestnika. W tym przykładzie sygnał jest żądaniem zatwierdzenia karty kredytowej. Sygnały nadawane są w sposób asyn- chroniczny, co oznacza, że czynność nie musi oczekiwać na odpowiedź, lecz po wysłaniu sygnału kontynuuje natychmiast działanie, począwszy od kolejnej akcji. Rysunek 3.20. Węzły sygnału nadawanego oraz odbieranego wskazują na interakcję z zewnętrznymi uczestnikami Węzeł sygnału odbieranego wskazuje, że sygnał odbierany jest z zewnętrznego procesu. W tym przypadku system oczekuje na odpowiedź od wystawcy karty kredytowej. Po napotkaniu węzła sygnału odbieranego akcja oczekuje do czasu odbioru sygnału, a czynność jest kontynuowana jedynie w przypadku jego otrzymania. Należy zauważyć, że łączenie sygnałów nadawanych oraz odbieranych powoduje w rezultacie zachowanie podobne do wywołania synchronicznego lub oczekującego na odpowiedź. Sygnały nadawane oraz odbierane są bardzo często łączone na diagra- mach czynności, ponieważ bardzo często zachodzi potrzeba uzyskania odpowiedzi na te pierwsze. Jeżeli napotkamy węzeł sygnału odbieranego bez przepływu wchodzącego, oznacza to, że w przypadku gdy czynność zawierająca węzeł jest aktywna, on zawsze oczekuje na sygnał. W przypadku przedstawionym na rysunku 3.21 czynność jest wykonywana zawsze po otrzy- maniu zamówienia. Rysunek 3.21. Czynność rozpoczynająca się od węzła sygnału odbieranego, zastępującego występujący zazwyczaj węzeł początkowy Taki węzeł różni się od węzła sygnału odbieranego z wchodzącą krawędzią, jak chociażby tego o nazwie Odbierz odpowiedź z rysunku 3.20. Taki węzeł sygnału odbieranego z wchodzącą krawędzią zaczyna oczekiwanie dopiero po zakończeniu poprzedniej akcji. 64 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności Rozpoczynanie czynności Najprostszym oraz najczęstszym sposobem rozpoczynania czynności jest użycie pojedynczego węzła początkowego. Większość diagramów, które dotąd widzieliśmy, używa tej notacji. Istnieją jednak również inne sposoby rozpoczynania czynności mające specjalne znaczenie: • Czynność rozpoczyna się od odebrania danych wejściowych, co zostało omówione wcze- śniej, w podrozdziale zatytułowanym „Prezentacja danych wejściowych oraz wyjściowych czynności”. • Czynność rozpoczyna się w odpowiedzi na zdarzenia czasowe, co zostało omówione wcze- śniej, w podrozdziale zatytułowanym „Zdarzenia czasowe”. • Czynność rozpoczyna się w wyniku wzbudzenia przez sygnał. Aby zasygnalizować, że czynność rozpoczyna się w wyniku wzbudzenia przez sygnał, należy zamiast węzła początkowego użyć węzła sygnału odbieranego. Wewnątrz tego węzła należy okre- ślić rodzaj sygnału, który będzie rozpoczynać daną czynność. Na rysunku 3.21 przedstawiona została czynność rozpoczynana po otrzymaniu zamówienia. Kończenie czynności oraz przepływów Do tej pory węzły końcowe czynności nie były zbyt interesujące. W rzeczywistości nie były one używane jako nic innego niż zwykłe znaczniki końca. W realnych sytuacjach można napotkać znacznie bardziej złożone zakończenia procesów. Przepływy na przykład mogą być przery- wane, ale mogą się też kończyć bez przerywania całej czynności. Przerywanie czynności Na rysunku 3.21 przedstawiony został typowy diagram czynności z pojedynczym zakończeniem. Należy zauważyć, że istnieje tylko jedna ścieżka prowadząca do końcowego węzła czynności. Każda akcja na tym diagramie ma szansę zakończenia. Niekiedy istnieje konieczność zamodelowania procesu, który może być przerwany przez zda- rzenie. Taka sytuacja mogłaby się zdarzyć, gdybyśmy na przykład mieli długo wykonujący się proces, który mógłby zostać przerwany przez użytkownika. Natomiast w czynności obsługi zamówienia systemu CMS mogłaby zachodzić konieczność zaksięgowania odwołanego za- mówienia. Tego rodzaju przerwania mogą być przedstawiane przy użyciu obszarów przerwań (ang. interruption regions). Obszar przerwań oznaczany jest przy użyciu zaokrąglonego prostokąta narysowanego za pomocą linii przerywanej, otaczającego akcje, które mogą zostać przerwane, oraz zdarzenie mogące powodować przerwanie. Ze zdarzenia przerywającego wychodzi linia przypominająca błyskawicę. Rysunek 3.22 rozszerza rysunek 3.21 poprzez dodanie obsługi możliwości wyco- fania zamówienia. Jeżeli w sytuacji przedstawionej na rysunku 3.22 prośba wycofania zamówienia zostanie otrzy- mana w chwili, gdy akcja o nazwie Przetwórz zamówienie jest aktywna, wtedy akcja ta zosta- nie przerwana, a aktywna stanie się Wycofaj zamówienie. Obszary przerwań odnoszą się jedy- nie do zawartych w nich akcji. Jeżeli wycofanie zamówienia zostanie otrzymane w chwili, gdy aktywna jest akcja Dostarcz zamówienie, wtedy nie zostanie ona przerwana, ponieważ nie znajduje się w obszarze przerwań. Kończenie czynności oraz przepływów | 65 Rysunek 3.22. Obszar przerwań sygnalizuje możliwość przerwania procesu Niekiedy można napotkać diagramy z wieloma końcowymi węzłami czynności, w odróżnieniu od takiego z wieloma przepływami wchodzącymi do pojedynczego końcowego węzła czynności. Taki diagram jest dopuszczalny i może pomóc w upo- rządkowaniu wielu linii na diagramie z wieloma rozgałęzieniami. Niemniej jednak diagramy czynności są zazwyczaj łatwiejsze do zrozumienia, jeżeli zawierają poje- dynczy końcowy węzeł czynności. Kończenie przepływu Nową funkcją wersji UML 2.0 jest możliwość pokazania końca przepływu bez konieczności kończenia całej czynności. Węzeł końcowy przepływu (ang. flow final node) kończy jedynie wła- sną ścieżkę, a nie całą czynność. Jest on oznaczany przy użyciu symbolu koła z wpisanym zna- kiem X, jak to zaprezentowano na rysunku 3.23. Rysunek 3.23. Węzeł końcowy przepływu kończy jedynie własną ścieżkę, a nie całą czynność Rysunek 3.23 przedstawia mechanizm wyszukiwania dla systemu CMS, z dwu sekundowym oknem do tworzenia najlepszych możliwych wyników wyszukiwania. Po wystąpieniu dwu- sekundowego opóźnienia wyniki wyszukiwania są zwracane i cała czynność, włączając akcję Popraw wyniki wyszukiwania, kończy się. Jednakże jeżeli akcja Popraw wyniki wyszukiwania zakończy się przed upływem dwusekundowego czasu oczekiwania, wtedy nie spowoduje to zakończenia całej czynności, ponieważ przepływ kończy się węzłem końcowym przepływu. 66 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności Używając węzła końcowego przepływu po rozgałęzieniu, należy zachować ostroż- ność. Po napotkaniu węzła końcowego zakończą się wszystkie inne akcje w danej czynności (również te przed węzłem końcowym). Jeżeli chcemy, aby wszystkie roz- widlone akcje zakończyły całkowicie swoje działanie, wtedy należy dodać scalenie. Partycje (tory pływackie) W czynności mogą brać udział różni uczestnicy, jak chociażby różne grupy lub role w organi- zacji lub systemie. Poniższe scenariusze wymagają do dokończenia czynności udziału wielu uczestników (nazwy uczestników napisane są czcionką pochyłą): Czynność przetwarzania zamówienia Wymaga od działu logistyki dostarczenia produktu oraz od działu księgowości wystawienia rachunku dla klienta. Proces obsługi technicznej Wymaga różnych poziomów obsługi, do których należą wsparcie pierwszego poziomu, wspar- cie rozszerzone oraz dział rozwoju produktu. Aby pokazać, za które akcje są odpowiedzialni dani uczestnicy, można użyć partycji (ang. parti- tions). Partycje dzielą diagram na wiersze oraz kolumny (w zależności od usytuowania diagramu czynności) i zawierają akcje, które są wykonywane przez odpowiedzialne za nie grupy. Kolumny oraz wiersze są niekiedy określane mianem torów pływackich (and. swimlanes). Na rysunku 3.24 przedstawiony jest proces obsługi technicznej uwzględniający trzy rodzaje uczestników: wsparcie pierwszego poziomu, wsparcie rozszerzone oraz dział rozwoju produktu. Rysunek 3.24. Partycje pomagają w organizacji diagramu czynności, określając strony odpowiedzialne Partycje (tory pływackie) | 67 Odpowiedzialność może być również zasygnalizowana przy użyciu adnotacji (ang. annotations). Warto zauważyć, że w takim przypadku nie istnieją już tory pływackie. W zamian nazwa odpowiedzialnej strony jest umieszczona w nawiasach w samym węźle, jak pokazano to na ry- sunku 3.25. Tego rodzaju notacja zazwyczaj sprawia, że diagram jest bardziej zwięzły, jednakże uczestnicy są przedstawieni mniej przejrzyście niż w przypadku torów pływackich. Rysunek 3.25. Używanie adnotacji zamiast torów pływackich jest sposobem przedstawienia odpowiedzialności bezpośrednio w akcji Zarządzanie złożonymi diagramami czynności Diagramy czynności posiadają wiele dodatkowych symboli służących do modelowania szero- kiego zakresu procesów. Przedstawione poniżej podrozdziały zawierają niektóre z wygodnych skrótów upraszczających diagramy czynności. Łączniki Jeżeli diagram czynności zawiera dużo akcji, efektem tego może być umieszczenie na nim wielu długich, przecinających się linii, co spowoduje, że będzie go trudniej odczytać. W takiej sytu- acji pomagają właśnie łączniki (ang. connectors — przyp. tłum.). Łączniki pomagają uprościć diagramy, łącząc krawędzie z symbolami, a nie z konkretnymi li- niami. Łącznik oznaczany jest za pomocą kółka z wpisaną nazwą. Nazwy łączników przyjmują najczęściej postać jednoliterową. W przypadku rysunku 3.26 nazwą łącznika jest litera n. 68 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności Rysunek 3.26. Łączniki mogą zwiększyć przejrzystość dużych diagramów czynności Łączniki występują w parach — jeden z nich ma krawędź wchodzącą, drugi wychodzącą. Drugi łącznik rozpoczyna się w miejscu zakończenia pierwszego. Dlatego też przepływ na rysunku 3.26 jest identyczny z tym, w którym Krok 3. miałby krawędź prowadząca bezpośrednio do Kroku 4. Z łącznikami należy uważać. Jeżeli na jednym diagramie zostanie użytych zbyt wiele różnych łączników, jego czytelnik może stracić zbyt wiele czasu, próbując je połączyć. Obszary rozszerzenia Obszary rozszerzenia (ang. expansion regions — przyp. tłum.) sygnalizują, że akcje umieszczone w tym obszarze są wykonywane dla każdego obiektu ze zbioru wejściowego. Na przykład obszar rozszerzenia mógłby zostać użyty w celu zamodelowania funkcji oprogramowania przyjmują- cej jako dane wejściowe listę plików, a następnie przeszukującej każdy z nich na obecność szu- kanego wyrazu. Obszary rozszerzenia przedstawiane są jako duże zaokrąglone prostokąty narysowane przery- waną linią z czterema kwadracikami dołączonymi z każdej strony. Cztery kwadraty reprezen- tują zbiory wejściowe oraz wyjściowe (ale nie wymuszają ograniczenia rozmiaru zbioru do czte- rech elementów). Z rysunku 3.27 wynika, że raport o błędach jest dyskutowany dla każdego raportu ze zbioru wejściowego. Jeżeli jest to rzeczywisty błąd, wtedy czynność jest wykonywana dalej. W przeciwnym przypadku błąd jest odrzucany, a przepływ dla tych danych wejściowych jest kończony. Rysunek 3.27. Akcje w obszarze rozszerzenia są wykonywane dla każdego z elementów zbioru Zarządzanie złożonymi diagramami czynności | 69 Co dalej? Diagramy komunikacji oraz sekwencji są kolejnymi diagramami UML-a, które mogą służyć do modelowania dynamicznego zachowania systemu. Diagramy te koncentrują się na uka- zywaniu sekwencji zdarzeń oraz szczegółów interakcji, jak chociażby tego, które obiekty są użyte w interakcji, jakie metody są wywoływane. Diagramy sekwencji są opisane w rozdziale 7., nato- miast diagramy komunikacji w rozdziale 8. Jeżeli czytelnik nie zapoznał się jeszcze z rozdziałem 2., opisującym przypadki użycia, warto polecić jego przeczytanie, ponieważ diagramy czynności udostępniają właśnie wspaniałą metodę na przedstawienie graficznej reprezentacji przepływu przypadków sterowania. 70 | Rozdział 3. Modelowanie przepływu czynności w systemie: diagramy czynności
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

UML 2.0. Wprowadzenie
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: