Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji 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. Budowa diagramu sekwencji...3 2. Scenariusz pracy...5 2.1. Demonstracja budowy diagramu sekwencji...5 2.2. Zadanie 1...5 2.3. Zadanie 2...10 3. Literatura...10 2
1. Informacje wstępne 1.1. Cel ćwiczenia Celem ćwiczenia jest zapoznanie się ze sposobami tworzenia diagramów sekwencji w narzędziu Enteprise Architect oraz ich zastosowaniem do modelowania interakcji pomiędzy elementami systemu. Za poprawne wykonanie ćwiczenia moŝna otrzymać 2 punkty. 1.2. Budowa diagramu sekwencji W języku UML, podstawowym sposobem na pokazanie dynamicznej wymiany komunikatów między obiektami są diagramy sekwencji. Diagramy te doskonale nadają się do pokazywania wymiany komunikatów w czasie. Komunikaty zaznaczane są poziomymi strzałkami skierowanymi od nadawcy do odbiorcy komunikatu. Sekwencja komunikatów czytana jest od góry do dołu, odzwierciedlając upływ czasu. Podstawową diagramów sekwencji są pionowe kolumny zwane liniami Ŝycia (ang. lifeline). KaŜda linia Ŝycia odpowiada pojedynczemu obiektowi uczestniczącemu w sekwencji. Linia Ŝycia rozpoczyna się od góry symbolem reprezentującym obiekt. Od obiektu biegnie pionowo w dół przerywana linia oznaczająca czas Ŝycia tego obiektu. Najczęściej obiekty Ŝyją przez cały czas trwania interakcji, czyli linia obejmuje cały diagram od góry do dołu. Linie Ŝycia mogą reprezentować obiekty róŝnego rodzaju. Mogą to być klasy, interfejsy, komponenty lub aktorzy. JeŜeli diagram sekwencji ma prezentować sposób działania jakiegoś podsystemu, najpewniej będzie on zawierał jedynie obiekty odpowiednich klas. JeŜeli zechcemy opisać diagramem sekwencji realizację przypadku uŝycia, to co najmniej jedna linia Ŝycia powinna odpowiadać aktorowi. 3
Rysunek 1.1: Diagram sekwencji Komunikaty rysowane są na diagramie sekwencji między jedną linią Ŝycia a drugą. Komunikat ma najczęściej nazwę. Nazwa ta zazwyczaj odpowiada nazwie operacji zawartej w klasie związanej z linią Ŝycia odbiorcy komunikatu. Obsługa komunikatu, czyli wykonanie usługi przez odbiorcę, zaznaczana jest pionową belką umieszczoną wzdłuŝ linii Ŝycia. Belka kończy się w momencie zakończenia wykonywania usługi. Rysunek 1.1 przedstawia przykładowy diagram sekwencji obrazujący wykonanie przypadku uŝycia na poziomie architektonicznym komunikaty wymieniane są pomiędzy interfejsami. MoŜna wyróŝnić dwa rodzaje komunikatów: synchroniczne i asynchroniczne. Komunikaty synchroniczne zaznaczane są strzałkami z pełnym grotem. Dla komunikatu synchronicznego belka na linii Ŝycia wyznacza czas, w którym wykonywany jest kod operacji obsługującej ten komunikat. Po zakończeniu obsługi komunikatu, sterowanie powraca do obiektu, który był nadawcą komunikatu. Powrót sterowania oznacza się komunikatem zwrotnym w postaci przerywanej strzałki. Komunikat zwrotny moŝe być opisany np. wynikiem wykonania operacji. Komunikaty asynchroniczne zaznaczane są za pomocą strzałek z otwartymi grotami. Komunikat asynchroniczny oznacza, Ŝe jego przesłanie powoduje uruchomienie działania operacji niewymagającej na końcu synchronizacji z obiektem wywołującym tę operację, tzn. nadawca komunikatu nie oczekuje biernie na zakończenie wykonywania operacji związanej z tym komunikatem. Komunikaty asynchroniczne nie wymagają więc przesyłania komunikatów powrotnych przez odbiorcę. Na diagramach sekwencji moŝliwe jest zaznaczenie utworzenia (konstrukcji) nowego obiektu. W tym celu naleŝy umieścić na diagramie odpowiedni komunikat tworzący obiekt. Oznaczany on jest strzałką z otwartym grotem, przy czym konstruowany obiekt umieszczony jest na linii Ŝycia na poziomie komunikatu tworzącego obiekt. Destrukcja obiektu, oznaczająca usunięcie go z pamięci, rysowana jest w postaci znaku X umieszczonego na końcu linii Ŝycia obiektu. Rysunek 1.2 przedstawia przykład tworzenia i destrukcji obiektu. Rysunek 1.2: Tworzenie i destrukcja obiektu Bardzo przydatnymi elementami, które moŝemy wykorzystywać na diagramach sekwencji są tzw. Fragmenty włączone (ang. combined fragment). Fragmenty takie umieszcza się na diagramach w postaci ramki z nagłówkiem, która obejmuje pewien zbiór komunikatów. Fragment włączony oznacza pewien fragment diagramu sekwencji stanowiący osobną interakcję wykonywana w określony sposób pod określonymi warunkami. W nagłówku ramki określony jest typ fragmentu włączonego 4
oraz, ewentualnie, jego nazwa. Wewnątrz fragmentu umieszczany jest jeden lub więcej warunków. JeŜeli warunków jest kilka, to cały fragment podzielony jest na tyle części, ile jest warunków. Części oddzielone są pozioma przerywaną linią. Istnieje wiele typów fragmentów włączonych. NajwaŜniejsze z nich są następujące: alt (alternatywa) zawiera dwie lub więcej części z warunkami rozłącznymi. Wykonywana jest interakcja zawarta w tej części, dla której warunek jest spełniony. Fragment ten działa na podobnej zasadzie jak instrukcja if-else w większości języków programowania. Rysunek 1.1 przedstawia przykład tego typu ramki. opt (opcja) zawiera dokładnie jedną część opisaną warunkiem. Interakcja zawarta w tej części jest wykonywana wtedy, gdy warunek jest spełniony. Odpowiada to pojedynczej instrukcji if w języku programowania. loop (pętla) zawiera dokładnie jedną część z warunkiem. Wykonywanie sekwencji komunikatów zawartej w tej części powtarzane jest dotąd, aŝ zostanie spełniony warunek zakończenia pętli. Warunek moŝe zawierać liczbę określającą ilość iteracji lub warunek logiczny zakończenia pętli. Fragment ten działa na podobnej zasadzie jak instrukcje for czy while spotykane w róŝnych językach programowania. break (przerwanie) zawiera jedną lub więcej części z warunkami. Po wykonaniu interakcji zawartej w części, dla której spełniony jest warunek, przerywane jest wykonywanie całej sekwencji w ramach aktualnej interakcji. Odpowiada to instrukcji break występującej w większości języków programowania. par (zrównoleglenie) zawiera kilka części, które mogą być wykonywane równolegle. W ramach takiego wykonania moŝe następować przeplatanie komunikatów między sekwencjami zawartymi w róŝnych częściach. 2. Scenariusz pracy 2.1. Demonstracja budowy diagramu sekwencji W tej części zajęć prowadzący zademonstruje tworzenie diagramów sekwencji. W ramach demonstracji zaprezentowane zostaną róŝne sposoby umieszczania poszczególnych elementów na diagramie: linii Ŝycia obiektów oraz aktorów, komunikatów synchronicznych i asynchronicznych, komunikatów zwrotnych oraz fragmentów włączonych. NaleŜy zwrócić uwagę na wykorzystanie narzędzia EA do tworzenia wymienionych elementów oraz przydatne opcje i ustawienia. Prowadzący objaśni jednocześnie semantykę tworzonych elementów modelu. 2.2. Zadanie 1 Zadanie to polega na utworzeniu, wspólnie z prowadzącym, diagramu sekwencji modelującego dynamikę wybranego zagadnienia, zgodnie z ustalonym scenariuszem. Proponowany scenariusz wykonania zadania: 1. Przedstawienie przez prowadzącego tematyki zadania zagadnienia, w którym występuje interakcja pomiędzy róŝnymi elementami, np. kierowanie samochodem ruszanie. 2. Utworzenie nowego projektu. W drzewie projektu naleŝy utworzyć widok zawierający diagram klas oraz widok zawierający diagram sekwencji (Rys. 2.1). 5
Rys. 2.1 3. W czasie dyskusji z prowadzącym, naleŝy utworzyć aktorów oraz klasy (około 3-4) modelujące elementy, które będą brały udział w interakcji (np. kierowca, samochód, silnik, skrzynia biegów) (Rys. 2.2). Rys. 2.2 4. Wspólnie z prowadzącym naleŝy ustalić ogólny scenariusz interakcji pomiędzy elementami w ramach wybranego zagadnienia, np. 1) Kierowca przekręca kluczyk 2) Samochód uruchamia silnik 3) Kierowca wyłącza sprzęgło i zmienia bieg 4) Kierowca dodaje gazu 5) Samochód zwiększa obroty silnika 6) itd. 5. Analizując czynności wykonywane przez poszczególne elementy w scenariuszu, naleŝy utworzyć kilka podstawowych operacji w odpowiednich klasach (Rys. 2.3). 6
Rys. 2.3 6. Na diagramie sekwencji naleŝy utworzyć linie Ŝycia poprzez przeciągnięcie aktora oraz klas z przeglądarki projektu na otwarty diagram sekwencji. Przy przenoszeniu elementów, nale- Ŝy wybrać opcję as instance of Element (Object) w celu utworzenia instancji danej klasy (Rys. 2.4). Rys. 2.4 7. Utworzenie sekwencji komunikatów przesyłanych pomiędzy liniami Ŝycia obiektów w celu zamodelowania dynamiki wybranego zagadnienia zgodnie z ustalonym scenariuszem (Rys. 2.5). 7
Rys. 2.5 MoŜna tworzyć komunikaty synchroniczne wraz z komunikatami zwrotnymi a takŝe w razie potrzeby komunikaty asynchroniczne. Rodzaj komunikatu określa się w oknie właściwości komunikatu (Rys. 2.6) Rys. 2.6 KaŜdemu komunikatowi naleŝy przypisać operacje wykonywaną przez obiekt odbierający komunikat, na zlecenie obiektu wysyłającego komunikat. JeŜeli potrzebna operacja została uprzednio zdefiniowana w odpowiedniej klasie, naleŝy wybrać jej nazwę z listy w oknie właściwości komunikatu (pole Message) (Rys. 2.7). 8
Rys. 2.7 JeŜeli klasa nie ma zdefiniowanej odpowiedniej operacji, naleŝy ją utworzyć korzystając z opcji Operations (Rys. 2.8). W przypadku niektórych operacji naleŝy równieŝ utworzyć potrzebne parametry. Rys. 2.8 9
8. Umieszczenie na diagramie fragmentów włączonych (Combined Fragments) wybranego typu (alt, opt, loop) w celu zamodelowania bardziej złoŝonego scenariusza zawierającego np. czynności wykonywane warunkowo i/lub czynności wykonywane w pętli. NaleŜy odpowiednio zmodyfikować komunikaty wewnątrz fragmentów włączonych (Rys. 2.9). 2.3. Zadanie 2 Rys. 2.9 Zadanie to polega na samodzielnej stworzeniu diagramu sekwencji. Temat modelowanego zagadnienia oraz scenariusz interakcji zostanie przedstawiony przez prowadzącego. Zadanie naleŝy wykonać zgodnie ze scenariuszem pracy przedstawionym w zadaniu poprzednim. 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) 10