Przypadki użycia a proces Wykład 6 Rational Unified Process Studia Podyplomowe IT w Biznesie

Studia Podyplomowe IT w Biznesie

Rational Unified Process

Wykład 6

Przypadki użycia a proces

Wykładowca:

dr inż. Ewa Stemposz ewag@ipipan.waw.pl

Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Warszawa

Zagadnienia Zagadnienia

Definicje

Przepływ zdarzeń Scenariusze

Identyfikacja przypadków użycia

Budowanie modelu przypadków użycia Przypadki użycia a inne modele

Podsumowanie

Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The

Rational Unified Process An Introduction, Addison-Wesley, 1999.

Definicje (1)

 Modelowanie przypadków użycia - rekomendowane przez RUP - jest metodą prezentowania problemu w sposób zrozumiały dla szerokiego grona uczestników projektu: użytkowników końcowych, klientów i członków zespołu projektowego (stakeholders: wszystkie osoby zainteresowane realizacją projektu).

Przypadek użycia: sekwencja akcji realizowanych przez system, w efekcie których dostarczane są obserwowalne rezultaty do konkretnego aktora.

Aktor: ktoś (lub coś) spoza systemu, wchodzący w interakcję z systemem.

 Akcja: atomowa operacja - wykonywana w całości lub 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 do aktora, który ją wywołał, albo do innych aktorów.

Definicje

Definicje (2)

 Sekwencja akcji: w odpowiedzi na przepływ zdarzeń między aktorem a systemem. Sekwencje akcji są grupowane w przypadki użycia.

 Akcje realizowane przez system: jest to ważne sformułowanie służące określeniu granic systemu i ustaleniu zakresu jego odpowiedzialności - to, co jest wykonywane przez system jest tu jasno zdefiniowane, inne od akcji świata zewnętrznego i wyraźnie od nich oddzielone.

 Obserwowalny rezultat: sekwencja akcji musi zakończyć się wyprodukowaniem czegoś, co posiada użyteczną wartość dla aktora. Nie zaleca się wykonywania kilku przypadków użycia, dla uzyskania czegoś użytecznego. 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ść jest dostarczana do specyficznych

grup użytkowników, specyfika polega tu na związku z pewną rolą, a nie z

konkretnymi osobami.

Definicje (3)

 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. Realizacja przypadku użycia, wykorzystywana dalej w projektowaniu, pokazuje jak - w kategoriach współpracujących obiektów - przypadek jest aktualnie realizowany w systemie.

 Załóżmy, że trzy powyższe przypadki użycia specyfikują wszystkie możliwe sposoby wykorzystania systemu dla bankomatu.

 Nazwy przypadków opisują wartości dostarczane do aktora.

Wypłać pieniądze

Dokonaj transferu pieniędzy

Sprawdź stan konta

Klient

Przepływ zdarzeń (1)

 Najważniejszym elementem w opisie każdego przypadku użycia - na etapie formułowania wymagań (przepływ prac: Wymagania) - 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.

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.

Na przykład, przepływ zdarzeń między aktorem a systemem dla przypadku

użycia “Wypłać pieniądze” mógłby być opisany, jak poniżej:

Przepływ zdarzeń (2)

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 przebiegi dla tego przypadku użycia:

 Dane od aktora: np. aktor może unieważnić transakcję w dowolnym momencie lub może nie chcieć potwierdzenia.

 Stan 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 też blokada urządzenia drukującego potwierdzenie.

 Time-out lub błędy: np. jeśli Klient nie odpowie w określonym czasie,

system może unieważnić transakcję.

Scenariusze

 Każdy alternatywny przebieg nie oznacza oddzielnego przypadku użycia raczej grupujemy wszystkie powiązane przebiegi w jeden przypadek użycia.

 Taką grupę czasami nazywa się klasą przypadków użycia.

 Wystąpieniem klasy przypadków użycia jest wtedy jeden z pojedynczych, alternatywnych przebiegów.

 Wystąpienie klasy przypadków użycia jest także nazywane scenariuszem.

 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ąć prace od

pewnego konkretnego scenariusza, a następnie dokładać przebiegi

alternatywne - w ten sposób tworzy się klasę przypadków użycia.

Identyfikacja przypadków użycia

 Trudna decyzja: czy zbiór interakcji między użytkownikiem a systemem, konkretny dialog (scenariusz) opisuje jeden czy kilka przypadków użycia?

Podstawę do rozróżnienia musi stanowić stwierdzenie: czy system dostarcza obserwowalny – mający jakąś wartość dla użytkownika - rezultat!!!

 Dla przykładu z bankomatem: czy osiągnęlibyśmy satysfakcję użytkownika, gdyby po włożeniu karty do bankomatu i podaniu PINu, system powiadomił go o prawidłowym wprowadzeniu danych i zwrócił kartę nie odpytując o wielkość kwoty i nie wypłacając pieniędzy?

 Ważne: trzymać razem akcje prowadzące do uzyskania obserwowalnego

rezultatu, tak by mogłyby 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 można stracić z oczu cel: wartość

dostarczaną do użytkownika.

Budowanie modelu przypadków użycia (1)

 Model przypadków użycia: zbiór przypadków użycia dla systemu (całości lub tylko pewnego fragmentu) wraz ze zbiorem aktorów współdziałających z systemem za pośrednictwem przypadków.

 Model przypadków użycia dostarcza opisu funkcjonalności systemu i jego kontekstu oraz służy jako podstawa kontraktu między klientem a członkami zespołu projektowego.

 Diagramy przypadków użycia w UML służą do wizualizacji modelu.

 Na etapie tworzenia modelu przypadków użycia są ignorowane wymagania niefunkcjonalne, jak np. współbieżność w korzystaniu ze wspólnych zasobów w trakcie interakcji między przypadkami użycia.

Główne zadanie modelu - to przeniesienie funkcjonalności, wymagania niefunkcjonalne stanowią warunki uzupełniające, wypełnieniem których należy się zająć na etapie projektowania.

 Aby zapewnić jednolite używanie terminów w trakcie tworzenia modelu,

jednocześnie z nim musi powstawać słownik pojęć z dziedziny problemowej

i/lub prosty model obiektowy dziedziny.

Budowanie modelu przypadków użycia (2)

 Budowanie modelu przypadków użycia powinno rozpoczynać się od

“naszkicowania” przypadków - bez zbędnych detali. W pierwszych iteracjach fazy opracowywania, tylko przypadki mające szczególne znaczenie dla architektury systemu powinny być wyposażone w szczegółowe opisy. Podstawę do rozróżnienia czy opis jest wystarczająco szczegółowy stanowi stwierdzenie:

Czy wszyscy uczestnicy projektu rozumieją, co oznacza przypadek? Czy dokumentacja jest wystarczająco szczegółowa dla oparcia na niej pracy projektantów czy testerów?

 Na zakończenie fazy opracowywania, szczegółową dokumentację powinny posiadać wszystkie - oprócz bardzo prostych - przypadki użycia.

 Strukturalizacja przypadków użycia: przeprowadzana w oparciu o analizę przepływu zdarzeń, niezbędna dla dużych systemów, tak by aktywności, takie jak: planowanie, ustalanie priorytetów i szacowanie rezultatów nie stały się zadaniami znacząco utrudniającymi realizację projektu.

(1) Pakiety przypadków użycia: grupują powiązane przypadki użycia w

jednym kontenerze.

Budowanie modelu przypadków użycia (3)

(2) Inkluzja, ekstensja: przepływ zdarzeń należy 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 użycia. Jest to zgodne z regułą obowiązującą przy projektowaniu: dane zachowanie systemu jest realizowane przez jeden podzbiór obiektów, niezależnie od tego, który przypadek użycia jest realizowany.

(3) Generalizacja/specjalizacja również opierana jest o wyszukiwanie podobieństw w przypadkach użycia. Jest używana w celu rozszerzenia czy ulepszenia pierwotnego przepływu zdarzeń. Specjalizacja jest środkiem ułatwiającym modelowanie szkieletów i wariantów aplikacji.

Podsumowywując, inkluzja i ekstensja są wykorzystywane dla:

- uproszczenia złożonego przepływu zdarzeń,

- reprezentowania zachowań opcjonalnych,

- obsługi wyjątków.

Budowanie modelu przypadków użycia (4)

Podstawowy błąd: nadużywanie relacji inkluzji, ekstensji i generalizacji/specjalizacji, co prowadzi do utworzenia modelu trudnego do zrozumienia i pielęgnacji i pośrednio skutkuje zwiększeniem kosztów projektu.

Przypadki użycia a RUP

RUP, będąc procesem “prowadzonym” w oparciu o przypadki użycia, uczynił z nich podstawę dla całego procesu tworzenia produktu.

 budowie i walidacji modelu logicznego (specyfikacji implementacji),

 definiowaniu przypadków i procedur testowych w modelu testów,

 planowaniu iteracji,

 tworzeniu dokumentacji użytkownika,

 rozmieszczaniu aplikacji (deployment).

W RUP, przypadki użycia wspomagają członków zespołu przy:

Przypadki użycia a inne modele

Modelowanie

biznesowe Wymagania Analiza i

projektowanie Implementacja Testowanie Główne przepływy prac

Biznesowy model przypadków

użycia

Biznesowy model obiektowy

Model przypadków

użycia

Model projektowy

Model implementacji

Model testów Modele

realizowany przez

automatyzowany przez

implementowany przez

weryfikowany przez realizowany

przez

Podsumowanie

 Różnice w modelach: problemu i rozwiązania (a także konieczność przeprowadzania transformacji między nimi) to poważne źródło błędnych interpretacji.

 Brak dobrej komunikacji między klientem i użytkownikami a członkami zespołu projektowego często wręcz uniemożliwia określenie rozwiązania dla danego problemu.

 RUP - jako proces “prowadzony” w oparciu o przypadki użycia - uczynił z

przypadków (efektu końcowego aktywności: Wymagania) bazę dla całego

procesu budowania produktu tworząc w oparciu o nie rodzaj języka

stanowiącego podstawę do komunikacji między wszystkimi osobami

zaangażowanymi w realizację projektu.