UML (Unified Modeling

Language)

Czym jest UML?

• Językiem pozwalającym tworzyć modele systemów

• Pozwala obrazować, specyfikować, tworzyć i dokumentować
elementy systemu

• Ułatwia wymianę informacji pomiędzy przyszłymi użytkownikami
systemu, menadżerami, analitykami, projektantami,
programistami i testerami

• Ułatwia wykorzystanie zalet programowania obiektowego

• UML jest jedynie językiem modelowania używanym w procesie
analizy
i projektowania systemów komputerowych

Konstrukcja UML

Notacja

Metamodel

•elementy graficzne
•składnia języka
modelowania
•istotna przy szkicowaniu
modeli

•definicje pojęć języka
i powiązania między nimi
•istotny przy graficznym

programowaniu

Z punktu widzenia analityka istotniejsze jest czytelne i
jednoznaczne opisanie modelu tak, aby inne osoby mogły
zrozumieć jego znaczenie. Zatem ważniejsza dla niego jest
notacja, zaś metamodel powinien być zrozumiały intuicyjnie. Z
kolei przy generowaniu kodu i przejściu do implementacji
ważniejsze jest ścisłe rozumienie znaczenia poszczególnych
elementów, tak, aby możliwa była automatyczna konwersja
modelu do innego formalizmu.

Rodzaje diagramów

Diagramy

strukturalne

Diagramy dynamiki

• Diagram klas
• Diagram obiektów
• Diagram pakietów
• Diagram

komponentów
• Diagram wdrożenia
• Diagram struktur
złożonych

•Diagram przypadków

użycia
•Diagram stanów
•Diagram przebiegu
•Diagram czynności
•Diagram kooperacji
•Diagram przeglądu

interakcji
•Diagram uwarunkowań

czasowych

Widoki modelu 4+1

Kruchtena

Jednym ze sposobów rozbijania diagramów UML na
perspektywy lub widoki jest system widoków 4+1 Kruchtena

WIDOK LOGICZNY

Używany do modelowania części systemu oraz sposobów, w jaki
one ze sobą współdziałają. Ten widok zazwyczaj tworzą diagramy:

• klas

• obiektów

• stanu

• interakcji

WIDOK PROCESU

Opisuje procesy w systemie. Przydatny przy wizualizacji
przypadków jakie muszą zajść w systemie. Zawiera zazwyczaj
diagramy czynności.

WIDOK KONSTRUKCJI

Opisuje sposób w jaki części systemu są zorganizowane w moduły
oraz komponenty. Zawiera zazwyczaj diagramy:

• pakietów

• komponentów

WIDOK FIZYCZNY

Wyjaśnia w jaki sposób projekt systemu opisany w trzech
poprzednich widokach jest powoływany do życia w postaci
zestawu rzeczywistych obiektów. Rzeczywiste wdrożenie
systemu. Zawiera zazwyczaj diagramy wdrożenia.

WIDOK PRZYPADKÓW UŻYCIA

Widok opisuje funkcjonalność modelowanego systemu z
perspektywy zewnętrznej. Prezentuje przeznaczenie systemu.
Wszystkie inne widoki bazują na widoku przypadków użycia.
Zawiera zazwyczaj diagramy przypadków użycia, opisy i
diagramy przeglądowe.

Diagram przypadków użycia –

Use case diagram

Przypadek użycia

•

Jest przypadkiem, w którym dany system jest używany w

celu spełniania jednego lub większej liczby wymagań
użytkowników.

• Wychwytuje fragment funkcji udostępnianych przez
system.

• Określają wymagania funkcjonalne systemu.

Aktorzy

Aktorzy mogą być:

• ludźmi wchodzącymi w interakcję

• systemami zewnętrznymi

• częściami systemu, które mają wpływ na funkcjonowanie
systemu, ale same przez ten system nie mogą być zmieniane
(jak np. zegar systemowy).

Wychwytywanie przypadków użycia

• Analiza opisu systemu z punktu widzenia przyszłego
użytkownika.

- wymagania konieczne
- wymagania opcjonalne

• Których funkcji aktor oczekuje od systemu?

• Czy aktor musi czytać, modyfikować, tworzyć lub likwidować
pewne informacje w systemie?

• Czy aktor powinien być powiadomiony o zdarzeniach w
systemie lub sam informować system?

• Jakich danych we/wy wymaga system?

Rozpoznawanie aktorów

• Kto będzie używał podstawowych funkcji?

• Kto ma administrować systemem, konserwować i utrzymywać
w działaniu?

• Jakimi urządzeniami zarządza system?

• Z którymi systemami system ma współpracować (np.
wymieniać dane)?

NOTACJA

Przypadek użycia:
Powinien mieć unikalną nazwę,
opisującą przypadek użycia z punktu
widzenia jego zasadniczych celów.

Aktor:
Powinien mieć unikalną nazwę.

Interakcja:
Pokazuje interakcję pomiędzy
przypadkiem użycia a aktorem.

Blok ponownego użycia:
Pokazuje fragment systemu,
który jest używany przez kilka
przypadków użycia; może być

oznaczony jako samodzielny
przypadek użycia.

Relacja typu << include >>

lub
<< extend >>:
Pokazuje związek zachodzący

między dwoma przypadkami
użycia lub przypadkiem użycia
a blokiem ponownego użycia.

Nazwa systemu wraz

z otoczeniem systemu:
Pokazuje granicę pomiędzy
systemem a jego otoczeniem.

ZALEŻNOŚCI MIĘDZY PRZYPADKAMI UŻYCIA

Przypadki użycia mogą być konstruowane w dowolnej
kolejności, chyba że występują między nimi relacje typu:
<< include >> czy << extend >>.

Przebieg podstawowy (sekwencyjny): p1 zawsze włącza
(używa) p2.

Przebieg opcjonalny: p1 jest czasami rozszerzane o p2.

<< include >> wskazuje na wspólny fragment wielu
przypadków użycia; wykorzystywane w przebiegach
podstawowych (operacje zawsze wykonywane)
<< extend >> strzałka prowadzi od przypadku użycia, który
czasami rozszerza inny przypadek użycia - wykorzystywane w
przebiegach opcjonalnych (operacje nie zawsze wykonywane)

DZIEDZICZENIE PRZYPADKÓW UŻYCIA

Dziedziczenie pozwala na współdzielenie większości
zachowania ogólnego przypadku użycia.
Dziedziczenie przypadków użycia - jeden przypadek użycia
dziedziczy zachowanie innego i zarazem dodaje lub modyfikuje
część tego zachowania.

Diagram klas - Class

diagram

Diagram klas - cechy:
• Zawiera informacje o statycznych związkach między

elementami (klasami)

• Klasy są ściśle powiązane z technikami programowania

zorientowanego obiektowo

Symbol klasy
Symbolem klasy jest prostokąt, zwykle podzielony liniami na trzy

sekcje:

• nazwy
• atrybutów
• operacji
W razie potrzeby może zostać uzupełniony dodatkowymi sekcjami
(np. wyjątków).

NOTACJA

Podstawowe sposoby przedstawiania klas, różne poziomy
szczegółowości:

Poziomy dostępu:

+ publiczna
- prywatna
# chroniona
~ zakres pakietu

Składniki statyczne

Składniki można zadeklarować jako statyczne, działające
na rzecz klasy, nie obiektu.
Koncepcja identyczna jak w językach zorientowanych
obiektowo.
Reprezentacją graficzną jest podkreślenie.

Krotność

Krotność pozwala określić minimalną i maksymalną liczbę
obiektów, jakie można powiązać z daną cechą:
dolna granica..górna granica - przedział od - do
1 - dokładnie jeden obiekt
0..1 - opcjonalnie jeden obiekt
1..* - przynajmniej jeden obiekt
1, 3, 5 - konkretne liczby obiektów
* - dowolna liczba obiektów

Krotność cechy wskazuje, ile obiektów można, a ile trzeba w
niej zawrzeć. Krotność można określać jako ograniczenie dolne i
górne.
W praktyce programowania istotna jest krotność 0, 1 i dowolna,
natomiast wartości dyskretne są mniej ważne, jako szczególne
przypadki wymienionych trzech.

Ogólna deklaracja atrybutu wpisanego

[widoczność] nazwa [:typ] [=wartość początkowa] [właściwość]

właściwość:

• changeable - bez ograniczeń

• addOnly - gdy liczebność jest większa niż jeden, można dodawać
nowe
wartości, ale raz dodane nie moga byc zmieniane

• readOnly, frozen - nie ma możliwości zmiany (jak const w C++)

Przykład: + wysokosc : double = 10 frozen

Ogólna deklaracja operacji

[widoczność] nazwa [(lista_parametrów)] [: typ_wyniku]
[właściwość]

gdzie lista parametrów:
[tryb] nazwa : typ [=wartość_domyślna]

tryb:
in - wejściowy, nie może być modyfikowany
out - wyjściowy, może być modyfikowany
inout - wejściowy, wyjściowy, może być modyfikowany

właściwość:
leaf - funkcja niepolimorficzna (nie może być nadpisana)
isQuery - funkcja nie zmieniająca obiektu
sequental, guarded, concurent (mają zastosowanie przy
operacjach współbieżnych)

Nazwa funkcji pisana kursywą - funkcja wirtualna

Związki między klasami

Zależność - dependency

Zależność pomiędzy dwiema klasami informuje, że jedna z nich,
aby używać obiektów innej, musi mieć o niej informacje.
Zależność występuje, gdy zmiana specyfikacji jednej klasy,
może powodować konieczność wprowadzania zmiany w innej
klasie. Najczęściej używa się zależności do pokazania, że jedna
klasa używa innej jako parametru jakiejś operacji. Obie klasy są
zależne od siebie nawzajem w celu zapewnienia poprawnej
pracy.

<< call >> - operacje w klasie A wywołują operacje w klasie B
<< create >> - klasa A tworzy instancje klasy B
<< instantiate >> - obiekt A jest instancją klasy B
<< use >> - do zaimplementowania klasy A wymagana jest
klasa B

Asocjacja

Asocjacja reprezentuje czasowe powiązanie pomiędzy
obiektami dwóch klas. Obiekty związane asocjacją są od siebie
niezależne. Asocjacja jest też używana jako alternatywny (obok
atrybutu) i równorzędny sposób zapisu cech klasy.

Asocjacje są silniejszymi relacjami niż zależności. Wskazują, że
jeden obiekt jest związany z innym przez pewien okres czasu.
Jednak czas życia obu obiektów nie jest od siebie zależny:
usunięcie jednego nie powoduje usunięcia drugiego.

W przypadku asocjacji żaden obiekt nie jest właścicielem
drugiego: nie tworzy go, nie zarządza nim, a moment
usunięcia drugiego obiektu nie jest z nim związany. Z drugiej
strony, obiekt powiązany asocjacją z drugim posiada
referencję do niego, może się do niego odwołać itd.

Asocjacja jest równoważna atrybutowi: UML nie rozróżnia
obiektu, który jest polem klasy od obiektu i jest z nią
związany asocjacją. Warto jednak przyjąć konwencję, w której
obiekty reprezentujące wartości (np. daty) oraz typy proste
(liczby, napisy, znaki) są modelowane jako atrybuty,
natomiast obiekty dostępne poprzez referencje są
przedstawiane poprzez asocjacje.

Klasa asocjacyjna

Klasy asocjacyjne są związane z relacją asocjacji i opisują jej
właściwości. Mają dostęp do innych obiektów uczestniczących w
relacji.

Klasa asocjacyjna umożliwia opisanie za pomocą atrybutów i
operacji nie obiektu, ale właśnie samej asocjacji pomiędzy
klasami. Informacje przechowywane w klasie asocjacyjnej nie są
związane z żadną z klas uczestniczących w asocjacji, dlatego
wygodnie jest stworzyć dodatkową klasę i powiązać ją z relacją.
Klasy asocjacyjne są reprezentowane graficznie jako klasy
połączone linią przerywaną z relacją asocjacji, której dotyczą.

Agregacja częściowa

Agregacja reprezentuje relację typu całość-część, w której
część może należeć do kilku całości, a całość nie zarządza
czasem istnienia części.

Agregacja jest silniejszą formą asocjacji. W przypadku tej
relacji równowaga między powiązanymi klasami jest
zaburzona: istnieje właściciel i obiekt podrzędny, które są ze
sobą powiązane czasem swojego życia. Właściciel jednak nie
jest wyłącznym właścicielem obiektu podrzędnego, zwykle też
nie tworzy i nie usuwa go. Relacja agregacji jest zaznaczana
linią łączącą klasy/obiekty, zakończoną białym rombem po
stronie właściciela.

Agregacja całkowita (kompozycja)

Agregacja całkowita jest relacją typu całość-część, w której
całość jest wyłącznym właścicielem części, tworzy je i zarządza
nimi.

Agregacja całkowita jest najsilniejszą relacją łączącą klasy.
Reprezentuje relacje całość-część, w których części są tworzone
i zarządzane przez obiekt reprezentujący całość. Ani całość, ani
części nie mogą istnieć bez siebie, dlatego czasy ich istnienia są
bardzo ściśle ze sobą związane
i pokrywają się: w momencie usunięcie obiektu całości obiekty
części są również usuwane. Typowa fraza związana z taką relacją
to "...jest częścią...". Agregacja całkowita jest przedstawiana na
diagramie podobnie jak agregacja częściowa, przy czym romb
jest wypełniony.

Uogólnienie - Dziedziczenie

Uogólnienie tworzy hierarchię klas, od ogólnych do bardziej
szczegółowych. Pozwala wyłączyć części wspólne klas.

W modelu pojęciowym Katalog jest uogólnieniem Katalogu
rzeczowego, jeżeli każda instancja Katalogu rzeczowego jest
także instancją Katalogu. Uogólnienie w przypadku klas często
jest traktowane jako synonim dziedziczenia.

Interfejsy i klasy abstrakcyjne

Klasa abstrakcyjna

Klasa abstrakcyjna deklaruje wspólną funkcjonalność grupy klas.
Nie może posiadać obiektów i musi definiować podklasy.

Interfejs

Interfejs - klasyfikator zawierający deklaracje właściwości i metod
ale nie implementuje ich.

• Celem tworzenia klas abstrakcyjnych i interfejsów jest
identyfikacja wspólnych zachowań różnych klas, które są
realizowane w różny od siebie sposób. Użycie tych mechanizmów
pozwala na wykorzystanie relacji uogólniania do ukrywania
(hermetyzacji) szczegółów implementacji poszczególnych klas.

• Klasa abstrakcyjna reprezentuje wirtualny byt grupujący wspólną
funkcjonalność kilku klas. Posiada ona sygnatury operacji (czyli
deklaracje, że klasy tego typu będą akceptować takie komunikaty),
ale nie definiuje ich implementacji.

• Podobną rolę pełni interfejs. Różnica polega na tym, że klasa
abstrakcyjna może posiadać implementacje niektórych operacji,
natomiast interfejs jest czysto abstrakcyjny (choć, oczywiście
interfejs i klasa w pełni abstrakcyjna są pojęciowo niemal
identyczne).

• Ponieważ klasy abstrakcyjne nie mogą bezpośrednio tworzyć
swoich instancji (podobnie jak interfejsy, które z definicji nie
reprezentują klas,
a jedynie ich typy) dlatego konieczne jest tworzenie ich podklas,
które zaimplementują odziedziczone abstrakcyjne metody. W
przypadku interfejsu sytuacja jest identyczna.

• Przyjętym sposobem oznaczania klas i metod abstrakcyjnych
jest zapisywanie ich pochyłą czcionką lub opatrywanie słowem
kluczowym {abstract}.

Szablony klas

Szablon klasy określa, z jakimi innymi klasami (nie
obiektami) może współpracować podana klasa. Klasy te są
przekazywane jako jej parametry. Klasa będąca
uszczegółowieniem takiej klasy jest klasą związaną.

Diagram obiektów - Object

diagram

• przedstawia egzemplarze elementów z diagramu klas

• obrazuje zbiór obiektów i ich związków w danej chwili

• często nazywany jest diagramem instancji (przedstawia
instancje klas a nie same klasy)

• zawiera na ogół: obiekty, wiązania, notatki, ograniczenia,
pakiety, podsystemy, klasy

Na diagramie obiektów przedstawia się obiekty, czyli
konkretne instancje klas i związki między nimi. Diagram ten
wyobraża statyczny rzut pewnych egzemplarzy elementów
występujących na diagramie klas. Podobnie jak diagram klas,
odnosi się do statycznych aspektów perspektywy projektowej
lub procesowej. Korzystając z niego bierze się jednak pod
uwagę przypadki rzeczywiste lub prototypowe.

Diagram aktywności

(czynności) - activity diagram

W języku UML służy do modelowania czynności i zakresu
odpowiedzialności elementów bądź użytkowników systemu. Jest
niejako podobny do diagramu stanu, jednak w odróżnieniu od
niego nie opisuje działań związanych z jednym obiektem a
wieloma, pomiędzy którymi może występować komunikacja
przy wykonywaniu czynności.

Cechy:

•

pokazuje aktywności bez pokazywania bytów, realizujących

daną aktywność i dlatego z reguły używane są jako punkt
startowy dla procesu modelowania zachowań

• diagramy aktywności z zasady nie pokazują wszystkich
szczegółów przetwarzania

• dla skompletowania projektu każda aktywność powinna być
rozpisana na szereg operacji (akcji), z których każdą trzeba
będzie na późniejszym etapie przydzielić do odpowiedniej klasy

Czynność może być interpretowana różnie, w zależności od
perspektywy: jako zadanie do wykonania i to zarówno przez
człowieka, jak i przez komputer (z perspektywy pojęciowej)
czy też np. jako pojedyncza metoda (z perspektywy
projektowej).

Podobnie, przejścia między stanami raczej nie są tu związane
z nadejściem zdarzenia, ale z zakończeniem przetwarzania
wyspecyfikowanego dla danego stanu.

Akcje są już niepodzielne, trwanie ich nie podlega
przerwaniu.

NOTACJA

Aktywność/Czynność - rodzaj zachowania, składającego się
z przynajmniej jednej akcji.

Akcja reprezentuje wykonanie pojedynczej operacji, której nie
można rozbić na mniejsze jednostki na diagramie. Na przykład
akcjami mogą być funkcje matematyczne.

Akcje i aktywności reprezentowane są identycznie, jako:

Decyzje

Wyjście decyzji stanowią dwa lub więcej przepływów, z
których tylko jeden może być zrealizowany.

1. Warunek logiczny - różne warunki
muszą się wykluczać, aby zapewnić
jednoznaczny przepływ sterowania

2. Rozgałęzienie (decyzja)

Ścieżki współbieżne

Rozwidlenie - fork

Akcje współbieżne

Scalenie sterowania - join

Złączenia

Każdy przypływ sterowania docierający do wejścia inicjuje proces
wyjściowy

Proces wyjściowy jest inicjalizowany dopiero po dotarciu znaczników
od wszystkich przypływów - synchronizacja

Diagram sekwencji (przebiegu)

-

sequence diagrams

Obrazuje kolejność w czasie wysyłania komunikatów pomiędzy
różnymi obiektami w systemie

Diagramy sekwencji intuicyjnie prezentują kolejność wywołań
operacji, przepływ sterowania pomiędzy obiektami oraz
szablon realizowanego algorytmu. Pomijają natomiast
całkowicie aspekt dostępu i operacji na danych, związany z
komunikacją.

• Uczestnikami diagramów sekwencji są obiekty, opisane
nazwą obiektu i jego klasą, które wymieniają między sobą
komunikaty.

• Diagram sekwencji jest zapisany w prostokącie oznaczonym
operatorem sd i składa się z pionowych linii życia (ang.
lifelines) poszczególnych obiektów uczestniczących w
interakcji oraz wymienianych między nimi komunikatów
(wywołań operacji). Białe prostokąty umieszczone na linii życia
obiektu oznaczają, że obiekt jest zajęty wykonywaniem
pewnej czynności (natomiast nie mają bezpośredniego
związku z istnieniem obiektu).

• Czas jest reprezentowany w postaci pionowej osi
diagramu. Linia życia obiektu to czas, w którym konkretna
instancja obiektu jest w stanie przyjmować komunikaty i
wysyłać je. Innymi słowy, obejmuje ona czas istnienia
obiektu w systemie.

• Obiekt jest tworzony poprzez wysłanie do niego
komunikatu -konstruktora, natomiast niekoniecznie jest
fizycznie usuwany na końcu linii życia, raczej przestaje być
istotny. Fizycznie usunięcie obiektu można wprost oznaczyć
jako znak X na linii życia.

Rodzaje komunikatów

wywołanie procedury

powrót z wywołania

wywołanie asynchroniczne

komunikat tworzenia
uczestnika

komunikat usuwania
uczestnika

Diagram komunikacji -

kooperacji

Diagram komunikacji jest jednym z diagramów interakcji.
Diagram komunikacji przedstawia sposób wymiany
komunikatów pomiędzy obiektami uczestniczącymi w
interakcji.

Diagramy czasowe -

harmonogramowanie interakcji

Diagram harmonogramowania jest rodzajem diagramu
interakcji, reprezentującym na osi czasu zmiany
dopuszczalnych stanów, jakie może przyjmować instancja
klasyfikatora uczestnicząca w interakcji.

Diagramy harmonogramowania dokumentują aspekt czasu
interakcji. Na osi poziomej zaznacza się skalę czasu w
postaci ustalonych odcinków. Natomiast na osi pionowej
przedstawia się poszczególne instancje klasyfikatorów
biorące udział w interakcji, a przy każdej
z nich jej stany. Z zasady diagramy harmonogramowania
tworzy się po opracowaniu diagramów sekwencji lub
komunikacji.

Diagram komponentów -

(component diagram)

• Diagramy komponentów pokazują podział systemów
programowych na mniejsze podsystemy.

• Komponent to wymienialny, wykonywalny fragment
systemu, z ukrytymi szczegółami implementacyjnymi (np. plik
.dll, podprogram).

• Komponent udostępnia zestaw interfejsów, może też
wymagać pewnych interfejsów do funkcjonowania.

• Komponenty z natury służą do ponownego wykorzystania
poprzez połączenie ich z innymi komponentami, zwykle
poprzez ich skonfigurowanie, bez potrzeby rekompilacji.

• Diagram komponentów służy do pokazania związków
pomiędzy komponentami i interfejsami.

Diagram struktur złożonych

Diagram struktur złożonych pokazuje związki istniejące pomiędzy
częściami systemu, które współpracując dostarczają pewnej
funkcjonalności.

Diagramy struktur złożonych mogą zawierać:
struktury - zespoły powiązanych elementów
konektory - łącza komunikacyjne (ich typ nie jest określony)