RAFAŁ 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ą

RAFAŁ KASPRZYK, copyright reserved

o Przypadki użycia ułatwiają zadanie ustalenia priorytetów dla wymagań

funkcjonalnych

 Odpowiedź 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

RAFAŁ 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.

RAFAŁ 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ądź wiele interfejsów. Interfejs definiuje zewnętrznie
obserwowane zachowanie klasy lub komponentu, określając zbiór deklaracji
operacji, ale nigdy sposobu implementacji.

RAFAŁ KASPRZYK, copyright reserved

RAFAŁ 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 ź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ą luźno powiązane
najczęściej za pomocą zależności i realizacji.

RAFAŁ KASPRZYK, copyright reserved

RAFAŁ 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ęźle, co ma na celu parametryzację
relacji pomiędzy różnymi programowymi i sprzętowymi technologiami. Specyfikacja
wdrożenia jest obrazowana za pomocą stereotypu <<deploymentSpecyfication>>
Ciekawym elementem jest również tzw. środowisko wykonania. Element ten
reprezentuje wybrany rodzaj platformy i jest obrazowany za pomocą stereotypu
<<ExecutionEnvironment>>

RAFAŁ KASPRZYK, copyright reserved

RAFAŁ 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ń.

RAFAŁ KASPRZYK, copyright reserved

DAIGRAMY STRUKTUR ZŁ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 wyraź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:
<<role binding>>, <<represents>>, <<occurrence>>

Ponieważ struktury złożone są nowością, to trudno stwierdzić, jak przydatne okażą się w
praktyce.

RAFAŁ KASPRZYK, copyright reserved

RAFAŁ 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 ź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.

RAFAŁ KASPRZYK, copyright reserved

RAFAŁ 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.

RAFAŁ 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.

RAFAŁ 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.

RAFAŁ KASPRZYK, copyright reserved

RAFAŁ 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ądź 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

RAFAŁ 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.

RAFAŁ 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 – bodź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

RAFAŁ 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

RAFAŁ 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ądź 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.

RAFAŁ 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ń.

RAFAŁ KASPRZYK, copyright reserved

Ź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

RAFAŁ KASPRZYK, copyright reserved