2 Model przypadków uŝycia 2.1 Wstęp Brak właściwej komunikacji pomiędzy klientem a członkami zespołu projektowego często wręcz uniemoŝliwia poprawną identyfikację potrzeb uŝytkownika końcowego. RóŜnice w modelach problemu i rozwiązania, a takŝe konieczność przeprowadzania transformacji między nimi, stanowią powaŝne źródło błędnych interpretacji, gdzie do typowych sytuacji naleŝą: niezrozumienie potrzeb uŝytkownika w ogóle albo zrozumienie nie do końca. Popularną techniką radzenia sobie z tego rodzaju problemami jest modelowanie przypadków uŝycia, które dzięki specyfikowaniu funkcjonalności i kontekstu systemu w prosty sposób, zrozumiały dla szerokiego grona uczestników projektu, pozwala na zbudowanie pewnego rodzaju języka do wymiany in formacji pomiędzy wszystkimi zainteresowanymi stronami. Prostota modelu przypadków uŝycia okazała się być głównym powodem wykorzystywania przypadków uŝycia nie tylko jako podstawy kontraktu między klientem a zespołem projektowym, ale takŝe np. jako podstawy dla całego procesu tworzenia produktu (jak np. w Rational Unified Process, będącym procesem prowadzonym w oparciu o przypadki uŝycia). W pierwszej części wykładu omówiono podstawowe pojęcia wykorzystywane w modelu przypadków uŝycia. Następnie została przeprowadzona analiza aktorów, analiza przypadków uŝycia, analiza relacji między przypadkami uŝycia i relacji między aktorami. W końcowej części wykładu przedstawiono cztery kolejno następujące po sobie kroki, specyfikujące proces budowy modelu przypadków uŝycia. 2.2 Podstawowe pojęcia Model przypadków uŝycia wykorzystuje zestaw podstawowych pojęć przedstawionych w Tab. 1 Pojęcia modelu przypadków uŝycia. Pojęcie Znaczenie Notacja aktor Ktoś (lub coś) spoza systemu, wchodzący w interakcję z systemem. (1) Standardowa: Aktor reprezentuje potencjalnego uŝytkownika systemu traktowanego jako całość, albo uŝytkownika tylko pewnego fragmentu systemu (podsystemu czy nawet pojedynczej klasy). Potencjalny uŝytkownik to dowolny byt z otoczenia tego fragmentu systemu, którego dotyczy rozpatrywana funkcjonalność. Aktor moŝe zlecić systemowi zadanie (np. potwierdzenie otrzymania podania, złoŝenie zamówienia, wysłanie komunikatu do obiektu) i/lub moŝe współdziałać z systemem w trakcie realizacji tego zadania. Sformułowanie lub dotyczy aktorów pasywnych, którzy wyłącznie odbierają dane wytworzone w trakcie realizacji zadania zleconego przez innego aktora. Aktor musi posiadać unikatową nazwę. Częste pytania: 1. Czy system moŝe być aktorem sam dla siebie? Aktor to przecieŝ, zgodnie z definicją, byt z C lien t (2) Z wykorzystaniem notacji klasyfikatora i stereotypem w postaci tekstu: «actor» (3) Z wykorzystaniem standardowej notacji dla klasyfikatora i stereotypem w postaci ikony:
otoczenia systemu. PowyŜsze pytanie jest formułowane z reguły dla zadań zlecanych przez aktora nazywanego podsystemem czasu, czyli stanowiącego fragment systemu (w sytuacji, gdy rozpatrywana jest funkcjonalność systemu traktowanego jako całość). Bardziej prawidłowe byłoby wykorzystywanie w stosunku do tego aktora terminu czas niematerialny byt z otoczenia systemu, którego upływ spowodował reakcję podsystemu czasu, fragmentu systemu. Inne wykorzystywane oznaczenia: (1) dla aktora oznaczającego inny system, współpracujący z rozwaŝanym: 2. Aktor jest pierwotną przyczyną napędzającą przypadki uŝycia, co oznacza, Ŝe jest sprawcą zdarzeń powodujących uruchomienie przypadku uŝycia, jak teŝ nadawcą i odbiorcą danych do/z przypadku uŝycia. Sprawca zdarzeń? Czy np. klienta, dla którego nie rozwaŝa się udzielenia prawa bezpośredniego dostępu do funkcji systemu, naleŝy traktować jak aktora dla tego systemu? To, czy klient jest czy teŝ nie jest aktorem dla danego systemu, zaleŝy od rozwaŝanego poziomu abstrakcji: z reguły klient nie posiadający bezpośredniego dostępu do funkcji systemu jest brany pod uwagę jako aktor w modelu biznesowym, ale nie w modelu przypadków uŝycia. Insurance system (2) dla aktora podsystem czasu: The 1st day of a year przypadek uŝycia Aktor moŝe wchodzić w interakcję z systemem na róŝne, jemu właściwe sposoby. KaŜdy z tych sposobów nosi nazwę przypadku uŝycia i reprezentuje sekwencję akcji realizowanych przez system, w efekcie których do konkretnego aktora dostarczane są obserwowalne rezultaty. Akcja jest to atomowa operacja (czyli wykonywana w całości albo nie wykonywana w ogóle), realizowana przez system w odpowiedzi albo na sygnał pochodzący od aktora, albo na zdarzenie związane z upływem czasu. Akcja moŝe implikować transmisję sygnału albo do aktora, który ją wywołał, albo do innych aktorów. Sekwencja akcji występuje w odpowiedzi na przepływ zdarzeń między aktorem a systemem. Sekwencje akcji są grupowane w przypadki uŝycia. Sekwencja akcji realizowanych przez system jest to waŝne sformułowanie słuŝące określeniu granic systemu oraz ustaleniu zakresu jego odpowiedzialności. To, co jest wykonywane przez system, jest tu jasno zdefiniowane (jest inne od akcji świata zewnętrznego i jest wyraźnie od nich oddzielone). Pojęcie obserwowalny rezultat oznacza, Ŝe sekwencja akcji musi zakończyć się wytworzeniem czegoś, co posiada uŝyteczną Place an order albo Place an order
wartość dla aktora. Nie zaleca się wykonywania kilku przypadków uŝycia dla uzyskania pojedynczego obserwowalnego rezultatu (np. kilku przypadków uŝycia, których obserwowalnym wspólnym rezultatem ma być zarejestrowania zamówienia). Efektem skupienia się na dostarczaniu obserwowalnych rezultatów przez kaŝdy przypadek uŝycia jest zarówno relewantność przypadków, jak i poziom szczegółowości zrozumiały dla uŝytkownika. Konkretny aktor uŝyteczna wartość (obserwowalny rezultat) jest dostarczana do specyficznych grup uŝytkowników; specyfika polega tu na związku z pewną rolą, a nie z konkretnymi osobami. Przypadek uŝycia musi posiadać unikatową nazwę, która powinna wyraźnie określać cel zaistnienia przypadku (obserwowalny rezultat). NaleŜy unikać nazw sugerujących czynności realizowane przez aktora w otoczeniu systemu (bez wsparcia systemu), czy teŝ sugerujące czynności trwające w czasie. Według niektórych metodologów nazwa przypadku uŝycia powinna opisywać czynność (np. złoŝenie zamówienia ), według innych polecenie (np. złóŝ zamówienie ). Kompletny zbiór przypadków uŝycia definiuje funkcjonalność systemu jako całości. Pojedynczy przypadek, reprezentując specyficzny przepływ zdarzeń, określa fragment zachowania systemu. interakcja aktora z przypadkiem uŝycia Dla oznaczenia interakcji aktora z przypadkiem uŝycia stosuje się linię ciągłą (1). W celu zaznaczenia kierunku przepływu zdarzeń uŝywa się linii skierowanej (2); grot wskazuje na byt (aktora lub przypadek uŝycia), który inicjuje zdarzenia. Interakcja oznaczona symbolem (3), jako równowaŝna interakcji (1), nie jest wykorzystywana. (1) (2) (3) blok ponownego uŝycia Pojęcie to nie wchodzi w skład standardu UML, aczkolwiek wydaje się być uŝyteczne dla opisu funkcjonalności pomocniczej, szczególnie w procesie Reprezentuje fragment systemu, który jest wykorzystywany przez kilka przypadków uŝycia. Blok ponownego uŝycia moŝe być samodzielnym przypadkiem uŝycia, co pozwala na oznaczenie moŝliwej interakcji aktora z przypadkiem. Interakcja aktora z blokiem ponownego uŝycia w jego podstawowym znaczeniu, tzn. jako funkcjonalności pomocniczej dla innych przypadków uŝycia i niedostępnej dla bytów z otoczenia systemu (oznaczonej na diagramie przez symbol prostokąta, a nie elipsy), jest zabroniona. authorization
określania struktury projektowanego systemu. relacje między przypadkami uŝycia Relacje i reprezentują związki zachodzące między przypadkami uŝycia, lub między przypadkami uŝycia a blokami ponownego uŝycia; pojęcia te są omówione w dalszej części rozdziału. Tab. 1 Pojęcia modelu przypadków uŝycia 2.3 Kontekst systemu Modelowanie przypadków uŝycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystaniem projektowanego systemu, czyli określenia potencjalnych uŝytkowników systemu (inaczej: kontekstu systemu). Zazwyczaj aktorem jest osoba, ale moŝe nim być takŝe pewna organizacja (np. biuro prawne) lub inny system komputerowy. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. Na przykład, zgodnie z Error! Reference source not found. konkretna osoba moŝe wchodzić w interakcję z systemem z pozycji wielu aktorów: moŝe być zarówno Administratorem systemu, jak i Klientem. I odwrotnie, jeden aktor moŝe odpowiadać wielu konkretnym osobom, np. aktor Osoba informowana. User Actor Use case can play a role of orders Jan Kowalski System administrator Reboot system Adam Malina Employee Enter with authorization Concrete guest Informed person Get general information Concrete client Withdraw money Rys. 1 Ilustracja róŝnicy między pojęciem aktora a konkretnym uŝytkownikiem systemu 2.4 Scenariusze przypadków uŝycia NajwaŜniejszym elementem w opisie kaŝdego przypadku uŝycia jest specyfikacja przepływu zdarzeń między aktorem a systemem. Specyfikację przepływu zdarzeń naleŝy formułować w języku naturalnym: prostą, spójną prozą i w oparciu o terminy zawarte w słowniku pojęć z dziedziny problemowej. Na przykład, przepływ zdarzeń między aktorem a systemem dla przypadku uŝycia Wypłać pieniądze w systemie wspierającym obsługę bankomatu, mógłby być opisany, jak poniŝej: 1. Przypadek uŝycia rozpoczyna się, gdy klient wkłada kartę do bankomatu. System czyta informacje na karcie i bada ich poprawność. 2. System pyta o PIN. Klient wprowadza PIN. System sprawdza poprawność. 3. System pyta o rodzaj operacji do wykonania. Klient wybiera: Wypłać pieniądze. 4. System pyta o wielkość kwoty. Klient wprowadza kwotę. 5. System komunikuje się z bankiem, Ŝeby sprawdzić poprawność ID konta, PIN i dostępność kwoty.
6. System pyta klienta czy potrzebuje potwierdzenie. Ten krok jest wykonywany tylko wtedy, gdy papier do drukowania jest dostępny. 7. System komunikuje klientowi prośbę o zabranie karty. Klient zabiera kartę. Komunikat stanowi tu pewien mechanizm bezpieczeństwa chroniący klienta przed nie zabraniem karty. 8. System wydaje pieniądze. 9. System drukuje potwierdzenie (o ile klient sobie Ŝyczył) i to kończy przypadek uŝycia. MoŜliwe są róŝne, alternatywne przepływy zdarzeń (przebiegi) dla tego przypadku uŝycia, w zaleŝności od: Danych dostarczanych przez aktora: np. aktor moŝe uniewaŝnić transakcję w dowolnym momencie lub moŝe nie chcieć potwierdzenia. Stanu systemu: np. bankomat moŝe nie zawierać pieniędzy, moŝe brakować papieru, moŝe nastąpić blokada urządzenia wydającego pieniądze czy urządzenia drukującego potwierdzenie. Time-out u lub błędów: np. jeśli klient nie odpowie w określonym czasie, system moŝe uniewaŝnić transakcję. Pojedynczy alternatywny przebieg nie powinien być traktowany jako oddzielny przypadek uŝycia raczej grupujemy wszystkie powiązane przebiegi w jeden przypadek. Taką grupę przebiegów nazywa się czasami klasą przypadków uŝycia (zamiast: przypadkiem uŝycia). Wystąpieniem klasy przypadków uŝycia jest wtedy jeden z pojedynczych, alternatywnych przebiegów. To wystąpienie klasy przypadków uŝycia jest nazywane scenariuszem przypadku uŝycia. Scenariusze są uŝywane do ekstrahowania z przypadku uŝycia unikatowej sekwencji akcji, inaczej: wątków w przypadku uŝycia. Na wczesnych etapach rozwoju systemu łatwiej jest rozpocząć pracę od pewnego konkretnego scenariusza, a następnie dodawać przebiegi alternatywne tworząc w ten sposób klasę przypadków uŝycia. Akcje prowadzące do uzyskania obserwowalnego rezultatu naleŝy grupować w taki sposób, aby mogły być razem poddawane przeglądom, modyfikowane, testowane (w ogólności, traktowane jako jedna jednostka w trakcie całego cyklu Ŝyciowego produktu). Nie jest to jednoznaczne z funkcjonalną dekompozycją, gdzie łatwo moŝna stracić z oczu cel, jakim jest wartość dostarczana uŝytkownikowi. Konstruując diagram przypadków uŝycia naleŝy rozwaŝyć, czy zbiór interakcji między uŝytkownikiem a systemem, konkretny scenariusz (dialog) opisuje jeden, czy kilka przypadków uŝycia. Podstawę do rozróŝnienia stanowi odpowiedź na pytanie: czy system dostarcza obserwowalny rezultat mający dla uŝytkownika rzeczywistą wartość? Dla powyŝszego przykładu z bankomatem pytanie takie moŝna byłoby sformułować następująco: czy uŝytkownik byłby zadowolony, gdyby po autoryzacji karty system powiadomił go o prawidłowym wprowadzeniu danych i zwrócił kartę nie pytając o wielkość kwoty i nie wypłacając pieniędzy? Konstruowanie scenariuszy, które w przejrzysty i jednoznaczny sposób specyfikowałyby sekwencję interakcji zachodzących między aktorem a systemem, moŝe okazać się zadaniem trudnym, szczególnie dla przypadków z duŝą ilością wątków alternatywnych. Zadanie to jest tym trudniejsze, Ŝe scenariusz specyfikowany jest w języku naturalnym. Niektórzy analitycy proponują wykorzystanie do opisu scenariuszy tabel w formacie, jak w Tab. 2 Specyfikowanie scenariuszy w formacie tabeli. Nazwa przypadku uŝycia Aktor(rzy) Scenariusz główny Scenariusz poboczny 1-szy Scenariusz poboczny 2-gi... Tab. 2 Specyfikowanie scenariuszy w formacie tabeli
Schemat wydaje się być przejrzysty, ale raczej trudno jest wyobrazić sobie wykorzystanie go dla przypadków bardziej złoŝonych, np. takich, jak wspomniano powyŝej, z duŝą liczbą wątków alternatywnych czy z duŝą liczbą iteracji. KaŜdy scenariusz poboczny, aby uniknąć niejednoznaczności, powinien specyfikować kompletny przebieg, co będzie prowadziło do powtórzeń całych fragmentów tekstu scenariusza. Ponadto, taki sposób zapisu raczej nie ułatwi wyszukiwania podprzepływów, które w dalszych etapach analizy mogą ulec przekształceniu w bloki ponownego uŝycia. Alternatywnym, wydaje się Ŝe lepszym rozwiązaniem, jest wyróŝnienie dwóch elementów składowych, w oparciu o które moŝna specyfikować sekwencje interakcji dla kaŝdego przypadku uŝycia: główny przepływ zdarzeń, alternatywne przepływy zdarzeń, Specyfikacje obu rodzajów wątków mogłyby składać się z oznaczonych kolejnymi liczbami naturalnymi sekwencji interakcji, co pozwoliłoby na uniknięcie powtórzeń fragmentów tekstu. Podprzepływy powinny być traktowane jak funkcje w językach proceduralnych, tzn. powrót z podprzepływu następowałby do kroku kolejnego po tym kroku, w którym wywołano podprzepływ. Przykład scenariusza z podziałem na przepływ główny i przepływy alternatywne pokazano w 2.5 Strukturalizacja przypadków uŝycia Strukturalizacja przypadków uŝycia, przeprowadzana z reguły w oparciu o analizę przepływu zdarzeń, jest niezbędna w procesie projektowania duŝych systemów, po to aby aktywności, takie jak: planowanie, ustalanie priorytetów i szacowanie rezultatów, nie stały się zadaniami znacząco utrudniającymi realizację projektów. Strukturalizację przeprowadza się wykorzystując pakiety przypadków uŝycia oraz relacje występujące pomiędzy przypadkami uŝycia: inkluzji, ekstensji oraz generalizacji-specjalizacji. Podstawowym błędem popełnianym podczas strukturalizacji jest naduŝywanie relacji inkluzji, ekstensji i generalizacji-specjalizacji, co moŝe doprowadzić do skonstruowania modelu trudnego do zrozumienia i pielęgnacji, oraz pośrednio skutkować zwiększeniem kosztów projektu. 2.5.1 Pakiety przypadków uŝycia Pakiety przypadków uŝycia grupują powiązane przypadki uŝycia w jednym kontenerze. Pakiety są istotne przede wszystkim dla duŝych projektów, które składają się z wielu jednostek funkcjonalnych o złoŝonych wzajemnych zaleŝnościach, oraz są tworzone przez grupę współpracujących osób. Stosowanie pakietów ułatwia zarządzanie przechowywaniem, konfiguracjami oraz modyfikowaniem elementów modelu. Właściwie przeprowadzony podział na pakiety moŝe znacząco ułatwić zarządzanie procesem wytwarzania nie tylko modelu przypadków uŝycia, ale i całości produktu programistycznego. 2.5.2 Inkluzja i ekstensja Przepływ zdarzeń moŝna przedstawić w postaci sekwencji podprzepływów: jeden główny i kilka pobocznych. Te same podprzepływy mogą powtarzać się w róŝnych przypadkach uŝycia, moŝna więc wyodrębnić je w postaci oddzielnych przypadków. W opisie sekwencji przypadków, kaŝde dwa przypadki uŝycia moŝna połączyć wykorzystując jeden z dwóch rodzajów relacji: inkluzję (notacja: stereotyp ) lub ekstensję (notacja: stereotyp ). PowyŜsze stwierdzenie obowiązuje takŝe dla bloków ponownego uŝycia. W obu poniŝszych diagramach (Error! Reference source not found. i Error! Reference source not found.), P1, nazywane przypadkiem bazowym, zawsze występuje jako pierwsze w kolejności działania. Diagram nie specyfikuje, w którym momencie realizacji przypadku P1 jest wywoływany przypadek P2: Przebieg podstawowy (Error! Reference source not found.): przypadek bazowy P1 zawsze wywołuje (uŝywa, włącza) przypadek P2, zwany tu przypadkiem włączanym. P1 P2 Rys. 2 Przebieg podstawowy Przebieg opcjonalny (Error! Reference source not found.): P1 jest czasami rozszerzane o P2, zwane tu przypadkiem rozszerzającym (inaczej: P2 czasami rozszerza P1). Sformułowanie czasami oznacza, Ŝe
warunek nałoŝony na wywołanie P2 musi być spełniony, aby P2 zostało wywołane z P1. JeŜeli warunek nie został wyspecyfikowany, co jest dopuszczalne, P2 będzie wywoływane zawsze. P1 P2 Rys. 3 Przebieg opcjonalny Diagram na Error! Reference source not found. ilustruje nieprawidłowe wykorzystanie relacji łączącej przypadek ZłoŜenie zamówienia z przypadkiem Realizacja zamówienia, przy załoŝeniu, Ŝe niemoŝliwa jest realizacja obu przypadków podczas tego samego przebiegu systemu. Ograniczenie, zabraniające łączenia przypadków nie występujących w tym samym przebiegu systemu, dotyczy obu rodzajów relacji. Place an order Supplier Process an order Rys. 4 Ilustracja nieprawidłowego wykorzystania relacji Przykład diagramu ze specyfikacją punktów rozszerzeń, umoŝliwiających podanie warunków wymaganych do uŝycia przypadków rozszerzających, przedstawiono na Rys. 5. Car repair extension points: Car is out of repair shop Car needs review extension point: Car needs review extension point: Car is out of repair shop Car towing Car review extension points: Car is dirty Car wash extension point: Car is dirty Rys. 5 Ilustracja specyfikowania punktów rozszerzeń Podsumowując, inkluzja i ekstensja są wykorzystywane dla: uproszczenia złoŝonego przepływu zdarzeń; reprezentowania zachowań opcjonalnych; obsługi wyjątków.
2.5.3 Generalizacja-specjalizacja przypadków uŝycia Generalizacja-specjalizacja przypadków uŝycia bazuje na wyszukiwaniu podobieństw w przypadkach uŝycia i jest uŝywana w celu rozszerzenia i/lub ulepszenia pierwotnego przepływu zdarzeń. Relacja ta jest środkiem ułatwiającym modelowanie szkieletów i wariantów aplikacji. Związek generalizacji-specjalizacji, dla pojęcia aktor, zostanie szerzej omówiony w dalszej części rozdziału. 2.6 Przykłady diagramów przypadków uŝycia Na Rys. 6 i Rys. 7 pokazane są przykładowe diagramy przypadków uŝycia: dla systemów wspierających obsługę odpowiednio automatów do sprzedaŝy papierosów i automatów do operacji bankowych. ud Cigarettes selling machine Refill comodity Sell cigarettes Execute money transaction Create report Operator Controler Rys. 6 Diagram przypadków uŝycia dla automatu sprzedającego papierosy Zwróćmy uwagę, Ŝe diagram przypadków uŝycia dla systemu wspierającego obsługę automatu do operacji bankowych nie spełnia podstawowych wymogów czytelności, poniewaŝ zawiera przecinające się linie odwzorowujące interakcje aktorów z systemem. Czytelności diagramów nie wolno lekcewaŝyć, gdyŝ diagramy są waŝnym medium ułatwiającym komunikację zarówno między członkami zespołu projektowego, jak i między zespołem projektowym a klientem.
ud Bank operations machine Database management subsystem s account service Account s balance information s card and code verification s card initialization System administrator Rys. 7 Diagram przypadków uŝycia dla automatu do operacji bankowych 2.7 Rozbudowa modelu przypadków uŝycia RozwaŜmy diagram przypadków uŝycia przedstawiony na Rys. 8.? Deposit money Withdraw money Rys. 8 Przykładowy diagram przypadków uŝycia O ile klient moŝe sam wypłacać pieniądze, o tyle kwestią otwartą pozostaje to, czy moŝe je takŝe sam wpłacać. Przyjmując, Ŝe klient nie ma bezpośredniego dostępu do funkcjonalności związanej z wpłatą pieniędzy, naleŝy wprowadzić nowego aktora, np. kasjera. Na diagramie na Error! Reference source not found. aktor Kasjer został dołączony jako kolejny element rozbudowujący model. Deposit money Cashier Withdraw money Rys. 9 Model rozbudowany o dodatkowego aktora
ud Bank system Deposit money Withdraw money Cashier Bank client Check account balance Take a loan Management Rys. 10 Model rozbudowany o kolejnych aktorów, kolejne przypadki uŝycia, obramowanie diagramu i nagłówek Model moŝna dalej rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków uŝycia, bloków ponownego uŝycia czy teŝ relacji zarówno między przypadkami uŝycia, jak i przypadkami uŝycia i blokami ponownego uŝycia (Rys. 10 i Rys. 11). Ponadto moŝna wprowadzić obramowanie diagramu i nazwę systemu. ud Bank system Deposit money Cashier Withdraw money Update account balance Bank client Check account balance Take a loan Management Rys. 11 Model rozbudowany o blok ponownego uŝycia i relacje między przypadkami uŝycia
2.8 Stopień szczegółowości modelu przypadków uŝycia Model przypadków uŝycia dostarcza bardzo abstrakcyjnego spojrzenia na system spojrzenia z pozycji aktorów, którzy go uŝywają. Podstawowym, choć nie jedynym, zastosowaniem tego modelu jest dialog z przyszłymi uŝytkownikami, którego celem jest sformułowanie poprawnych wymagań na system. Model nie powinien być ani zbyt szczegółowy ani zbyt ogólny: zbyt szczegółowy utrudnia analizę, a zbyt ogólny nie pozwala na wykrycie bloków ponownego uŝycia. Jak pokazuje praktyka, tworzenie diagramów przypadków uŝycia jest w duŝym stopniu niezdeterminowane i subiektywne, w związku z czym zarówno zawartość, jak i stopień szczegółowości diagramów pozostają kwestią intuicji i doświadczenia analityka. Na ogół róŝni analitycy tworzą (przynajmniej częściowo) róŝne modele (patrz: Error! Reference source not found. i Rys. 13Error! Reference source not found.), przy czym stwierdzenie to ma znaczenie bardziej ogólne i odnosi się do wszelkiego rodzaju modeli, a nie tylko modelu przypadków uŝycia. Edit program Compile program Programmer Execute program Print file User Rys. 12 Przykładowy diagram przypadków uŝycia Edit program Compile program Programmer Execute program Print file User Rys. 13 Inny wariant diagramu z Rys. 12 2.9 Tworzenie modelu przypadków uŝycia Model przypadków uŝycia, reprezentowany przez zbiór przypadków uŝycia oraz zbiór aktorów wchodzących w interakcję z systemem za pośrednictwem tych przypadków, dostarcza opisu funkcjonalności systemu i jego kontekstu. Oznacza to, Ŝe na etapie tworzenia modelu przypadków uŝycia główny nacisk jest połoŝony na wymagania funkcjonalne, natomiast wymagania niefunkcjonalne (np. współbieŝność w korzystaniu ze wspólnych zasobów w trakcie interakcji między przypadkami uŝycia) są ignorowane. Głównym zadaniem
modelu jest bowiem poprawne opisanie funkcjonalności dla projektowanego systemu, podczas gdy wymagania niefunkcjonalne stanowią warunki uzupełniające, wypełnieniem których naleŝy zająć się na etapie projektowania. Aby zapewnić uŝywanie jednolitych terminów w trakcie tworzenia modelu, jednocześnie z nim musi powstawać słownik pojęć z dziedziny problemowej i/lub prosty model obiektowy dziedziny. Tworzenie modelu przypadków uŝycia opiera się na czterech krokach (Rys. 14) i wymaga ścisłej współpracy z przyszłym uŝytkownikiem systemu, co implikuje zasadę: nie opisuj przypadków uŝycia w sposób, który nie jest łatwo zrozumiały dla uŝytkownika. Following steps are documented in 1 Establish glossary Notion glossary 2 Determine actors 3 Determine use cases Actors definition document 4 Create description for each use case and: split use case into named parts search for common parts in different use cases Use case diagram with detailed description for each use case Rys. 14 Kolejne kroki w konstrukcji modelu przypadków uŝycia 2.9.1 Krok 1: sporządzenie słownika pojęć Słownik pojęć dotyczy dziedziny problemowej. Tworzenie słownika naleŝy rozpocząć juŝ na etapie budowy modelu przypadków uŝycia dla projektowanego systemu, zwracając uwagę m.in. na następujące elementy: Budowa słownika polega na wyłowieniu z wymagań uŝytkownika tych pojęć, które odnoszą się do aktorów, przypadków uŝycia, obiektów, operacji, zdarzeń, itp. Pojęcia w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Posługiwanie się pojęciami ze słownika powinno być regułą przy opisie kaŝdego kolejnego problemu czy budowie kaŝdego kolejnego modelu. PoniŜej przedstawiamy przykładowy termin ze słownika pojęć: Konto słuŝy do rejestrowania zasobów i wyników transakcji przeprowadzanych przez klienta, będącego właścicielem konta. Konta mogą być róŝnych typów, w szczególności wyróŝnia się konta indywidualne, małŝeńskie, firmowe i inne. Klient moŝe posiadać więcej niŝ jedno konto. Kwalifikując pojęcia do słownika naleŝy zwrócić uwagę na: rzeczowniki mogą one oznaczać aktorów lub byty z dziedziny problemowej; frazy opisujące funkcje, akcje, zachowanie mogą one być podstawą do wyróŝnienia przypadków uŝycia. 2.9.2 Krok 2: identyfikowanie aktorów Przy określaniu aktorów istotne są odpowiedzi na następujące pytania: Jaka grupa uŝytkowników potrzebuje wspomagania ze strony systemu (np. osoba wysyłająca korespondencję, składająca zamówienia, itp.)? Jacy uŝytkownicy są potrzebni do tego, aby system działał i wykonywał swoje funkcje (np. administrator systemu)? Z jakich elementów zewnętrznych (innych systemów, czujników, sieci, itp.) musi korzystać system, aby realizować swoje funkcje?
Ustalanie potencjalnych aktorów musi być powiązane z ustaleniem zakresu odpowiedzialności systemu, co oznacza konieczność określenia granic systemu, tj. odrzucenia tych obszarów dziedziny problemowej, których system nie obejmuje. Potencjalnych aktorów moŝna graficznie przedstawić wykorzystując diagram kontekstowy jak na Rys. 15. Database management subsystem «system» Bank operations machine System administrator Rys. 15 Diagram kontekstowy dla systemu dla automatu do operacji bankowych W następnym etapie naleŝy ustalić: nazwę dla kaŝdego aktora/roli; zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy wyspecyfikowanymi zakresami, np. sekretarka a pracownik administracji, pracownik administracji a dowolny pracownik, pracownik a dowolna osoba. Niekiedy, aby ulepszyć zarówno strukturę diagramu, jak i jego czytelność (poprzez zmniejszenie liczby interakcji aktorów z przypadkami uŝycia, co pozwala np. zmniejszyć liczbę przecinających się linii), warto ustalić dla aktorów hierarchię dziedziczenia dostępu do funkcji systemu, czyli zbudować strukturę generalizacjispecjalizacji dla aktorów. Na przykład, na Rys. 16 aktor Pracownik administracji dziedziczy dostęp do przypadków uŝycia wyspecyfikowanych dla aktora Pracownik, oraz ma dostęp do przypadków związanych z jego własnym, specyficznym sposobem wykorzystywania systemu. Natomiast na Rys. 17 wykorzystano strukturę dziedziczenia dla aktorów w celu zmniejszenia liczby linii oznaczających interakcje aktorów z systemem. inheritance symbol Person Employee Guest Accountant Administrative worker Rys. 16 Przykładowa struktura dziedziczenia dla aktorów
ud Bank operations machine Database management subsystem s account service System administrator Account s balance information s card initialization s card and code verification Rys. 17 Diagram dla automatu do operacji bankowych z wykorzystaniem struktury dziedziczenia dla aktorów 2.9.3 Krok 3: określanie przypadków uŝycia Kolejne czynności, które moŝna zalecić analitykowi w procesie wyszukiwania przypadków uŝycia, to: Dla kaŝdego aktora określ zadania (funkcje), które powinien wykonywać w związku z działalnością w zakresie zarówno dziedziny problemowej, jak i wspomagania działalności systemu. W pierwszej kolejności wyodrębnij zadania główne, czyli te, które stanowią istotę współpracy z systemem (są normalnym, standardowym uŝyciem). Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcjonalne. PowiąŜ w jeden przypadek uŝycia zespół zadań realizujących podobne cele, unikając przy tym rozbicia jednego przypadku uŝycia na zbyt wiele podprzypadków (szczególnie na wczesnych etapach budowy modelu). Uporządkuj aktorów i przypadki uŝycia w postaci diagramu. Przeanalizuj zarówno wyspecyfikowane przypadki uŝycia (niektóre z nich mogą być mutacjami lub szczególnymi przypadkami innych przypadków uŝycia), jak i powiązania aktorów z przypadkami uŝycia. Ustal, co jest zbędne, a co moŝe być uogólnione. Określ wzajemne relacje pomiędzy przypadkami głównymi, dla kaŝdej relacji specyfikuj rodzaj zaleŝności: podstawowa czy opcjonalna. Dodaj zachowania skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie przypadków głównych z tego rodzaju zachowaniem; mogą być one takŝe powiązane w pewną strukturę. Opisz przypadki uŝycia przy pomocy zdań w języku naturalnym, uŝywając terminów zdefiniowanych w słowniku pojęć. Podstawę do stwierdzenia, czy opis jest wystarczająco szczegółowy, stanowią odpowiedzi na pytania: czy wszyscy uczestnicy projektu rozumieją znaczenie przypadku?; czy dokumentacja jest wystarczająco szczegółowa dla projektantów i testerów? Tworząc podział kaŝdego przypadku uŝycia na nazwane części (bloki) staraj się, aby nie były one, podobnie jak cały model, ani zbyt ogólne, ani zbyt szczegółowe. Przeanalizuj istniejące przypadki pod kątem wyizolowania bloków ponownego uŝycia. Przeanalizuj podobieństwo nazw przypadków uŝycia oraz podobieństwo nazw i zachowania bloków występujących w ich specyfikacji. Wydzielenie bloku ponownego uŝycia moŝe być powiązane z określeniem bardziej ogólnych zadań lub dodaniem nowej specjalizacji do istniejącego zadania. Nazwy dla przypadków uŝycia powinny być krótkie, ale jednoznacznie określające charakter zadania. Nazwy te powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. wpłacanie pieniędzy, a nie przyjęcie pieniędzy od klienta.
2.9.4 Krok 4: dokumentowanie przypadków uŝycia Dokumentacja przypadków uŝycia powinna zawierać: Diagramy przypadków uŝycia: aktorzy, przypadki uŝycia i relacje zachodzące między przypadkami. Krótki, ogólny opis kaŝdego przypadku uŝycia: jak i kiedy przypadek uŝycia zaczyna się i kończy; opis interakcji przypadku uŝycia z aktorami, m.in. kiedy interakcja ma miejsce i co jest przesyłane; kiedy i do czego przypadek uŝycia potrzebuje danych zapamiętanych w systemie, oraz jak i kiedy zapamiętuje dane w systemie; wyjątki występujące przy obsłudze przypadku; specjalne wymagania, np. czas odpowiedzi, wydajność; jak i kiedy uŝywane są pojęcia dziedziny problemowej. Opis szczegółowy kaŝdego przypadku uŝycia: scenariusz(e); diagram(y) aktywności; diagramy aktywności są omówione w wykładzie poświęconym temu zagadnieniu. Tab. 3 zawiera przykładowy formularz dla dokumentowania przypadków uŝycia. Tab. 4 prezentuje opis przypadku uŝycia WypoŜycz płytę dla systemu wspierającego pracę wypoŝyczalni płyt DVD (tekst wymagań umieszczono w 2.12). Nazwa Nr id Autor Priorytet Typ Aktorzy Opis Warunek początkowy Warunek końcowy Główny przepływ zdarzeń Alternatywne przepływy zdarzeń Wymagania niefunkcjonalne Uwagi dodatkowe Nazwa przypadku uŝycia Numer identyfikacyjny przypadku Informacje o autorze Np. wysoki, średni, itd. Np. ogólny, szczegółowy Lista aktorów związanych z przypadkiem Krótka charakterystyka przypadku Świat przed, czyli informacja o tym, co powinno być wykonane wcześniej, tak aby system mógł zrealizować dany przypadek Świat po Scenariusz główny Scenariusze alternatywne Np. czas odpowiedzi, szybkość transakcji, itd. Ograniczenia; informacje biznesowe Tab. 3 Przykładowy formularz dla dokumentowania przypadków uŝycia Nazwa Wypożycz płytę Nr id 7 Autor Jan Kowalski - analityk Priorytet Wysoki Typ Szczegółowy Aktorzy Pracownik wypożyczalni
Opis Warunek początkowy Warunek końcowy Główny przepływ zdarzeń Alternatywne przepływy zdarzeń Wymagania niefunkcjonalne Przypadek dotyczy rejestracji wypoŝyczenia płyty; płyty przeznaczone dla dorosłych moŝna wypoŝyczać po ukończeniu 18-tego roku Ŝycia; jednocześnie moŝna mieć wypoŝyczonych co najwyŝej 5 płyt; nie wolno wypoŝyczać osobie, która aktualnie znajduje się w okresie karencji; Osoba wypoŝyczająca powinna być zarejestrowana jako klient wypoŝyczalni O ile warunki wypożyczenia zostały zrealizowane, to powinny zostać zarejestrowane następujące informacje o wypożyczeniu płyty : kto wypożyczył, jaką płytę wypożyczył i kiedy wypożyczył. 1. Pracownik wypożyczalni uruchamia przypadek Wypożycz płytę. 2. System odpytuje o nazwisko i imię osoby wypożycząjącej. Pracownik wprowadza odpowiednie informacje. 3. System odpytuje o tytuł filmu. Pracownik wprowadza tytuł. 4. System rejestruje wypożyczenie płyty z filmem (kto, co, data wypoŝyczenia.) 2a O ile osoba wypożyczająca nie jest zarejestrowana w systemie, system informuje o tym aktora i kończy przypadek użycia. 2b. O ile jest zarejestrowana więcej niż jedna osoba o tym samym nazwisku i imieniu, system wyświetla listę osób. Pracownik wybiera odpowiednią osobę z listy. 3a O ile aktualnie nie ma filmu o tym tytule w zasobach wypożyczalni, lub wszystkie płyty z filmem zostały wypożyczone, system informuje o tym aktora i kończy przypadek. 3b O ile film jest przeznaczony dla osób dorosłych a osoba wypożyczająca nie ukończyła 18-tu lat, system informuje o tym aktora i kończy przypadek. 3c Jeśli osoba wypoŝyczająca ma juŝ aktualnie co najmniej pięć wypoŝyczonych płyt na koncie, system informuje o tym aktora i kończy przypadek. 3d Jeśli osoba wypoŝyczająca znajduje się aktualnie w okresie karencyjnym, system informuje o tym aktora i kończy przypadek. Brak Uwagi dodatkowe Brak Tab. 4 Formularz dla przypadku uŝycia WypoŜycz płytę dla systemu obsługującego wypoŝyczalnię płyt DVD. 2.10 Przykład z kancelarią prawniczą Na Rys. 18 umieszczono diagram przypadków uŝycia skonstruowany w oparciu o tekst wymagań dla systemu wspierającego pracę kancelarii prawniczej. Kancelaria prawnicza Pewna kancelaria prawnicza postanowiła usprawnić obsługę prowadzonych przez nią spraw poprzez wykorzystanie systemu informatycznego. PoniŜej prezentujemy tekst wymagań uŝytkownika, w oparciu o który przeprowadzimy modelowanie pojęciowe: 1) NaleŜy przechowywać następujące dane o klientach i prawnikach: imiona (nie więcej niŝ dwa), nazwisko, nazwisko panieńskie (tylko dla kobiet), adres i telefon. 2) Dla prawników ma być przechowywany takŝe staŝ pracy w zawodzie.
3) Dla spraw prowadzonych przez kancelarię mają być pamiętane informacje, takie jak: data rozpoczęcia i data zakończenia sprawy, czego dotyczyła, czy zakończyła się sukcesem, dane klienta, który ją zlecił oraz jacy prawnicy zajmowali się sprawą. 4) Mają być przechowywane daty i miejsca wszystkich rozpraw związanych ze sprawą. KaŜdej rozprawie ma być przypisywany identyfikator, unikatowy w ramach danej sprawy. 5) PoniewaŜ moŝliwa jest sytuacja, Ŝe prawnik zostanie odsunięty od sprawy jeszcze w trakcie jej trwania, ma być pamiętane od kiedy do kiedy prawnik zajmował się daną sprawą. 6) W danym momencie czasu prawnik moŝe być przydzielony tylko do jednej sprawy. 7) NaleŜy uwzględnić fakt, Ŝe prawnik moŝe być klientem kancelarii, ale wtedy nie moŝe zajmować się sprawami, które zlecił. 8) Sprawa moŝe być anulowana w dowolnym momencie; dane sprawy anulowanej nie mają być przechowywane. 9) Dane sprawy mają być przechowywane przez 10 lat od momentu jej zakończenia. 10) Oczekuje się, Ŝe system będzie wspomagał pracę kancelarii przy: Rejestrowaniu spraw. Przydzielaniu prawników do spraw. Odsuwaniu prawników od spraw. Rejestracji rozpraw. Rejestracji zakończenia spraw. Ustalaniu listy spraw, które w zadanym okresie czasu zakończyły się sukcesem. ud Law office Register trial Lawyer Register case Law office manager Assign lawyer to the case Check if the lawyer is currently available Dismiss lawyer from the case List cases met with success Cancel case 10 years after closing the case Delete case Rys. 18 Diagram przypadków uŝycia dla systemu wspierającego pracę kancelarii prawniczej
2.11 Podsumowanie Głównym celem konstruowania modelu przypadków uŝycia jest wsparcie analityka w trakcie wykonywania waŝnego i jednocześnie trudnego zadania, jakim jest określenie poprawnych wymagań funkcjonalnych na projektowany system. Ponadto model przypadków uŝycia pozwala na: lepsze zrozumienie moŝliwych sposobów wykorzystania projektowanego systemu, co oznacza zwiększenie stopnia świadomości przyszłych uŝytkowników, analityków i projektantów co do celów systemu, oraz pośrednio co do jego funkcjonalności; usprawnienie komunikacji wewnątrz tzw. szerokiego grona uczestników projektu (przedstawicieli klienta, uŝytkowników końcowych i członków zespołu projektowego); ustalenie praw dostępu do zasobów (dzięki wyspecyfikowaniu interakcji aktorów z przypadkami uŝycia); ustanowienia bazy do projektowania interfejsu uŝytkownika. wstępne określenie strukturalnych własności systemu, a przez to ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu; dostarczenie bazy do szacowania czasu i kosztów realizacji projektu; dostarczenie podstawy do budowy planu rozwoju oprogramowania; dostarczenie podstawy do sporządzenia planu testów systemu; weryfikację poprawności i kompletności artefaktów wytwarzanych w trakcie budowy systemu. Rys. 19 ilustruje wpływ, jaki model przypadków uŝycia projektowanego systemu wywiera zarówno na model analityczny tego systemu, jak i na model dziedziny problemowej oraz vice versa, tj. wpływ, jaki model dziedziny problemowej wywiera na model zastosowania (model zgodny z zakresem odpowiedzialności systemu) i model analityczny systemu. Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu, obejmując takŝe współpracujące systemy zewnętrzne. Experts Domain experience Domain model Users Use cases Analytical model of system strong influence weak influence Rys. 19 Ilustracja wzajemnych zaleŝności między elementami istotnymi w procesie budowy systemu 2.12 Przykładowe pytania i problemy do rozwiązania 1. Wykonaj poniŝsze zadania w oparciu o tekst specyfikujący wymagania dla systemu wspierającego pracę wypoŝyczalni płyt DVD: Utwórz słownik pojęć; Określ aktorów systemu; Dla kaŝdego z aktorów znajdź przypadki uŝycia (bez zagłębiania się w wewnętrzną organizację kaŝdego z poszczególnych przypadków); W oparciu o aktorów i wyspecyfikowane przypadki zbuduj diagram przypadków uŝycia;
Przeprowadź strukturalizację przypadków uŝycia uwzględniając występujące pomiędzy nimi relacje: inkluzji oraz ekstensji; Zbuduj hierarchię dla aktorów; Dokonaj transformacji diagramu uwzględniając moŝliwe relacje występujace pomiędzy aktorami systemu; Udokumentuj przypadki uŝycia; Zaktualizuj słownik pojęć. 2. Dla kilku wybranych nietrywialnych przypadków uŝycia (np. mógłby to być przypadek związany ze zwrotem plyty) wykonaj następujące zadania: Skonstruuj scenariusze; Zidentyfikuj bloki ponownego uŝycia; Zbuduj diagramy przypadków uŝycia, dla kaŝdego z wybranych nietrywialnych przypadków, uwzględniając wnioski wynikłe z analizy scenariuszy oraz zidentyfikowane bloki ponownego uŝycia; Zmodyfikuj dokumentację przypadków; Zaktualizuj słownik pojęć. WypoŜyczalnia płyt DVD 1. System ma przechowywać informacje o wszystkich klientach (imię, nazwisko, adres, telefon). Klientem wypoŝyczalni moŝe zostać osoba, która ukończyła 16 lat Ŝycia. 2. System ma przechowywać informację o wszystkich pracownikach (imię, nazwisko, data urodzenia, miejsce urodzenia, adres, telefon, data zatrudnienia, pensja). Nie wolno jest zatrudniać nieletnich. Pracownik wypoŝyczalni moŝe być jednocześnie klientem wypoŝyczalni i wtedy obowiązują go te same zasady, które dotyczą zwykłych klientów. 3. System ma przechowywać informacje o wszystkich filmach i płytach DVD w wypoŝyczalni. 4. Informacja o filmie dotyczy: tytułu filmu, daty produkcji, długości filmu, aktorów grających główne role oraz opłaty pobieranej za wypoŝyczenie płyty z filmem. Filmy przeznaczone wyłącznie dla osób dorosłych moŝe wypoŝyczyć osoba, która ukończyła 18 lat. 5. MoŜe istnieć wiele płyt z danym filmem; co najmniej jedna. KaŜda płyta (numer identyfikacyjny) moŝe mieć nagrany tylko jeden film. Usunięcie filmu pociąga za sobą usunięcie wszystkich płyt z tym filmem. 6. Informacja o wypoŝyczeniu dotyczy: daty wypoŝyczenia, daty zwrotu (określonej przez klienta) oraz opłaty za wypoŝyczenie. Opłata jest wnoszona od razu przy wypoŝyczeniu. Klient moŝe podać róŝne daty zwrotu dla kaŝdej z wypoŝyczanych jednocześnie płyt. 7. Do jednego wypoŝyczenia moŝe być przypisane kilka płyt, jednak nie więcej niŝ trzy. 8. Jednocześnie moŝna mieć wypoŝyczonych max. 5 płyt chodzi tu o liczbę płyt jaka w ogóle jest w danym momencie wypoŝyczona danemu klientowi. 9. W przypadku przetrzymania płyty, opłata za dzień przetrzymania zostaje zwiększona o pewien procent w stosunku do opłaty standardowej. Procent ten rośnie wraz z kolejnymi przetrzymaniami ale nie moŝe przekroczyć 100% opłaty standardowej. 10. Jeśli fakt przetrzymania powtórzy się trzykrotnie, osoba traci chwilowo prawo do korzystania z wypoŝyczalni; okres karencji trwa rok czasu. 11. Codziennie opracowuje się raport dzienny o wydarzeniach w wypoŝyczalni, tzn. o: ilości nowych wypoŝyczeń, ilości zwrotów, ilości aktualnie wypoŝyczonych płyt oraz o dziennym utargu. 12. Co jakiś czas opracowuje się raport okresowy za zadany okres (okresy mogą się nakładać), który zawiera informacje o najczęściej wypoŝyczanym filmie oraz o najpopularniejszym aktorze. 13. Dla kaŝdego raportu jest pamiętana data sporządzenia. 14. Raporty są uporządkowane chronologicznie.