Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

Transkrypt

1 Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use Cases)

2 Cele Uproszczenie utrzymywania wymagań bez poświęcania jasności i zrozumiałości dla stron Strukturyzacja modelu przypadków użycia Definicja i opis związków pomiędzy przypadkami include, extend, generalizacja Opis konkretnych i abstrakcyjnych przypadków Definicja generalizacji aktorów Opis konkretnych i abstrakcyjnych aktorów 2

3 W którym miejscu dyscypliny Wymagania jesteśmy? 3

4 Czynności i artefakty (1) 4

5 Czynności i artefakty (2) Celem tego punktu workflow są: Ewaluacja formalnie złożonych żądań zmian i określanie ich wpływy na istniejący zbiór wymagań Strukturyzacja modelu przypadków użycia Określenie odpowiednich atrybutów wymagań i traceability Formalna weryfikacja rezultatów dyscypliny wymagań względem zgodności z punktem widzenia systemu przez klienta Obecnie istotna dla nas jest strukturyzacja modelu przypadków użycia 5

6 Strukturyzacja modelu przypadków użycia (1) Co oznacza strukturyzacja modelu? Wyciąganie przed nawias części przypadków użycia w celu stworzenia nowych przypadków Po co strukturyzujemy? Uproszczenie oryginalnych przypadków Łatwiejsze do zrozumienia Łatwiejsze do utrzymania Ponowne użycie wymagań Części wspólne można dzielić pomiędzy przypadkami Procesu nie można rozpoczynać zbyt wcześnie, ponieważ możemy zdezorientować klienta 6

7 Strukturyzacja modelu przypadków użycia (2) Celem strukturyzacji modelu przypadków użycia jest wydobycie z przypadku użycia zachowania, które lepiej będzie zaprezentowane w oddzielnym przypadku Przykłady takiego zachowania: Wspólne zachowanie Opcjonalne zachowanie Wyjątkowe zachowanie Zachowanie, które ma zostać rozwinięte w późniejszych iteracjach 7

8 Strukturyzacja modelu przypadków użycia (3) Przypadek reprezentujący modyfikację nazywa się przypadkiem dodatkowym (addition use case), natomiast przypadek oryginalny do przypadek bazowy (base use case) 8

9 Związki między przypadkami użycia <<include>> <<extend>> UWAGA: Nadużywanie include i extend doprowadza do dekompozycji funkcjonalnej, co z kolei utrudnia testowanie i implementację 9

10 Związek include (1) Oznacza włączanie (inclusion) jednego przypadku do drugiego (przypadek bazowy włącza do siebie przypadek włączany) Zachowanie przypadku włączanego jest jawnie włączone do przypadku bazowego włączenie <<include>> bazowy 10

11 Związek include (2) Związek include łączy przypadek bazowy z przypadkiem włączanym Przypadek włączany opisuje fragment zachowania, który zostaje wstawiony do instancji bazowego przypadku użycia Przypadek bazowy może zależeć od wyniku przypadku włączanego, ale nigdy żaden z nich nie może mieć dostępu do atrybutów drugiego W tym sensie włączenie jest hermetyzowane i reprezentuje zachowanie, które może zostać ponownie użyte w innym bazowym przypadku użycia 11

12 Przykład związku include Zmień hasło <<include>> Wykonaj dowolny przelew <<include>> Zweryfikuj hasło jednorazowe Klient Zdefiniuj nowy przelew <<include>> Zmień hasło 1. Ciąg podstawowy 1. Włącz zweryfikuj hasło jednorazowe lub SMS w celu potwierdzenia uprawnień Klienta 2. System wyświetla formularz zmiany hasła 3. Klient wpisuje Ciągi alternatywne... Zweryfikuj hasło jednorazowe 1. Ciąg podstawowy 1. System wyświetla formularz wpisania hasła jednorazowego z widocznym numerem żądanego hasła 2. Klient wpisuje hasło i zatwierdza 3. System weryfikuje hasło 2. Ciągi alternatywne A1. Niewłaściwe hasło A2. Hasło było już użyte wcześniej... 12

13 Wykonanie związku include Pełne wykonanie przypadku włączanego w momencie osiągnięcia punktu włączenia (przypomina wykonanie procedury w programie) Wykonanie przypadku włączanego jest obowiązkowe po dojściu do punktu włączenia samo dojście może być natomiast warunkowe (należy wtedy użyć ciągu alternatywnego) Po wykonaniu przypadku włączonego, sterowanie wraca do przypadku bazowego Instancja przypadku bazowego Przypadek bazowy 13 Włączany przypadek

14 Kiedy i dlaczego używamy include? Wyciągnięcie zachowania wspólnego dla dwóch lub więcej przypadków Unikanie wielokrotnego opisu tego samego zachowania Zapewnienie spójności wspólnego zachowania (zmianę wystarczy wprowadzić w jednym miejscu Wyciągnięcie i hermetyzacja części zachowania przypadku bazowego Uproszczenie złożonych ciągów zdarzeń (podobnie jak podciągi) Wyciągnięcie zachowania wtórnego przypadku użycia (nie stanowiącego o jego istocie także podobnie jak z podciągami) Przypadek włączany może powstać z ciągu zdarzeń 14

15 Związek extend (1) Łączy od przypadku rozszerzającego do przypadku bazowego Wstawia zachowanie przypadku rozszerzającego do przypadku bazowego Wstawienie następuje tylko, jeżeli warunek rozszerzenia jest prawdziwy Wstawienie następuje w nazwanym punkcie rozszerzalności bazowy <<extend>> rozszerzenie 15

16 Związek extend (2) Związek extend łączy rozszerzenie z przypadkiem bazowym Określamy, w którym miejscu przypadku bazowego następuje rozszerzenie poprzez referencję do nazwanego punktu rozszerzalności w bazowym przypadku użycia Przypadek rozszerzający może być abstrakcyjny, ale nie musi Przypadek rozszerzający może mieć dostęp do atrybutów przypadku bazowego i je modyfikować, nigdy odwrotnie (przyp. bazowy nie wie o rozszerzeniach) 16

17 Związek extend (3) Przypadek bazowy musi być kompletny i zrozumiały bez konieczności odnoszenia się do rozszerzeń (są one opcjonalne) Przypadek bazowy nie jest niezależny od rozszerzeń, ponieważ jego powodzenie potencjalnie zależy od ich wykonania 17

18 Przykład związku extend Dokonaj płatności Klient <<extend>> <<extend>> Dokonaj płatności kartą Dokonaj płatności przelewem Dokonaj płatności 1. Ciąg podstawowy... N-1 Klient kończy zakupy N. Klient wybiera opcję dokonania płatności N Ciągi alternatywne A1 Zmiana sposobu płatności Punkty rozszerzalności Punkt rozszerzalności Specyfika płatności mieści się w kroku N ciągu podstawowego i w kroku A1.7 ciągu alternatywnego A1 Zmiana sposobu płatności Centrum obsługi kart płatniczych System transakcyjny banku Dokonaj płatności kartą Przypadek rozszerza przypadek Dokonaj płatności w punkcie rozszerzalności Specyfika płatności 1. Ciąg podstawowy 1. Jeżeli klient wybierze płatność kartą, system prosi o podanie numeru karty 2. Klient wpisuje i zatwierdza numer karty 3. System łączy się z Ciągi alternatywne... 18

19 Dynamiczne planowanie przypadku użycia z extend Nazwane punkty rozszerzalności możemy umieszczać wszędzie, gdzie oczekujemy, że wymagania ulegną zmianie Przypadek użycia nie musi wiedzieć, w jaki sposób (i czy w ogóle) zostanie rozszerzony, decydują o tym warunki w przypadkach rozszerzających Do punktu rozszerzalności może być zaczepiona dowolna liczba przypadków rozszerzających 19

20 Zastosowanie związku extend Zazwyczaj zachowanie rozszerza się z kliku powodów: Rozwijane są dwie wersje systemu. Wymagania specyficzne dla klienta A są w jednym przypadku rozszerzającym, klienta B w drugim. Wymagania wspólne znajdują się w przypadku bazowym (rozszerzanym) Rozwijana jest kolejna generacja produktu i chcemy wizualnie wyróżnić, gdzie nastąpiły zmiany w wymaganiach, jak również uczynić zaktualizowane wymagania łatwiejszymi do identyfikacji W danym punkcie pojawia się kilka możliwych rozwojów wypadków, każdy określony indywidualnymi warunkami 20

21 Wykonanie związku extend Rozszerzenie wykonywane jest w momencie dojścia do punktu rozszerzalności, o ile odpowiedni warunek jest spełniony Ewaluowane są warunki dla wszystkich zaczepionych w punkcie rozszerzeń, wykonywane tylko te, dla których test będzie prawdziwy Warunek może być pusty, wtedy rozszerzenie zawsze jest wykonywane w punkcie rozszerzalności Po wykonaniu rozszerzenia, przyp. bazowy wraca do wykonania, które przerwał Instancja przypadku użycia Punkt rozszerzalności Bazowy przypadek użycia 21 Rozszerzający przypadek użycia

22 Kiedy i dlaczego używamy extend? Wyciągnięcie opcjonalnego lub wyjątkowego zachowania Kiedy wykonywane jest tylko w określonych warunkach Kiedy wyciągnięcie upraszcza ciągi zdarzeń przypadku bazowego Przykład: uruchomienie alarmu Dodawanie rozszerzenia zachowania Zachowanie opracowane będzie oddzielnie, być może w późniejszej wersji 22

23 Przypadki konkretne i abstrakcyjne (1) Kiedy wyciągamy zachowanie poprzez include lub extend, te nowe przypadki najczęściej nie są wykonywane samodzielnie (ale mogą być) W takim przypadku stanowią przypadki abstrakcyjne, istnieją tylko jako część innego przypadku Jednak przypadki konkretne mogą także: Włączać inne konkretne przypadki użycia Być rozszerzane przez konkretne przypadki użycia W celu uniknięcia nieporozumień można przyjąć założenie, że wszystkie przypadki rozszerzające i włączane muszą być abstrakcyjne (decyzja musi zostać udokumentowana) 23

24 Przypadki konkretne i abstrakcyjne (2) A B <<include>> Przypadki abstrakcyjne (A i D) Nie muszą być kompletne Istnieją tylko dla innych przypadków Nigdy nie są uruchamiane samodzielnie A i D mogą być abstrakcyjne lub konkretne B i C muszą być konkretne Przypadki konkretne (B i C) Muszą być kompletne i zrozumiałe Mogą być uruchamiane samodzielnie C <<extend>> Wskazówka Model powinien być zrozumiały po ukryciu wszystkich przypadków abstrakcyjnych D 24

25 Dlaczego nie należy strukturyzować modelu? Trudniej odnaleźć rozwiązanie, kiedy przypadki użycia są pofragmentowane Funkcjonalna dekompozycja wymagań Obniżenie zrozumiałości Wzrost złożoności Wzrost nakładów na recenzentów, implementatorów i testerów Nie wszystkie strony są zadowolone z takiej formy dziecko bazowy włączenie <<include>> Model przypadków użycia wygląda jak projekt (design) Wniosek należy zachować umiar i równowagę <<extend>> rozszerzenie 25

26 Generalizacja aktorów Aktorzy mogą mieć wspólna charakterystykę Wielu aktorów może odgrywać tą samą rolę lub wchodzić w interakcję z tym samym przypadkiem użycia Dziecko dziedziczy wszystkie powiązania Rodzic rodzica Dzieci tego samego rodzica stanowią jego specjalizacje Dziecko1 Dziecko2 26

27 Generalizacja aktorów - przykład Przeglądaj kartę choroby Planuj operację Pracownik medyczny Lekarz Pielęgniarka Pomoc Sporządź raport wypadków 27 Okulista Ortopeda

28 Dlaczego generalizować aktorów? Uproszczenie asocjacji pomiędzy wieloma aktorami, a przypadkiem użycia Pokazanie, że instancja dziecka może wykonywać zachowanie opisane dla rodzica Reprezentowanie różnych poziomów bezpieczeństwa Uwzględnienie faktu, że fizyczny użytkownik może działać w kilku rożnych rolach 28

29 Aktorzy konkretni i abstrakcyjni Aktor abstrakcyjny zawiera część wspólną ról Nie można tworzyć bezpośrednio jego instancji Przykład: Nie można nikogo zatrudnić na stanowisku pracownika medycznego Można tworzyć instancje aktorów konkretnych Przykład: Nowak jest lekarzem Kowalska jest pielęgniarką Pracownik medyczny Lekarz Pielęgniarka Pomoc 29