Wykład 6 Przypadki użycia a proces Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa 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

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). Definicje Aktor: ktoś (lub coś) spoza systemu, wchodzący w interakcję z systemem. Przypadek użycia: sekwencja akcji realizowanych przez system, w efekcie których dostarczane są obserwowalne rezultaty do konkretnego aktora. 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 (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. Wypłać pieniądze Dokonaj transferu pieniędzy Sprawdź stan konta Klient 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.

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. 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: 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.

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. Podsumowywując, inkluzja i ekstensja są wykorzystywane dla: - uproszczenia złożonego przepływu zdarzeń, - reprezentowania zachowań opcjonalnych, - obsługi wyjątków. (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.

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. W RUP, przypadki użycia wspomagają członków zespołu przy: 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).

Przypadki użycia a inne modele Główne przepływy prac Modelowanie biznesowe Analiza i projektowanie Wymagania Implementacja Testowanie Modele Biznesowy model przypadków użycia Model przypadków użycia realizowany przez implementowany przez weryfikowany przez realizowany przez Biznesowy model obiektowy Model projektowy Model implementacji Model testów automatyzowany 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.