Mimo że zaczęliśmy od diagramów klas, bardzo często pracę nad projektem rozpoczyna się od diagramów przypadków użycia.
Diagramy klas miały na celu głównie zainteresować
cię ideą projektowania aplikacji przed
przystąpieniem do programowania. Teraz
jednak nadszedł czas na diagramy przypadków
użycia. Jeśli uważnie śledzisz nasz kurs, materiał
przedstawiony w tej części nie sprawi ci najmniejszego
problemu.
Aktorzy
Aktorzy reprezentują spójny zbiór ról, jakie
odgrywają użytkownicy przypadku użycia w czasie
interakcji z danym przypadkiem użycia. Aktorzy
mogą reprezentować stanowiska i funkcje w danej
organizacji, mogą to być także systemy zewnętrzne
aplikacji (podsystem, baza danych itd.) czy też
urządzenia.
|
|
|
Aktorzy są najczęściej prezentowani jako
proste postacie, tak jak to pokazano na rysunku
1. Jeśli twój program nie pozwala na utworzenie
podobnych aktorów, inną dozwoloną notacją jest
kwadrat znany z diagramów klas wraz ze stereotypem
{html}<
z obu reprezentacji aktorów ci nie odpowiada,
standard UML pozwala użyć zdefiniowanej samodzielnie
ikony – nie zawsze jest to jednak możliwe
do wykonania w programach.
I jeszcze słów kilka na temat nazw aktorów.
Powinien to być rzeczownik bądź określenie rzeczownikowe
w liczbie pojedynczej. Pamiętaj, że
nawet jeśli firma zatrudnia wielu sprzedawców, to
z puntu widzenia systemu będą oni obsługiwani
jednakowo. Pamiętaj też, że nazwami aktorów nie
powinny być imiona pracowników!
Przypadek użycia
Opisani wyżej aktorzy, a więc użytkownicy
projektowanego przez nas systemu, oczekują od
niego, aby oferował on określoną funkcjonalność.
Każdy z aktorów potrzebuje innej funkcjonalności
systemu (jednak może się ona miejscami nakładać,
a więc pewne funkcje mogą być potrzebne jednocześnie
kilku aktorom). Te funkcjonalności to inaczej
mówiąc zadania, jakie system musi spełniać.
|
|
|
Zadania to jednocześnie nasze przypadku użycia.
Oficjalnie (a co za tym idzie mniej przejrzyście
i zawile) przypadek użycia jest specyfikacją akcji
i ich wariantów, które poprzez interakcje z aktorami
systemu, system może wykonać.
Czym jest więc przypadek użycia? Najprościej
rzecz ujmując, jest on działaniem, jakie realizuje
system w odpowiedzi na aktywność aktora.
Przypadki użycia na diagramach UML prezentuje
się w postaci elips z umieszczonymi w środku nazwami
(zobacz rysunek 3). Na rysunku 4 zaprezentowana
jest alternatywna notacja przypadków użycia.
Związki
Typy związków, jakie są używane w przypadkach
użycia, już znasz. Głównym związkiem jest
asocjacja. To ona jest najczęściej spotykana. O czym
nam ona mówi? O wystąpieniu dwukierunkowej
komunikacji pomiędzy przypadkiem użycia a aktorem. Jeśli komunikacja ta przebiega tylko w jednym
kierunku, można kierunek ten zaznaczyć strzałką.
W przypadku diagramów użycia, związkom nie
nadaje się nazw.
Na rysunku 5 zaprezentowany został przykładowy
diagram klas. Zauważ, że aktorzy klient oraz
sprzedawca dzielą między sobą część przypadków
użycia. Dzięki temu obsługa sklepu on-line może za
klienta złożyć zamówienie w przypadku, gdy klient
skontaktuje się z obsługą telefonicznie.
Innym związkiem, już o wiele rzadziej spotykanym
w przypadkach użycia, jest zawieranie. Zawierany
przypadek użycia nie jest wykonywany samodzielnie.
|
|
|
Związek zawierania ma postać przerywanej
strzałki ze stereotypem {html}<
przypadku użycia zawierającego do zawieranego.
Związku zawierania używa się wówczas, gdy
z kilku innych przypadków użycia można wydzielić
pewną część wspólną. Przyjrzyj się rysunkowi 6
– zamiast przypadków użycia \”Sprawdź dostępność
towarów, a następnie zapakuj zamówienie\”,
\”Sprawdź dostępność towarów a następnie złóż
zamówienie\” i \”Sprawdź dostępność towarów, a następnie
przekaż zamówienie do realizacji\” mamy
\”Zapakuj zamówienie\”, \”Złóż zamówienie\” i \”Przekaż
zamówienie do realizacji\” z wydzielonym osobnym
przypadkiem użycia \”Sprawdź dostępność towaru\”.
Kolejnym związkiem jest rozszerzanie.
|
|
|
Związek ten pozwala na wydzielenie przypadku
użycia, który w pewnych sytuacjach może zostać
wzbogacony o dodatkowe opcje. Wygląda on tak
samo jak związek zawierania, jednak ma stereotyp
{html}<
użycia \”Dodaj towar do koszyka\” oraz \”Usuń towar
z koszyka\” rozszerzają przypadek użycia \”Przelicz
wartość koszyka\”.
Ostatnim poznanym dziś związkiem będzie
uogólnienie. Jak sama nazwa wskazuje, ma on
na celu uogólnienie aktorów bądź przypadków
użycia, przy czym obiekt uogólniany posiada
wszystkie cechy obiektu ogólnego. Uogólnienie ma
postać strzałki z linią ciągłą i zamkniętym grotem.
Uogólnienie zostało zaprezentowane na rysunku 8
– aktorzy Dział zamówień oraz Sprzedzwca on-line
są specjalizacjami aktora Pracownik sklepu.
Zakończenie
W następnym odcinku będziemy kontynuowali
naukę przypadków użycia, dlatego uważnie
zanalizuj materiał zawarty w tej części. Zauważ, że
tworząc diagram przypadków użycia, musisz dobrze
zastanowić się nad funkcjonalnością projektowanego
systemu.
Dzięki temu często już na etapie
projektowania okazuje się, że nie przewidziano
w systemie pewnych fundamentalnych funkcjonalności
albo też że niektóre z planowanych można
wyeliminować.
