Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla studentów

Transkrypt

1 Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas 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 Budowa diagramu klas Scenariusz pracy Demonstracja budowy diagramu klas Zadanie 1 dzielenie duŝych diagramów klas Zadanie 2 podział modelu klas na pakiety Literatura

3 1. Informacje wstępne 1.1. Cel ćwiczenia Celem ćwiczenia jest zapoznanie się ze sposobami tworzenia diagramów klas w narzędziu Enterprise Architect, przedstawianiem klas modelu na diagramach oraz grupowaniem klas w pakiety. Za poprawne wykonanie ćwiczenia moŝna otrzymać 2 punkty Budowa diagramu klas Wraz z rozwojem technik obiektowych, klasy stały się podstawowymi elementami konstrukcyjnymi systemów oprogramowania. Modele klas tworzone są na kaŝdym etapie procesu wytwarzania oprogramowania począwszy od etapu analizy, kiedy modelowane są pojęcia związane z dziedziną problemu, poprzez etapy projektowania oraz implementacji, podczas których tworzone są bardziej szczegółowe modele klas, uwzględniające aspekty konstrukcyjne i implementacyjne oprogramowania. PoniŜej przedstawione są najwaŝniejsze elementy języka UML słuŝące do tworzenia modeli klas. Opisana została zarówno ich semantyka, jak równieŝ ich graficzna reprezentacja słuŝącą do rysowania diagramów klas. Podstawowa notacja dla klas Klasa (ang. class) to opis grupy obiektów, które mają taki sam zestaw właściwości oraz sposób zachowania. KaŜda klasa ma przypisaną nazwę, która wyróŝnia ją spośród innych klas. Właściwości obiektów reprezentowanych przez klasę zwane są atrybutami. Klasa moŝe mieć dowolną ilość atrybutów (ang. attribute), a nawet nie mieć ich wcale. Zachowanie, czyli usługi, które mogą wykonywać obiekty danej klasy nazywane są operacjami (ang. operation). Klasa moŝe mieć dowolną ilość operacji, a nawet nie mieć ich wcale. Rysunek 1.1 przedstawia notację dla klasy w języku UML. Ta sama klasa moŝe być reprezentowana w róŝny sposób na róŝnym poziomie szczegółowości. W najprostszym wariancie, klasa jest symbolizowana przez prostokąt z nazwą klasy (Rysunek 1.1a). Na ogół nazwę podaje się w formie rzeczownika lub wyraŝenia rzeczownikowego, pochodzącego z modelowanej dziedziny. KaŜdy wyraz w nazwie zaczyna się zwykle wielką literą. MoŜliwe jest takŝe pokazanie atrybutów klasy. Umieszcza się je w sekcji oddzielonej poziomą kreską od jej nazwy klasy (Rysunek 1.1b). MoŜna podać jedynie nazwy atrybutów. MoŜna teŝ podać typ wartości, jakie atrybut moŝe przyjmować. Nazwę atrybutu podaje się zazwyczaj w formie rzeczownika lub wyraŝenia opisującego właściwości obiektów danej klasy. MoŜliwe jest pokazanie tylko operacji klasy, poprzez umieszczenie ich w sekcji symbolu klasy poniŝej jej nazwy (Rysunek 1.1c). MoŜna podać jedynie nazwy operacji. MoŜna teŝ dokładnie określić operacje poprzez podanie w nawiasach typu przekazywanych parametrów oraz typu wartości zwracanej. Jeśli chcemy pokazać jednocześnie atrybuty i operacje klasy, to atrybuty umieszczamy w sekcji poniŝej nazwy klasy, natomiast operacje w sekcji poniŝej atrybutów (Rysunek 1.1d). Symbol klasy nie musi zawierać wszystkich atrybutów i operacji. 3

4 Rysunek 1.1: Notacja dla klasy w języku UML Sposób prezentacji klasy na diagramie zaleŝy od celu, w jakim sporządzamy diagram oraz od osoby, która będzie ten diagram czytać. Jeśli diagram ma na celu poglądowe przedstawienie struktury pojęć modelowanej dziedziny, wystarczy, Ŝe klasy będą przedstawione w najprostszej postaci. W przypadku diagramów, które mają posłuŝyć programistom do implementacji systemu, przedstawione na nich klasy powinny zawierać wszystkie szczegóły. Przestrzenie nazw klas Pakiety słuŝą do grupowania elementów modelu w hierarchiczne struktury. W przypadku modelu klas, gdzie moŝe występować bardzo duŝa ilość elementów, stworzenie odpowiedniej struktury pakietów moŝe okazać się niezbędne. Modelując dziedzinę problemu, za pomocą pakietów grupujemy logicznie powiązane ze sobą pojęcia (Rysunek 1.2). MoŜemy teŝ oddzielić klasy modelujące aspekty techniczne oprogramowania (np. okna interfejsu uŝytkownika) od klas modelujących pojęcia dziedziny. Rysunek 1.2: Pakiety jako elementy grupujące klasy Pakiety stanowią przestrzenie nazw dla klas. W modelu nie mogą istnieć dwie klasy o takiej samej nazwie, chyba, Ŝe naleŝą do innych przestrzeni nazw. Na diagramie, nazwa klasy moŝe być poprzedzona nazwą pakietu. Nazwę klasy oddziela się od nazwy pakietu znakiem ::. Takie nazwy klas określa się mianem nazw kwalifikowanych. Ich stosowanie ma szczególne znaczenie wtedy, gdy na diagramie umieszczamy klasy o takiej samej nazwie, lecz pochodzące z innych przestrzeni nazw. Atrybuty i operacje Klasę moŝna prezentować na róŝnym poziomie szczegółowości. Czasami wystarczy zaprezentować klasę w postaci prostokąta z nazwą, jednak w większości przypadków umieszcza się takŝe atrybuty i operacje klasy. W zaleŝności od szczegółowości diagramu, notacja dla atrybutów i operacji moŝe uwzględniać lub pomijać pewne elementy. Tworząc model klas na wysokim poziomie abstrakcji, zazwyczaj wystarczy podać jedynie nazwy atrybutów i operacji. Atrybuty i operacje mogą mieć określoną widoczność. Widoczność określa czy dany składnik klasy jest dostępny dla pozostałych klas. UML definiuje cztery poziomy widoczności składników klas. 4

5 Public (publiczny). KaŜda zewnętrzna klasa, która ma dostęp do klasy zawierającej składniki publiczne, ma równieŝ dostęp do tych składników. Na diagramie składowe publiczne oznacz się znakiem +. Jeśli składnik nie ma określonej widoczności, domyślnie przyjmuje się, Ŝe jest to składnik publiczny. Private (prywatny). Dostęp do składników prywatnych ma jedynie klasa zawierająca te składniki. Na diagramie składowe prywatne oznacza się znakiem -. Protected (zabezpieczony). Dostęp do składników chronionych ma klasa zawierająca te składniki oraz wszystkie klasy dziedziczące z niej (podklasy). Na diagramie składniki chronione oznaczamy znakiem #. Package (pakietowy). Dostęp do składników o takiej widoczności ma kaŝda klasa znajdująca się w tym samym pakiecie, co klasa zawierająca te składniki. Na diagramie oznaczamy takie składniki znakiem ~. Rysunek 1.3 przedstawia przykład klasy zawierającej atrybuty i operacje o róŝnej widoczności. Rysunek 1.3: Widoczność atrybutów i operacji klasy Kolejną cechą atrybutów i operacji jest ich zasięg. Normalnie, atrybuty i operacje klasy występują w kaŝdym obiekcie danej klasy określając ich właściwości oraz zachowanie. O takich atrybutach i operacjach mówimy, Ŝe mają zasięg instancji. Dla niektórych atrybutów i operacji klasy, moŝemy określić, Ŝe ich zasięg ogranicza się jedynie do tej klasy. Składniki o takim zasięgu określamy mianem statycznych. Oznacza to, Ŝe istnieje jeden egzemplarz takiego składnika, wspólny dla wszystkich instancji klasy. Na diagramie atrybuty i operacje statyczne oznacza się poprzez ich podkreślenie. Rysunek 1.4 przedstawia klasę zawierającą operację statyczną. Operacja statyczna generujnowynumer() zawsze zwraca unikalny numer zamówienia, który moŝe być przypisany jako wartość atrybutu numer w nowo tworzonych obiektach klasy Zamówienie. Numer ten moŝe być odczytany poprzez wywołanie na obiekcie operacji podajnumer(), która ma zasięg instancji. Rysunek 1.4: Operacja statyczna Oprócz widoczności oraz zasięgu atrybutu, moŝna takŝe określić jego liczebność, typ oraz wartość początkową. Liczebność atrybutu określa ilość egzemplarzy danego atrybutu, jaką moŝe zawierać kaŝdy obiekt klasy posiadającej ten atrybut. Liczebność definiuje się podając w nawiasach kwadratowych liczbę lub zakres. 5

6 Typ atrybutu moŝe być jednym z typów pierwotnych, jak np. int (liczby całkowite) lub boolean (wartość logiczna). Typem atrybutu moŝe być inna klasa, co oznacza, Ŝe jego wartością jest obiekt danej klasy. Wartość początkowa określa wartość, jaką atrybut przyjmuje zaraz po utworzeniu obiektu danej klasy. Wartość ta musi być zgodna z typem atrybutu. Atrybuty moŝemy więc określać w następujący sposób: [widoczność] nazwa [[liczebność]] [: typ] [= wartość początkowa] Elementy w nawiasach ostrokątnych moŝemy umieszczać na diagramach opcjonalne. Rysunek 1.3 zawiera przykłady róŝnych atrybutów. Oprócz widoczności oraz zasięgu metody, moŝna takŝe określić jej listę parametrów oraz typ wyniku. Nazwa operacji wraz z parametrami oraz typem wyniku nazywamy sygnaturą. Dana klasa moŝe zawierać operacje o takiej samej nazwie, jednak ich sygnatury muszą być róŝne. Operacje klasy moŝemy deklarować w następujący sposób: [widoczność] nazwa [(lista parametrów)] [: typ wyniku] Parametry są wartościami określonych typów, przekazywanymi operacji podczas jej wywoływania. Mogą one np. stanowić dane wejściowe dla operacji, sterować sposobem jej wykonania, przekazywać wartości potrzebne do zmiany stanu obiektu, przekazywać wyniki wykonania operacji do obiektu wywołującego, itp. Lista parametrów moŝe zawierać dowolną ilość parametrów oddzielonych przecinkami. Deklaracja kaŝdego z parametrów jest następująca: [tryb] nazwa : typ [= wartość domyślna] Tryb określa, w jaki sposób operacja wykorzystuje dany parametr i moŝe przyjmować jedną z trzech wartości: in parametr jest parametrem wejściowym i nie moŝe być modyfikowany, out parametr jest parametrem wyjściowym i moŝe być zmodyfikowany w celu przekazania informacji obiektowi wywołującemu, inout parametr jest parametrem wejściowym, ale moŝe być zmodyfikowany. JeŜeli tryb nie jest określony dla parametru, to domyślnie przyjmuje się tryb in. Typ parametrów określa się w taki sam sposób jak typ atrybutów. Wartość domyślna, natomiast, określa wartość, jaką przyjmuje parametr w przypadku, kiedy wartość parametru nie zostanie podana podczas wywołania operacji. Jeśli operacja w wyniku wykonania zwraca jakąś wartość, to typ zwracanej wartości jest określany poprzez typ wyniku. Jeśli operacja nie zwraca Ŝadnej wartości, typ wyniku moŝemy określić jako void. Rysunek 1.3 przedstawia przykładowe deklaracje operacji. Asocjacje Podstawowymi blokami konstrukcyjnymi w języku UML, słuŝącymi do łączenia elementów modelu są związki. Związki są bardzo istotnym elementem modelu klas. Najczęstszym rodzajem związków w modelach klas są asocjacje. Asocjacje reprezentują związki strukturalne pomiędzy instancjami klas. Najogólniej, asocjacja pomiędzy dwiema klasami oznacza, Ŝe moŝliwe jest przejście od obiektu jednej klasy do obiektu drugiej klasy. Z punktu widzenia perspektywy pojęciowej asocjacje odzwierciedlają związki znaczeniowe pomiędzy pojęciami modelowanej dziedziny. W przypadku modeli na niŝszym poziomie abstrakcji asocjacja oznacza najczęściej, Ŝe obiekt jednej klasy ma stały, bezpośredni dostęp do obiektu drugiej klasy. Asocjacja jest przedstawiana na diagramie jako linia ciągła łącząca powiązane klasy. Asocjacja moŝe być uzupełniona o dodatkowe informacje, takie jak nazwa asocjacji, nazwy ról, krotności oraz kierunek asocjacji. 6

7 Rysunek 1.5: Asocjacja z nazwą Rysunek 1.5 przedstawia przykład asocjacji z nazwą. Nazwa określa znaczenie. Strzałka obok nazwy wskazuje kierunek, w jakim naleŝy odczytywać asocjację. Asocjacja z powyŝszego przykładu mówi nam: osoba pracuje dla przedsiębiorstwa. MoŜliwe jest zamodelowanie tej asocjacji w drugą stronę: przedsiębiorstwo zatrudnia osobę. Nazywanie kaŝdej asocjacji w modelu nie jest konieczne. Nazwy nadaje się zwykle wtedy, kiedy pozwala to uniknąć niejednoznaczności. Nazwy asocjacji nie trzeba podawać zwłaszcza w przypadku, kiedy wyraźnie określi się nazwy ról. KaŜda z klas będąca końcem asocjacji moŝe być opisana nazwą roli, jaką dana klasa pełni w związku. W kolejnym przykładzie (Rysunek 1.6) Osoba pełni rolę pracownika względem Przedsiębiorstwa, natomiast Przedsiębiorstwo występuje w roli pracodawcy względem Osoby. Rysunek 1.6: Role i krotności asocjacji Rysunek 1.6 zawiera równieŝ przykład asocjacji, której oba końce stanowi ta sama klasa. Taka asocjacja oznacza, Ŝe obiekty danej klasy mogą być połączone z innymi obiektami tej samej klasy. W takim przypadku równieŝ moŝemy określić role końców asocjacji. Rysunek 1.7: Instancje asocjacji Rysunek 1.7 przedstawia diagram obiektów pokazujący instancje asocjacji z powyŝszego diagramu klas. Mamy tutaj dwie instancje klasy Osoba: kierownikoddziału oraz kasjer. Połączenie między nimi jest natomiast instancją asocjacji, której oba końce stanowi klasa Osoba występująca w róŝnych rolach. Na tym samym diagramie obiektów widzimy, Ŝe obiekt klasy Przedsiębiorstwo łączy się z dwoma obiektami klasy Osoba mamy więc dwie instancje asocjacji łączącej Osobę z Przedsiębiorstwem. O tym, ile obiektów klasy będącej jednym końcem asocjacji moŝe być połączonych z obiektem klasy z drugiego końca asocjacji decyduje krotność. Ogólnie rzecz biorąc, krotność wskazuje dolne i górne granice dla liczby obiektów mogących brać udział w asocjacji. Krotności umieszczamy na końcach asocjacji, przy klasach, których te krotności dotyczą. Na omawianym diagramie klas (Rysunek 1.6) widzimy, Ŝe Przedsiębiorstwo moŝe mieć co najmniej jednego pracownika. Jedna Osoba, natomiast, moŝe mieć dowolną ilość pracodawców (przynajmniej w teorii) lub nie mieć Ŝadnego. W praktyce najczęściej uŝywa się krotności: jeden (1), zero lub jeden (0..1), dowolna ilość (*), co najmniej jeden (1..*). MoŜna teŝ określić dowolną kombinację liczb i zakresów, jak np. 2, 10..*, Asocjacja pomiędzy dwiema klasami oznacza moŝliwość przejścia od obiektów jednej klasy do obiektów drugiej klasy w obu kierunkach. Czasami jednak zachodzi potrzeba ograniczenia moŝli- 7

8 wości nawigowania pomiędzy klasami tylko do jednego kierunku. Stosuje się wtedy asocjację jednokierunkową, która oznacza, Ŝe mając dostęp do obiektu na jednym końcu moŝna bezpośrednio przejść do obiektów na drugim końcu. W modelu implementacyjnym jest to zazwyczaj moŝliwe dzięki przechowywaniu przez obiekt źródłowy odniesień do obiektów będących celem asocjacji. Rysunek 1.8: Asocjacja jednokierunkowa Rysunek 1.8 przedstawia przykład asocjacji jednokierunkowej. Dla konkretnej Osoby, mamy bezpośredni dostęp do jej adresów, ale na podstawie danego Adresu nie jesteśmy w stanie bezpośrednio zidentyfikować powiązanych z nimi Osób. Istnienie asocjacji jednokierunkowej nie wyklucza jednak zupełnie moŝliwości wskazania Osób na podstawie Adresu moŝliwe jest przejście pośrednie poprzez inne klasy. Asocjacje odzwierciedlają zwykle związek strukturalny pomiędzy równorzędnymi klasami, znajdującymi się na tym samym poziomie pojęciowym. Czasem jednak klasy powiązane są relacją całość-część, w której klasa-agregat (całość) zawiera klasę-składnik (część). Innymi słowy, oznacza to zawieranie się obiektów jednej klasy w obiektach innej klasy. Taki rodzaj asocjacji nazywa się agregacją. Na diagramie agregację oznacza się poprzez umieszczenie pustego rombu po stronie klasy reprezentującej całość. Agregacja nie zmienia znaczenia nawigacji między klasami. Oprócz zwykłej agregacji, UML udostępnia jej silniejszą wersję zwaną kompozycją. Ten rodzaj asocjacji charakteryzuje się wyłączną własnością oraz zaleŝnością czasu Ŝycia całości i części. W odróŝnieniu od agregacji, w przypadku kompozycji obiekt będący częścią moŝe naleŝeć wyłącznie do jednej całości. Ponadto, części mogą powstawać po utworzeniu całości i umierają razem z nią. Usunięcie całości powoduje kaskadowe usunięcie wszystkich części. Na diagramie kompozycję oznacza się poprzez umieszczenie zaczernionego rombu po stronie klasy reprezentującej całość. NaleŜy pamiętać, Ŝe krotność po stronie klasy reprezentującej całość w relacji kompozycji musi być zawsze równa 1. Rysunek 1.9: Agregacja i kompozycja Rysunek 1.9 pokazuje przykład agregacji i kompozycji. Wielokąt moŝe zawierać 3 lub więcej instancji Punktu, przy czym Ŝadna z tych instancji nie moŝe naleŝeć do Koła, które posiada własną instancję Punktu. Instancja Stylu natomiast, moŝe być dzielona przez wiele Wielokątów i Kół. Usunięcie Wielokąta bądź Koła spowoduje usunięcie wszystkich naleŝących do niego Punktów, ale nie spowoduje usunięcia zawartego w nim Stylu. ZaleŜności Obok asocjacji, w modelu klas moŝna uŝywać innego rodzaju związków pomiędzy klasami, a mianowicie zaleŝności. ZaleŜność oznacza, Ŝe jeden element modelu uŝywa innego elementu. Np. 8

9 jedna klasa uŝywa drugiej jako argumentu w sygnaturze operacji. Zmiany dokonane w specyfikacji jednej klasy mogą mieć wpływ na klasę, która uŝywa tej pierwszej. Rysunek 1.10 przedstawia przykład zaleŝności pomiędzy klasami. Widać na nim, Ŝe klasa Produkt jest wykorzystywana jako argument operacji w klasie Koszyk. Zmiana sposobu zachowania klasy Produkt moŝe zatem pociągnąć za sobą zmianę w zachowaniu klasy Koszyk, która jest zaleŝna od tej pierwszej. Generalizacja i klasy abstrakcyjne Rysunek 1.10: ZaleŜność WaŜnym rodzajem związku pomiędzy elementami modelu w UML, zwłaszcza modelu klas, jest generalizacja. Generalizacja jest to związek między elementem ogólnym, zwanym równieŝ nadklasą lub przodkiem, a pewnym specyficznym jego rodzajem zwanym podklasą lub potomkiem. Potomek dziedziczy wszystkie właściwości przodka jego atrybuty, operacje, związki. Potomek moŝe rozszerzać zbiór właściwości odziedziczonych od przodka o swoje własne cechy. Potomek moŝe zatem wystąpić wszędzie tam, gdzie spodziewany jest przodek, ale nie na odwrót. Generalizacja przedstawiana jest na diagramie za pomocą strzałki z zamkniętym pustym w środku grotem wskazującym przodka. Generalizacja umoŝliwia stworzenie hierarchii dziedziczenia. Klasy ogólne znajdują się na górze hierarchii, a bardziej szczegółowe na dole. Klasa moŝe mieć dowolną ilość potomków. Jeśli chodzi o przodków, to rozróŝniamy dziedziczenie pojedyncze gdy klasa ma jednego przodka, oraz dziedziczenie wielokrotne gdy klasa ma wielu przodków. Dla danej klasy moŝemy ograniczyć moŝliwość tworzenia klas potomnych. Taką klasę nazywamy liściem i oznaczamy na diagramie napisem {leaf} umieszczonym pod nazwą klasy. Klasę znajdującą się na szczycie hierarchii dziedziczenia, która nie ma przodków nazywamy korzeniem i oznaczamy na diagramie napisem {root} umieszczonym pod jej nazwą (patrz Rysunek 1.11). Niektóre klasy w hierarchii dziedziczenia mogą być określone jako abstrakcyjne, czyli takie, dla których nie moŝna utworzyć instancji. Klasy takie nie dostarczają implementacji niektórych lub wszystkich swoich operacji, zwanych operacjami abstrakcyjnymi. Implementację operacji abstrakcyjnych powinny zapewnić klasy potomne, które następnie mogą być uŝyte wszędzie tam, gdzie spodziewana jest klasa abstrakcyjna. Nazwy klas i operacji abstrakcyjnych zapisuje się kursywą. W przedstawionym przykładzie (Rysunek 1.11) klasa Kształt zawiera abstrakcyjną operację obliczpowierzchnie(). Klasy Koło, Trójkąt oraz Prostokąt, będące klasami konkretnymi, dostarczają własnej specyficznej implementacji tej metody. 9

10 Rysunek 1.11: Generalizacja 10

11 2. Scenariusz pracy 2.1. Demonstracja budowy diagramu klas W tej części zajęć prowadzący demonstruje tworzenie modelu klas. W ramach demonstracji zostaną zaprezentowane róŝne sposoby umieszczania na diagramie poszczególnych elementów modelu: klas, asocjacji, generalizacji, atrybutów oraz operacji. Jednocześnie objaśniona zostanie semantyka tworzonych elementów Zadanie 1 dzielenie duŝych diagramów klas Zadanie to polega na samodzielnym stworzeniu modelu klas dla wybranej dziedziny oraz wizualizacja tego modelu na diagramach klas. Przed realizacją zadania, prowadzący przedstawi tematykę zadania, tj. opis dziedziny, dla której naleŝy stworzyć model klas. Przykładowy scenariusz wykonania zadania: 1. Utworzenie nowego projektu. W drzewie projektu naleŝy utworzyć odpowiedni widok oraz diagram klas (Rys. 2.1). Rys Utworzenie w modelu oraz umieszczenie na diagramie 7-10 klas dla zadanej dziedziny oraz utworzenie odpowiednich powiązania między nimi (asocjacji oraz relacji dziedziczenia) (Rys. 2.2). 11

12 Rys Ustawienie odpowiednich właściwości asocjacji (Rys. 2.3) oraz utworzenie niezbędnych atrybutów oraz operacji w klasach (Rys. 2.4). Rys

13 Rys Wyodrębnienie w modelu dziedziny dwóch (lub więcej) obszarów tematycznych. KaŜdy obszar powinien zawierać klasy modelujące odrębne zagadnienia. Niektóre klasy mogą nale- Ŝeć do więcej niŝ jednego obszaru w sytuacji, gdy jest to pomocne w pełnym zrozumieniu modelowanego obszaru. Rys

14 5. Mając wyodrębnione obszary tematyczne, naleŝy utworzyć dla kaŝdego z nich oddzielny diagram klas. Nazwa diagramu powinna nawiązywać do tematyki wyodrębnionej poddziedziny. Na kaŝdym z diagramów naleŝy umieści klasy stanowiące model odpowiedniego obszaru tematycznego. Klasy, które są wspólne dla wielu obszarów, powinny być umieszczone na kaŝdym z diagramów (Rys. 2.6). Rys Zadanie 2 podział modelu klas na pakiety Zadanie to polega na samodzielnej rozbudowie modelu stworzonego w poprzednim zadaniu poprzez podział modelu na pakiety. Przykładowy scenariusz wykonania zadania: 1. Utworzenie w drzewie projektu pakietów odpowiadających wydzielonym obszarom tematycznym modelu (Rys. 2.7a). 2. Przeniesienie w drzewie projektu odpowiednich klas oraz diagramów dla kaŝdego z obszarów tematycznych do odpowiedniego pakietu (Rys. 2.7b). 14

15 Rys Edycja właściwości diagramów w celu uwidocznienia przestrzeni nazw dla elementów znajdujących się na diagramach. Przenosząc klasy między pakietami naleŝy zaobserwować zmieniające się przestrzenie nazw wyświetlane w piktogramach klas (Rys. 2.8). Rys Literatura 1. OMG Unified Modeling Language, Superstructure, version 2.2, formal/ ( 2. Martin Fowler: UML w kropelce, wersja 2.0, LTP Oficyna Wydawnicza,

16 3. 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 ( 16