plik

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

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

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

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

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

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

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

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