Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 7 Modelowanie klas i stanów, generacja kodu Materiały dla studentów Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego
Spis treści 1. Informacje wstępne...3 1.1. Cel ćwiczenia...3 1.2. Tematyka i przygotowanie się do ćwiczenia...3 2. Zajęcia nr 1 scenariusz pracy...4 2.1. Omówienie zadania...4 2.2. Zadanie...4 3. Zajęcia nr 2 scenariusz pracy...6 3.1. Omówienie zadania...6 3.2. Zadanie...7 4. Zajęcia nr 3 scenariusz pracy...9 4.1. Omówienie zadania...9 4.2. Zadanie...11 5. Literatura...12 2
1. Informacje wstępne 1.1. Cel ćwiczenia Celem ćwiczenia jest rozwinięcie praktycznych umiejętności w zakresie tworzenia modelu klas (oraz w niewielkim stopniu maszyny stanów) na róŝnych poziomach szczegółowości i dla róŝnych zastosowań. Stworzone modele mają na celu zilustrować szeroki zakres stosowania modeli klas i róŝne znaczenie modeli w zaleŝności od zastosowania. Dzięki temu, studenci powinni nabrać umiejętności pozwalających na stosowanie modeli klas na róŝnych etapach procesu konstrukcji oprogramowania (od specyfikowania wymagań do projektowania szczegółów struktury kodu). Po zakończeniu ćwiczenia studenci powinni potrafić wykonać podstawowy wizualny słownik wymagań oraz zaprojektować podstawową strukturę systemu w architekturze warstwowej. Powinni równieŝ potrafić generować kod na podstawie diagramów klas oraz rozumieć zaleŝność kodu klas od diagramów maszyny stanów związanych z klasami. Ćwiczenie wykonywane jest na trzech kolejnych zajęciach, które tworzą spójną całość. Zajęcia nr 1 obejmują tworzenie diagramów klas opisujących słownik dla systemu modelowanego w ramach ćwiczenia 6. W trakcie zajęć nr 2, studenci samodzielnie projektują system realizujący przypadki uŝycia z ćwiczenia 6 oraz zgodny ze słownikiem zrealizowanym podczas zajęć 1. Podczas zajęć nr 3, studenci mają za zadanie wygenerować kod oraz zapewnić spójność zwrotną kodu z modelem klas. Ponadto, studenci mają za zadanie uzupełnić model klas o model maszyny stanów dla wybranych klas i uzupełnić kod tych klas. Wynikiem ćwiczenia powinien być plik.eap zawierający kompletny słownik na poziomie wymagań oraz model struktury kodu i dynamiki zmiany stanów na poziomie projektu systemu. Dodatkowym wynikiem ćwiczenia jest szkielet kodu systemu wygenerowany w wybranym języku programowania i uzupełniony o elementy związane ze zmianą stanu obiektów w warstwie logiki dziedzinowej. Za poprawne wykonanie ćwiczenia moŝna 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. 1.2. Tematyka i przygotowanie się do ćwiczenia Tematem ćwiczenia jest wykonanie modeli klas na poziomie wymagań oraz projektu szczegółowego. W celu przygotowania się do ćwiczenia naleŝy zapoznać się z problematyką tworzenia modelu klas dla róŝnych etapów wytwarzania oprogramowania. W zakresie modelowania słownika wymagań naleŝy zapoznać się z sekcją 6.2 podręcznika [1]. Bardzo istotne jest zachowanie spójności słownika z modelem przypadków uŝycia (w tym: scenariuszy), co zostało opisane w sekcji 6.4 podręcznika. W zakresie projektowania systemu, naleŝy najpierw zapoznać się z zasadami tworzenia architektury warstwowej, co jest opisane w sekcji 7.2 podręcznika (opis wokół rysunków 7.5 i 7.6). Uwaga: nie jest konieczne zapoznawanie się ze szczegółami tworzenia modelu komponentów, a jedynie o zrozumienie zasady tworzenia projektów warstwowych. Następnie, naleŝy zapoznać się z sekcją 8.2, która zawiera opis zasad tworzenia modeli klas na poziomie bliskim kodu. Uwaga: nie jest konieczne zapoznawanie się z zasadami implementacji interfejsów. Ostatnim elementem, jest zapoznanie się z podstawami tworzenia modelu maszyny stanów opisanymi w końcowej części sekcji 6.3 (wokół rysunku 6.27). 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. 3
2. Zajęcia nr 1 scenariusz pracy 2.1. Omówienie zadania Początkowym elementem ćwiczenia będzie wprowadzenie do tworzenia modeli słownika zgodnych z modelami przypadków uŝycia i scenariuszami przypadków uŝycia. Prowadzący krótko podsumuje techniki poszukiwania pojęć, oraz zasady łączenia scenariuszy przypadków uŝycia z pojęciami w słowniku (klasami). 1. Pierwszą czynnością jest uwaŝne przeczytanie scenariuszy przypadków uŝycia. W scenariuszach naleŝy wyraźnie wyróŝnić dopełnienia zdań (rzeczowniki, grupy rzeczownikowe). Przykład: dane filtru wniosków na rysunku poniŝej. 2. Podczas wyróŝniania pojęć, moŝna utworzyć nowe pojęcia (klasy). W tym celu, naleŝy w menu kontekstowym wybrać opcję Create>New Element from Selection, jak na rysunku poniŝej. NaleŜy utworzyć element typu klasa ( Class ) i o stereotypie «boundary» (element interfejsu uŝytkownika) lub «entity» (element dziedziny problemu). 3. NaleŜy zwrócić uwagę, Ŝe elementy, dla których utworzono definicję (klasę) posiadają automatyczne wyróŝnienie (hiperłącze). W związku z tym, w zdaniach naleŝy uŝywać nazw jedynie w formie mianownika w liczbie pojedynczej (patrz na przykładzie poniŝej). KaŜdy wyróŝniony element moŝna obejrzeć (właściwości) lub zidentyfikować w przeglądarce projektu za pomocą menu kontekstowego pokazanego poniŝej. 2.2. Zadanie W trakcie zadania naleŝy stworzyć model klas na poziomie wymagań zgodny z wybranym fragmentem modelu przypadków uŝycia. NaleŜy wybrać najwaŝniejsze przypadki uŝycia z modelu stworzonego podczas ćwiczenia 6. Dla tych przypadków naleŝy zdefiniować słownik pojęć umieszczony w odpowiednich pakietach. Dla elementów dziedziny (klas o stereotypie «entity») naleŝy stworzyć diagramy, zawierające relacje między pojęciami dziedziny wraz z odpowiednimi krotnościami. Przykład struktury słownika oraz diagramu z elementami dziedziny został przedstawiony poniŝej. 4
Dla elementów interfejsu uŝytkownika (klas o stereotypie «boundary») naleŝy utworzyć diagramy zawierające te elementy w relacji do elementów dziedziny. Przykład takiego diagramu zamieszczono poniŝej. Dla klas będących elementami dziedziny naleŝy zdefiniować po kilka atrybutów i uwidocznić je na diagramie. W celu uwidocznienia atrybutów, naleŝy wyłączyć reprezentację klas za pomocą ikon stereotypów. Zostało to zilustrowane na rysunku poniŝej. NaleŜy równieŝ wyłączyć uwidacznianie wskaźników widoczności ( Show qualifiers and visibility indicators, w zakładce Features ). 5
Proponowany plan wykonania zadania: 1. Utworzenie pojęć (klas) na bazie dopełnień w zdaniach scenariuszy przypadków uŝycia. Przydzielenie klasom stereotypów («boundary» lub «entity»). 2. Ujednolicenie nazewnictwa w scenariuszach. 3. Utworzenie pakietów pojęć w słowniku. Przydzielenie pojęć (klas) do poszczególnych pakietów. 4. Utworzenie diagramów klas dla kaŝdego pakietu. Zdefiniowanie relacji między klasami (asocjacje, agregacje, generalizacje). 5. Zdefiniowanie atrybutów wybranych klas. Uwidocznienie atrybutów klas na wyróŝnionych diagramach klas. 3. Zajęcia nr 2 scenariusz pracy 3.1. Omówienie zadania Kolejne zadanie w ramach tego ćwiczenia dotyczy tworzenia modelu klas projektowych. Klasy te odpowiadają klasom w odpowiednim języku programowania. Zadaniem będzie przekształcenie modelu na poziomie słownika w model na poziomie projektu. Model projektowy będzie podzielony na 3 warstwy. Poszczególne warstwy będą wyróŝnione na diagramach klas za pomocą torów przepływu. Odpowiednie tory naleŝy utworzyć poprzez odpowiednią opcję ( Swimlanes and matrix ) w menu kontekstowym diagramu, co pokazano na poniŝszym rysunku. 6
Podczas wykonywania ćwiczenia naleŝy pamiętać o zasadach translacji modeli wymagań w model projektowy: pojęcia dziedziny przekształcane są w klasy warstwy logiki dziedziny, przypadki uŝycia (lub ich pakiety) przekształcane są w klasy warstwy logiki aplikacji, elementy interfejsu uŝytkownika przekształcane są w klasy warstwy prezentacji. 3.2. Zadanie W trakcie zadania naleŝy stworzyć strukturę systemu realizującego kilka najwaŝniejszych przypadków uŝycia. W tym celu naleŝy wykorzystać model przypadków uŝycia wykonany podczas ćwiczenia 6 oraz model klas wykonany podczas zajęć 1. W ramach wykonania zadania naleŝy utworzyć trzy pakiety w ramach modelu projektowego, zgodnie z poniŝszym rysunkiem. Pakiety te (Prezentacja, Logika aplikacji i Logika dziedziny) będą zawierać klasy i diagramy opisujące poszczególne warstwy systemu. W pakietach naleŝy dokonać dalszego podziału, np. w warstwie prezentacji wydzielić osobne pakiety dla klas obsługujących okienka komunikatów i dla klas formularzy; w warstwie logiki aplikacji moŝna dokonać podziału podobnego do podziału modelu przypadków uŝycia; w warstwie logiki dziedzinowej moŝna utworzyć pakiety odpowiadające spójnym grupom klas odpowiadających pojęciom dziedzinowym (np. dane uŝytkowników). Po stworzeniu pakietów modelu struktury systemu, naleŝy utworzyć w nich odpowiednie diagramy i klasy. Diagramy w ramach warstwy prezentacji powinny zawierać klasy obsługujące elementy interfejsu uŝytkownika. Na diagramach naleŝy umieścić odpowiednie klasy i nadać im nazwy z przedrostkiem V (ang. view widok). Klasy powinny być umieszczone w strukturze generalizacji, z klasami ogólnymi typu Okienko, Formularz itp. MoŜna skorzystać z wiedzy o rzeczywistych technologiach okienkowych (np. technologia Swing i klasy pochodne od klasy JFrame ). NaleŜy zachować spójność z modelem wymagań i zapewnić zgodność z elementami interfejsu uŝytkowni- 7
ka zawartymi w słowniku. Uwaga: w tej warstwie na diagramach uwidaczniamy tylko zawarte w niej elementy, jak na przykładzie poniŝej. JForm + show() : void VFormularzPojadu + show() : void + on_ok(o :Object) : void + VFormularzPojazdu(p :MPojazd) : void W ramach warstwy logiki dziedzinowej naleŝy skorzystać z elementów dziedziny zawartych w słowniku. Na tej podstawie naleŝy utworzyć szczegółowy model projektowy. Powinny być w nim zawarte klasy odpowiadające elementom dziedziny, uzupełnione o szczegółowe atrybuty, operacje oraz relacje z krotnościami i nazwami ról. Klasy powinny posiadać nazwy rozpoczynające się przedrostkiem M (model; element logiki dziedziny) Odpowiednie diagramy powinny zawierać utworzone klasy wraz z relacjami w podziale na pod-pakiety warstwy logiki dziedziny. Uwaga: w tej warstwie na diagramach uwidaczniamy tylko zawarte w niej elementy, jak na przykładzie poniŝej. MPojazd - numer_vin: String - numer_rej: String + pobierz_z_bazy(long) : void + zapisz_do_bazy() : void +poj 0..* +w 0..2 Dane właścicieli:: MWlasciciel - imię: String - nazwisko: String - PESEL: long W ramach warstwy logiki aplikacji naleŝy utworzyć klasy odpowiadające przypadkom uŝycia lub ich grupom. W tym celu, naleŝy przejrzeć odpowiedni model w ramach specyfikacji wymagań. Dla najwaŝniejszych przypadków uŝycia naleŝy utworzyć diagramy opisujące strukturę warstwową. Na diagramach powinny znaleźć się przede wszystkim klasy logiki aplikacji, odpowiadające pojedynczym przypadkom uŝycia bądź ich grupom. Nazwy tych klas powinny być zgodne z nazwami przypadków uŝycia lub ich pakietów. Powinny rozpoczynać się od przedrostka C (ang. controller nadzorca). Na diagramach naleŝy uwzględnić klasy wszystkich warstw, tak jak na przykładzie poniŝej. Klasy warstw prezentacji i logiki dziedziny moŝna pokazać bez uwidaczniania szczegółów. W tym celu naleŝy wybrać w menu kontekstowym opcję Feature Visibility i wykluczyć pokazywanie atrybutów i operacji. 8
Proponowany plan wykonania zadania: 1. Utworzenie pakietów warstw systemu. 2. Utworzenie pakietów warstwy logiki aplikacji. Utworzenie klas (nazwa z przedrostkiem C ) odpowiadających przypadkom uŝycia lub ich pakietom. 3. Utworzenie pakietów warstwy logiki dziedziny. Utworzenie klas (nazwa z przedrostkiem M ) odpowiadających pojęciom dziedziny. Utworzenie diagramów zawierających te klasy oraz relacje między nimi. 4. Utworzenie pakietów warstwy prezentacji. Utworzenie klas (nazwa z przedrostkiem V ) odpowiadających elementom interfejsu uŝytkownika. 5. Utworzenie diagramów pokazujących strukturę systemu w układzie warstwowym. Diagramy takie naleŝy zawrzeć w pakietach warstwy logiki aplikacji i umieścić na nich klasy uczestniczące w realizacji wybranych przypadków uŝycia lub ich grup. 6. Utworzenie niektórych operacji klas. Końcowy model powinien mieć strukturę podobną do tej pokazanej poniŝej. 4. Zajęcia nr 3 scenariusz pracy 4.1. Omówienie zadania Ostatnie zadanie tego ćwiczenia dotyczy zaleŝności między projektowym modelem klas, a kodem. Podstawowymi czynnościami wykonywanymi w trakcie tych zajęć będzie generacja wprost oraz generacja odwrotna kodu. Ponadto, zadaniem będzie uzupełnienie wygenerowanych metod o kod dynamiki określanej diagramami maszyny stanów. W celu wygenerowania kodu, naleŝy w menu kontekstowym wybrać opcję Code Engineering Generate Source Code, tak jak to przedstawiono na rysunku poniŝej. Generacja kodu będzie dotyczyć wybranego pakietu (tu: Struktura systemu ). Uwaga: moŝliwa jest teŝ generacja kodu lokalnie, dla wybranej klasy. 9
Po wybraniu tej opcji, w okienku (patrz poniŝej) naleŝy ustawić opcję Auto Generate Files i wybrać katalog, w którym zostanie wygenerowany kod. NaleŜy równieŝ zaznaczyć opcję Include all Child Packages, dzięki czemu generowana będzie cała struktura klas zawartych w drzewie poni- Ŝej pakietu Struktura systemu. Po naciśnięciu przycisku Generate zostaną utworzone odpowiednie pliki z kodem w zadanym języku programowania. Uwaga: język wynikowy generacji moŝna zmienić w opcjach narzędzia (standardowo, językiem generowanym jest Java). Wygenerowany kod moŝna obejrzeć i dokonać jego edycji wybierając daną klasę w przeglądarce projektu i naciskając klawisz F12 (lub wybierając odpowiednią opcję w menu kontekstowym. Przykładowy efekt generacji kodu pokazano poniŝej. 10
Tak wygenerowany kod moŝe podlegać modyfikacji i uzupełnieniom. Modyfikacje treści (wnętrz) metod nie wpływają na model w języku UML. JednakŜe, kaŝda zmiana nazwy klasy bądź sygnatury metody (nazwa, parametry, ) powoduje konieczność synchronizacji z modelem. W tym celu moŝna wybrać odpowiednią opcję Synchronize with Code w menu kontekstowym klasy. 4.2. Zadanie Zadaniem jest wygenerowanie i analiza kodu klas powstałych podczas poprzednich zajęć. Po wygenerowaniu kod, naleŝy zastanowić się i przedyskutować z prowadzącym, w jaki sposób nale- Ŝy uzupełnić kod, aby powstała działająca aplikacja. MoŜna równieŝ dokonać wybranych uzupełnień treści metod, zgodnie z wynikami powyŝszej dyskusji. Dodatkowym zadaniem jest utworzenie jednego lub dwóch diagramów maszyny stanu. Diagramy naleŝy umieścić wewnątrz klasy w przeglądarce projektu, jak pokazano na rysunku poniŝej. Na bazie diagramu naleŝy uzupełnić kod metod, oraz atrybuty klasy, aby moŝliwa była zmiana stanu obiektów tej klasy. W szczególności, naleŝy dodać odpowiedni atrybut (pole) stan lub status i uzupełnić kod metod o zmianę wartości tego atrybutu. 11
Proponowany plan wykonania zadania: 1. Wygenerowanie klas z modelu utworzonego w poprzednim ćwiczeniu. 2. Utworzenie diagramów maszyny stanów dla wybranych klas warstwy logiki dziedziny. 3. Uzupełnienie kodu treści metod o instrukcje zmiany stanu obiektów danej klasy. 4. Dokonanie aktualizacji kodu wybranych klas i synchronizacja kodu z modelem. 5. Literatura 1. Michał Smiałek: Zrozumieć UML 2.0. Metody modelowania obiektowego, Wydawnictwo Helion, 2005 2. Enterprise Architect User Guide (http://www.sparxsystems.com/bin/eauserguide.pdf) 12