ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI

Transkrypt

1 ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 Instytut Informatyki, Politechnika Poznańska ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI Streszczenie Artykuł prezentuje koncepcję generatora diagramów sekwencji z przypadków użycia. Diagramy te dobrze obrazują poszczególne przebiegi scenariusza i pomagają zrozumieć skomplikowane przypadki użycia. Prezentowane narzędzie wchodzi w skład zintegrowanego środowiska UC Workbench będącego platformą wspomagającą pracę analityka w fazie analizy wymagań. 1. WSTĘP W późnych latach osiemdziesiątych Ivar Jacobson ([6]) przedstawił społeczności programistów obiektowych koncepcję przypadków użycia, dwadzieścia lat wcześniej wykorzystywanych przez niego w branży telekomunikacyjnej. Szybko wypełnił on ważną lukę w procesie analizy wymagań i został szeroko uznany jako standard tworzenia specyfikacji wymagań. Przypadki użycia specyfikują system informatyczny w ujęciu behawioralnym. Jeden przypadek użycia zawiera wiele scenariuszy połączonych wspólnym celem biznesowym. Ich główną zaletą jest fakt, że opisywane są w języku naturalnym i bardzo często mają postać następujących po sobie kolejno kroków. Chociaż zaleca się, aby przypadki użycia były w miarę krótkie (od 3 do 9 kroków), napisane przy użyciu prostych zdań (podmiot orzeczenie dopełnienie), jednak mimo to w niektórych sytuacjach powstają scenariusze bardzo skomplikowane. W takich przypadkach przydałaby się wizualizacja zachowania opisanego przypadkami użycia. Celem artykułu jest zaproponowanie wizualizacji przebiegu przypadków użycia za pomocą diagramów sekwencji języka UML tworzonych w procesie animacji. Opisywany animator przypadków użycia jest częścią zintegrowanego narzędzia UC Workbench rozwijanego w Instytucie Informatyki Politechniki Poznańskiej i obejmującego swoim zakresem nie tylko animację, ale również redagowanie przypadków użycia, generowanie dokumentacji wymagań oraz szacowanie pracochłonności. W drugim rozdziale omówiono pojęcie przypadków użycia wraz z prostym przykładem, rozdział trzeci przedstawia koncepcję i ideę narzędzia UC Workbench oraz jego części składowe. Czwarty rozdział prezentuje koncepcję generowania diagramów

2 2 sekwencji w procesie animacji, lecz proces ten byłby niemożliwy, gdybyśmy nie znali dokładnej struktury przypadku użycia. W rozdziale piątym przedstawiono koncepcję semiformalnego języka opisu przypadków użycia, dzięki któremu struktura scenariuszy jest jednoznaczna i zrozumiała przez komputer. W szóstym rozdziale znajduje się opis metody generowania diagramów sekwencji. 2. PRZYPADKI UŻYCIA Przypadek użycia jest zapisem pewnego rodzaju umowy pomiędzy aktorami systemu, a samym systemem. Opisuje zachowanie analizowanego systemu w różnych warunkach, gdzie system odpowiada na żądania jednego z uczestników nazywanego aktorem. Interakcja między aktorem i systemem ma na celu osiągnięcie pewnej wartości biznesowej przy założonym warunku początkowym i końcowym. Zatem przypadki użycia mogą służyć między innymi jako sposób komunikacji osób lub jako forma zapisu wymagań. Przypadki użycia mają być łatwe do zrozumienia oraz mogą być użyte w różnych sytuacjach, dlatego też nie jest narzucony jednolity styl ich pisania. Przypadek użycia dzięki mechanizmowi rozszerzeń, skoków oraz pętli jest zbiorem rozmaitych scenariuszy. Złożoność danego przypadku użycia uzależniona jest, więc przede wszystkim od liczby rozszerzeń i ich stopnia zagłębienia oraz liczby skoków. Struktura przypadku użycia zawiera oprócz scenariusza i jego rozszerzenia dodatkowe atrybuty, które z punktu widzenia animowania przypadków użycia będą nie istotne, zatem nie będą rozpatrywane. Dokładny opis struktury przypadków użycia oraz wskazówki jak dobrze pisać przypadki użycia zawarte są [1] oraz [2]. Poniżej przedstawiony został rzeczywisty przypadek użycia opisujący fragment internetowego sytemu obsługi konferencji, którego zadaniem jest zautomatyzowanie procesu obsługi streszczeń, artykułów i recenzji: UC4: Zarządzanie użytkownikami Aktor: Administrator Scenariusz główny: 1. System wyświetla listę z wszystkimi użytkownikami. 2. Administrator dodaje nowego użytkownika lub usuwa istniejącego. 3. System potwierdza wykonanie operacji. 4. Administrator wylosowuje się z panelu administratora. Rozszerzenia: 2.A. Podane dane użytkownika są niepełne, lub nieprawidłowe. 2.A.1. System wyświetla komunikat o błędzie i wraca do kroku 2. Rys.1. Przykład przypadku użycia.

3 Animacja przypadków użycia za pomocą diagramów sekwencji 3 3. KONCEPCJA SYSTEMU UC WORKBENCH UC Workbench jest narzędziem, które szeroko wspomaga proces inżynierii wymagań opartej o przypadki użycia. Analityk ma do dyspozycji edytor za pomocą, którego wprowadza przypadki użycia do systemu. Edytor ten w znacznym stopniu zwalnia go od uciążliwych czynności, które muszą być wykonywane w przypadku stosowania zwykłych edytorów tekstowych (pielęgnacja formatowania i odpowiedniej numeracji kroków). Na podstawie specyfikacji wymagań oraz szkiców ekranów aplikacji generowana jest makieta systemu i dokument specyfikacji wymagań (SRS), które są wręczane klientowi do przeglądu. Wymagania prezentowane klientowi w takiej formie dużo lepiej wpływają na jego wyobraźnię, łatwiej jest mu zrozumieć koncepcję zamawianego systemu, a tym samym znaleźć więcej błędów. Narzędzie umożliwia przyrostową pracę nad przypadkami użycia, zgodnie ze wzorcami BreadthBeforeDepth oraz SpiralDevelopment, zaproponowanymi przez [1]. Rysunek 2 przedstawia kontekst i schemat działania narzędzia UC Workbench i jego wpływ na osoby biorące udział w projekcie. Rys.2. Kontekst i schemat działania narzędzia UC Workbench. 4. KONCEPCJA ANIMATORA PRZYPADKÓW UŻYCIA Przypadki użycia zapisane za pomocą języka naturalnego mogą być niekiedy trudne do zrozumienia i dokładnego przeanalizowania. Dlatego też celem animatora jest pokazanie przypadków użycia w formie ułatwiającej ich zrozumienie. Do tego celu wybrano diagram sekwencji zapisany w języku UML [3]. Informacje dotyczące tworzenia diagramów sekwencji zawarte są również w [4]. Przedstawienie przypadków użycia za pomocą diagramów sekwencji, pokazuje nam zależności czasowe występujące podczas interakcji użytkownika z systemem. Można dzięki temu prześledzić cały przypadek użycia krok po kroku przechodząc po scenariuszu głównym, jak i wyjątkach (rozszerzeniach). Na początku pracy animator pokazuje główny scenariusz przypadku użycia w kolorze szarym, gdyż stanowi to podstawę generowanego diagramu. Każdy krok w scenariuszu

4 4 odpowiada komunikatowi na diagramie sekwencji (szczegółowy opis w punkcie 6). Następnie przechodzimy po krokach scenariusza głównego podświetlając kolorem czarnym odpowiednie komunikaty. Za każdym razem sprawdzane jest czy nie wystąpi zdarzenie wyjątkowe, w momencie pojawienia się go użytkownik decyduje czy przejść do scenariusza alternatywnego czy pozostać w głównym. Przejście takie uwidaczniane jest na diagramie zaznaczeniem wystąpienia odpowiedniego zdarzenia. Komunikaty pojawiające się po wystąpieniu wyjątku rysowane są kolorem czerwonym po to by odróżnić przechodzenie po scenariuszu alternatywnym. Jeden diagram przedstawia pojedynczy przypadek użycia, dlatego też animator umożliwia nawigacje pomiędzy przypadkami za pomocą drzewa kontekstu, w którym najwyższy poziom odpowiada poziomowi biznesowemu przypadków użycia. Dzięki temu mamy możliwość przejścia po wszystkich przypadkach oraz wszystkich krokach zarówno w scenariuszu głównym jak i alternatywnym sprawdzając kompletność i poprawność analizowanego systemu. Animator przypadków użycia pokazany jest na rysunku 3. Rys.3. Koncepcja działania animatora przypadków użycia. Należy zwrócić uwagę, że każdy komunikat zawierający nazwę posiada numer kroku ułatwiając tym samym jego lokalizacje oraz zrozumienie scenariusza. Opis każdego komunikatu znajdujący się nad każdą strzałką jest jedynie częścią kroku scenariusza. Dopiero po najechaniu myszką na taki komunikat pokazuje nam się treść całego kroku dzięki temu cały diagram nie staje się nieczytelny na skutek zbyt długich opisów nad strzałkami.

5 Animacja przypadków użycia za pomocą diagramów sekwencji 5 5. OPIS PRZYPADKÓW UŻYCIA W JĘZYKU FUSE Tradycyjne przypadki użycia pisane w języku naturalnym mają pewną poważną wadę: trudno jest w sposób automatyczny zanalizować ich strukturę kroków. Dzieje się tak, dlatego, że oprócz standardowego przebiegu scenariusza (sekwencje kroków i rozszerzenia) często pojawiają się dodatkowe opisy w języku naturalnym, np. Kroki 1-3 mogą być powtarzane wiele razy. Taki komentarz jest zrozumiały dla człowieka, lecz trudny do automatycznej analizy przez komputer. Narzędzia wchodzące w skład UC Workbench wymagają znajomości tej struktury do właściwego działania. W celu jej sformalizowania powstał język FUSE (Formal USE case language), który jednak zachowuje główną zaletę przypadków użycia czytelność dla człowieka (nadal wykorzystywany jest język naturalny). Podczas analizy przypadków użycia napotykamy wiele odstępstw od podstawowego modelu (kroki wykonywane sekwencyjnie wraz z rozszerzeniami), które musiały być rozważone podczas opracowywania języka FUSE. Niedeterministyczny wybór jednej z kilku alternatywnych kroków scenariusza to pierwszy problem, jaki napotykamy w tradycyjnych przypadkach użycia, które zakładają, że kroki będą wykonywane po kolei. Często alternatywy te są równorzędne, więc umieszczanie jednego wariantu w scenariuszu głównym, natomiast pozostałych jako rozszerzenia tego scenariusza byłoby rozwiązaniem mało naturalnym. Język FUSE daje do dyspozycji konstrukcję Albo-Lub, która wygląda następująco: 1. Zarz dzanie u ytkownikami: 1.1. Albo: Administrator dodaje nowego u ytkownika Lub: Administrator usuwa jednego z u ytkowników. FUSE pozwala na tworzenie zagnieżdżonych kroków. Konstrukcja ta umożliwia doprecyzowywanie kroków scenariusza, bez konieczności wprowadzania nowych przypadków użycia, co jest bardzo pomocne w przypadku prostych sekwencji kroków. Dopiero w połączeniu z możliwością zagnieżdżania kroków powyższy element jest silnym narzędziem służącym do opisu przypadków użycia. Przykładowy przypadek użycia napisany przy użyciu języka FUSE jest przedstawiony na rysunku 4 (kroki 2.1., 2.2., , oraz są krokami zagnieżdżonymi). 1. System wy wietla list z wszystkimi u ytkownikami. 2. Administrator wykonuje operacj na u ytkownikach: 2.1. Albo: Administrator dodaje nowego u ytkownika Administrator podaje dane nowego u ytkownika System waliduje poprawno nazwy u ytkownika System potwierdza dodanie u ytkownika Lub: Administrator usuwa jednego z u ytkowników. 3. Administrator wylogowuje si z panelu administratora. Rozszerzenia: A. Podane dane s niepe ne, lub nieprawid owe A.1. System wy wietla komunikat o b dzie i wraca do kroku Rys.4. Przykładowy przypadek użycia w języku FUSE.

6 6 6. GENERACJA DIAGRAMÓW SEKWENCJI Przypadki użycia spisane w języku FUSE za pomocą narzędzia UC Workbench są bardziej formalne i lepiej nadają się do dalszej prezentacji. Dlatego też wykorzystywane są w animatorze przypadków użycia jako dane wejściowe. Na ich podstawie generowany jest diagram sekwencji. Podczas generowania pojawiają się jednak problemy z wyborem typu i opisu komunikatu, z identyfikacją nadawcy i odbiorcy wiadomości, jak również z obsługą wyjątków i skoków. W tym celu wprowadzone zostają specjalne znaczniki umożliwiające określenie dodatkowych informacji niezbędnych do wygenerowania diagramu. Są one widoczne wyłącznie dla analityka i dzięki temu zachowana zostaje czytelność przypadków użycia, które widzą inni uczestnicy projektu. Animator przypadków użycia wykorzystuje dwa typy komunikatów: synchroniczne oraz wewnętrzne operacje. Ważne jest to, że oprócz wewnętrznych operacji występują tylko komunikaty synchroniczne. Wynika to z natury interakcji między dwoma aktorami ([1]) oraz stanowi lepszą podstawę do późniejszego tworzenia testów funkcjonalnych (dla każdej akcji istnieje reakcja systemu). Komunikat będący wewnętrzną operacją występujący po stronie systemu reprezentuje wewnętrzne przetwarzanie natomiast, gdy występuje po stronie użytkownika odzwierciedla operacje biznesowe. Generator diagramu sekwencji na podstawie danego kroku nie jest w stanie określić typu i nazwy komunikatu. W tym celu wprowadzone zostały znaczniki < > i [ ] obejmujące wybrany fragment kroku opisujący nazwę komunikatu. Rysunek 5 przedstawia użycie tych znaczników, gdzie [ ] oznacza komunikat synchroniczny, natomiast < > wewnętrzną operację. Należy zwrócić uwagę, że jeden krok może zawierać więcej niż jeden komunikat Administrator <podaje dane nowego u ytkownika> System [waliduje poprawno nazwy u ytkownika]. Rys.5. Użycie znaczników określających typ i nazwę komunikatu. Generator znając typ i nazwę komunikatu zawartego w danym kroku musi jeszcze zidentyfikować nadawcę oraz odbiorcę komunikatu. Dlatego też w każdym kroku pierwszy wyraz określa nadawcę wiadomości (zgodnie z zaleceniami Cockburna dotyczącymi prostej gramatyki kroku [2]). Rysunek 5 pokazuje na taką sytuację, gdzie dla kroku nadawcą komunikatu jest administrator i ponieważ odbiorca nie jest określony, przyjmowany jest domyślnie system. Krok przedstawia sytuację odwrotną, w której domyślnym odbiorcą jest administrator. Może jednak wystąpić sytuacja, w której w danym kroku nie będzie udziału systemu (poziom biznesowy) i będzie potrzeba ustalenia odbiorcy komunikatu. Taką sytuacje ilustruje rysunek 6, na którym odbiorca określony jest za pomocą znaczników / /. 5. Dostawca <wysy a potwierdzenie> do /klient/a. Rys.6. Użycie znaczników określających odbiorcę komunikatu. W przypadku sekwencyjnego wystąpienia kroków, w których mamy komunikaty synchroniczne posiadające tego samego nadawcę naruszona zostaje zasada, że dla każdej akcji istnieje reakcja. Generator diagramów sekwencji dodaje między nimi komunikat nieposiadający nazwy, aby tworzony diagram był prawidłowy Taka sytuacja pokazana jest na rysunku 7, na którym brakuje kroku reprezentującego reakcje na działanie systemu (por. przedstawienie tego fragmentu scenariusza na diagramie rysunek 8).

7 Animacja przypadków użycia za pomocą diagramów sekwencji 7 1. System <wy wietla formularz do wprowadzania danych>. 2. System <potwierdza wprowadzenie danych>. Rys.7. Naruszenie zasady interakcji. Rys.8. Diagram sekwencji obrazujący dodanie dodatkowego komunikatu. Pojawiające się rozszerzenia w przypadkach użycia są rysowane na diagramie sekwencji w postaci strzałki z odpowiednim komentarzem. W momencie, gdy osiągalne jest dane zdarzenie animator pyta się użytkownika czy ma ono wystąpić. Miejsce pojawienia się zdarzenia określane jest na podstawie jego nazwy. Gdy pierwszym wyrazem jest nazwa aktora to występuje po jego stronie na diagramie, w przeciwnym razie domyślną stroną jest system. Sytuacje taką ilustruje nam rysunek 9, na którym zdarzenie występuje po stronie systemu. W przypadkach użycia występują również skoki do innych kroków, których generator nie jest sam w stanie zidentyfikować. W tym celu wprowadzony został kolejny znacznik { } zawierający numer kroku do którego nastąpi skok. Rysunek 9 ilustruje nam skok do kroku System <wy wietla list z wszystkimi u ytkownikami>. 2. Administrator wykonuje operacj na u ytkownikach: 2.1. Albo: Administrator dodaje nowego u ytkownika Administrator <podaje dane nowego u ytkownika> System [waliduje poprawno nazwy u ytkownika] System <potwierdza dodanie u ytkownika> Lub: Administrator <usuwa jednego z u ytkowników>. 3. Administrator <wylogowuje si z panelu administratora>. Rozszerzenia: A. Podane dane s niepe ne, lub nieprawid owe A.1. System <wy wietla komunikat o b dzie> i wraca do kroku {2.1.1.} Rys.9. Przykładowy przypadek użycia w języku FUSE z użyciem znaczników. Generator diagramów użycia napotykając na konstrukcję Albo-Lub pyta się użytkownika, którą drogę w scenariuszu ma wybrać, symulując tym samym niedeterministyczny wybór jednej z kilku alternatywnych kroków scenariusza głównego. Przypadek użycia zapisany w języku FUSE przedstawiony na rysunku 4 wzbogacony odpowiednimi znacznikami widnieje na rysunku 9. Na tej podstawie animator przypadków

8 8 użycia wygeneruje diagram przedstawiony na rysunku 10. Należy zwrócić uwagę na pierwszy komunikat bez nazwy. Został on dodany przez animator w celu uzupełnienia brakującej akcji (istnieje reakcja systemu bez poprzedzającej akcji użytkownika). Rys.10. Diagram wygenerowany na podstawie przypadku przedstawionego na rysunku YY. 7. ZAKOŃCZENIE Pierwsza wersja narzędzia UC Workbench, którego częścią jest opisany animator przypadków użycia została sprawdzona w warunkach akademickich i jest obecnie stosowana w firmie PB Polsoft, zatrudniającej ponad 100 programistów. Sam animator, będący na razie w fazie prototypowej, jest intensywnie rozwijany. Wierzymy, że poza funkcją obrazowania poszczególnych scenariuszy przypadków użycia, zastosowanie generatora diagramów będzie dużo szersze od tego pokazanego w artykule (np. generowanie scenariuszy testowych). BIBLIOGRAFIA [1] Adolph S., Bramble P., Cockburn A., Pols A.: Patterns for Effective Use Cases. Addisson- Wesley, 2002 [2] Cockburn A.: Writing Effective Use Cases. Addisson-Wesley, 2000 [3] [4] Sinan Si Alhir: UML In A Nutshell A Desktop Quick Reference. O Reilly, 1998 [5] Schneider G., Winters J.: Applying Use Cases. A Practical Guide. Addisson-Wesley, 2001 [6] Jacobson I. Object-Oriented Software Engineering. Addisson-Wesley, 1992 USE CASES ANIMATION WITH SEQUENCE DIAGRAMS Summary

9 Animacja przypadków użycia za pomocą diagramów sekwencji 9 This paper presents concept of sequence diagram generator from use cases. Sequence diagrams visualize complex scenarios and helps to understand them. Presented tool is a part of UC Workbench an integrated environment for use case engineering.