PolskoJaposka Wysza Szkoa Technik Komputerowych Warszawa Studia Podyplomowe

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 E. Stemposz. Rational Unified Process, Wykład 6, Slajd 1 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 2 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 3 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 4 wrzesień 2002

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. Dokonaj transferu pieniędzy Wypłać pieniądze 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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 5 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 6 wrzesień 2002

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ę. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 7 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 8 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 9 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 10 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 11 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 12 wrzesień 2002

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, 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). E. Stemposz. Rational Unified Process, Wykład 6, Slajd 13 wrzesień 2002

Przypadki użycia a inne modele Główne przepływy prac Modelowanie biznesowe Wymagania Biznesowy model przypadków użycia Model przypadków użycia Analiza i projektowanie Implementacja Testowanie realizowany przez implementowany przez weryfikowany przez Model projektowy Model implementacji Model testów Modele realizowany przez Biznesowy model obiektowy automatyzowany przez E. Stemposz. Rational Unified Process, Wykład 6, Slajd 14 wrzesień 2002

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. E. Stemposz. Rational Unified Process, Wykład 6, Slajd 15 wrzesień 2002