Laboratorium modelowania oprogramowania w języku UMLwikidyd.iem.pw.edu.pl/attachments/LMUML/MUML_Cwiczenie01_S.pdfLaboratorium modelowania oprogramowania w języku UML Ćwiczenie

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 1

Wprowadzenie do narzędzia CASE

Materiały dla studenta


Ćwiczenie 1: Wprowadzenie do narzędzia CASE

2

Spis treści

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

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

1.2. Wprowadzenie do narzędzi CASE ....................................................................3

2. Scenariusz pracy....................................................................................................5

2.1. Demonstracja narzędzia ...................................................................................5

2.2. Zadanie 1..........................................................................................................5

2.3. Zadanie 2........................................................................................................ 14

3. Literatura .............................................................................................................. 14



3

1. Informacje wstępne

1.1. Cel ćwiczenia

Celem ćwiczenia jest zapoznanie się z narzędziem typu CASE – Enterprise Architect. Przedsta-wione zostaną najwaŜniejsze elementy interfejsu uŜytkownika, podstawowe funkcje narzędzia oraz sposoby tworzenia projektów, diagramów oraz innych elementów wspólnych dla wszystkich rodza-jów modeli UML.

1.2. Wprowadzenie do narzędzi CASE

Jednym z najwaŜniejszych zagadnień w procesie wytwarzania oprogramowania jest opanowanie ogromu informacji towarzyszącej powstającym systemom. Na wiedzę gromadzoną w trakcie trwa-nia projektów składają się dokumenty powstałe przy współpracy z klientem, modele, projekty, kod, testy, dokumentacja, podręczniki, multimedia, wersje produktów itp. Aby praca informatyków była nie tylko wydajna i zakończona sukcesami, ale w ogóle moŜliwa, niezbędne jest powstanie odpo-wiedniego środowiska, w którym te tworzone artefakty są właściwie katalogowane. Takie środowi-sko pracy powinno pozwalać nie tylko na łatwą wymianę informacji między uczestnikami projektu, ale równieŜ automatyzować moŜliwie wiele pracochłonnych czynności na wszystkich etapach procesu wytwórczego.

W celu konstrukcji środowisk pracy informatyków powstają narzędzia typu CASE (ang. Computer-Aided Software Engineering – InŜynieria oprogramowania wspomagana komputerowo) wspierają-ce praktyczne zastosowanie inŜynierii oprogramowania. Narzędzia te pozwalają usprawnić czyn-ności związane z wieloma aspektami rozwoju produktów systemowych: od zarządzania projektami informatycznymi, przez integrację powstających modułów i zarządzanie zmianami, po wsparcie dla modelowania systemów na róŜnych poziomach i ułatwianie implementacji.

Narzędzia wspierające modelowanie systemów naleŜą do najwaŜniejszych, jakie zespół projekto-wy posiada w swoim „warsztacie” inŜynierii oprogramowania. Znaczenie modelowania jest o tyle istotne, Ŝe ma ono miejsce w czasie wszystkich faz rozwoju produktów. Modelowanie wspierane narzędziami moŜe być odpowiednio automatyzowane. Pozwalające na łatwą wymianę informacji, dodatkowo umoŜliwia przetwarzanie modeli przez maszyny, w celu ich walidacji, analizy czy prze-kształceń.

Podstawową funkcjonalnością typowego narzędzia słuŜącego do modelowania jest wsparcie dla rysowania diagramów w wybranej notacji. Wsparcie to polega na udostępnieniu uŜytkownikowi moŜliwości łatwego umieszczania elementów na diagramach (poprzez np. tzw. przybornik), edycji diagramów oraz przeglądania modeli (Rys. 1.1 – po lewej stronie widoczny przybornik, w części środkowej edytowany diagram, po prawej podgląd struktury modelu). Wsparcie narzędzi dla notacji polega na łatwym i przejrzystym tworzeniu diagramów róŜnych typów. Dobre narzędzia „pilnują” poprawności notacji nie pozwalając uŜytkownikowi na umieszczenie na diagramie danego typu niewłaściwych elementów czy nieprawidłowe zapisanie konstrukcji języka.

Istotną funkcją narzędzia modelowania jest takŜe umoŜliwienie zarządzania modelami: odpowied-niego porządkowania ich struktury (np. w formie pakietów), a takŜe wygodnego przechodzenia między poziomami abstrakcji i śledzenia zaleŜności między fragmentami systemów opisanych z róŜnym stopniem szczegółowości. Cecha ta jest niezmiernie istotna, poniewaŜ systemy reprezen-towane są przez modele na wielu poziomach abstrakcji: poczynając od wymagań, a kończąc na „mapach kodu” – modelach projektowych.

Wyspecjalizowane narzędzia modelowania nie dość, Ŝe upraszczają proces zapisu wiedzy na temat systemów od strony czysto technicznej, to takŜe udostępniają szereg innych przydatnych funkcjonalności.

Jedną z nich jest inŜynieria kodu. Korzystając z funkcji z nią związanych moŜna generować szkie-let kodu odzwierciedlający wiedzę zawartą w modelu (tzw. „inŜynieria w przód”), tworzyć modele w celu zrozumienia istniejącego kodu („inŜynieria odwrotna”), a takŜe wspierać proces jednoczesne-



4

go pisania kodu i uaktualniania modelu („inŜynieria w obie strony”). Narzędzia najczęściej pozwala-ją na szeroką parametryzację tych procesów – nie tylko przez określenie „docelowego” języka programowania, ale sposobu interpretacji konstrukcji języków modelowania i opisujących kod.

WaŜnym zagadnieniem związanym z tworzeniem modeli jest udostępnianie efektów pracy pozo-stałym osobom uczestniczącym w projekcie w dogodnej dla nich formie. Większość narzędzi po-zwala na generację dokumentacji modeli. Jest to, podobnie jak inŜynieria kodu, proces parametry-zowalny: dostępna jest mnogość formatów docelowych dokumentów (statyczny lub dynamiczny HTML, pliki RTF, pliki graficzne itd.). MoŜliwa jest takŜe konfiguracja zakresu generowanej treści, często istnieje teŜ wsparcie dla tworzenia szablonów dokumentów. Inny sposób wymiany modeli to poddanie ich kontroli wersji. UmoŜliwia to pracę grupową nad modelami. Czasami zachodzi takŜe potrzeba wymiany modeli między zespołami korzystającymi z róŜnych zestawów narzędzi mode-lowania – słuŜy temu ustandaryzowany format XMI (ang. XML Metadata Interchange).

Rys. 1.1: Tworzenie modelu w narzędziu CASE

Zaawansowane narzędzia modelowania pozwalają takŜe przypisać elementom zapisanym w wybranym języku modelowania (np. UML) pewne atrybuty związane z zarządzaniem projektami, takie jak ryzyko związane z danym elementem, osobę za niego odpowiedzialną, fazę prac, wersję itp. Atrybuty te pozwalają one na łatwą analizę pewnych zagadnień związanych z zarządzaniem projektami, śledzenie zmian, kalkulację ryzyka, czy obliczanie miar w projekcie.



5

2. Scenariusz pracy

2.1. Demonstracja narzędzia

W tej części zajęć prowadzący demonstruje narzędzie Enterprise Architect. Demonstracja obejmu-je: uruchomienie narzędzia, tworzenie nowych projektów, prezentację podstawowych elementów okna głównego oraz systemu pomocy, tworzenie struktury modelu, tworzenie diagramów oraz umieszczanie na diagramach elementów modelu.

2.2. Zadanie 1

Celem tego zadania jest praktyczne przećwiczenie podstaw pracy z narzędziem zademonstrowa-nych przez prowadzącego w poprzednim punkcie. Zadanie polega na stworzeniu, razem z prowa-dzącym zajęcia, nowego projektu EAP (Enterprise Architect Project).

Proponowany scenariusz wykonania zadania:

1. Utworzenie nowego projektu EAP (Rys. 2.1, Rys. 2.2).

Rys. 2.1



6

Rys. 2.2

NaleŜy utworzyć pusty projekt – bez wykorzystania predefiniowanych szablonów projektów. W tym celu naleŜy odznaczyć wszystkie opcje w oknie wyboru modeli (Rys. 2.3).

Rys. 2.3

2. Utworzenie struktury projektu składającej się z widoków (view) oraz pakietów (package) o róŜnym poziomie zagnieŜdŜenia.

a. Najpierw naleŜy utworzyć widoki będące rodzajem pakietów grupujących elementy modelu na najwyŜszym poziomie abstrakcji. Tworząc widok naleŜy podać jego na-zwę oraz wybrać typ (Rys. 2.4).



7

Rys. 2.4

b. W poszczególnych widokach naleŜy utworzyć strukturę pakietów. Pakiety mogą być zagnieŜdŜone w innych pakietach. Tworząc pakiet naleŜy podać jego nazwę (Rys. 2.5).

Rys. 2.5

3. Utworzenie diagramu przypadków uŜycia.

a. Diagram przypadków uŜycia naleŜy utworzyć w odpowiednim miejscu w drzewie projektu. W oknie dialogowym wyświetlanym podczas tworzenia diagramu moŜna podać własną nazwę diagramu lub zostawić nazwę domyślną – identyczną jak na-zwa pakietu, w którym diagram będzie utworzony. NaleŜy takŜe określić typ diagra-mu wybierając najpierw kategorię diagramów dynamiki (UML Behavioral) oraz typ diagramu Use Case (Rys. 2.6).



8

Rys. 2.6

b. Na nowoutworzonym, pustym diagramie, naleŜy umieścić nowe elementy z przy-bornika dla danego diagramu: przypadek uŜycia (use case) oraz aktora (actor) (Rys. 2.7).

Rys. 2.7

Podczas umieszczania nowych elementów na diagramie, naleŜy podać ich nazwę w oknie dialogowym dla tworzonego elementu (Rys. 2.8). MoŜliwe jest podanie równieŜ innych parametrów tworzonego elementu.



9

Rys. 2.8

c. Utworzone elementy naleŜy połączyć odpowiednim typem powiązania – asocjacją łączącą przypadek uŜycia z aktorem (Rys. 2.9). W tym celu naleŜy wybrać jeden z elementów (przypadek uŜycia) i przeciągnąć symbol strzałki do elementu, który ma być z nim powiązany.

Rys. 2.9

4. Utworzenie diagramu klas

a. Diagram klas naleŜy utworzyć w sposób analogiczny jak diagram przypadków uŜy-cia, wybierając odpowiednią lokalizację w drzewie projektu. Przy określaniu typu diagramu naleŜy wybrać kategorię diagramów struktury (UML Structural) oraz typ Class (Rys. 2.10).



10

Rys. 2.10

b. Na nowoutworzonym, pustym diagramie, naleŜy umieścić nowe elementy z przy-bornika dla danego diagramu: klasa (class). Utworzone elementy naleŜy połączyć odpowiednim typem powiązania – asocjacją łączącą odpowiednie klasy (Rys. 2.11).

Rys. 2.11

c. Dla wybranych klasach naleŜy utworzyć operacje. W tym celu naleŜy kliknąć pra-wym przyciskiem myszy na wybraną klasę i wybrać opcję Operations… Nazwę oraz inne parametry operacji naleŜy podać w wyświetlonym oknie dialogowym (Rys. 2.12).



11

Rys. 2.12

5. Utworzenie diagramu sekwencji

a. Diagram sekwencji naleŜy utworzyć w sposób analogiczny jak poprzednie diagra-my, wybierając odpowiednią lokalizację w drzewie projektu. Przy określaniu typu diagramu naleŜy wybrać kategorię diagramów dynamiki (UML Behavioral) oraz typ Sequence (Rys. 2.13).

Rys. 2.13

b. Na nowoutworzonym, pustym diagramie sekwencji, naleŜy utworzyć tzw. linie Ŝycia (lifeline) dla elementów juŜ istniejących w modelu. W tym celu naleŜy przeciągnąć



12

wcześniej utworzone elementy z drzewa projektu na diagram (Rys. 2.14). Podczas umieszczania istniejących elementów modelu na diagramie, naleŜy zaznaczyć w wyświetlanym oknie dialogowym (Rys. 2.15) czy element umieszczony na dia-gramie będzie odnośnikiem do wybranego elementu modelu, czy teŜ będzie nową instancją (obiektem) wybranego elementu.

Rys. 2.14

Rys. 2.15

c. Pomiędzy utworzonymi liniami Ŝycia dla wybranych elementów, naleŜy umieścić komunikaty (message), które modelują wywołanie operacji poszczególnych elemen-tów (Rys. 2.16). Aby przypisać komunikatowi określoną operację elementu, który jest odbiorcą komunikatu, naleŜy dwukrotnie otworzyć okno właściwości komunikatu a następnie wybrać odpowiednią operację z listy operacji danego elementu (Rys. 2.17). NaleŜy zauwaŜyć, Ŝe lista zawiera operacje klas utworzone podczas budowy diagramu klas.



13

Rys. 2.16

Rys. 2.17



14

Rys. 2.18

2.3. Zadanie 2

Zadanie to polega na samodzielnym rozbudowaniu modelu stworzonego w zadaniu 1. Zakres rozbudowy zostanie określony przez prowadzącego zajęcia. MoŜe on obejmować m.in.:

1. Umieszczenie na określonym diagramie dodatkowych elementów oraz powiązanie ich z elementami istniejącymi.

2. Umiejscowienie nowych elementów w przeglądarce projektu.

3. Utworzenie nowego diagramu i umieszczenie na nim nowoutworzonych elementów z przeglądarki projektu.

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

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 UMLwikidyd.iem.pw.edu.pl/attachments/LMUML/MUML_Cwiczenie01_S.pdfLaboratorium modelowania oprogramowania w języku UML Ćwiczenie