M.Okoniewski 2002

Projektowanie systemów

informatycznych

Cz. 4

UML

M.Okoniewski 2002

UML

• Unified (universal) Modelling Language
• Porozumienie twórców

najpopularniejszych metodyk

• Ivar Jacobson, Grady Booch, James

Rumbaugh

• Rational.com
• Rational Rose - uniwersalne narzedzie

CASE

M.Okoniewski 2002

Obiektowość - podstawy

• Definiowanie klas - będących

enkapsulacją (opakowaniem) danych i
metod na nich operujących

• Klasa : samochód
• Dane: nr rejestracyjny, ilość paliwa,

ciśnienie w oponach

• Metody: pokaż dane rejestracyjne,

zatankuj do pełna, napompuj koła

M.Okoniewski 2002

Obiektowość - podstawy

• Powoływanie instancji klas (obiektów)

• Obiekt : Skoda ZNA 6362 - instancja klasy

Samochód

• Dziedziczenie

• Klasa Ciężarówka dziedziczy z klasy Samochód

• Polimorfizm - możliwość dziedziczenia z wielu

klas

• Klasa SprzedażAuta dziedziczy z klas Samochód

i UmowaSprzedaży

M.Okoniewski 2002

Typy diagramów

Diagram klas - podstawowy diagram
opisujący statyczną strukturę systemu

Diagram obiektów - przedstawia
statyczną strukturę systemu w określonym
momencie

Diagram pakietów - szczególny przypadek
opisu klas - za pomocą pakietów minimalizując
zależności między nimi - max. enkapsulacji

M.Okoniewski 2002

Typy diagramów

Diagram użycia - modeluje funkcjonalność
systemu pokazując aktorów i przypadki użycia

Diagram współpracy - pokazuje zależności
między obiektami i sekwencje komunikatów
między nimi. Modeluje statyczne i dynamiczne
zachowanie systemu.

Diagram sekwencji - zależności
pomiędzy klasami i wymiana
komunikatów w czasie

M.Okoniewski 2002

Typy diagramów

Diagram komponentów - organizacja fizycznych
komponentów oprogramowania (kod, dll, exe, ...)

Diagram rozmieszczenia (deployment) -
rozmieszczenie komponentów w systemie

Diagram stanów - dynamiczne reakcje obiektów
na zdarzenia zewnętrzne

Diagram aktywności - dynamiczne
zachowanie klasy. Opis procesów
biznesowych.

M.Okoniewski 2002

Diagram klas

Klasa - składa się z nazwy, atrybutów i metod

Aktywna klasa - grubsze obramowanie
dla klas, które inicjują i kontolują działania -
a nie tylko służą do przechowywania danych

Widoczność - atrybutów i metod. Publiczne,
prywatne lub chronione. Chronione są widoczne
tylko w klasach dziedziczących

M.Okoniewski 2002

Diagram klas

Związki - jak w ER, mogą być skierowane,
i uzupełnione o opisy ról

Krotności - jak w ER, zapisywane
liczbami + gwiazdka

Ograniczenia (constraints) - między klasami
lub związkami

M.Okoniewski 2002

Diagram klas

Kompozycja - związek typu „całość - część”.
Wypełniony romb gdy zależność jest silna.
Zwykła agregacja gdy klasy mogą istnieć
oddzielnie.

W agregacji klasa „całość” widzi tylko dane i metody publiczne,
zaś w dziedziczeniu podklasa widzi także chronione.

Generalizacja - reprezentacja
dziedziczenia lub związku typu
„is a”

M.Okoniewski 2002

M.Okoniewski 2002

Diagram pakietów

Pakiety - podobnie jak w klasach
możemy dopisywać do nich atrybuty

Zależności między pakietami - gdy zmiany
w jednym pakiecie pociągają konieczność
zmian w drugim. Np. <<import>> daje pakietom
dostęp do innych

Widzialność - jak w klasach

M.Okoniewski 2002

M.Okoniewski 2002

Diagram obiektów

Obiekt - zawsze jest instancją klasy

Atrybuty - w obiektach powinny
mieć przypisaną wartość

Aktywny obiekt - kontroluje
przebieg procesu - pogrubiony

M.Okoniewski 2002

Diagram obiektów

Zwielokrotnienie obiektu - kiedy
nie są ważne indywidualne wartości
atrybutów

Połączenia - instancje związków

Połączenie do samego siebie
jest możliwe dla obiektów

M.Okoniewski 2002

Diagram użycia

Przypadek użycia - pojedyncza procedura
biznesowa czy funkcja systemu

System - można oznaczyć prostokątem.
Aktorzy są poza systemem

Aktor - użytkownicy. Jeśli aktorem jest
system, należy go oznaczyć <<actor>>

M.Okoniewski 2002

Diagram użycia

Związki - dla związków między
przypadkami użycia dopisujemy
stereotypy <<uses>>, <<extends>>

M.Okoniewski 2002

M.Okoniewski 2002

Diagram sekwencji

Rola klasy - obiekt w danym kontekście

Aktywności - reprezentują czas potrzebny
do wykonania zadania

Komunikaty - przesyłane między obiektami

M.Okoniewski 2002

Diagram sekwencji - typy

komunikatów

M.Okoniewski 2002

Diagram sekwencji

Linie życia obiektów - na nich znajdują
się aktywności

Wywołania destruktora
dla obiektów

Pętle - wraz z warunkami wyjścia
z nich

M.Okoniewski 2002

M.Okoniewski 2002

Diagram współpracy

Role klas - bez zapisu atrybutów, chodzi
tylko o opis zachowania klas

Role asocjacji - zachowanie
asocjacji, możliwe są stereotypy

Komunikaty - numerujemy je, w [] są
warunki, zaś * oznacza pętlę

M.Okoniewski 2002

M.Okoniewski 2002

Diagram stanów

Stan - sytuacja w życiu obiektu

Przekształcenie - opisywane przez
zdarzenie wyzwalające je i wyzwalaną
akcję

Stan początkowy...

...i końcowy.

Synchronizacja
i rozejście kontroli

M.Okoniewski 2002

M.Okoniewski 2002

M.Okoniewski 2002

Diagram aktywności

Aktywność - nieprzerywalna czynność
obiektu

Przepływy (action flow) - zależności
między aktywnościami.

Przepływy obiektowe - wpływ
aktywności na obiekty - strzałki
mogą być w obie strony

Stan początkowy...

...i końcowy.

M.Okoniewski 2002

Diagram aktywności

Rozgałęzienia - decyzja z podanymi
warunkami reprezentowana jest przez romb

Synchronizacja - przekaształcenia
równoległe - „fork & join”

„Tory pływackie” (swimlanes) - grupują
aktywności w kolumny

M.Okoniewski 2002

M.Okoniewski 2002

Diagram komponentów

Komponent - fizyczny blok budowy
systemu

Interfejs - pojedyncza
udostępniana operacja komponentu

Zależności między komponentami

M.Okoniewski 2002

Diagram rozmieszczenia

Węzeł - zasób fizyczny zawierający
komponenty

Połączenie - fizyczne pomiędzy
węzłami - np. sieć

Komponenty - można umieszczać
w węzłach

M.Okoniewski 2002