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)