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

Podobne dokumenty