Modelowanie UML
Karol Grudziński
Uniwersytet Kazimierza Wielkiego i
Wyższa Szkoła Gospodarki
E-Mail: [e-mail]


Krótko o UML.

Narzędzia do Modelowania UML.

Co nowego w UML 2.0?

Przegląd i diagramy UML.
1
Krótko o UML

UML (Unified Modelling Language) to
graficzny język do obrazownia, specyfikowania
i dokumentowania elementów systemów
informatycznych. Umożliwia standaryzację
sposobu opracowania przekrojów systemu,
obejmujących obiekty pojęciowe, takie jak
procesy przedsiębiorstwa i funkcje systemowe,
a także obiekty konkretne, takie jak klasy
zaprogramowane w konkretnym języku,
schematy baz danych i komponenty
programowe nadające się do ponownego
użycia. 2
Narzędzia do Modelowania UML

`Together [Community Edtion]' Borlanda
(Java)

'Umbrello'. (Linux, KDE-Cygwin: Windows)

Poseidon [Community Edition]: (Java)

gModeler (online przez WWW)

Pluginy do Środowisk wielo-językowych IDE
Eclipse i NetBeans (cross-platform) (głównie
Java)

Więcej na
http://plg.uwaterloo.ca/~migod/uml.html
3
Together Designer Community Edition
4
KDE-Cygwin i Umbrello UML Modeller
5
Co nowego w UML 2.0?

Activity Diagram (zupełnie nowy diagram, jest
kombinacją data and object flow diagram)

Deployment Diagram (zupełnie nowy diagram)

Statechart Diagram (pozwala modelować zachowanie
systemu)

Component Diagram (pozwala modelować system
softwareowy o dowolnym stopniu kompilkacji i jego
komponnty)

Class diagram (modelowanie klas, ich usług (interfejsów)
i ich instancji)

Composite structure diagram (pokazuje wewnętrzną
strukturę klasyfikatora i oddziaływanie z innymi elemenami
systemu). 6
Przegląd UML

UML: język i notacja do specyfikowania,
wizualizowania i dokumentowania modeli systemów
obiektowych.

UML nie jest narzędziem rozwojowym, więc nie
dostarcza informacji co zrobić najpierw a co potem ale
pomaga zwizualizować projekt i komunikować się z
innymi użytkownikami/projektantami.

UML jest kontrolowany przez OMG (Object
Management Group) i jest standardem przemysłowym
dla graficznej reprezentacji oprogramowania.

UML jest dostosowany do systemów
obiektowych/komponentowych i ma ograniczone
zastosowania w innym (starszym) typie
oprogramowania.
7
Diagramy UML

UML składa się z wielu elementów składających się na model
systemu softwareowego (składa się z diagramów do
reprezentowania różnych części systemu lub sposobu patrzenia
na system).

Niektóre Diagramy (wspierane przez umbrello 1.2):

Use Case Diagrams

Classes Diagrams

Sequence Diagrams

Collaboration Diagrams

State Diagrams

Activity Diagrams

Component Diagrams
Deployment Diagrams 8
Use Case Diagrams (Przypadki
Użycia)
9
Diagramy Przypadków Użycia

Diagramy Przypadków użycia ilustrują zależności i relacje
pomiędzy grupą przypadków użycia (use cases) a użytkownikami
systemu (aktorami  actors).

Te diagramy nie reprezentują projektu ani szczegółów systemu.

Te diagramy mają na celu zilustrować komunikację między
przyszłymi użytkownikami systemu i klientami i są bardzo
przydatne do określenia jakie cechy system powinien mieć.

Przypadki użycia mówią co system powinien zapewniać i robić
ale nie pokazują (i nie mogą) jak dane cechy zrealizować.

Diagramy Przypadków Użycia składają się z:

1) Przypadków Użycia

2) Aktorów

3) Opisów przypadków użycia. 10
Przypadek Użycia

Przypadek użycia, z punktu widzenia aktorów, reprezentuje
grupę czynności prowadzących do wymiernego rezultatu
(efektu).

Przypadki użycia reprezentują typowe interakcje użytkowników
systemu z samym systemem.

Stanowią zewnętrzny interfejs systemu i określają co system
powinien zapewniać (robić) ale nie jak to robić.

Reguły

1) Każdy przypadek użycia jest powiązany z co najmniej
jednym aktorem.

2) Każdy przypadek użycia ma swojego inicjatora, który jest
aktorem.

3) Każdy przypadek użycia prowadzi do pewnego rezultatu (o
określonej wartości biznesowej). 11
Aktor i Opis Przypadku Użycia

Aktor to zewnętrzna jednostka (z poza systemu), która
oddziałuje z systemem, uczestnicząc w przypadku użycia i
często go początkując.

Aktorami mogą być ludzie (użytkownicy), zewnętrzne
systemy komputerowe lub zewnętrzne zdarzenia.

Aktorzy nie reprezentują fizycznych, konkretnych
użytkowników czy systemów lecz ich rolę. Dlatego, jeśli jedna
fizyczna osoba będzie spełniała w systemie różne role, to
będzie reprezentowana przez wielu różnych aktorów.

Opis przypadku użycia to tekstowa notatka dokumentująca
czynności mające miejsce w Przypadku Użycia. 12
Diagramy Klas

Diagramy klas ilustrują klasy składające się na system i
powiązania miedzy nimi.

Diagramy klasowe zwane są diagramami 'statycznymi' jako, że
pokazują klasy, metody i atrybuty jak i statyczne powiązania
między klasami (tj. które klasy wiedzą o których lub są ich
częściami) lecz nie są zilustrowane wywołania metod pomiędzy
klasami.

Na diagramy klas składają się

Klasy

Atrybuty

Operacje (Metody)

Wzorce (Szablony)

Powiązania między klasami 13
Przykładowy Diagram Klasowy
14
Klasy

Klasy definiują atrybuty (zmienne) i metody
grupy obiektów. Obiekty są instancjami klas, tj.
mają te same metody i własny zestaw
atrybutów czyli mają wspólne zachowanie
narzucone przez klasę.

Termin Typ jest często stosowany zamiennie z
klasą ale typ jest zasadniczo terminem bardziej
ogólnym.

Klasy są reprezentowane przez prostokąty
zawierające nazwę klasy oraz atrybuty i metody
(funkcje, operacje na atrybutach), które
stanowią dwa pod-prostokąty zawarte w klasie.
15
Przykładowa Klasa
16
Atrybuty i Metody

Atrybuty (zmienne klasowe) są w UML reprezentowane
przynajmniej przez nazwę, ale często też przez typ, wartość
początkową i widoczność (zasięg).

Metody to funkcje (operacje) klasowe operujące na danych
klasy. Są w UML reprezentowane przez nazwę jak i zasięg,
argumenty i zwracaną wartość.

Zasięg:

+ - atrybuty/metody publiczne (public).

# - atrybuty/metody chronione (protected).

- - atrybuty/metody prywatne (private). 17
Wzorce (Szablony)

Klasy mogą być parametryzowane typem (np.
macierz lub wektor liczb całkowitych,
rzeczywistych). Wzorce/Szablony (Templates)
są w C++ już od dłuższego czasu i pojawiły się
też w Javie (po raz pierwszy w Java 1.5), gdzie
nazywane są Generics.

Ustalanie typu zparemetryzowanej klasy
nazywamy jej konkretyzowaniem. Ma to
miejsce podczas tworzenia instancji klasy czyli
obiektu. 18
Powiązania między klasami

Generalizacja. Dziedzicznie jest jednym z
fundamentalnych pojęć programowania obiektowego.
Klasa może zdobyć (odziedziczyć) po klasie bazowej
wszystkie metody i atrybuty, i przesłonić/przeciążyć je
oraz można dodać nową funkcjonalność w postaci
nowych atrybutów i metod. W UML do reprezentacji
dziedziczenia stosuje się powiązanie zwane właśnie
generalizacją.
19
Powiązania między klasami

Asocjacja reprezentuje takie powiązanie między
klasami, które nakłada wspólną strukturę i semantykę
na połączenia między obiektami powiązanych klas.
Asocjacja umożliwia komunikację miedzy obiektami
różnych klas. Konkretne połączenie między obiektami
nazywa się dowiązaniem (link). Asocjacja może być
jedno lub dwu kierunkowa (czyli określa się czy obiekty
wiedzą o sobie nawzajem czy nie). Na końcu
połączenia podaje się (ilustruje) wartość ile obiektów z
każdej ze stron jest związanych z jednym obiektem z
drugiej ze stron.
20
Modelowanie UML
Karol Grudziński
Uniwersytet Kazimierza Wielkiego i
Wyższa Szkoła Gospodarki
E-Mail: [e-mail]

Krótko o UML.

Narzędzia do Modelowania UML.

Co nowego w UML 2.0?

Przegląd i diagramy UML.
21
Krótko o UML

UML (Unified Modelling Language) to
graficzny język do obrazownia, specyfikowania
i dokumentowania elementów systemów
informatycznych. Umożliwia standaryzację
sposobu opracowania przekrojów systemu,
obejmujących obiekty pojęciowe, takie jak
procesy przedsiębiorstwa i funkcje systemowe,
a także obiekty konkretne, takie jak klasy
zaprogramowane w konkretnym języku,
schematy baz danych i komponenty
programowe nadające się do ponownego
użycia. 22
Narzędzia do Modelowania UML

`Together [Community Edtion]' Borlanda
(Java)

'Umbrello'. (Linux, KDE-Cygwin: Windows)

Poseidon [Community Edition]: (Java)

gModeler (online przez WWW)

Pluginy do Środowisk wielo-językowych IDE
Eclipse i NetBeans (cross-platform) (głównie
Java)

Więcej na
http://plg.uwaterloo.ca/~migod/uml.html
23
Together Designer Community Edition
24
KDE-Cygwin i Umbrello UML Modeller
25
Co nowego w UML 2.0?

Activity Diagram (zupełnie nowy diagram, jest
kombinacją data and object flow diagram)

Deployment Diagram (zupełnie nowy diagram)

Statechart Diagram (pozwala modelować zachowanie
systemu)

Component Diagram (pozwala modelować system
softwareowy o dowolnym stopniu kompilkacji i jego
komponnty)

Class diagram (modelowanie klas, ich usług (interfejsów)
i ich instancji)

Composite structure diagram (pokazuje wewnętrzną
strukturę klasyfikatora i oddziaływanie z innymi elemenami
systemu). 26
Przegląd UML

UML: język i notacja do specyfikowania,
wizualizowania i dokumentowania modeli systemów
obiektowych.

UML nie jest narzędziem rozwojowym, więc nie
dostarcza informacji co zrobić najpierw a co potem ale
pomaga zwizualizować projekt i komunikować się z
innymi użytkownikami/projektantami.

UML jest kontrolowany przez OMG (Object
Management Group) i jest standardem przemysłowym
dla graficznej reprezentacji oprogramowania.

UML jest dostosowany do systemów
obiektowych/komponentowych i ma ograniczone
zastosowania w innym (starszym) typie
oprogramowania.
27
Diagramy UML

UML składa się z wielu elementów składających się na model
systemu softwareowego (składa się z diagramów do
reprezentowania różnych części systemu lub sposobu patrzenia
na system).

Niektóre Diagramy (wspierane przez umbrello 1.2):

Use Case Diagrams

Classes Diagrams

Sequence Diagrams

Collaboration Diagrams

State Diagrams

Activity Diagrams

Component Diagrams
Deployment Diagrams 28
Use Case Diagrams (Przypadki
Użycia)
29
Diagramy Przypadków Użycia

Diagramy Przypadków użycia ilustrują zależności i relacje
pomiędzy grupą przypadków użycia (use cases) a użytkownikami
systemu (aktorami  actors).

Te diagramy nie reprezentują projektu ani szczegółów systemu.

Te diagramy mają na celu zilustrować komunikację między
przyszłymi użytkownikami systemu i klientami i są bardzo
przydatne do określenia jakie cechy system powinien mieć.

Przypadki użycia mówią co system powinien zapewniać i robić
ale nie pokazują (i nie mogą) jak dane cechy zrealizować.

Diagramy Przypadków Użycia składają się z:

1) Przypadków Użycia

2) Aktorów

3) Opisów przypadków użycia. 30
Przypadek Użycia

Przypadek użycia, z punktu widzenia aktorów, reprezentuje
grupę czynności prowadzących do wymiernego rezultatu
(efektu).

Przypadki użycia reprezentują typowe interakcje użytkowników
systemu z samym systemem.

Stanowią zewnętrzny interfejs systemu i określają co system
powinien zapewniać (robić) ale nie jak to robić.

Reguły

1) Każdy przypadek użycia jest powiązany z co najmniej
jednym aktorem.

2) Każdy przypadek użycia ma swojego inicjatora, który jest
aktorem.

3) Każdy przypadek użycia prowadzi do pewnego rezultatu (o
określonej wartości biznesowej). 31
Aktor i Opis Przypadku Użycia

Aktor to zewnętrzna jednostka (z poza systemu), która
oddziałuje z systemem, uczestnicząc w przypadku użycia i
często go początkując.

Aktorami mogą być ludzie (użytkownicy), zewnętrzne
systemy komputerowe lub zewnętrzne zdarzenia.

Aktorzy nie reprezentują fizycznych, konkretnych
użytkowników czy systemów lecz ich rolę. Dlatego, jeśli jedna
fizyczna osoba będzie spełniała w systemie różne role, to
będzie reprezentowana przez wielu różnych aktorów.

Opis przypadku użycia to tekstowa notatka dokumentująca
czynności mające miejsce w Przypadku Użycia. 32
Diagramy Klas

Diagramy klas ilustrują klasy składające się na system i
powiązania miedzy nimi.

Diagramy klasowe zwane są diagramami 'statycznymi' jako, że
pokazują klasy, metody i atrybuty jak i statyczne powiązania
między klasami (tj. które klasy wiedzą o których lub są ich
częściami) lecz nie są zilustrowane wywołania metod pomiędzy
klasami.

Na diagramy klas składają się

Klasy

Atrybuty

Operacje (Metody)

Wzorce (Szablony)

Powiązania między klasami 33
Przykładowy Diagram Klasowy
34
Klasy

Klasy definiują atrybuty (zmienne) i metody
grupy obiektów. Obiekty są instancjami klas, tj.
mają te same metody i własny zestaw
atrybutów czyli mają wspólne zachowanie
narzucone przez klasę.

Termin Typ jest często stosowany zamiennie z
klasą ale typ jest zasadniczo terminem bardziej
ogólnym.

Klasy są reprezentowane przez prostokąty
zawierające nazwę klasy oraz atrybuty i metody
(funkcje, operacje na atrybutach), które
stanowią dwa pod-prostokąty zawarte w klasie.
35
Przykładowa Klasa
36
Atrybuty i Metody

Atrybuty (zmienne klasowe) są w UML reprezentowane
przynajmniej przez nazwę, ale często też przez typ, wartość
początkową i widoczność (zasięg).

Metody to funkcje (operacje) klasowe operujące na danych
klasy. Są w UML reprezentowane przez nazwę jak i zasięg,
argumenty i zwracaną wartość.

Zasięg:

+ - atrybuty/metody publiczne (public).

# - atrybuty/metody chronione (protected).

- - atrybuty/metody prywatne (private). 37
Wzorce (Szablony)

Klasy mogą być parametryzowane typem (np.
macierz lub wektor liczb całkowitych,
rzeczywistych). Wzorce/Szablony (Templates)
są w C++ już od dłuższego czasu i pojawiły się
też w Javie (po raz pierwszy w Java 1.5), gdzie
nazywane są Generics.

Ustalanie typu zparemetryzowanej klasy
nazywamy jej konkretyzowaniem. Ma to
miejsce podczas tworzenia instancji klasy czyli
obiektu. 38
Powiązania między klasami

Generalizacja. Dziedzicznie jest jednym z
fundamentalnych pojęć programowania obiektowego.
Klasa może zdobyć (odziedziczyć) po klasie bazowej
wszystkie metody i atrybuty, i przesłonić/przeciążyć je
oraz można dodać nową funkcjonalność w postaci
nowych atrybutów i metod. W UML do reprezentacji
dziedziczenia stosuje się powiązanie zwane właśnie
generalizacją.
39
Powiązania między klasami

Asocjacja reprezentuje takie powiązanie między
klasami, które nakłada wspólną strukturę i semantykę
na połączenia między obiektami powiązanych klas.
Asocjacja umożliwia komunikację miedzy obiektami
różnych klas. Konkretne połączenie między obiektami
nazywa się dowiązaniem (link). Asocjacja może być
jedno lub dwu kierunkowa (czyli określa się czy obiekty
wiedzą o sobie nawzajem czy nie). Na końcu
połączenia podaje się (ilustruje) wartość ile obiektów z
każdej ze stron jest związanych z jednym obiektem z
drugiej ze stron.
40