Laboratorium modelowania oprogramowania w języku UML

Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego

Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej

Wydział Elektryczny, Politechnika Warszawska

Laboratorium modelowania oprogramowania w języku UML

Ćwiczenie 2

Ćwiczenia w narzędziu CASE – diagram klas

Materiały dla studentów


Ćwiczenie 2: Ćwiczenia w narzędziu CASE – diagram klas

2

Spis treści

1. Informacje wstępne ................................................................................................3

1.1. Cel ćwiczenia....................................................................................................3

1.2. Budowa diagramu klas......................................................................................3

2. Scenariusz pracy.................................................................................................. 11

2.1. Demonstracja budowy diagramu klas.............................................................. 11

2.2. Zadanie 1 – dzielenie duŜych diagramów klas ................................................ 11

2.3. Zadanie 2 – podział modelu klas na pakiety.................................................... 14

3. Literatura .............................................................................................................. 15



3

1. Informacje wstępne

1.1. Cel ćwiczenia

Celem ćwiczenia jest zapoznanie się ze sposobami tworzenia diagramów klas w narzędziu Enter-prise Architect, przedstawianiem klas modelu na diagramach oraz grupowaniem klas w pakiety.

Za poprawne wykonanie ćwiczenia moŜna otrzymać 2 punkty.

1.2. 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 dziedzi-ną problemu, poprzez etapy projektowania oraz implementacji, podczas których tworzone są bar-dziej szczegółowe modele klas, uwzględniające aspekty konstrukcyjne i implementacyjne opro-gramowania.

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 ryso-wania 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ć reprezento-wana 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.



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 grupu-jemy 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ć po-przedzona 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 zaprezento-wać 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 wystar-czy 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.



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 chro-nione 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.



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, przeka-zywać 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 oddzielo-nych 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 zna-czeniowe 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.



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ła-du 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 diagra-mu 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..*, 5..7.

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-



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śred-nio 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 bez-poś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 wyklu-cza 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, znajdu-ją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 in-stancji 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.



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.

Rysunek 1.10: ZaleŜność

Generalizacja i klasy abstrakcyjne

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Ŝ nadkla-są lub przodkiem, a pewnym specyficznym jego rodzajem zwanym podklasą lub potomkiem. Po-tomek 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 wska-zują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ę znajdu-jącą się na szczycie hierarchii dziedziczenia, która nie ma przodków nazywamy korzeniem i ozna-czamy 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 abstrak-cyjnych 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ę ob-liczPowierzchnie(). Klasy Koło, Trójkąt oraz Prostokąt, będące klasami konkretnymi, dostarczają własnej specyficznej implementacji tej metody.



10

Rysunek 1.11: Generalizacja



11

2. Scenariusz pracy

2.1. Demonstracja budowy diagramu klas

W tej części zajęć prowadzący demonstruje tworzenie modelu klas. W ramach demonstracji zosta-ną zaprezentowane róŜne sposoby umieszczania na diagramie poszczególnych elementów mode-lu: klas, asocjacji, generalizacji, atrybutów oraz operacji. Jednocześnie objaśniona zostanie se-mantyka tworzonych elementów.

2.2. Zadanie 1 – dzielenie duŜych diagramów klas

Zadanie to polega na samodzielnym stworzeniu modelu klas dla wybranej dziedziny oraz wizuali-zacja 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. 2.1

2. 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).



12

Rys. 2.2

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

Rys. 2.3



13

Rys. 2.4

4. Wyodrębnienie w modelu dziedziny dwóch (lub więcej) obszarów tematycznych. KaŜdy ob-szar 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. 2.5



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 poddzie-dziny. Na kaŜdym z diagramów naleŜy umieści klasy stanowiące model odpowiedniego ob-szaru tematycznego. Klasy, które są wspólne dla wielu obszarów, powinny być umieszczo-ne na kaŜdym z diagramów (Rys. 2.6).

Rys. 2.6

2.3. Zadanie 2 – podział modelu klas na pakiety

Zadanie to polega na samodzielnej rozbudowie modelu stworzonego w poprzednim zadaniu po-przez podział modelu na pakiety.

Przykładowy scenariusz wykonania zadania:

1. Utworzenie w drzewie projektu pakietów odpowiadających wydzielonym obszarom tema-tycznym modelu (Rys. 2.7a).

2. Przeniesienie w drzewie projektu odpowiednich klas oraz diagramów dla kaŜdego z obsza-rów tematycznych do odpowiedniego pakietu (Rys. 2.7b).



15

Rys. 2.7

3. Edycja właściwości diagramów w celu uwidocznienia przestrzeni nazw dla elementów znaj-dują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. 2.8

3. Literatura

1. OMG Unified Modeling Language, Superstructure, version 2.2, formal/2009-02-02 (http://www.omg.org/spec/UML/2.2/Superstructure)

2. Martin Fowler: UML w kropelce, wersja 2.0, LTP Oficyna Wydawnicza, 2005



16

3. Michał Smiałek: Zrozumieć UML 2.0. Metody modelowania obiektowego, Wydawnictwo Helion, 2005

4. Grady Booch, James Rumbaugh, Ivar Jacobson: UML przewodnik uŜytkownika, wydanie drugie, WNT, 2005

5. Enterprise Architect User Guide (http://www.sparxsystems.com/bin/EAUserGuide.pdf)

Documents

Laboratorium modelowania oprogramowania w języku UML