instrukcja UML - w trakcie prac (wersja robocza 31.12.2006)
Transkrypt
instrukcja UML - w trakcie prac (wersja robocza 31.12.2006)
UML – informacje do ćwiczeń laboratoryjnych 1 1. WPROWADZENIE 1.1. Podstawowe pojęcia Największy problem stanowi przedstawienie świata rzeczywistego w komputerze. Nie da się „wpakować” kawałka rzeczywistości do komputera, ale trzeba przedstawić – mówimy zamodelować pewne jego cechy (wszyscy wiemy jak dobrze robiły to komputery w filmie pt. „Matrix”). Zatem model to abstrakcja (pewien „uproszczony” opis) świata rzeczywistego. Domena (dziedzina) – to upraszczając, modelowany fragment rzeczywistości. Modele składają się z obiektów, które mogą na siebie oddziaływać (wchodzić w interakcje, przesyłając sobie komunikaty). Obiekty w modelu opisujemy przez atrybuty (cechy, które przyjmują określone wartości) i operacje (to co może „zrobić” obiekt). Szczegóły dotyczące modelowania obiektowego można znaleźć np. w [1]. 1.2. Język UML UML (Unified Modeling Language), to zunifikowany język umożliwiający opis systemu pod różnymi aspektami. Na przykład budując budynek musimy zaplanować kupno działki o określonej wielkości, sporządzić lub kupić projekt domu oraz zaplanować szereg czynności związanych z jego realizacją (wdrożeniem), a zatem posiadamy (lub opracujemy), co najmniej projekt budynku, kosztorys oraz harmonogram prac. Takie możliwości w stosunku do świata projektów informatycznych (ale nie tylko) daje UML. Modelowanie wykonujemy korzystając z określonych symboli graficznych –diagramów (które trzeba rozumieć ) oraz używając opisu tekstowego. Natomiast szczegóły dotyczące języka UML: http://www.uml.org/ http://www.omg.org (dokładna specyfikacja UML v.2.0 http://www.omg.org/cgibin/doc?formal/05-07-04) http://www.borland.pl/tech/poradnik_uml.shtml - uwaga, definicje podane w tym serwisie są w wielu miejscach mało precyzyjne, ale zachęcam do obejrzenia przykładów oraz prześledzenia odnośników do stron angielskojęzycznych (pierwowzoru), wykład. Oficjalna specyfikacja języka UML składa się z: − UML Superstructure - definiuje wszystkie typy diagramów występujących w języku UML; jest to zasadnicza część specyfikacji, − UML Infrastructure - definicja podstawowych klas stanowiących fundament definicji języka UML, jak również języka MOF (metajęzyka służącego do zdefiniowania UML-a). − UML Diagram Interchange - dodaje do opisu języka dodatkowe definicje sposobów przechowywania informacji o układzie graficznym diagramów i sposobach wymiany tej informacji. − UML OCL - definiuje formalny język OCL (tekstowy) pozwalający na jednoznaczne określanie warunków nakładanych na elementy modeli w języku UML. Dane z: http://www.iem.pw.edu.pl/~smialek/uml.htm Dostępne diagramy: (por. z http://pl.wikipedia.org/wiki/UML) W wersji 2.0 języka UML możemy wyróżnić poniższe diagramy (w tym 4 abstrakcyjne: struktur, dynamiki, wdrożeniowe, interakcji): Diagramy struktury: • Klas (class) • Obiektów (object) • Pakietów (package) • Struktur połączonych (composite structures) • Wdrożeniowe (diagram abstrakcyjny): o Komponentów (components) o Rozmieszczenia (deployment) Diagramy dynamiki: • Przypadków użycia (use case) • Czynności (activity) • Maszyny stanowej (state) • Interakcji (diagram abstrakcyjny): o Sekwencji (sequences) o Komunikacji (communication) o Harmonogramowania (lub zależności czasowych) (timing) o Sterowania interakcją (interaction) UML – informacje do ćwiczeń laboratoryjnych 2 2. Modelowanie struktury (ang. structure) Rysunki zostały zaczerpnięte z dokumentacji UML’a. Definicje opracowane z wykorzystaniem [3]. Tam również można odnaleźć znacznie szerszy opis poszczególnych zagadnień. Pakiety wspomagające modelowania struktury pokazuje rysunek 1. Klasa – zbiór obiektów (obiekty z jednej klasy posiadają np. takie same atrybuty, operacje, semantyka, relacje). Trzy sposoby „spojrzenia” na klasę: - jako zbiór (kolekcja) elementów (obiektów), - jako typ, - jako wzorzec (szablon, według którego można generować obiekty). UWAGA: Symbol graficzny (z lewej) należy odczytać: „pakiet (grupa, zbiór) klas” Struktura połączona – struktura złożona z współdziałających elementów. Komponent – fizyczna, przemieszczalna część systemu. Komponent reprezentuje fizycznie część implementacji systemu, włączając w to moduły programowe, np. skrypty, pliki. Rozmieszczenie – przedstawienie konfiguracji węzłów z umieszczonymi w nich komponentów, a także zachodzących pomiędzy nimi relacji. Węzłem możemy być np. serwer (komputer), a komponentami np. moduły programowe, skrypty, baza danych „w tym” komputerze. Rys. 1. Pakiety wspomagające modelowanie struktury systemu UML – informacje do ćwiczeń laboratoryjnych 3. Modelowanie działania (ang. behavior) 3 Rys. 2. Pakiety wspomagające modelowanie zachowania (działania) systemu CommonBehaviors – główne (kluczowe) wymagania dla elementów dynamicznych Aktywność – jedno z głównych zadań systemu np. pojedynczy krok w procesie biznesowym. W skład aktywności mogą wchodzić akcje np. wykonywane sekwencyjnie i/lub równolegle. Aktywność zajmuje na ogół niezerowy czas i jest podzielna na akcje. Akcja – niepodzielna czynność, której wynikiem jest zmiana stanu systemu lub dostarczenie pewnej wartości Interakcja – „wymiana” (specyfikacja przesyłania) wiadomości w celu realizacji konkretnego zadania. Wymiana może polegać na przesyłaniu sygnałów lub wywołaniu operacji. Maszyna stanowa – specyfikacja (ustalenie, określenie) sekwencji stanów, przez które podczas swego istnienia przechodzi obiekt (lub grupa współdziałania). Zadanie do przemyślenia: przez jakie stany przechodzi ciasto w piekarniku ? Przypadek użycia (usługa) – obejmuje specyfikację sekwencji akcji (również alternatywne i wyjątkowe), które system, podsystem lub klasa może wykonać współdziałając ze swoim otoczeniem (np. aktorami) UML – informacje do ćwiczeń laboratoryjnych 4 3. Symbole używane w diagramach – wyciąg ze specyfikacji 3.1. Diagram przypadków użycia Ze względu na to, iż w oryginalnej notacji używane są napisy w języku angielskim, rysunki zostały przedstawione jak w oryginale (specyfikacji UML 2.0), jednak w niektórych miejscach autor instrukcji zdecydował się podać tłumaczenie. Jeśli projekt sporządzamy dla krajowego kontrahenta, to oczywiście umieszczamy napisy tylko w języku polskim, a jeśli dla odbiorcy z zagranicy – to w języku ustalonym dla realizowanego projektu. Powyższa uwaga nie obejmuje „słów kluczowych” takich jak np. <<extend>>, <<include>>. Uwagi Typ węzła Notacja AKTOR - coś lub ktoś, kto zapewnia Actor Extend Extend (whit conditions) stymulowanie systemu; np. zamówienie posiłku wymaga aktora klient. Aktor może być aktywny – inicjuje interakcje z systemem lub pasywny – stanowi cel żądań (zapotrzebowań) lub jest aktywowany przez system. Można używać również innych ikon niż domyślna np. obrazek komputera. customer =klient, nabywca <<extend>> - stereotyp, oznacza, że przypadek użycia wskazany przez strzałkę rozszerza swoje zachowanie o to, które jest reprezentowane przez przypadek użycia z którego strzałka wychodzi. <<extend>> (z warunkiem) – przykład notacji warunku rozszerzenie pod warunkiem: klient zaznaczył(wybrał) HELP Extension point Przypadek użycia, który rozszerza zachowanie innego przypadku użycia. Można powiedzieć, że wskazuje na inny przebieg (lub kilka alternatyw) scenariusza dla innego określonego przypadku użycia. Include <<include>> oznacza, że przypadek użycia withdraw (pobranie w domyśle: gotówki) włącza do swojego scenariusza (w odpowiednim miejscu) przypadek użycia Card Identification (identyfikacja karty). UML – informacje do ćwiczeń laboratoryjnych UseCase 5 Różne sposoby notacji przypadków użycia. Przypadek użycia (usługa) jest opisem zbioru skończonych ciągów akcji – scenariuszy. Zwykle jest to opis akcji podejmowanych przy realizacji określonej usługi. W obrębie przypadku użycia można umieszczać znaczniki w postaci listy poniżej nazwy przypadku użycia. Na przykład przypadek użycia Perform ATM Transaction (nazwa mogłąby być zapisana również nad kreską w obrębie elipsy) zawiera znacznik (extension points – punkt rozszerzenia) o nazwie Selection. Przykład: Rys. 3. Przypadki użycia – „obsługa sprzedaży wysyłkowej” Możemy przyjąć, że jeśli ktoś nie otrzymał „kredytu” na zakup towaru, to wysyłka jest realizowana za zaliczeniem pocztowym . UML – informacje do ćwiczeń laboratoryjnych 6 3.2. Diagram klas Diagram służy do modelowania struktury – statycznych elementów systemu. Uwagi Typ węzła Notacja KLASA – wyjaśniono wcześniej Class ClassName=nazwa klasy Przykład zawiera: • klasę Window (tylko nazwa klasy w prostokącie), • klasę Window (dwa atrybuty i dwie operacje), • klasę Window z dokładną specyfikacją atrybutów i operacji gdzie: Sekcja z nazwą klasy może zawierać dodatkowo stereotyp np. <<interface>>. Dodatkowo, oprócz sekcji z atrybutami oraz operacjami może wystąpić np. sekcja z wyjątkami (poniżej sekcji z operacjami). UWAGA: Metoda (określa algorytm lub procedurę), to implementacja operacji. Interface Instance Specificatio n Package INTERFEJS – ogólna charakterystyka spójnego zestawu usług reprezentowanych określone operacje (interfejs jest też określany jako “łącze pomiędzy czyś i czymś” np. interfejs pomiędzy systemem alarmowy i człowiekiem stanowi dzwonek) INSTANCJA – model elementu reprezentującego “występienie” (np. encję, obiekt) w modelowanym systemie/klasie, np. reprezentacja powiązania dwóch instancji klasy Person (osoba). PAKIET – służy do grupowania różnego rodzaju elementów. Wykorzystujemy głównie do dekompozycji (rozłożenia) tworzonych modeli, np. projektując system możemy podzielić go na podsystemy (każdy podsystem będzie zawarty w pakiecie). UWAGI: diagram klas tworzymy jako jeden z aspektów „dekompozycji” przypadków użycia (jeśli mielibyśmy wykonać to precyzyjnie, to od wersji UML 1.3 taką dekompozycję możemy wykonać na tzw. „grupy współdziałania” będące zbiorem klas, interejsów, komponentów itp., lecz także obejmujące diagramy aktywności), • wybrane typy powiązań • UML – informacje do ćwiczeń laboratoryjnych 7 Typ Notacja graficzna Opis Association Relację tą można nazwać związkiem, Asocjacja a odzwierciedla ona powiązanie pomiędzy dwoma bądź więcej elementami (klasyfikatorami). Na końcach asocjacji można umieścić informację o liczności jej końców (np. na jednym końcu zaznaczyć 1, a na drugim 1..5 co może oznaczać w odpowiednim kontekście: jednej osobie może przypadać od 1 do 5 kart). Może zostać dodatkowo opisana etykietą (nazwana). Dependency Zależność polegająca na tym, że zmiana w jednym Zależność elemencie (niezależnym) powoduje zmianę w drugim elemencie. Zależność może być określonego rodzaju, np. <<use>> (użycie) oznacza, że jeden element używa drugiego. Aggregation Relacja „całość-część”. Obiekt reprezentowany jako Agregacja całość (od strony rombu) zawiera elementy (komponenty) reprezentowane jako części. Composition Taka agregacja, w której elementy składowe należą Kompozycja/ tylko do jednego elementu macierzystego i są silna agregacja kreowane po jego utworzeniu, a kasowane wraz z nim (lub przed momentem jego kasowania). Generalizatio Relacja pomiędzy elementem ogólnym (od strony n trójkąta), a specyficznym. Element specyficzny jest Generalizacja całkowicie zgodny z ogólnym i zawiera dodatkową informację. Realization Jeden element stanowi realizację innego. Może być Realizacja wykorzystana np. przy opisie optymalizacji, transformacji, syntezie modeli. Bibliografia [1] Internet –dokumentacja: www.uml.org; www.omg.org [2] pod red. J. Górski, Inżynieria oprogramowania, MIKOM, Warszawa 2000, str. 116-154 [3] Z. Huzar, Wprowadzenie do języka UML, Politechnika Wrocławska, Raport PRE 24/99 [4] Michał Śmiałek, Zrozumieć UML 2.0, HELION, Gliwice 2005 [5] Martin Fowler, UML w kropelce, LTP Warszawa 2005 [6] G. Booch, J. Rumbaugh, I. Jacobson UML przewodnik użytkownika, WNT 2000