M.Okoniewski 2002
Projektowanie systemów
informatycznych
Cz. 4
UML
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