Inżynieria oprogramowania

Wykład IV. Przypadki użycia

Politechnika Radomska

O czym będzie ?

definicja przypadków użycia,
tworzenie przypadków użycia,
zawieranie przypadków użycia,
rozszerzanie przypadków użycia,
rozpoczynanie analizy przypadków użycia.
przedstawienie modelu przypadków użycia,
pokazanie związków między przypadkami użycia,
zrozumienie roli diagramów przypadków użycia w

procesie budowania systemu,
tworzenie i stosowanie modeli przypadków użycia,
tworzenie ogólnego obrazu przeglądowego UML-a.

Potrzebny jest obraz

systemu widzianego od

strony użytkownika

Na poprzednich wykładach zajmowaliśmy się głównie

diagramami dającymi statyczny obraz systemu. Teraz pora na

zajęcie

się

diagramami

ukazującymi

perspektywę

dynamiczną i pokazanie, w jaki sposób system i jego klasy

zmieniają się w czasie.
Perspektywa statyczna ułatwia analitykowi komunikowanie

się z klientem. Perspektywa dynamiczna, jak się przekonacie,

pozwala na komunikowanie się z grupą tworzącą

oprogramowanie — z projektantami i z programistami.
To prawda, że klient i twórcy oprogramowania stanowią grupę

osób zainteresowanych systemem i mających wielki wpływ

na jego tworzenie, ale dla dopełnienia obrazu nie możemy

pominąć jeszcze jednego ważnego elementu tej układanki -

użytkownika.

Spróbujemy wyjaśnić

czym są przypadki użycia

Ani perspektywa statyczna, ani dynamiczna nie ilustrują

zachowania systemu z punktu widzenia użytkownika.

Zrozumienie jego punktu widzenia jest sprawą kluczową,

jeżeli chcemy zbudować system przydatny i łatwy w

użyciu, to znaczy taki, który wypełnia żądania

użytkowników i nie sprawia im kłopotu, a może nawet

dostarcza rozrywki.
Modelowanie systemu z punktu widzenia użytkownika

oznacza zajmowanie się przypadkami użycia. Spróbujemy

zatem wyjaśnić, czym są przypadki użycia i do czego służą.
W drugiej części wykładu wyjaśnimy, w jaki sposób

przypadki użycia są przedstawiane na diagramach UML-a.

Przykład - Kupowanie

faksu

Kilka lat temu kupiłem faks. Gdy poszedłem do sklepu, znalazłem

wielki wybór różnego rodzaju urządzeń różnych marek. W jaki

sposób dokonałem wyboru?

– Zastanowiłem się, do czego właściwie ten przyrząd ma służyć.
– Jakie jego funkcje są mi potrzebne?
– Które funkcje są absolutnie niezbędne?
– Czy chcę również kopiować?
– Czy będę łączyć faks z komputerem?
– Czy będę używać faksu jako skanera?
– Czy będę wysyłać faksy tak szybko, że potrzebna będzie funkcja

szybkiego wybierania numerów?

– Czy potrzebna będzie funkcja automatycznego odróżniania

przychodzącego faksu od przychodzącej rozmowy telefonicznej?

Analiza przypadków

użycia

Zawsze, gdy dokonujemy zakupów, przechodzimy przez tego

rodzaju proces - poza przypadkami, gdy bez namysłu

odpowiadamy na wewnętrzny impuls.
Wszystkie rozważania tego rodzaju są formą analizy

przypadków użycia.
Pytamy siebie, w jaki sposób chcemy używać danego produktu

lub systemu, na który zamierzamy wydać sporą sumę, tak aby

później spełniał nasze potrzeby.
Ważne jest, abyśmy zdawali sobie sprawę z tego, jakie

naprawdę są nasze potrzeby i wymagania.
Dokonanie tego jest sprawą zasadniczą w fazie analizy

systemu, który ma powstać. Sposób korzystania z systemu

przez użytkowników określa, jak należy go projektować i

budować.

Przypadek użycia,

scenariusz, aktorzy

Przypadek użycia to konstrukcja, która pomaga analitykowi

wspólnie z użytkownikami określić, jak system ma być

używany.
Zbiór przypadków użycia opisuje system za pomocą pojęć

określających, co użytkownicy zamierzają z nim robić.
Myśl o przypadku użycia jako o zbiorze scenariuszy

opisujących używanie systemu.
Każdy scenariusz to ciąg zdarzeń.
Każdy ciąg jest inicjowany przez osobę, inny system, jakieś

urządzenie lub upływ czasu.
Byty, które inicjują ciąg zdarzeń, nazywamy aktorami.
Rezultatem zainicjowanego ciągu zdarzeń jest coś, co służy

aktorowi, który dokonał inicjacji, albo innemu aktorowi.

Przypadki użycia —

dlaczego są ważne?

Diagram klas jest doskonałym narzędziem skłaniającym klienta

do mówienia o systemie z jego punktu widzenia, zaś przypadki

użycia pobudzają do mówienia użytkowników i pozwalają

spojrzeć na system z ich perspektywy.
Użytkownikom często trudno wyrazić słowami, w jaki sposób

zamierzają

korzystać

z

systemu.

Ponieważ

tradycyjnie

tworzeniem systemów rządził raczej przypadek, wstępna analiza

była zwykle krótka. Użytkownicy bywają zdumieni, gdy ktoś pyta

o ich punkt widzenia.
Podstawą omawianego działania jest skłonienie użytkowników do

udziału we wczesnym stadium analizowania i projektowania

systemu. Zwiększa to prawdopodobieństwo, że system

ostatecznie stanie się przydatnym i przyjaznym narzędziem, a

nie

niezrozumiałym

i

niepotrzebnym

ludziom

biznesu

monumentem wyspecjalizowanej wiedzy.

Przykład: automat do

sprzedaży napojów

gazowanych

Załóżmy, że mamy zaprojektować automat do sprzedaży

napojów

gazowanych.

Aby

poznać

punkt

widzenia

użytkowników, przeprowadzamy z nimi wywiady i staramy się

dowiedzieć, w jaki sposób wyobrażają sobie własną interakcję

z tym urządzeniem.
Ponieważ głównym zadaniem automatu jest umożliwienie

użytkownikowi kupienia puszki napoju, jest prawdopodobne,

że użytkownicy szybko powiedzą nam, że powinniśmy się

skupić na zbiorze scenariuszy - mówiąc inaczej: przypadku

użycia - który można nazwać „Kup napój”.
Przyjrzymy się zatem możliwym scenariuszom tworzącym ten

przypadek użycia. Pamiętajmy, że podczas rzeczywistego

tworzenia systemu te scenariusze pojawiają się w wyniku

rozmów z użytkownikami.

Scenariusz „Kupuj napój”

Przypadek

użycia

określa

zbiór

scenariuszy wykonujących dla aktora

jakieś pożyteczne zadanie.
W tym przykładzie zajmujemy się

przypadkiem użycia „Kup napój”
W tym przypadku użycia aktorem jest

osoba, która chce kupić puszkę napoju

gazowanego.
Osoba ta inicjuje scenariusz, wrzucając

monetę do maszyny. Potem dokonuje

selekcji. Jeżeli wszystko przebiegnie

bez zakłóceń i w automacie jest choć

jedna puszka, klient otrzyma to, co

chciał.

Inne aspekty scenariusza

Oprócz powyższej sekwencji kroków należy
wziąć pod uwagę inne aspekty scenariusza.

– Jakie

warunki

początkowe

motywują

kupującego do zainicjowania scenariusza z
przypadku użycia „Kup napój”? Najbardziej
oczywistą przyczyną jest pragnienie.

– Jakie są warunki końcowe wykonania kolejnych

kroków scenariusza? To również jest oczywiste:
dana osoba ma puszkę napoju.

Inne możliwe scenariusze

Czy zbiór scenariuszy tworzących przypadek
użycia „Kup napój” składa się tylko z tego jednego
ciągu zdarzeń? Na myśl natychmiast przychodzą
inne. Może się zdarzyć, że w automacie brakuje
puszek, których potrzebuje użytkownik.
Może się zdarzyć, że kupujący nie ma dokładnie
takiej sumy, jaką powinien wrzucić do automatu.
Jak powinniśmy zaprojektować automat do
sprzedaży napojów gazowanych, aby realizował
różne scenariusze?

Zajmijmy się scenariuszem „brak

towaru” , który również należy do

przypadku użycia „Kup napój”.

Myśl o nim jako o alternatywnym ciągu zdarzeń. Kupujący

inicjuje przypadek użycia przez wrzucenie pieniędzy do

automatu.
Potem dokonuje wyboru. W automacie nie ma ani jednej

puszki wybranego rodzaju, więc wysyła on do kupującego

komunikat informujący o braku. Komunikat ten powinien

zawierać propozycję wybrania puszki innego rodzaju.
Automat powinien także udostępnić kupującemu możliwość

zwrotu pieniędzy. W tym momencie kupujący żąda zwrotu

pieniędzy lub wybiera inny rodzaj puszki, którą automat

następnie dostarcza (jeżeli ją ma).
Warunkiem początkowym jest spragniony kupujący, a

warunkiem końcowym — kupujący z puszką napoju lub ze

zwróconymi pieniędzmi.

Teraz przyjrzyjmy się

scenariuszowi

„niewłaściwa suma

pieniędzy”.

Również w tym przypadku kupujący inicjuje przypadek użycia

przez wrzucenie pieniędzy i dokonanie wyboru.
Załóżmy, że w automacie jest odpowiednia puszka. Jeżeli automat

ma zapas odpowiednich monet do rozmienienia wrzuconej

monety na drobne, wyda kupującemu puszkę i wypłaci resztę.
Jeżeli automat nie ma odpowiednich monet do wydania reszty,

zwróci pieniądze i wyśle komunikat z prośbą o wrzucenie

odpowiedniej sumy.
Warunek wstępny nie zmienił się. Warunek końcowy to puszka

wody i wydana reszta lub zwrot wrzuconych pieniędzy.
Inną możliwością jest, że zaraz po wyczerpaniu pieniędzy na

wydawanie reszty wyświetlany jest komunikat o konieczności

wrzucania dokładnie odliczonej sumy pieniędzy. Komunikat ten

znikałby dopiero po uzupełnieniu zapasu monet.

Dodatkowe przypadki

użycia

Przyjrzeliśmy się automatowi do wody sodowej z

punktu widzenia tylko jednego użytkownika -

kupującego, ale na scenie pojawiają się inni

użytkownicy.
Dostawca musi napełniać automat puszkami z wodą

sodową, a inkasent (może to być ta sama osoba)

musi odbierać zebrane pieniądze.
Oznacza to, że musimy stworzyć przynajmniej dwa

dodatkowe przypadki użycia „Dostarcz towar” i

„Zainkasuj pieniądze”. Ich szczegóły staną się jasne

po przeprowadzeniu wywiadów z dostawcą i

inkasentem.

Weźmy pod uwagę

przypadek użycia

„Dostarcz towar”

Dostawca inicjuje ten przypadek użycia po upływie

pewnego określonego czasu (powiedzmy tygodnia lub

dwóch).
Przedstawiciel

dostawcy

odbezpiecza

automat

(prawdopodobnie otwiera zamek, ale to sprawa

implementacji), otwiera drzwi i wypełnia przedziały

puszkami odpowiedniego rodzaju.
Uzupełnia także zapas pieniędzy do wydawania reszty.

Potem zamyka drzwi automatu i zabezpiecza je.

Warunkiem

początkowym

jest

tutaj

upłynięcie

odpowiedniego czasu, a warunkiem końcowym -

przywrócenie automatowi możliwości sprzedawania

puszek.

Przypadek „Zainkasuj

pieniądze”

W przypadku użycia „Zainkasuj pieniądze”

inkasent również rozpoczyna działanie wskutek

upływu ustalonego czasu.
Najpierw wykonuje tę samą sekwencję kroków co

dostawca w przypadku użycia „Dostarcz towar”,

tzn. odbezpiecza automat i otwiera drzwi.
Potem wyjmuje z automatu pieniądze.
Kolejne kroki są znów takie same jak w przypadku

użycia „Dostarcz towar”. Warunek początkowy to

upływ wyznaczonego czasu, a warunek końcowy

to pieniądze w rękach inkasenta.

Określając przypadki

użycia nie zajmujemy się

ich implementacją

W naszym przykładzie nie skupialiśmy się na tym, co

znajduje się w środku automatu do sprzedaży napojów

gazowanych. Nie interesuje nas, jak działa mechanizm

chłodzący i co urządzenie robi z wrzucanymi pieniędzmi.
Próbujemy jedynie spojrzeć na urządzenie z perspektywy

kogoś, kto ma go użyć. Celem jest otrzymanie zbioru

przypadków

użycia,

który

przekażemy

projektantom

automatu

sprzedającego

napoje

gazowane

i

jego

konstruktorom.
Aby rozszerzyć nasz zbiór przypadków użycia, zastanówcie

się, czego jeszcze mogą potrzebować kupujący napój, jego

dostawcy i inkasenci pieniędzy. Jeżeli zbiór będzie pełny,

powstanie

automat

zadawalający

wszystkie

grupy

użytkowników.

Zawieranie przypadków

użycia

Oba przypadki użycia: „Dostarcz towar” i „Zainkasuj pieniądze”

częściowo zawierają te same sekwencje kroków. Oba zaczynają się od

odbezpieczenia automatu i otwarcia drzwi i kończą zamknięciem drzwi i

zabezpieczeniem automatu. Czy możemy wyeliminować powtarzanie się

tych samych kroków w różnych przypadkach użycia?
Tak. Rozwiązaniem jest wydzielenie powtarzających się ciągów zdarzeń i

uznanie ich za oddzielne przypadki użycia. Połączymy kroki „odbezpiecz

automat” i „otwórz drzwi” w przypadek użycia „Udostępnij wnętrze”, zaś

kroki „zamknij automat” i „zabezpiecz drzwi” w przypadek „Zablokuj

dostęp”.
Mając w ręku te dwa nowe przypadki użycia, przypadek „Dostarcz towar”

rozpoczynamy od przypadku „Udostępnij wnętrze”, potem wykonujemy

te same kroki co poprzednio i kończymy przypadkiem „Zablokuj dostęp”.
Jak widać, przypadki użycia „Dostarcz towar” i „Zainkasuj pieniądze”

zawierają w sobie inne przypadki użycia. Tę technikę wielokrotnego

używania nazywamy zawieraniem przypadków użycia.

Rozszerzanie przypadków

użycia

Nie tylko zawieranie umożliwia wielokrotne korzystanie z przypadków
użycia. Czasami tworzymy nowy przypadek przez dodanie kilku kroków
do już istniejącego.
Wróćmy do przypadku „Dostarcz towar”. Przypuśćmy, że przed
włożeniem puszek do automatu pracownik dostawcy notuje, które
rodzaje sprzedają się dobrze, a które źle. Następnie przed ponownym
napełnieniem pojemników osobnik ten opróżnia pojemniki z puszkami
napojów, które się źle sprzedają i wkłada tam puszki firm, które
zdobyły sobie popularność na rynku. Potem na przedniej ścianie
automatu umieszcza informacje o zmianie asortymentu.
Po dodaniu nowych kroków do „Dostarcz towar” otrzymujemy nowy
przypadek użycia, który możemy nazwać „Dostarcz towar według
wyników sprzedaży”. Ten nowy przypadek będzie rozszerzeniem
przypadku oryginalnego, a zastosowaną technikę nazywamy
rozszerzaniem przypadków użycia.

W świecie rzeczywistym

przystąpienie do analizy przypadków

użycia wymaga poddania się

wymogom kilku procedur.

Po rozpoczęciu wywiadów z klientem lub z ekspertami przystępujemy do

tworzenia diagramów klas, o czym mówiliśmy na poprzednich wykładach.

To pozwala na ogólne zapoznanie się z dziedziną, z którą mamy do

czynienia, i z pojęciami, które będą stosowane. W ten sposób tworzy się

bazę do rozmów z użytkownikami.
W wywiadach z użytkownikami (lepiej z grupami użytkowników) należy

wypytywać o wszystko, co zamierzają robić z systemem, którego

projektowanie rozpoczynacie. Ich odpowiedzi pozwolą na stworzenie

zestawu kandydatów na przypadki użycia. Potem ważną rzeczą jest

opisanie każdego przypadku użycia. Musicie także ustalić listę aktorów

inicjujących i korzystających z przypadków użycia. Ta faza zwiększy

Waszą umiejętność rozmawiania z użytkownikami ich własnym językiem.
Przypadki użycia okażą się pomocne również w kilku następnych fazach

procesu tworzenia systemu. Pomogą w projektowaniu interfejsu

użytkownika, tworzącym oprogramowanie ułatwią dokonywanie wyborów

oraz staną się podstawą testowania nowo utworzonego systemu.

Korzyści ze stosowania

„przypadków użycia”

Stosowanie pojęcia „przypadek użycia” przynosi sporo

korzyści, a stają się one znacząco większe, jeżeli na

dodatek

za

pomocą

języka

UML

zastosujemy

wizualizację.
Pokazanie użytkownikom przypadków użycia w postaci

graficznej ułatwia uzyskanie dodatkowych informacji.

Jest rzeczą sprawdzoną, że użytkownicy zwykle wiedzą

więcej, niż potrafią wypowiedzieć, a stosowanie

przypadków użycia ułatwia przełamanie tej niemożności.
Ponadto graficzne przedstawienie ułatwia łączenie

diagramów przypadków użycia z diagramami innych

typów.

Cel analizy systemu

Jednym z celów procesu analizy systemu jest
stworzenie zbioru przypadków użycia.
Dążymy do skatalogowania przypadków użycia,
aby można się było do nich odwoływać w celu
poznania

systemu

z

punktu

widzenia

użytkownika.
Gdy nadejdzie pora na opracowanie nowej wersji
systemu, katalog przypadków użycia posłuży
jako podstawa do zbierania informacji na temat
wymagań, które ma spełniać nowa wersja.

Aktorzy

Aktor inicjuje przypadek użycia i aktor (być może

ten sam, ale niekoniecznie) otrzymuje jakąś

wartość przez ten przypadek utworzoną.
Łatwo to przedstawić w postaci graficznej. Aktora

inicjującego umieszczamy na lewo od przypadku

użycia, a aktora czerpiącego korzyść - na prawo.
Nazwę przypadku użycia umieszczamy wewnątrz

elipsy lub tuż pod nią. Linia powiązania łączy aktora

z przypadkiem użycia i reprezentuje komunikację

między nimi. Jest to linia ciągła, taka sama, jaką

stosujemy, przedstawiając powiązania klas.

Granice systemu

Jedną z korzyści płynących ze stosowania
analizy przypadków użycia jest wyznaczanie
granicy

między

systemem

i

światem

zewnętrznym.
Aktorów zwykle umieszczamy poza systemem,
przypadki użycia - wewnątrz.
Granice systemu przedstawiamy w postaci
prostokąta z nazwą systemu umieszczoną
gdzieś w środku. Wewnątrz tego prostokąta
umieszczamy przypadki użycia.

Prezentacja modelu

przypadków użycia

W modelu przypadków użycia schematyczna
figurka człowieka reprezentuje aktora, elipsa
- przypadek użycia, a ciągła linia powiązania
- komunikacją między aktorem i przypadkiem
użycia

Wracamy do przypadku

automatu do sprzedaży

napojów gazowanych

Zastosujmy wprowadzone symbole

do

przypadku

rozważanego

poprzednio.

Jak

zapewne

pamiętacie, zajmowaliśmy się tam

automatem sprzedającym napoje

gazowane. Przypadek użycia „Kup

napój”

został

umieszczony

wewnątrz

systemu

razem

z

przypadkami „Dostarcz towar” i

„Zainkasuj pieniądze”.
Aktorzy to: kupujący, pracownik

dostawcy i inkasent. Na rysunku

widzimy

UML-owy

model

przypadków użycia dla automatu

do sprzedaży napojów.

Śledzenie kroków

scenariuszy

Każdy przypadek użycia jest zbiorem scenariuszy, a
każdy scenariusz — ciągiem kroków. Jak widać, kroki
te nie są pokazywane na diagramie. Nie ma ich
także w notatkach załączanych do przypadków
użycia.
Choć UML tego nie zakazuje, przypisywanie notatek
do każdego przypadku użycia znacznie pogorszyłoby
klarowność diagramu, a właśnie klarowność jest
rzeczą podstawową. A zatem w jaki sposób i gdzie
możemy prześledzić kroki scenariuszy?

Diagramy umieszczamy w

dokumentacji produktu

Diagramy przypadków użycia są zwykle częścią dokumentacji

projektu przeznaczonej dla klientów i twórców oprogramowania.
Każdemu diagramowi jest poświęcana oddzielna strona. Oddzielną

stronę tworzy się także dla scenariusza każdego przypadku

użycia. Oto elementy wyliczane na takiej liście:

 aktor, który inicjuje przypadek użycia,
 warunki wstępne przypadku użycia,
 kroki scenariusza,
 warunki końcowe scenariusza,
 aktor, który czerpie korzyść z przypadku użycia.

Można także dodać listę założeń dla danego scenariusza (na

przykład, że w danej chwili z automatu do napojów może

korzystać tylko jeden użytkownik) oraz jego krótki, jednozdaniowy

opis.

Pokazywanie kroków

scenaruisza

Poprzednio omówiliśmy kilka alternatywnych
scenariuszy przypadku użycia „Kup napój”. W
opisie

można

podać

dwa

niezależne

scenariusze („Niewłaściwa suma pieniędzy” i
„Brak towaru”) lub potraktować je jako
odstępstwa od scenariusza podstawowego.
Szczegóły realizacji zależą od Was, od klientów
i użytkowników.
Innym sposobem pokazania kroków scenariusza
jest diagram czynności.

Związki między

przypadkami użycia

We wspomnianym przykładzie zostały pokazane dwa

przykłady związków między przypadkami użycia. Jeden

to zawieranie, które pozwala na wielokrotne użycie

ciągu kroków z jednego przypadku użycia wewnątrz

innego. Druga możliwość - rozszerzanie pozwala na

tworzenie nowych przypadków użycia przez dodawanie

kroków do przypadków już istniejących.
Dwa inne rodzaje związków to uogólnienie i

grupowanie.

Uogólnienie

oznacza,

że

jeden

przypadek użycia dziedziczy z innego przypadku użycia

- dokładnie tak, jak było w przypadku uogólnienia klas.

Grupowanie jest prostym sposobem tworzenia

zestawów przypadków klas.

Zawieranie

Przypatrzmy się przypadkom użycia „Dostarcz towar” i

„Zainkasuj

pieniądze”.

Oba

rozpoczynały

się

od

odbezpieczenia automatu i otwarcia jego drzwi i oba

kończyły się zamknięciem i zabezpieczeniem drzwi. Kilka

pierwszych kroków zostało wyodrębnionych w przypadku

„Udostępnij wnętrze”, a kilka ostatnich - w przypadku

„Zlikwiduj dostęp”. Zarówno „Dostarcz towar”, jak i

„Zainkasuj pieniądze” zawierają oba te przypadki częściowe.
Zawieranie przypadków użycia oznaczamy tym samym

symbolem co zależność klas. Jest to linia przerywana

zakończona grotem strzały wskazującym na niezależny

przypadek użycia (czyli ten, od którego zależy inny

przypadek). Nad linią związku zawierania umieszczamy w

nawiasach francuskich stereotyp «include».

Model przypadków użycia z

zawieraniem na przykładzie

automatu do napojów

Na

rysunku

widzimy

związek zawierania w

modelu

przypadków

użycia

automatu

do

napojów.
W notatce tekstowej

opisującej kolejne kroki

ciągu zdarzeń należy

wyliczyć

zawarty

przypadek

użycia.

Pierwsze

kroki

przypadku

„Dostarcz

towar”

zawierają

przypadek „Udostępnij

wnętrze”.

Rozszerzenie

W przykładzie przypadek użycia „Dostarcz towar” został rozszerzony do

przypadku „Dostarcz towar według wyników sprzedaży”, w którym,

zamiast zwykłego uzupełnienia zapasu puszek we wszystkich

pojemnikach, przedstawiciel dostawcy zwraca uwagę na to, które rodzaje

sprzedają się dobrze, a które zalegają w pojemnikach, i ładuje automat

najbardziej popularnymi.
Ten nowy przypadek użycia nazywamy rozszerzeniem oryginalnego,

ponieważ poprzedni ciąg zdarzeń zostaje uzupełniony o nowe kroki.

Przypadek oryginalny nazywamy podstawowym.
Rozszerzenie może mieć miejsce jedynie w wybranych punktach ciągu

kroków przypadku podstawowego. Punkty te nazywamy miejscami

rozszerzenia. W przypadku użycia „Dostarcz towar” nowe kroki

(dotyczące sprawdzania sprzedaży i wypełniania pojemników) powinny

znaleźć się w tym miejscu, gdzie pracownik dostawcy po otworzeniu

automatu jest gotów do napełniania pojemników puszkami różnych

rodzajów. W tym przypadku miejscu rozszerzenia można nadać nazwę

„Napełnij pojemniki”.

Diagram przypadków

użycia z rozszerzeniem i

zawieraniem

Tak samo jak zawieranie,

rozszerzenie

przedstawiamy za pomocą

oznaczenia zależności (linii

przerywanej

z

grotem

strzały) z ujętą w nawiasy

francuskie

nazwą

stereotypu «extend».

Punkt rozszerzenia wpisujemy wewnątrz elipsy przypadku

użycia pod jego nazwą.
Na rysunku widzimy związek rozszerzający przypadek użycia

„Dostarcz towar” do przypadku „Dostarcz towar według

wyników sprzedaży” oraz związki zawierania dla przypadków

„Dostarcz towar” i „Zainkasuj pieniądze”.

Uogólnienie

Jedna klasa (potomek) może dziedziczyć po innej

(przodek). To samo dotyczy przypadków użycia,

które mogą dziedziczyć zachowanie i wartości.

Potomek do tego, co odziedziczy po przodku, może

dodać własne zachowanie. Potomka możemy

używać wszędzie, gdzie jest możliwe użycie

przodka.
W naszym przykładzie można wyobrazić sobie

przypadek użycia „Kup kubek napoju” dziedziczący

po przypadku „Kup napój”. Potomek dodaje takie

zachowania jak „Dodaj lodu” i „Zmieszaj kilka

rodzajów napojów”.

Jeden przypadek użycia

może po innym

dziedziczyć zachowanie

Uogólnienie

przypadków

użycia

przedstawiamy na diagramie w taki
sam sposób jak uogólnienie klas — za
pomocą linii ciągłej z niewypełnionym
grotem wskazującym na przodka, jak
to zostało pokazane na rysunku.

Związek uogólnienia może istnieć

między aktorami, tak samo jak

między klasami i przypadkami użycia

Tak

samo

jak

między

przypadkami użycia, związek

uogólnienia

może

istnieć

również między aktorami.
Pracownika dostarczającego

towar i inkasenta możemy

uznać

za

przedstawicieli

dostawcy.
Wówczas dostawca towaru i

inkasent będą potomkami

przedstawiciela dostawcy, co

zostało pokazane na rysunku.

Grupowanie

Na niektórych diagramach występuje wiele przypadków
użycia i warto je w jakiś sposób uporządkować. Przydaje się
to, gdy system składa się z wielu podsystemów oraz gdy w
wywiadach z użytkownikami staramy się zebrać wymagania
stawiane systemowi. Każdy warunek powinien być
przedstawiony w postaci oddzielnego przypadku użycia.
Przyda się wówczas dzielenie warunków na kategorie.
Najprostszym sposobem wprowadzenia porządku jest
grupowanie związanych przypadków użycia w pakiety.
Pamiętajcie, że pakiety przedstawimy w postaci teczek z
zakładkami. Zgrupowane przypadki użycia są pokazywane
wewnątrz ikony takiej teczki.

Stosowanie przypadków

użycia w procesie analizy

Proces zaczyna się od wywiadów z klientem. Ich
rezultatem jest stworzenie diagramu klas, który następnie
może służyć za podstawę wiedzy o domenie systemu
(zakresie, w którym system będzie rozwiązywał problemy).
Po poznaniu ogólnej terminologii używanej przez klienta
przychodzi pora na rozmowy z użytkownikami.
Wywiady z użytkownikami rozpoczynamy od terminologii
domeny, którą powinniśmy wzbogacić o terminologię
użytkowników. Już pierwsze wywiady powinny odkryć
aktorów i przypadki użycia wysokiego poziomu, opisujące
ogólne warunki funkcjonalne. Te informacje prowadzą do
poznania ograniczeń i zakresu systemu.

Stosowanie przypadków

użycia w procesie analizy

Kolejne wywiady z użytkownikami są szczegółowym
zagłębianiem się w te warunki i prowadzą do tworzenia
modelu ukazującego scenariusze ze szczegółowymi ciągami
zdarzeń.
Może to prowadzić do tworzenia dodatkowych przypadków
użycia ze związkami zawierania i rozszerzania. Jest ważne, aby
w tej fazie polegać na własnym rozumieniu domeny (na
podstawie diagramu klas stworzonego w wyniku rozmów z
klientem).
Jeżeli nie rozumiecie domeny, możecie stworzyć zbyt wiele
przypadków użycia ze zbyt wieloma szczegółami, a to może w
sposób znaczący wpłynąć na projektowanie i budowanie
systemu.

Stosowanie modeli

przypadków użycia —

przykład

Aby pogłębić wiedzę na temat przypadków użycia i

ich stosowania, rozpatrzmy przykład bardziej

złożony niż automat do sprzedaży napojów.
Załóżmy, że należy zaprojektować lokalną sieć

komputerową (LAN) dla firmy konsultingowej i

musicie wyobrazić sobie funkcjonowanie tej sieci.

Od czego zacząć?

Oczywiście chodzi o projekt przypadków użycia sieci

komputerowej w tej firmie, a nie o techniczne

aspekty wykonania takiej sieci, które to aspekty nie

należą do klasy zagadnień rozważanej na wykładzie.

Poznanie domeny

Zacznijcie od

wywiadów z

klientem, co

pozwoli na

stworzenie

diagramu

będącego

odbiciem pracy

w firmie

konsultingowej.

Diagram ten może zawierać następujące klasy: Konsultant, Klient, Projekt,

Propozycja, Dane i Raport.
Przykład takiego diagramu został pokazany na rysunku.

Zrozumienie

użytkowników

Po poznaniu domeny skupiamy uwagę na użytkownikach,

pamiętając, że naszym celem jest wyobrażenie sobie pełnej

funkcjonalności systemu.
W

świecie

rzeczywistym

z

użytkownikami

trzeba

przeprowadzać wywiady. W tym przypadku należy się opierać

na ogólnej znajomości konstrukcji sieci lokalnych i znajomości

domeny. Pamiętajcie jednak, że w rzeczywistości nic nie

zastąpi wywiadów z ludźmi.
Jedną grupę będą stanowić konsultanci, drugą urzędnicy biura.

Inni potencjalni użytkownicy to: księgowi, handlowcy,

administratorzy

sieci,

kierownicy

działowi

kierownicy

projektów (czy możecie jeszcze kogoś dorzucić?).
W tym punkcie dobrze jest pokazać użytkownikom uogólnioną

hierarchię przedstawioną na rysunku (następny slajd)

Hierarchia użytkowników

sieci LAN

Zrozumienie

przypadków użycia

A co z przypadkami użycia? Oto kilka

możliwości: „Zapewnij bezpieczeństwo”,

„Przygotuj propozycję”, „Użyj poczty

elektronicznej”, „Udostępnij informację”,

„Wykonaj księgowanie”, „Połącz się z

siecią lokalną z innej sieci lokalnej”,

„Połącz się z Internetem”, „Współużytkuj

bazę danych”, „Zrób katalog propozycji”,

„Używaj

gotowych

propozycji”,

„Współużytkuj drukarki”. Na rysunku

został pokazany diagram przypadków

użycia wysokiego poziomu.
Ten zestaw przypadków użycia określa

warunki funkcjonalne sieci LAN.

Przypadek użycia

„Przygotuj propozycję”

Zajmijmy się dokładnie jednym z
przypadków użycia wysokiego poziomu
i zbudujmy jego dokładny model.
Jedną z najważniejszych powinności
firmy

konsultingowej

jest

przygotowywanie propozycji, a więc
przyjrzyjmy się bliżej przypadkowi
użycia „Przygotuj propozycję”.

Przypadek użycia

„Przygotuj propozycję”

Z rozmów przeprowadzonych z konsultantami

zapewne dowiesz się, ile kroków będzie liczył ciąg

czynności w tym przypadku użycia, którego aktorem

inicjującym jest właśnie konsultant.
Konsultant musi się załogować w sieci LAN i zostać

rozpoznany jako uprawniony użytkownik.
Potem, korzystając z oprogramowania pakietu

biurowego (procesora tekstu, arkusza kalkulacyjnego

i

programu

graficznego),

przystąpi

do

przygotowywania propozycji. Na tym etapie pracy

konsultant może korzystać z propozycji wcześniej

przygotowanych.

Przypadek użycia

„Przygotuj propozycję”

W części firm konsultingowych przygotowane propozycje

przed przekazaniem klientowi są sprawdzane przez

jednego z członków zarządu i dwóch innych konsultantów.

Aby tego rodzaju praktyka była możliwa, konsultant

zapisuje gotową propozycję w centralnym repozytorium i

pocztą elektroniczną powiadamia trzy zainteresowane

osoby o miejscu jej zapisania.
Po otrzymaniu uwag i dokonaniu modyfikacji (znów za

pomocą pakietu oprogramowania biurowego) konsultant

drukuje propozycję i wysyłają do klienta.
Gdy wszystko jest skończone, wylogowuje się z sieci.

Konsultant, który przygotował skończoną propozycję, jest

aktorem czerpiącym korzyść z danego przypadku użycia.

Uwaga !

Jeżeli podczas wywiadu odkrywa się coś takiego

jak wspomniana wyżej „polityka sprawdzania

przez trzech rewizorów”, należyte starannie

zanotować.
Oznacza to, że zaczyna się rozmowa o logice

biznesowej firmy, czyli zbiorze zasad, według

których firma jest prowadzona.
Im lepszymi jesteście analitykami, tym dokładniej

tę logikę poznacie. Starajcie się zrozumieć

kulturę korporacyjną Waszych klientów, co

pozwoli poznać i zrozumieć ich potrzeby.

Przypadek użycia

„Przygotuj propozycję”

Z wyliczonego poprzednio ciągu czynności wynika,
że niektóre kroki będą powtarzane w kilku
przypadkach użycia, zatem należy pomyśleć o
zastosowaniu zawierania, co na początku mogło nie
wydawać się takie oczywiste.
Z tego powodu można stworzyć przypadek użycia
„Sprawdź użytkownika”, który zostanie zawarty w
przypadku „Przygotuj propozycję”.

Razem z nim

zawarte zostaną dwa inne przypadki użycia: „Użyj
pakietu programów biurowych” i „Wyloguj się z
sieci”.

Rozszerzenie przypadku użycia

„Przygotuj propozycję” o wariant

nowego klienta

Dalsze rozważania prowadzą do stwierdzenia, że
propozycje pisane dla nowych klientów różnią się
od

propozycji

pisanych

dla

klientów

dotychczasowych.
W tych pierwszych umieszcza się materiały
promocyjne i informacyjne o firmie. W drugim
przypadku nie jest to potrzebne.
A zatem przypadek użycia „Przygotuj propozycję”
może zostać rozszerzony przez nowy przypadek -
„Przygotuj propozycję dla nowego klienta”.

Przypadek użycia „ Przygotuj

propozycją” w modelu LAN firmy

konsultingowej

Na

rysunku

widzimy

diagram

przypadków

użycia powstały w wyniku

analizy

przypadku

„Przygotuj propozycję” .
Ten

przykład

obrazuje

bardzo istotną kwestię, o

której

już

wcześniej

wspominaliśmy - analiza

przypadków

użycia

opisuje

zachowanie

systemu i nie ma nic

wspólnego

z

implementacją.

Podsumowanie

Przypadek użycia to konstrukcja opisująca, w jaki sposób

system

będzie

widziany

przez

potencjalnych

użytkowników. Jest to zbiór scenariuszy inicjowanych

przez byt zwany aktorem (osobę, urządzenie, upływ czasu

lub inny system). Rezultatem tego działania będzie

wartość potrzebna temu aktorowi, który przypadek

inicjował, lub innemu.
Wszystkie przypadki użycia mogą być stosowane

wielokrotnie. Jeden sposób („zawieranie”) pozwala na

„wmontowanie” ciągu kroków z jednego przypadku w ciąg

kroków innego przypadku. Drugi sposób („rozszerzanie”)

polega na tworzeniu nowego przypadku przez dodawanie

nowych kroków do już istniejącego przypadku.

Podsumowanie

Robienie wywiadów z użytkownikami jest najlepszą

techniką tworzenia przypadków użycia. Przy tworzeniu

przypadku bardzo ważną rzeczą jest ustalenie

warunków początkowych inicjowania przypadku i

warunków końcowych określających rezultat działania.
Wywiady

z

użytkownikami

przeprowadzamy

po

wywiadach z klientami i po przygotowaniu listy

kandydatów na klasy. To pozwala na stworzenie

podstawowej terminologii wykorzystywanej później w

rozmowach z użytkownikami. Dobrym pomysłem jest

przeprowadzanie wywiadu z grupą użytkowników.

Celem jest sporządzenie kompletnej listy kandydatów

na wszystkie możliwe przypadki użycia i aktorów.

Podsumowanie

Przypadek użycia jest potężnym narzędziem

służącym do poznania warunków funkcjonowania

systemu. Diagramy przypadków użycia są jeszcze

bardziej przydatne.
Ułatwiają one komunikowanie się analityków z

użytkownikami i klientami.
Na diagramach przypadki użycia oznaczamy

symbolem elipsy. Linia powiązania łączy ją z

schematycznym

wizerunkiem

człowieka

symbolizującym aktora. Elipsy przypadków użycia są

zwykle

umieszczane

wewnątrz

prostokąta

oznaczającego granice systemu.

Podsumowanie

Zawieranie jest przedstawiane za pomocą linii

zależności z nazwą stereotypu «include», a

rozszerzenie - z nazwą stereotypu «extend».
Dwa inne powiązania przypadków użycia to

uogólnienie i grupowanie. W uogólnieniu jeden

przypadek użycia dziedziczy po innym znaczenie

i zachowanie, zaś grupowanie pozwala na

łączenie przypadków w zestawy.
Uogólnienie przypadków użycia jest oznaczane

taką samą linią jak dziedziczenie klas.

Grupowanie oznaczamy ikoną pakietu.

Podsumowanie

Diagram przypadków użycia jest jednym z bardziej

znaczących

elementów

procesu

analizy.

Zawsze

rozpoczynajcie od wywiadów z klientami, co powinno

doprowadzić do stworzenia diagramu klas.
Ten z kolei będzie podstawą do rozmów z użytkownikami.

Wywiady z użytkownikami doprowadzą do stworzenia

diagramów przypadków użycia wysokiego poziomu, które

pokażą warunki funkcjonalne systemu.
Drążenie prowadzi do stworzenia modelu przypadków użycia.

Ostateczny diagram przypadków użycia będzie podstawą

dalszych prac projektowych i tworzenia oprogramowania.
Obiektowość i przypadki użycia to dwie podstawowe

koncepcje UML-a.