Modelowanie UML

Karol Grudziński

Uniwersytet Kazimierza Wielkiego i

Wyższa Szkoła Gospodarki

E-Mail: [e-mail]

<Zawiera obszerne cytaty z książek. Do użytku wewnętrznego.>

●

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