Inżynieria
oprogramowania
Wykorzystanie przypadków użycia
do modelowania zachowania
Rafał Kasprzyk
ozpoczynając budowę systemu informa- oczywistą, że nie warto o niej mówić, okazuje
tycznego pierwszym krokiem stanowiącym się, że dla dużych systemów o wielu złożonych
Rpodstawę dalszych działań jest próba zro- i wzajemnie powiązanych funkcjach tego rodza-
zumienia strony klienta, co do zakresu funkcjonal- ju podejście ma ogromny sens. Pozwala ono za-
ności, jaką ma oferować system. Klient ma pewne pomnieć o detalach technicznych (nawet abs-
wyobrażenie, co do sposobu funkcjonowania sys- trahować od architektury) i skoncentrować się
temu (ang. mental model), a naszym zadaniem na logice systemu. Podejście do projektowa-
jest zrozumienie, często niejasnych życzeń klienta. nia od strony przypadków użycia jest uważane
W tym celu tworzony jest model wymagań (ang. za znacznie bardziej zdrowe od podejść  tech-
requirements model). W zależności od wielkości nokratycznych , ponieważ sprzyja ono punktowi
przedsięwzięcia, aby model taki zbudować, nie- widzenia, w którym centralnym ośrodkiem zain-
kiedy wystarczy krótka pogawędka, ale często ko- teresowania staje się człowiek  przyszły użyt-
nieczne jest wielomiesięczne studium wykonalno- kownik systemu. Jak pokazały doświadczenia
ści. Zawsze jednak dążymy do zrozumienia za- wielu projektów, jedną z głównych przyczyn ich
chowania systemu wykorzystując przypadki użycia niepowodzeń było zbytnie skoncentrowanie się
i scenariusze przypadków użycia. projektantów na detalach technicznych, z pomi-
nięciem lub brakiem dostatecznej uwagi dla in-
Pochodzenie przypadków użycia terakcji użytkownik  system informatyczny.
Przypadki użycia były w sposób intuicyjny sto- Reasumując  przypadek użycia można definio-
sowane w tradycyjnym projektowaniu systemów wać na wiele sposobów. Oto kilka przykładowych
informatycznych na długo przed pojawieniem definicji:
się metodyk obiektowych i języka UML. Zasłu-
gą Ivar a Jacobsona jest zarówno wyodrębnie- " Przypadek użycia to wycinek funkcjonalności,
nie przypadków użycia, jak i stworzenie meto- którą system musi realizować, aby spełnić wyma-
dyki i notacji graficznej dla tego paradygmatu. gania;
Jak często bywa z powszechnie stosowanymi, " Przypadek użycia jest zbiorem ciągów akcji
lecz nie nazwanymi rzeczami, kariera przypad- wykonywanych przez system w celu dostar-
ków użycia w literaturze z zakresu projektowa- czenia określonemu aktorowi godnego uwagi
nia systemów informatycznych zaczęła się od wyniku;
wprowadzenia dla nich specjalnej nazwy, przy- " Przypadek użycia to zbiór scenariuszy powiąza-
pisaniu tej nazwie określonej semantyki i roz- nych wspólnym celem użytkownika. Przez sce-
propagowaniu tego pojęcia jako sposobu mode- nariusz rozumiany jest tu ciąg kroków opisują-
lowania zachowania. cych interakcje między użytkownikiem a syste-
mem.
Semantyka przypadków użycia
Przypadek użycia jest to pewna nazwana, do- Diagramy przypadków użycia są bardzo proste i głów-
brze określona interakcja pomiędzy użytkowni- nie dzięki temu tak użyteczne. Pomiędzy przypad-
kiem a systemem komputerowym. Przypadek kami użycia można wyróżnić trzy podstawowe za-
użycia odwzorowuje pewną funkcjonalność sys- leżności.
temu w taki sposób, w jaki będą ją widzieć jego
przyszli użytkownicy. Jakkolwiek w tym stwier- Zawieranie
dzeniu można podejrzewać banał, rzecz tak " Pozwala na współdzielenie fragmentu funkcjonal-
ności pomiędzy kilkoma przypadkami użycia. Do
relacji zawierania dochodzi wówczas, gdy kilka
Autor jest absolwentem Wydziału Cybernetyki WAT,
przypadków użycia ma wspólną sekwencję po-
gdzie od 2 lat zajmuje stanowisko asystenta w Instytu-
dobnych kroków, której nie warto wciąż kopiować
cie Systemów Informatycznych. Pracuje w firmie ISO-
z jednego przypadku użycia do drugiego.
LUTION będąc odpowiedzialnym za przygotowywa-
nie, prowadzenie i audyt szkoleń obejmujących analizę
Rozszerzanie
i projektowanie systemów informatycznych z użyciem
" Pozwala na warunkowe rozszerzenie funkcjo-
notacji UML.
Kontakt z autorem: [e-mail] nalności przypadku użycia  osadzone w punk-
cie rozszerzenia. Rozszerzenie przypadku użycia
68
www.sdjournal.org
Software Developer s Journal 07/2007
Wykorzystanie przypadków użycia do modelowania zachowania
Bibliografia
" [1] Marin Fowler UML Distilled: A Brief Guide To The Standard
Object Modeling Language, 3rd ed., Addison-Weslay Professio-
nal, 2004;
" [2] Grady Booch, James Rumbaugh, Ivar Jacobson, Unified
Modeling Language User Guide, 2nd ed., Addison-Weslay
Professional, 2005;
" [3] Michał Śmiałek, Zrozumieć UML 2.0. Metody modelowania
obiektowego, Helion, 2005;
" [4] http://www.holub.com/goodies/uml/;
" [5] http://www.agilemodeling.com/essays/umlDiagrams.htm
Rysunek 2. Strona główna holub.com
może więc wzbogacić go o dodatkowe zachowanie, ale
w takiej sytuacji podstawowy przypadek użycia musi okre- Do czego wykorzystywane są przypadki użycia
ślić pewne punkty rozszerzenia, a rozszerzający przypa- Podejście przypadków użycia ma przede wszystkim na wzglę-
dek użycia może dodać nowe zachowanie tylko w tych dzie określenie wymagań funkcjonalnych na projektowany
punktach. Przypadek użycia może mieć wiele punktów system.
rozszerzeń, a rozszerzający przypadek użycia może roz-
szerzać podstawowy przypadek użycia w kilku z tych Celem tej metody jest
punktów. Relacja rozszerzania służy do opisywania opcjo- " Identyfikacja wymagań funkcjonalnych;
nalnego przepływu zdarzeń i pozwala na minimalizację " Każdy przypadek użycia powinien opisywać realizację
liczby zmian wprowadzanych do podstawowego przypad- jakiegoś celu biznesowego opisanego z punktu widze-
ku użycia. nia aktora używającego system;
" Zbiór przypadków użycia stanowi podstawę do umowy
Uogólnienie między klientem, a dostawcą;
" Pozwala na zilustrowanie różnych wariantów realizacji te- " Przypadki użycia ułatwiają zadanie ustalenia prioryte-
go samego przypadku użycia. W istocie jest bardzo po- tów dla wymagań funkcjonalnych;
dobne do rozszerzania, jest jednak mniej formalne. Re- " Odpowiedz
na pytanie, co system ma robić bez określania
lacji uogólnienia używa się wówczas, gdy dany przypa- sposobu realizacji;
dek użycia jest podobny do innego, ale jest nieco obszer- " Umożliwienie interakcji zespołu projektowego z użytkowni-
niejszy. Specjalizowany przypadek użycia może przesło- kami systemu;
nić dowolną część podstawowego przypadku użycia, ale " Określenie granic systemu;
zawsze powinien dotyczyć osiągnięcia tego samego celu " Ustalenie praw dostępu do zasobów;
użytkownika, co podstawowy przypadek użycia. Relacja " Ustalenie składowych systemu i związanego z nimi planu
uogólniania może być traktowana jako sposób na przed- konstrukcji systemu;
stawienie szczególnej realizacji uogólnionego przypadku " Przygotowanie podstaw do szczegółowej analizy i projek-
użycia. towania:
" Podstawa do identyfikacji klas i obiektów;
" Określenie odpowiedzialności i współpracy obiektów;
University " Definicja przepływu komunikatów miedzy obiektami;
" Weryfikacja poprawności i kompletności projektu;
Enroll
" Dostarczenie podstaw do sporządzenia planu testów
in Seminar
systemu.
Applicant
Podsumowanie
<>
Przypadki użycia stały się podstawowym elementem współ-
czesnych metodyk wytwarzania oprogramowania. Mówi się,
Enroll
że dobra metodyka winna być ukierunkowana właśnie na
in University
przypadki użycia. Oznacza to, że przypadki użycia powinny
Student Registral
stanowić podstawowe narzędzie do zbierania i odkrywania
<> wymagań funkcjonalnych systemu (określanie pożądanego
zachowania systemu), planowania prac w projekcie (podsta-
wowe i stanowiące ryzyko przypadki użycia implementowa-
Enroll Family
Perform
ne są w pierwszej kolejności), zarządzania projektem oraz do
Member in
Security Check
University
testowania systemu. Przypadki użycia są niezbędne przy wy-
International
borze architektury i jej weryfikacji. Wykorzystuje się je rów-
Student
nież do komunikacji wewnątrz zespołu projektowego pracują-
Rysunek 1. Diagram przypadków użycia cego nad projektem, jak i przy rozmowie z klientem. n
Software Developer s Journal 07/2007 www.sdjournal.org
69