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 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. 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 2
1. Informacje wstępne 1.1. Cel ćwiczenia Celem ćwiczenia jest zapoznanie się z narzędziem typu CASE Enterprise Architect. Przedstawione 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 rodzajó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 trwania 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 odpowiedniego środowiska, w którym te tworzone artefakty są właściwie katalogowane. Takie środowisko 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ć czynnoś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ół projektowy 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 przekształ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: odpowiedniego 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 reprezentowane 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ć szkielet 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- 3
go pisania kodu i uaktualniania modelu ( inŝynieria w obie strony ). Narzędzia najczęściej pozwalają 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 pozostałym osobom uczestniczącym w projekcie w dogodnej dla nich formie. Większość narzędzi pozwala na generację dokumentacji modeli. Jest to, podobnie jak inŝynieria kodu, proces parametryzowalny: 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 modelowania 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. 4
2. Scenariusz pracy 2.1. Demonstracja narzędzia W tej części zajęć prowadzący demonstruje narzędzie Enterprise Architect. Demonstracja obejmuje: 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 zademonstrowanych przez prowadzącego w poprzednim punkcie. Zadanie polega na stworzeniu, razem z prowadzą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 5
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 nazwę oraz wybrać typ (Rys. 2.4). 6
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 nazwa pakietu, w którym diagram będzie utworzony. NaleŜy takŝe określić typ diagramu wybierając najpierw kategorię diagramów dynamiki (UML Behavioral) oraz typ diagramu Use Case (Rys. 2.6). 7
Laboratorium modelowania oprogramowania w języku UML Rys. 2.6 b. Na nowoutworzonym, pustym diagramie, naleŝy umieścić nowe elementy z przybornika 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. 8
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ŝycia, 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). 9
Laboratorium modelowania oprogramowania w języku UML Rys. 2.10 b. Na nowoutworzonym, pustym diagramie, naleŝy umieścić nowe elementy z przybornika 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ąć prawym 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). 10
Laboratorium modelowania oprogramowania w języku UML Rys. 2.12 5. Utworzenie diagramu sekwencji a. Diagram sekwencji naleŝy utworzyć w sposób analogiczny jak poprzednie diagramy, 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ąć 11
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 diagramie 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 elementó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. 12
Rys. 2.16 Rys. 2.17 13
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) 14