Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 6 Modelowanie przypadków uŝycia i czynności. Materiały dla studentów

Transkrypt

1 Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 6 Modelowanie przypadków uŝycia i czynności Materiały dla studentów Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego

2 Spis treści 1. Informacje wstępne Cel ćwiczenia Tematyka i przygotowanie się do ćwiczenia Zajęcia nr 1 scenariusz pracy Wprowadzenie do ćwiczenia Zadanie Zadanie Zajęcia nr 2 scenariusz pracy Omówienie zadania Zadanie Zajęcia nr 3 scenariusz pracy Omówienie zadania Zadanie Literatura

3 1. Informacje wstępne 1.1. Cel ćwiczenia Celem ćwiczenia jest rozwinięcie praktycznych umiejętności związanych z tworzeniem modeli przypadków uŝycia, scenariuszy przypadków uŝycia oraz powiązanych z nimi modeli czynności. Rozmiar tworzonych przez studentów modeli jest zdecydowanie szerszy niŝ w przypadku poprzednich ćwiczeń. Dzięki temu, studenci nabierają umiejętności, które pozwolą na tworzenie modeli w warunkach rzeczywistych projektów konstrukcji oprogramowania. Po wykonaniu ćwiczenia 6, studenci powinni potrafić wykonać nietrywialną specyfikację wymagań funkcjonalnych przy pomocy modeli języka UML. Ćwiczenie wykonywane jest na trzech kolejnych zajęciach, które tworzą pełną całość. Zajęcia nr 1 obejmują wprowadzenie do tematyki ćwiczenia przez prowadzącego oraz wykonanie modelu przypadków uŝycia samodzielnie przez studentów. Zajęcia nr 2 obejmują wykonanie samodzielnie przez studentów scenariuszy przypadków uŝycia. Zajęcia nr 3 zawierają wykonanie (wygenerowanie) diagramów czynności na podstawie scenariuszy oraz końcowy przegląd wykonanych przez studentów modeli. Wynikiem ćwiczenia powinien być plik.eap zawierający kompletny model przypadków uŝycia wraz z dokładnie przedstawioną ich reprezentacją (scenariusze i diagramy czynności). Za poprawne wykonanie ćwiczenia moŝna w sumie otrzymać 12 punktów. Za wykonanie pierwszych dwóch zadań podczas zajęć moŝna otrzymać po 3 pkt. Za wykonanie ostatniego zadania oraz za poprawiony i rozbudowany model końcowy moŝna otrzymać 6 punktów Tematyka i przygotowanie się do ćwiczenia Tematem ćwiczenia jest wykonanie modelu przypadków uŝycia systemu na podstawie modelu procesów biznesowych. W celu przygotowania się do ćwiczenia, naleŝy zapoznać się z problematyką modelowania dynamiki biznesu. Jest ona opisana w sekcji 5.3 podstawowego podręcznika do przedmiotu [1]. Studenci będą mieli za zadanie przeczytać i zrozumieć dwa procesy biznesowe zadane przy pomocy diagramów czynności. Jednocześnie, naleŝy zapoznać się z tematyką modelowania przypadków uŝycia, scenariuszy i diagramów czynności opartych na scenariuszach. Jest to przedstawione w sekcji 6.3 podręcznika [1]. Bardzo istotne jest równieŝ zapoznanie się z zasadami spójności modelu przypadków uŝycia systemu z modelem biznesu, co zostało opisane w sekcji 6.4 podręcznika [1]. Oprócz zapoznania się z podstawami modelowania, naleŝy zapoznać się z zasadami działania narzędzia Enterprise Architect (podręcznik uŝytkownika [2]) w zakresie określonym w omówieniu zadań w instrukcji poniŝej. 2. Zajęcia nr 1 scenariusz pracy 2.1. Wprowadzenie do ćwiczenia Na początku zajęć, prowadzący przedstawi model procesów biznesowych dla wybranego obszaru tematycznego. Będą to dwa przypadki uŝycia biznesu opisane przy pomocy diagramów czynności. Zadaniem będzie zapoznanie się z modelem i wyjaśnienie z prowadzącym ewentualnych niejasności. 1. Podstawowy model zawiera przypadki uŝycia, podobne do tych, które przedstawione są na rysunku: 3

4 Przedstawiony diagram zawiera przypadki uŝycia biznesu, dwóch aktorów oraz ramkę. Ramka określa system biznesowy (firmę, urząd, dział, itp.). Aktorzy definiują obiekty spoza systemu. Przypadki uŝycia biznesu definiują czynności, wykonywane na styku między systemem biznesowym, a aktorami. 2. Dla obydwu przypadków uŝycia biznesu są zdefiniowane diagramy czynności, które umieszczone są wewnątrz odpowiednich elementów w przeglądarce projektu, tak, jak to zaprezentowano poniŝej: KaŜdy biznesowy przypadek uŝycia zawiera wewnętrzny model, nazwany Procesem. Model ten składa się z jednego diagramu czynności opisującego dany proces biznesowy. 3. Diagram czynności przedstawia sieć czynności, która prowadzi od zdarzenia początkowego do zakończenia. Model wyjściowy zawiera dwa takie diagramy (po jednym dla kaŝdego procesu). Przykładowe diagramy pokazano poniŝej: 4

5 Diagramy stanowią szkic funkcjonowania pewnego fragmentu zadanej dziedziny biznesowej dla określonej jednostki organizacyjnej (firmy, urzędu, działu, itp.). Pozostałe modele, tworzone przez studenta (przez wszystkie następne ćwiczenia) będą dotyczyły obszaru określonego przez zdefiniowane w ten sposób procesy biznesowe. 4. Ostatnim elementem wprowadzenia do ćwiczenia jest prezentacja wizji systemu. Wizja ta jest przedstawiona w postaci kilku wymagań funkcjonalnych i jakościowych. Wizja stanowi zarys cech przyszłego systemu informatycznego, który powinien wspierać zdefiniowane wyŝej procesy biznesowe. Prowadzący przedstawi podstawowe załoŝenia dotyczące takiego systemu, zawarte w odpowiedniej części modelu, co jest zilustrowane na rysunku poniŝej. Wymagania na poziomie wizji są składnikiem wymagań na system. Umieszczone są w pakiecie o takiej właśnie nazwie. KaŜde z wymagań posiada swoją krótką nazwę oraz dokładniejszy opis. NaleŜy zapoznać się z tym opisem i wyjaśnić z prowadzącym ewentualne niejasności Zadanie 1 Główną treść zajęć stanowi wykonanie modelu przypadków uŝycia zgodnego z procesami biznesowymi i wizją systemu. Model powinien się składać z kilku diagramów przypadków uŝycia. Na kaŝdym diagramie naleŝy umieścić jednego lub kilku aktorów oraz kilka przypadków uŝycia. Diagramy przypadków uŝycia powinny być umieszczone w osobnych pakietach. Pakiety powinny dzielić funkcjonalność systemu na logiczne składniki. Kryterium podziału moŝe być wydzielenie 5.

6 funkcjonalności dostępnej dla poszczególnych aktorów, bądź realizacja osobnych procesów biznesowych. Efektem prac w ramach tego zadania powinien być model składający się z kilkunastu (do ok. 20) przypadków uŝycia. Między przypadkami uŝycia powinno występować, co najmniej kilka relacji «invoke» oraz co najmniej jedna relacja generalizacji. Przypadki uŝycia powinny być umieszczone w dwóch lub więcej pakietach zawartych w pakiecie Przypadki uŝycia (patrz rysunek poniŝej). W pakiecie Przypadki uŝycia naleŝy ponadto stworzyć jeden lub więcej diagram pokazujący ślad (relacje «trace») łączący akcje procesów biznesowych i wymagania z przypadkami uŝycia. Proponowany plan wykonania zadania: 1. Ustalenie aktorów systemowych. 2. Ustalenie podziału na pakiety w ramach pakietu Przypadki uŝycia. Utworzenie pakietów w modelu. 3. Ustalenie przypadków uŝycia oraz relacji między przypadkami uŝycia. Narysowanie diagramów zawartych w odpowiednich pakietach (patrz pkt. 2). 4. Ustalenie relacji śladu łączącego akcje procesów biznesowych i wymagania z przypadkami uŝycia. Narysowanie diagramów przedstawiających relacje śladu. Przykładowy diagram zawierający takie relacje przedstawiono poniŝej. Sprawdzenie moŝliwości odbioru dowodu rejestracyjnego Wyprodukowanie dowodu rejestracyjnego «trace» «trace» «trace» Wprowadzenie informacji o wyprodukowaniu dokumentu Sprawdzenie terminu odbioru dokumentu Dostęp przez internet «trace» W razie potrzeby moŝna powtórzyć powyŝsze punkty dokonując uaktualnień w modelu Zadanie 2 Drugim zadaniem jest dokonanie opisu przypadków uŝycia. Opis powinien zawierać deklarację fazy (ang. Phase), w której dany przypadek uŝycia będzie realizowany, oraz krótki opis funkcjonalności przypadku uŝycia. Fazę i funkcjonalność wpisujemy w okienku właściwości przypadku uŝycia, jak to zostało zaprezentowane poniŝej. 6

7 Przypadki uŝycia powinny zawierać po 2-3 zdania krótkiego opisu ich funkcjonalności. Opis ten powinien w przybliŝeniu określać, jaka powinna być interakcja aktora z systemem. Wszystkie przypadki uŝycia naleŝy podzielić według priorytetów ich wykonania. NajwaŜniejsze przypadki uŝycia powinny być wykonane w fazie 1. NaleŜy nadać co najmniej 3 wagi (fazy 1-3) i przydzielić przypadki uŝycia do faz w przybliŝeniu równomiernie (po kilka przypadków uŝycia na fazę). Dodatkowo, naleŝy wyróŝnić wizualnie przypadki uŝycia według faz. WyróŜnienia naleŝy dokonać poprzez nadanie przypadkom uŝycia róŝnych kolorów, co zostało zilustrowane poniŝej (wybór Default Appearance z menu kontekstowego lub poprzez naciśnięcie klawisza F4). Proponowany plan wykonania zadania: 1. Ustalenie priorytetów przypadków uŝycia. Przydzielenie przypadków uŝycia do faz. WyróŜnienie przypadków uŝycia kolorami w zaleŝności od przydziału do faz. 2. Dokonanie krótkiego opisu przypadków uŝycia. NaleŜy zacząć od opisu przypadków uŝycia przydzielonych do fazy 1 i kolejno dokonać opisu przypadków uŝycia dla faz następnych. 7

8 3. Zajęcia nr 2 scenariusz pracy 3.1. Omówienie zadania Prowadzący demonstruje sposób pisania scenariuszy w narzędziu CASE. Scenariusze piszemy w zakładce Scenarios okienka właściwości przypadku uŝycia. W ramach tej zakładki tworzymy scenariusz główny (typ: Basic Path) oraz scenariusze alternatywne (typ: Alternative). Scenariusze dodajemy w pod-zakładce Description, natomiast scenariusze piszemy w pod-zakładce Structured Specification. Przykładowy scenariusz został zilustrowany na poniŝszym diagramie. Pokazana zakładka zawiera edytor scenariuszy. MoŜliwe jest wprowadzanie kolejnych numerowanych zdań oraz określanie punktów rozgałęzienia scenariuszy. Dodatkowo, moŝna określać punkty rozszerzenia, łączące dany scenariusz z innym przypadkiem uŝycia (zdania [Invokes:]). Warto zauwaŝyć, Ŝe uŝycie nazwy istniejącego elementu modelu, powoduje jego zaznaczenie w scenariuszu (podkreślenie) i umoŝliwia szybki dostęp do właściwości tego elementu Zadanie Zadaniem jest napisanie scenariuszy przypadków uŝycia dla modelu stworzonego podczas zajęć nr 1. NaleŜy zwracać uwagę na to, Ŝeby zdania były pisane prostym językiem (podmiot - orzeczenie - dopełnienie). NaleŜy takŝe w jednolity sposób uŝywać słownictwa (bez synonimów i homonimów). Efektem wykonania zadania powinien być komplet scenariuszy dla najwaŝniejszych (ok. 1/4-1/3) przypadków uŝycia. Proponowany plan wykonania zadania: 1. Napisanie scenariuszy głównych do najwaŝniejszych przypadków uŝycia (faza 1). 2. Napisanie scenariuszy alternatywnych dla przypadków uŝycia j.w. 3. Uzupełnienie scenariuszy o zdania [Invokes:], dla przypadków uŝycia połączonych relacjami «invoke». 4. Napisanie scenariuszy dla wybranych pozostałych przypadków uŝycia. 8

9 4. Zajęcia nr 3 scenariusz pracy 4.1. Omówienie zadania Model czynności moŝe stanowić bardzo dobre uzupełnienie modelu przypadków uŝycia wraz ze scenariuszami. Podczas trzecich zajęć tego ćwiczenia dokonamy automatycznej generacji diagramów czynności na bazie wprowadzonych podczas poprzednich zajęć scenariuszy. W celu wygenerowania diagramu, naleŝy wybrać odpowiednią opcję w okienku właściwości przypadku uŝycia. W rezultacie otrzymamy diagram jak na rysunku poniŝej. Jak łatwo zauwaŝyć, poszczególne akcje na diagramie odpowiadają zdaniom scenariuszy. Jednocześnie, scenariusze alternatywne modelowane są za pomocą odpowiednich węzłów decyzyjnych i przepływów sterowania z warunkami. NaleŜy tutaj zwrócić uwagę na węzły zawierające wywołania innych przypadków uŝycia ([Invokes:]). Tego typu węzły generowane są podobnie jak pozostałe zdania. W wielu przypadkach, relacja «invoke» wymaga jednak powrotu do wykonania zdania je poprzedzającego. Wtedy, na diagramie czynności dokonujemy zmiany, zgodnie z rysunkiem poniŝej. 9

10 4.2. Zadanie Uwaga: przed przystąpieniem do wykonania zadania naleŝy (np. w domu) uporządkować dotychczasowe modele i scenariusze oraz ew. poprawić błędy i niedociągnięcia stwierdzone przez prowadzącego podczas poprzednich zajęć. W trakcie zadania naleŝy wygenerować diagramy czynności dla wszystkich przypadków uŝycia, dla których zostały stworzone scenariusze. Diagramy naleŝy odpowiednio zmodyfikować, tak, aby uwzględnić relacje «invoke» (patrz rysunki powyŝej). Po wykonaniu ćwiczenia naleŝy przedyskutować z prowadzącym uzyskane modele. Prowadzący, na podstawie dyskusji i oceny wykonanych modeli (zadania 1-3) wystawia ocenę za całe ćwiczenie. Proponowany plan wykonania zadania: 1. Wygenerowanie diagramów czynności dla kolejnych przypadków uŝycia. 2. Zmodyfikowanie akcji [Invokes:] na diagramach czynności. 3. Przedyskutowanie z prowadzącym wytworzonych modeli. 5. Literatura 1. Michał Smiałek: Zrozumieć UML 2.0. Metody modelowania obiektowego, Wydawnictwo Helion, Enterprise Architect User Guide ( 10