Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Transkrypt

1 Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia Materiały dla nauczyciela Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego

2 Spis treści 1. Informacje wstępne Cel ćwiczenia Niezbędne wyposaŝenie Scenariusz pracy Demonstracja budowy diagramu przypadków uŝycia Demonstracja budowy scenariuszy przypadków uŝycia Zadanie Sugerowana tematyka i wskazówki dydaktyczne Zasady zaliczenia Literatura...9 2

3 1. Informacje wstępne 1.1. Cel ćwiczenia Celem ćwiczenia jest zapoznanie się ze sposobami tworzenia diagramów przypadków uŝycia w narzędziu Enteprise Architect oraz pisaniem scenariuszy przypadków uŝycia a takŝe ich zastosowaniem do modelowania wymagań funkcjonalnych na system informatyczny. Przed przystąpieniem do wykonywania ćwiczenia, student powinien posiadać podstawową wiedzę teoretyczną na temat semantyki oraz składni konkretnej poszczególnych elementów diagramu przypadków uŝycia Niezbędne wyposaŝenie Do przeprowadzenia ćwiczenia niezbędne jest następujące wyposaŝenie sali laboratoryjnej: rzutnik multimedialny z komputerem, stacje robocze dla kaŝdego studenta, oprogramowanie Enterprise Architect zainstalowane na kaŝdej stacji roboczej. 2. Scenariusz pracy 2.1. Demonstracja budowy diagramu przypadków uŝycia W tej części zajęć prowadzący demonstruje tworzenie modelu przypadków uŝycia na przykładzie fragmentu prostego systemu. Prowadzący pokazuje róŝne sposoby umieszczania na diagramie poszczególnych elementów modelu przypadków uŝycia, moŝliwości ich łączenia oraz tworzenie bardziej złoŝonych konstrukcji zgodnie ze składnią języka UML. Jednocześnie prowadzący objaśnia semantykę tworzonych elementów modelu. Wszystkie wykonywane czynności naleŝy prezentować na rzutniku. Studenci powinni skupić uwagę na wykonywanych czynnościach i komentarzu prowadzącego. Proponowany scenariusz demonstracji: 1. Uruchomienie EA i utworzenie nowego, pustego modelu EA (nie naleŝy korzystać z gotowych szablonów modeli dostępnych w narzędziu). 2. Utworzenie odpowiedniej struktury modelu składającej się z widoków oraz pakietów (Rys. 2.1). Rys

4 3. Utworzenie diagramu przypadków uŝycia w odpowiednim pakiecie (Rys. 2.2). Rys Utworzenie przypadku uŝycia oraz aktora. Utworzone elementy naleŝy połączyć relacją asocjacji wskazującą, iŝ aktor jest aktorem głównym dla utworzonego przypadku uŝycia (Rys. 2.3). Rys Utworzenie przypadku uŝycia w relacji generalizacji z wcześniej utworzonym przypadkiem uŝycia. MoŜe to być przypadek rozszerzający lub rozszerzany względem przypadku istniejącego (Rys. 2.4). 4

5 Rys Utworzenie przypadku uŝycia w relacji «invoke» z wcześniej utworzonym przypadkiem uŝycia (Rys. 2.5). Rys

6 2.2. Demonstracja budowy scenariuszy przypadków uŝycia Po demonstracji budowy modelu przypadków uŝycia, prowadzący demonstruje tworzenie scenariuszy przypadków uŝycia. Wszystkie wykonywane czynności naleŝy prezentować na rzutniku. Studenci powinni skupić uwagę na wykonywanych czynnościach i komentarzu prowadzącego. Proponowany scenariusz demonstracji: 1. Krótkie przypomnienie czym są scenariusze przypadków uŝycia. Wyjaśnienie gramatyki zdań scenariuszy składających się z podmiotu, orzeczenia, dopełnienia i, ewentualnie, dopełnienia dalszego POD(D). NaleŜy wyjaśnić, do jakich pojęć modelowanego systemu odnoszą się poszczególne elementy zdania w scenariuszu. 2. NaleŜy wybrać jeden spośród przypadków uŝycia utworzonych w poprzedniej części zajęć. Wybrany przypadek uŝycia powinien posiadać punkty rozszerzenia być powiązany relacją «invoke» z innymi przypadkami uŝycia. Wspólnie ze studentami naleŝy napisać scenariusze dla wybranego przypadku uŝycia: jeden scenariusz główny (Basic Path) oraz co najmniej jeden scenariusz alternatywny (Alternate). Scenariusze naleŝy utworzyć w narzędziu EA w zakładce Structured specification w oknie właściwości przypadku uŝycia (Rys. 2.6). Rys Umieszczenie w scenariuszu punktów rozszerzenia «invoke» dla wybranego przypadku uŝycia (Rys. 2.7). 6

7 Rys. 2.7 JeŜeli wybrany przypadek uŝycia nie posiada punktów rozszerzenia, naleŝy dodać nowy przypadek uŝycia w relacji «invoke» z przypadkiem rozpatrywanym (Rys. 2.8). Rys

8 4. Dla kompletnych scenariuszy wybranego przypadku uŝycia naleŝy zademonstrować automatyczne generowanie diagramów aktywności, jako alternatywną notację dla scenariuszy. NaleŜy wyjaśnić studentom związek pomiędzy zdaniami scenariusza tekstowego a akcjami, przepływami sterowania oraz węzłami sterującymi na diagramie aktywności. NaleŜy zwrócić uwagę na akcje odpowiadające wywołaniom «invoke» innych przypadków uŝycia. Tego typu akcje generowane są podobnie jak akcje dla pozostałych zdań. W niektórych przypadkach jednak, przepływ sterowania z tych akcji powinien powracać do zdania je poprzedzającego. W takim przypadku naleŝy zmodyfikować diagram czynności (Rys. 2.9) Zadanie 1 Rys. 2.9 Zadanie to polega na samodzielnym rozbudowaniu przez studentów modelu przypadków uŝycia stworzonego podczas demonstracji. Przed przystąpieniem do realizacji zadania, prowadzący opisuje zakres rozbudowy modelu, który powinien obejmować: 1. Rozbudowa funkcjonalności systemu modelowanego podczas demonstracji poprzez utworzenie 2-3 nowych przypadków uŝycia. 2. Powiązanie nowoutworzonych przypadków uŝycia z istniejącymi przypadkami i/lub aktorami. Ewentualnie, naleŝy dodać nowych aktorów. Studenci powinni utworzyć przynajmniej jedną relację typu «invoke». 3. Napisanie scenariusza głównego i przynajmniej jednego scenariusza alternatywnego dla wybranego przypadku uŝycia. Przypadek, dla którego będzie pisany scenariusz, powinien zawierać wychodzącą relację «invoke» do innego przypadku uŝycia. 8

9 3. Sugerowana tematyka i wskazówki dydaktyczne Przykładowy system, którego funkcjonalność modelowana jest podczas demonstracji a następnie rozbudowywana przez studentów samodzielnie, powinien być systemem, w którym występuje interakcja z uŝytkownikiem. Dziedzina systemu powinna być znana studentom z doświadczenia bądź zrozumiała w sposób intuicyjny np. system obsługi dziekanatu, internetowy system obsługi rachunku bankowego, portal społecznościowy, itp. 4. Zasady zaliczenia Warunkiem zaliczenia jest dostarczenie przez studenta pliku w formacie EAP zawierającego model przypadków uŝycia utworzony przez studenta w czasie zajęć. Zaliczenie ćwiczenia polega na sprawdzeniu poprawności wykonania zadań przez studenta. W szczególności naleŝy zwrócić uwagę na zgodność diagramów ze składnią języka UML, zastosowanie wszystkich wymaganych elementów i konstrukcji języka, a takŝe zgodność scenariusza ze strukturą POD(D). Dodatkowo naleŝy sprawdzić poprawność wykorzystania narzędzia EA. Za poprawne wykonanie ćwiczenia student moŝe otrzymać 2 punkty. 5. Literatura 1. OMG Unified Modeling Language, Superstructure, version 2.2, formal/ ( 2. Alistair Cockburn: Jak pisać efektywne przypadki uŝycia, WNT, Martin Fowler: UML w kropelce, wersja 2.0, LTP Oficyna Wydawnicza, Michał Smiałek: Zrozumieć UML 2.0. Metody modelowania obiektowego, Wydawnictwo Helion, Grady Booch, James Rumbaugh, Ivar Jacobson: UML przewodnik uŝytkownika, wydanie drugie, WNT, Enterprise Architect User Guide ( 9