RAFAA
KASPRZYK, copyright reserved
DIAGRAMY PRZYPADKÓW UŻYCIA
Przypadki użycia były w sposób intuicyjny stosowane w tradycyjnym
projektowaniu systemów informatycznych na długo przed pojawieniem się
metodyk obiektowych. Zasługą Jacobsona jest zarówno wyodrębnienie przypadków
użycia jako metody projektowania, jak i stworzenie metodyki i notacji graficznej dla tego
paradygmatu. Jak często bywa z powszechnie stosowanymi, lecz nie nazwanymi
rzeczami, kariera przypadków użycia w literaturze z zakresu projektowania systemów
informatycznych (SI) zaczęła się od wprowadzenia dla nich specjalnej nazwy,
przypisaniu tej nazwie określonego znaczenia i rozpropagowanie tego pojęcia jako
swego rodzaju paradygmatu projektowania SI.
Przypadek użycia jest to pewna nazwana, dobrze określona interakcja pomiędzy
użytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje
pewną funkcjonalność systemu w taki sposób, w jaki będą ją widzieć jego
przyszli użytkownicy. Jakkolwiek w tym stwierdzeniu można podejrzewać banał,
rzecz tak oczywistą, że nie warto o niej mówić, okazuje się, że dla dużych systemów o
wielu złożonych i wzajemnie powiązanych funkcjach tego rodzaju podejście ma ogromny
sens. Pozwala ono zapomnieć o detalach technicznych (nawet abstrahować od
architektury) i skoncentrować się na logice systemu. Podejście do projektowania od
strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść
 technokratycznych , ponieważ sprzyja ono punktowi widzenia, w którym
centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik
systemu. Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich
niepowodzeń było zbytnie skoncentrowanie się projektantów na detalach technicznych,
z pominięciem lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami, a
systemem komputerowym.
Reasumując przypadek użycia można definiować na wiele sposobów. Oto kilka definicji:
üð Przypadek użycia to wycinek funkcjonalnoÅ›ci, którÄ… system musi realizować,
aby spełnić wymagania
üð Przypadek użycia jest zbiorem ciÄ…gów akcji wykonywanych przez system
w celu dostarczenia określonemu aktorowi godnego uwagi wyniku
üð Przypadek użycia to zbiór scenariuszy powiÄ…zanych wspólnym celem
użytkownika. Przez scenariusz rozumiany jest tu ciąg kroków opisujących
interakcje między użytkownikiem, a systemem
Podejście przypadków użycia ma przede wszystkim na względzie określenie wymagań
funkcjonalnych na projektowany system. Celem tej metody jest:
üð Identyfikacja wymagaÅ„ funkcjonalnych
o Każdy przypadek użycia powinien opisywać realizację jakiegoś celu
biznesowego opisanego z punktu widzenia aktora używającego system
o Zbiór przypadków użycia stanowi podstawę do umowy między klientem, a
dostawcÄ…
RAFAA
KASPRZYK, copyright reserved
o Przypadki użycia ułatwiają zadanie ustalenia priorytetów dla wymagań
funkcjonalnych
üð Odpowiedz
na pytanie, co system ma robić bez określania sposobu realizacji
üð Umożliwienie interakcji zespoÅ‚u projektowego z przyszÅ‚ymi użytkownikami
systemu
üð OkreÅ›lenie granic systemu
üð Ustalenie praw dostÄ™pu do zasobów
üð Ustalenie skÅ‚adowych systemu i zwiÄ…zanego z nimi planu konstrukcji systemu
üð Przygotowanie podstaw do szczegółowej analizy i projektowania
o Podstawa do identyfikacji klas i obiektów
o Określenie odpowiedzialności i współpracy obiektów
o Definicja przepływu komunikatów miedzy obiektami
üð Weryfikacja poprawnoÅ›ci i kompletnoÅ›ci projektu
üð Dostarczenie podstaw do sporzÄ…dzenie planu testów systemu
Pomiędzy przypadkami użycia można wyróżnić przynajmniej trzy podstawowe relacje:
üð Zawieranie
o Pozwala na współdzielenie fragmentu funkcjonalności pomiędzy
kilkoma przypadkami użycia. Do relacji zawierania dochodzi wówczas, gdy
kilka przypadków użycia ma wspólną sekwencję podobnych kroków, której
nie warto wciąż kopiować z jednego przypadku użycia do drugiego.
üð Rozszerzanie
o Pozwala na warunkowe rozszerzenie funkcjonalności przypadku
użycia  osadzone w punkcie rozszerzenia. Rozszerzenie przypadku użycia
może więc wzbogacić go o dodatkowe zachowanie, ale w takiej sytuacji
podstawowy przypadek użycia musi określić pewne punkty rozszerzenia, a
rozszerzający przypadek użycia może dodać nowe zachowanie tylko w tych
punktach. Przypadek użycia może mieć wiele punktów rozszerzeń, a
rozszerzający przypadek użycia może rozszerzać podstawowy przypadek
użycia w kilku z tych punktów. Relacja rozszerzania służy do opisywania
opcjonalnego przepływu zdarzeń i pozwala na minimalizację liczby
zmian wprowadzanych do podstawowego przypadku użycia.
üð Uogólnienie
o Pozwala na zilustrowanie różnych wariantów realizacji tego
samego przypadku użycia. W istocie jest bardzo podobne do
rozszerzania, jest jednak mniej formalne. Relacji uogólnienia używa się
wówczas, gdy dany przypadek użycia jest podobny do innego, ale jest
nieco obszerniejszy. Specjalizowany przypadek użycia może
przesłonić dowolną część podstawowego przypadku użycia, ale
zawsze powinien dotyczyć osiągnięcia tego samego celu użytkownika, co
podstawowy przypadek użycia. Relacja uogólnianie może być traktowana
RAFAA
KASPRZYK, copyright reserved
jako sposób na przedstawienie szczególnej realizacji uogólnionego
przypadku użycia.
Diagramy przypadków użycia są bardzo proste i głównie dzięki temu tak użyteczne.
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY KLAS
Diagram klas jest ściśle powiązany z projektowaniem obiektowym systemów
informatycznych. Opisuje wyróżnione w systemie klasy obiektów i statyczne
powiązania między nimi. Zawiera on również takie elementy jak atrybuty i operacje
klas oraz ograniczenia nakładane na klasy obiektów i ich powiązania.
Modelując statyczne aspekty perspektywy projektowej, diagramów klas używa się do:
üð Modelowanie sÅ‚ownictwa systemu. Zadanie to polega miÄ™dzy innymi na
podejmowaniu decyzji, które abstrakcje są częścią rozważanego systemu, a które
nie i jakie zobowiązania ma każda z tych abstrakcji.
üð Modelowanie prostych kooperacji. Kooperacja jest to zestaw klas,
interfejsów i innych bytów istniejących celem realizacji pewnego zespołowego
zachowania wymagającego współpracy wszystkich elementów. Nie należy skupiać
się nad jedną klasą, lecz nad zbiorem współpracujących ze sobą klas, by
zrozumieć, o co chodzi. W tym wypadku diagramy klas wykorzystuje się do
zobrazowania i określenia tego zbioru klas i związków między nimi.
üð Modelowanie schematu logicznej bazy danych. Przez schemat rozumiany
jest plan projektu koncepcyjnego bazy danych. W wielu dziedzinach zachodzi
potrzeba trwałego przechowywania informacji w bazach danych. W tym wypadku
diagram klas wykorzystuje się do modelowania schematów takich baz danych.
Klasa jest opisem zbioru obiektów, które mają takie same:
üð Atrybuty  opisujÄ… stan
o Najczęściej typy proste lub biblioteczne
o Nie posiadają własnych reguł biznesowych
o Ich wartości są istotne dla obiektów klasy
üð Operacje  opisujÄ… zachowanie
o Usługi oferowane przez każdy obiekt klasy
o Zwykle powodujÄ… zmianÄ™ stanu obiektu
o DzielÄ… siÄ™ na zapytania i polecenia
üð ZwiÄ…zki  uogólnienie, realizacja, zależność, asocjacja, agregacja, kompozycja
o Umożliwiają obrazowanie faktu, że zachowanie jednej klasy zależy od
zachowania innej klasy
o Powalają na unikanie antywzorów (np.  BLOB )
üð Znaczenie
Klasa realizuje jeden bÄ…dz
wiele interfejsów. Interfejs definiuje zewnętrznie
obserwowane zachowanie klasy lub komponentu, określając zbiór deklaracji
operacji, ale nigdy sposobu implementacji.
RAFAA
KASPRZYK, copyright reserved
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY KOMPONENTÓW
Komponenty, w odróżnieniu od bytów koncepcyjnych jakimi są np. diagramy klas, są
elementami oprogramowania istniejÄ…cymi w systemie komputerowym i
będącymi fizyczną realizacją zamysłu projektanta oprogramowania, czyli
składnikiem konkretnego systemu programowego. Należy tu uchwycić subtelną granicę
rozciągłości definicji klasy w stosunku do definicji komponentu, tzn. najważniejszym
wyróżnikiem odmienności tych dwóch pojęć jest to, iż klasa jest abstrakcyjnym
przedstawieniem zbioru atrybutów i operacji, podczas gdy komponent jest
fizyczną częścią systemu.
Analizując zagadnienie projektowania realnych fragmentów oprogramowania
(komponentów) można dojść do wniosku, że szczególny nacisk powinien zostać
położony na możliwość wyizolowania komponentu i jego wielokrotnego
użycia. Zadanie to ułatwiają dobrze zdefiniowane interfejsy, które są jedyną drogą
przez którą dostępne są operacje komponentu - zupełnie jak w przypadku klas - relację
tego typu nazywamy realizacją. Nie można pominąć znaczenia interfejsu jako
swego rodzaju "okna na świat" dla komponentu, co warunkuje możliwości jego
wymiany i wielokrotnego wykorzystania. Należy w tym miejscu dodać, że w specyfikacji
UML 2.0 wyróżnione zostały dwa typy interfejsów. Jeżeli komponent udostępnia jakieś
usługi w postaci interfejsu to mówimy wówczas o tzw. interfejsie dostarczanym,
udostępnianym lub eksportowanym (ang. provided interface). Może jednak zajść
przypadek, że komponent, aby w pełni realizować swoje usługi, potrzebuje skorzystać z
usług innych komponentów, co obrazuje się za pomocą interfejsu wymaganego,
importowanym (ang. required interface).
Wyróżniamy 3 podstawowe rodzaje komponentów:
üð wdrożenia - sÄ… podstawÄ… oprogramowania wykonywalnego
o COM+, JavaBeans, EJB, biblioteki DLL, pliki wykonywalne EXE, ...
üð procesu wytwórczego - komponenty bÄ™dÄ…ce artefaktami powstaÅ‚ymi w
procesie wytwarzania, na ich podstawie generuje się komponenty wdrożenia
o schemat logiczny bazy danych, skrypty SQL, pliki z kodem z
ródłowym, &
üð komponenty wykonania - tworzone jako rezultat dziaÅ‚ania systemu
o wydruki, raporty, &
W końcu dochodzimy do definicji diagramu komponentów, który zawiera komponenty,
interfejsy oraz ich wzajemne zwiÄ…zki. Elementy te sÄ… ze sobÄ… luz
no powiÄ…zane
najczęściej za pomocą zależności i realizacji.
RAFAA
KASPRZYK, copyright reserved
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY WDROŻENIA
Diagram wdrożenia, obok diagramu komponentów to jeden z dwóch rodzajów
diagramów przedstawiających fizyczne aspekty systemów. Jego zadaniem jest
zobrazowanie konfiguracji węzłów w czasie wykonania, na których
rozmieszczone będą komponenty. Komponenty reprezentują fizyczne
(programowe  ang. software), wymienne części systemu, które realizują
elementy logiczne, podczas gdy węzły to fizyczne (sprzętowe  ang.
hardware) składnik systemu na których wdrożone zostają komponenty.
Najczęściej mamy do czynienia z sytuacją w której diagramy komponentów
 umieszczane są na diagramach wdrożenia, aby pokazać, które komponenty działają na
których węzłach.
Węzły dzielone są na:
üð procesory  reprezentujÄ… zasoby obliczeniowe
o posiadają pewną ilość pamięci i zdolność przetwarzania,
o mogą wykonywać kod komponentu
üð urzÄ…dzenia  sÄ… interfejsem do Å›wiata zewnÄ™trznego
o nie mają zdolności przetwarzania (np. monitor, drukarka)
Diagramy wdrożenia są szczególnie przydatne dla projektantów systemów, których
sposób funkcjonowania zależy równie sileni od oprogramowaniu wchodzącym w skład
systemu, jak i sprzętu na którym to oprogramowanie ma działać. Pozwalają na
zobrazowanie infrastruktury wymaganej przez system.
Pomiędzy węzłami występują połączenia (ang. connection), które najczęściej opatrzone
są różnymi stereotypami opisującymi ich charakter.
Można wyróżnić trzy zasadnicze typy systemów, przy modelowani których warto
wykorzystać diagramy wdrożenia: systemy wbudowane, systemy typu klient-serwer oraz
systemy rozproszone.
Istotna nowością, która została wprowadzona w specyfikacji UML 2.0 jest dodanie
elementu będącego specyfikacją wdrożenia. Element ten odpowiada za opis parametrów
potrzebnych do wdrożenia komponentu na danym węz
le, co ma na celu parametryzacjÄ™
relacji pomiędzy różnymi programowymi i sprzętowymi technologiami. Specyfikacja
wdrożenia jest obrazowana za pomocą stereotypu <>
Ciekawym elementem jest również tzw. środowisko wykonania. Element ten
reprezentuje wybrany rodzaj platformy i jest obrazowany za pomocÄ… stereotypu
<>
RAFAA
KASPRZYK, copyright reserved
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY OBIEKTÓW
Diagramy obiektów przedstawiają hierarchię obiektów i ich wzajemne
powiązania w danej chwili. Jako że przedstawiają instancje klas, a nie same klasy -
nazywane są też czasem diagramami instancji. Na diagramach obiektów
umieszczamy specyfikacje instancji, a nie same instancje. RozwiÄ…zanie takie
umożliwia nie nadawanie wartości obowiązkowym atrybutom, lub też obrazowanie
specyfikacji instancji klas abstrakcyjnych.
Diagramy obiektów podobne są do diagramów komunikacji, jednakże te
pierwsze służą do zobrazowania struktury instancji, diagramy komunikacji
natomiast do pokazania ich zachowań.
RAFAA
KASPRZYK, copyright reserved
DAIGRAMY STRUKTUR ZA
OŻONYCH
Diagramy struktur złożonych służą do hierarchicznego opisywania
skomplikowanych fragmentów oprogramowania. Pozwala to na zajęcie się
skomplikowanym elementem i podzielenie go na części. Struktury złożone są
podobne do pakietów. Aby uświadomić sobie podstawową różnicę najlepiej myśleć o
pakietach jako o sposobie grupowania elementów w czasie kompilacji,
podczas gdy struktury złożone grupują elementy w czasie wykonania
programu.
Diagramy struktury swoja notację i zakres stosowania wywodzą głównie z modeli
systemów czasu rzeczywistego, gdzie stosowane jest pojęcie tzw. kapsuły, która
reprezentuje wyraz
nie wydzielony i hermetyczny wątek sterowania systemu. Całkowita
izolacja kapsuła (w obu kierunkach) od jej otoczenia możliwa jest dzięki portom, które
pełnia rolę obiektów granicznych (interfejsów). Interesujący jest fakt, że diagramy
struktury mogą obrazować aspekty statyczny i dynamiczny modelowanego systemów, co
stanowi o ich osobliwości. Najczęściej mamy do czynienia z przypadkiem, w
którym diagramy struktury ilustrują dekompozycję wskazującą z jakich części
składa się kapsuła i w jakie interfejsy jest ona zaopatrzona. Istnieje jednak
druga forma diagramów struktury umożliwiająca przedstawienie
komunikacji, jaka zachodzi pomiędzy wewnętrznymi elementami kapsuły.
Taka forma prezentacji diagramów struktury została nazwana w UML 2.0 diagramem
współpracy. Należy pamiętać, że gdy diagram struktury przyjmuje pierwszą formę to
można użyć na nim portów i interfejsów. Prezentując natomiast zbiór współpracujących
ze sobą elementów składowych kapsuły nie można wykorzystywać portów i interfejsów,
ale należy skorzystać ze stereotypowych zależności:
<>, <>, <>
Ponieważ struktury złożone są nowością, to trudno stwierdzić, jak przydatne okażą się w
praktyce.
RAFAA
KASPRZYK, copyright reserved
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY PAKIETÓW
Pakiet jest konstrukcją pozwalającą organizować elementy modelu np. klasy,
w logiczne grupy. Natomiast diagram pakietów to diagram składający się z pakietów i
zależności między nimi.
Pakiety z reguły tworzy się, aby:
üð W przejrzysty sposób zobrazować zależnoÅ›ci pomiÄ™dzy poszczególnymi
elementami modelu.
üð Efektywniej organizować kod z
ródłowy.
üð Zaznaczyć podobieÅ„stwa i różnice pomiÄ™dzy poszczególnych elementów
modelu.
Na diagramie pakietów wszelkie elementy modelu (klasy, interfejsy, kooperacje,
komponenty,& ) grupowane sÄ… w pakiety i/lub podpakiety zgodnie z poziomami
zawierania. Warto tworzyć tego typu diagramy dążąc do tego, aby elementy modelu
połączone relacjami asocjacji, agregacji, czy to kompozycji umieszczone były w jednym
pakiecie. Z reguły naturalnym jest, by w pakiecie umieszczać elementy modelu, które w
jakikolwiek sposób od siebie zależą. Diagramy pakietów można także stosować w celu
grupowania przypadków użycia.
Ogólne zasady tworzenia diagramów pakietów są bardzo proste:
üð Zawsze nadawaj pakietom proste, opisowe nazwy
üð Stosuj pakiety do upraszczania struktury diagramów
üð Stosuj stereotypy by zaznaczyć warstwy architektury programu
üð ZależnoÅ›ci miÄ™dzy pakietami powinny odzwierciedlać faktyczne wewnÄ™trzne
relacje w programie
üð Pakiety powinna charakteryzować wysoka zwartość i niskie sprzężenie.
RAFAA
KASPRZYK, copyright reserved
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY SEKWENCJI
Diagram sekwencji (przebiegu) jest jednym z diagramów interakcji. Diagramy interakcji
odnoszą się do modelowania dynamicznych aspektów systemu i służy do opisu
współpracy pomiędzy grupą obiektów. Na diagramach sekwencji uwzględnia się
konkretne i prototypowe egzemplarze klas, interfejsów, komponentów i
węzłów, a także komunikaty przekazywane między nimi. Elementy te są
rozpatrywane w kontekście pewnego scenariusza ilustrującego zachowanie
systemu.
Diagram sekwencji główny nacisk kładzie na uwypuklenie kolejność przesyłania
komunikatów w czasie. Diagramy sekwencji stosuje się, aby spojrzeć na
zachowanie się kilku obiektów w ramach jednego przypadku użycia systemu.
Są użyteczne do przedstawiania współpracy obiektów, ale nie umożliwiają ścisłej
definicji zachowania.
ReasumujÄ…c diagramy sekwencji:
üð PrzedstawiajÄ… interakcje pomiÄ™dzy obiektami (w UML 2.0 tzw. uczestnikami
interakcji), przy czym największy nacisk kładą na zależności czasowe.
üð Stosowane sÄ… zawsze, gdy kolejność wywoÅ‚aÅ„ oraz ograniczenia
czasowe sÄ… istotne
üð NadajÄ… siÄ™ do modelowania:
o Systemów czasu rzeczywistego
o Przetwarzania współbieżnego
o Złożonych scenariuszy
üð Nie prezentujÄ… zwiÄ…zków strukturalnych miedzy współdziaÅ‚ajÄ…cymi obiektami
(uczestnikami)
üð PozwalajÄ… na zaprezentowanie różnych typów interakcji:
o Synchroniczna
o Asynchroniczna
o &
Notacja UML 2.0 wprowadziła do diagramów sekwencji szereg nowości, które bez
wątpienia ułatwiają prezentację złożonych scenariuszy wybranych przypadków użycia.
Częstym problemem towarzyszącym diagramom sekwencji była trudność z
przedstawieniem zachowania warunkowego i pętli. Rozwiązaniem okazało się
wprowadzenie ramek interakcji, które służą do wyróżnienia fragmentu
diagramu sekwencji. Każda taka ramka ma operator (stereotyp interakcji), a
każdej wydzielonej części ramki może towarzyszyć warunek, co pozwala na
wizualizowanie różnych wariantów złożonego scenariusza.
Najczęściej stosowane stereotypy interakcji:
üð alt (alternatywa)  zostaje wykonany tylko ta część ramki, której warunek jest
prawdziwy.
RAFAA
KASPRZYK, copyright reserved
üð opt (opcja)  fragment zostaje wykonany tylko wówczas, gdy zawarty w nim
warunek jest prawdziwy, czyli odpowiednik operatora alt z jednym wejściem.
üð par (współbieżność)  każda część ramki interakcji uruchamiana jest równolegle.
üð loop (pÄ™tla)  ramka interakcji może być wykonana kilka razy, a warunek
określa podstawę interakcji.
üð region (obszar krytyczny)  ramka interakcji może mieć tylko jeden wÄ…tek
uruchomiony w dane chwili.
üð neg (negacja)  ramka przedstawia niepoprawna interakcjÄ™.
üð ref (referencja)  ramka odwoÅ‚uje siÄ™ do interakcji zdefiniowanej na innym
diagramie. Ramka jest rysowana tak, aby przykrywać linie czasu obiektów
biorących udział w interakcji. Można zdefiniować parametry wejściowe i wartości
zwracanÄ….
üð sd (diagram sekwencji)  używany do otaczania ramkÄ… caÅ‚ego diagramu
sekwencji, w miarÄ™ potrzeb.
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY KOMUNIKACJI
Diagram komunikacji jest jednym z diagramów interakcji. Diagramy interakcji odnoszą
się do modelowania dynamicznych aspektów systemu i służy do opisu współpracy
pomiędzy grupy obiektów. Na diagramach komunikacji uwzględnia się konkretne i
prototypowe egzemplarze klas, interfejsów, komponentów i węzłów, a także komunikaty
przekazywane między nimi. Elementy te są rozpatrywane w kontekście pewnego
scenariusza ilustrujÄ…cego zachowanie systemu.
Diagram komunikacji kładzie nacisk na związki strukturalne między
obiektami (w UML 2.0 tzw. uczestnikami) biorącymi udział w interakcji oraz
komunikaty przesyłane między nimi. Jest wygodniejszy od diagramów sekwencji do
przedstawienia złożonych iteracji i rozgałęzień. W swojej idei diagramy komunikacji są
podobne do diagramów sekwencji. Ich głównym celem jest więc przedstawienie
przepływu komunikatów pomiędzy obiektami. Diagramy komunikacji uwzględniają
jednak dwa aspekty: statyczną strukturę uczestniczących obiektów, włączając związki,
atrybuty i operacje (jest to nazywane  kontekstem współpracy ), oraz kolejność
komunikatów wymienianych pomiędzy obiektami dla realizacji konkretnego zadania.
Diagram komunikacji może być rozrysowany dla pewnych typów obiektów, dla pewnych
operacji lub pewnych przypadków użycia. W odróżnieniu od diagramów sekwencji
wymiar czasu nie jest bezpośrednio odwzorowany i nie ma on takiego znaczenia.
Natomiast odwzorowane są powiązania pomiędzy obiektami (prezentujące pewną część
powiązań z diagramu klas). Diagram sekwencji i komunikacji są semantycznie
równoważne  tzn. , że przekazują tę samą informację. Istnieje możliwość
przekształcenia diagramu sekwencji w diagram komunikacji i odwrotnie bez
utraty informacji.
RAFAA
KASPRZYK, copyright reserved
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY CZYNNOÅšCI
Diagramy czynności to kolejny diagram służący do modelowania dynamicznych
aspektów systemu. Diagramy te w zasadzie są schematami blokowymi, które
przedstawiają przepływ sterowania z czynności do czynności. Obrazują one
sekwencyjne bÄ…dz
to równoległe/współbieżne kroki procesu. Stanowią uogólnioną
wersję diagramów stanów, a ich podstawowym zadaniem nie jest analiza
stanów obiektu, ale modelowanie przetwarzania (przepływu zadań). Stany
diagramu czynności odpowiadają stanom wyróżnianym w trakcie
przetwarzania, a nie stanom obiektów. Czynność może być interpretowana jako
zadanie do wykonania przez człowieka lub komputer ale również jako odpowiedzialność,
operacja czy metoda klasy, a więc diagram może być tworzony na różnych
poziomach szczegółowości. Przejścia pomiędzy stanami (czynnościami) nie są
związane z nadejściem zdarzenia, ale z zakończeniem przetwarzania
specyficznego dla danej aktywności.
Diagramy czynności możemy wykorzystać na bardzo wiele sposobów. Są szczególnie
przydatne przy tworzeniu SI i to nie tyko w podejściu obiektowym. Tak więc:
üð UmożliwiajÄ…c zrozumienie procesów biznesowych
üð Doskonale nadajÄ… siÄ™ do modelowania przepÅ‚ywu zdaÅ„ i w opisie procesów
z dużą liczbą równoległych czynności
üð Wykorzystywane sÄ…, jako wygodnym sposobem analizy przypadków użycia
üð DajÄ… możliwość opisu czynnoÅ›ci warunkowych i współbieżnych
o Proces warunkowy jest przedstawiany za pomocą rozgałęzienia (ang.
branch) i scalenia (ang. marge)
o Proces współbieżnych jest przedstawiany za pomocą rozwidlenia (ang.
fork) i złączenia (ang. join)
üð OkreÅ›lajÄ… sposób realizacji rozpatrywanego dziaÅ‚ania opisujÄ…c
podstawowe reguły porządkujące (szeregujące) czynności
üð PozwalajÄ… na zobrazowanie współdziaÅ‚ania obiektów oraz okreÅ›lenie
obiektów odpowiedzialnych za wykonanie danej czynności na wysokim
poziomie abstrakcji za pomocą tzw. torów pływackich (ang. swimlines). W celu
uszczegółowienia należy stosować diagramy interakcji
üð MogÄ… być stosowane do opisu algorytmów sekwencyjnych, równolegÅ‚ych
i współbieżnych
Zmiany wprowadzone w notacji UML 2.0, a dotyczące diagramów czynności sięgają
bardzo daleko. Pierwszą widoczną zmianą jest umożliwienie zastosowania torów
(partycji) zarówno pionowych jak i poziomych (powstaje dwuwymiarowa siatka).
Pozwala to prezentować nie tylko obiekty odpowiedzialne za wykonanie danej czynności,
ale grupować czynności w większe zbiory i przypisywać im zbiorcze nazwy lub miejsca
realizacji. Inna nowością jest wprowadzenie możliwości zakończenia realizacji
scenariusza, w dowolnym miejscu jeżeli zajdzie określony warunek. Dopracowano
RAFAA
KASPRZYK, copyright reserved
również sposób przesyłania obiektów pomiędzy czynnościami wprowadzając
pojęcie żetonu (ang. token) i wtyku (ang. pin) wykorzystywanych do przekazywania
parametrów wejściowych i wyjściowych pomiędzy czynnościami. Idea ta pochodzi z sieci
Petriego.
Diagramy czynności wykorzystywane są do dynamicznego modelowania systemów. W
szczególności stosowane są do modelowania przepływu zadań i opisu algorytmów.
Mocną stroną tych diagramów jest to, że zachęcają do stosowania procesów
współbieżnych tam gdzie to tylko możliwe.
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY MASZYNY STANÓW
Diagramy maszyny stanów, nazywane również diagramami stanów, są znaną techniką
opisu zachowania się systemu. Wykorzystywane są więc do modelowania dynamicznych
aspektów systemu. W technice obiektowej diagramy te wykorzystuje się do
zobrazowania możliwych stanów obiektu oraz przejść, które powodują
zmianę stanu obiektu. Istotną zaletą diagramów maszyny stanów jest możliwość
modelowania zachowania obiektów danej klasy w oderwaniu od reszty
systemu. Są szczególnie użyteczne do modelowania historii życia obiektu.
Przedstawiają reakcje obiektów na otrzymane zdarzenia. Nadaje się więc do opisu
obiektów reaktywnych oraz projektowania systemów interakcyjnych.
Formalnie diagram maszyny stanów jest grafem skierowanym, którego
wierzchołki stanowią stany obiektu, a łuki opisują przejścia między stanami.
Przejście jest odpowiedzią obiektu na jakieś zdarzenie. Akcje są związane z
przejściami i traktuje się je jako procesy szybkie i nieprzerywalne (atomowe).
Ze stanami związane są czynności, które mogą trwać dłużej i mogą zostać
przerwane przez zdarzenie.
Diagramy maszyny stanów pozwalają również na wizualizowanie tzw. stanów
złożonych. Stan złożony powstaje w efekcie zagnieżdżania stanów i w związku z tym
może być dokomponowany na stany bardziej proste. Dekompozycja jest rodzajem
specjalizacji. Każdy z podstanów musi dziedziczyć przejścia nadstanu. Tylko jeden z
podstanów może być aktywny w danym momencie. Diagramy maszyny
stanów radzą sobie również w wypadku, gdy obiekt ma pewne zbiory
niezależnych zachowań czyli może znajdować się w kilku stanach
równocześnie (tzw. stany współbieżne). Jeśli jednak dla jednego obiektu jest
klika skomplikowanych diagramów stanów współbieżnych, to dobrom
praktyką jest próba rozbicia tego obiektu na kilka prostszych.
Reasumując elementy diagramów stanów to:
üð Stany  mogÄ… mieć nazwy, a identyfikowane sÄ… na trzy sposoby:
o Wartości atrybutów obiektu
o Czas, gdy obiekt oczekuje na nadejście jakiegoś zdarzenia
żð event zdarzenie(a:T)/[warunek]/akcja
o Czas, w którym obiekt wykonuje jakieś czynności
żð do/czynność1/czynność2/&
üð Zdarzenia  bodz
ce, które mogą uruchomić przejścia pomiędzy stanami
o Wolanie  operacja(a:T), synchroniczne wywołanie żądania, gdzie obiekt
wołający czeka na wynik
o Zmiana  when(wyrażenie), ciągłe czekania na spełnienie warunku
o Sygnał  sygnał(a:T), asynchroniczna komunikacja jednokierunkowa
RAFAA
KASPRZYK, copyright reserved
o Czas  after(czas), uzależnienie od czasu określanego bezwzględnie lub
względnie
üð PrzejÅ›cia  wskazujÄ…, że obiekt przejdzie z jednego stanu do drugiego,
o ile zajdzie określone zdarzenie i będą spełnione warunki
o zdarzenie(a:T)[warunek]/akcja  przejścia zewnętrzne i wewnętrzne
o [warunek]/akcja  przejście automatyczne
o entry/akcja1we/akcja2we/&  wykonanie akcji podczas wejścia do stanu
o exit/akcja1wy/akcja2wy/&  wykonanie akcji podczas wyjścia ze stanu
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY PRZEGL
DU INTERAKCJI
Diagramy przeglądu interakcji są krzyżówką diagramów czynności i
diagramów sekwencji i/lub komunikacji. Należy je traktować tak, jak diagramy
czynności, w których czynności (aktywności) są zastąpione przez diagramy sekwencji.
Istnieje możliwość stosowania dwóch rodzajów elementów interakcyjnych:
üð prostokÄ…ty posiadajÄ…ce nazwÄ™ diagramu sekwencji i stanowiÄ…ce jego referencjÄ™,
zaznaczaną słowem kluczowym REF, które znajduje się w lewym górnym rogu
üð diagramy sekwencji bÄ…dz
komunikacji , które mogą być bezpośrednio
zagnieżdżane w diagramach przeglądu interakcji
Ponieważ diagramy przeglądu interakcji są nowością, to trudno stwierdzić, jak przydatne
okażą się w praktyce.
RAFAA
KASPRZYK, copyright reserved
DIAGRAMY PRZEBIEGÓW CZASOWYCH
Diagram przebiegów czasowych jest nowym diagramem interakcji, w którym
nacisk kładzie się na ograniczenia czasowe  albo dla pojedynczego obiektu, albo,
co bardziej pożyteczne dla całej grupy obiektów. Na jego pojawienie się czekali przede
wszystkim projektanci systemów czasu rzeczywistego i aplikacji, których działanie jest
uzależnione od współpracy z urządzeniami wejścia/wyjścia.
Diagram przebiegów czasowych obrazuje zachowanie obiektu z naciskiem na
dokładne określenie czasu, w którym obiekt jest poddawany jakimś zmianą
lub sam wykonuje jakieś działanie.
Diagramy czasowe przydają się do obrazowania ograniczeń czasowych
występujących między zmianami stanów różnych obiektów. Są szczególnie
przyjazne dla inżynierów zajmujących się projektowaniem urządzeń.
RAFAA
KASPRZYK, copyright reserved
y
ródła:
Martin Fowler, UML w kropelce  wersja 2.0, LTP, Warszawa 2005
Michał Śmiałek, Zrozumieć UML 2.0. Metody modelowania obiektowego, Helion, Gliwice
2005
http://www.holub.com/goodies/uml/
http://www.agilemodeling.com/essays/umlDiagrams.htm
RAFAA
KASPRZYK, copyright reserved