Projektowanie systemów informatycznych
Projektowanie systemów informatycznych
Metody obiektowe
Język UML
Język UML
Unified Modeling Language
Unified Modeling Language
Język UML powstał z połączenia trzech notacji i został
nazwany ujednoliconym językiem modelowania.
Może znalez
ć zastosowanie zarówno na etapie zamawiania
oprogramowania, jak i podczas szczegółowego
projektowania struktury oraz interakcji składników kodu
systemu i zyskuje przez to powszechne uznanie.
Jest zasadniczym elementem opracowanego przez OMG
standardu Model-Driven Architecture (MDA), który ma na
celu określenie metod tworzenia oprogramowania opartego
na modelach i sterowaniu nimi.
Michał Śmiałek,  Zrozumieć UML 2.0 Metody modelowania
obiektowego , Wyd. Helion, Gliwice 2005
Język UML

Język UML przyjmuje w praktyce postać graficznej
reprezentacji tworzonego systemu, składającej się z
logicznie powiązanych ze sobą diagramów.

Pozwalają one na opisanie systemu od modeli
ogólnych do bardzo szczegółowych.

W standardzie UML w wersji 2.0 występuje
trzynaście rodzajów diagramów, które
charakteryzują statystykę i dynamikę tworzonego
systemu.

Klasyfikację diagramów UML przedstawia następny
slajd..
Diagram UML 2.0
Diagramy w języku UML 2.0
Diagram struktury
Diagram dynamiki
Diagram
Diagram klas
przypadków
Diagram
użycia
Diagram
obiektów
czynności
Diagram
Diagram
Diagram
pakietów struktur
maszyny
połączonych
stanowej
Diagram wdrożeniowy
Diagram interakcji
Diagram
sekwencji
Diagram Diagram
Diagram
komponentów rozlokowania
komunikacji
Stanisław Wrycza, Bartosz Marcinkowski,
Diagram
Krzysztof Wyrzykowski, Język UML 2.0
harmonogramowania
w modelowaniu systemów
Diagram sterowania
informatycznych, Helion, Gliwice 2005
interakcją
Język UML

Na poprzednim slajdzie występują kategorie
diagramów abstrakcyjnych i konkretnych.

Diagramy abstrakcyjne są nazwami uogólniającymi
grupy diagramów konkretnych:

diagramy struktury,

diagramu dynamiki,

diagramy interakcji,

diagramy wdrożenia.
Język UML
Diagramy konkretne stanowią standard języka UML 2.0, są to:

diagram klas,

diagram obiektów,

diagram pakietów,

diagram struktur połączonych,

diagram komponentów,

diagram rozlokowania,

diagram przypadków użycia,

diagram czynności,

diagram maszyny stanowej,

diagram sekwencji,

diagram komunikacji,

diagram harmonogramowania,

diagram sterowania interakcją.
Język UML

Diagram klas (ang. Class Diagram) to graficzne
przedstawienie statystycznych, deklaratywnych
elementów dziedziny przedmiotowej oraz związków
między nimi.

Diagram obiektów (ang. Object Diagram) to
wystąpienie diagramu klas, odwzorowujące strukturę
systemu w wybranym momencie jego działania.

Diagram pakietów (ang. Package Diagram) to
graficzne przedstawienie logicznej struktury systemu
w postaci zestawu pakietów połączonych
zależnościami i zagnieżdżeniami.
Język UML

Diagram struktur połączonych (ang. Composite
Structure Diagram) to graficzne przedstawienie
wzajemnie współdziałających części dla osiągnięcia
pożądanej funkcjonalności współdziałania.

Diagram komponentów (ang. Component Diagram)
to rodzaj diagramu wdrożeniowego, który wskazuje
organizację i zależności między komponentami.

Diagram rozlokowania (ang. Deployment Diagram)
to rodzaj diagramu wdrożeniowego, który
przedstawia sieć połączonych ścieżkami
komunikowania węzłów z ulokowanymi na nich
artefaktami.
Język UML

Diagram przypadków użycia (ang. Use Case
Diagram) to graficzne przedstawienie przypadków
użycia, aktorów oraz związków między nimi,
występujących w danej dziedzinie przedmiotowej.

Diagram czynności (ang. Activity Diagram) to
graficzne przedstawienie sekwencyjnych i (lub)
współbieżnych przepływów sterowania oraz danych
pomiędzy uporządkowanymi ciągami czynności,
akcji i obiektów.

Diagram maszyny stanowej (ang. Stade Machine
Diagram) to graficzne odzwierciedlenie dyskretnego,
skokowego zachowania skończonych systemów
stan-przejście.
Język UML

Diagram sekwencji (ang. Sequence Diagram) jest rodzajem
diagramu interakcji, opisującym interakcje pomiędzy
instancjami klasyfikatorów systemu w postaci sekwencji
komunikatów wymienianych między nimi.

Diagram komunikacji (ang. Communication Diagram) jest
rodzajem diagramu interakcji, specyfikującym strukturalne
związki pomiędzy instancjami klasyfikatorów biorącymi
udział w interakcji oraz wymianę komunikatów pomiędzy
tymi instancjami.

Diagram harmonogramowania (ang. Timing Diagram) jest
rodzajem diagramu interakcji, reprezentującym na osi czasu
zmiany dopuszczalnych stanów, jakie może przyjmować
instancja klasyfikatora uczestnicząca w interakcji.
Język UML

Diagram sterowania interakcją (ang. Interaction
Overview Diagram) jest rodzajem diagramu
interakcji, dokumentującym przepływ sterowania
pomiędzy logicznie powiązanymi diagramami i
fragmentami interakcji z wykorzystaniem kategorii
modelowania diagramów czynności.
[Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język
UML 2.0 w modelowaniu systemów informatycznych, Wyd. Helion,
Gliwice 2005]
Diagram przypadków użycia
Diagram przypadków użycia to graficzne
przedstawienie przypadków użycia, aktorów oraz
związków między nimi, występujących w danej
dziedzinie przedmiotowej.
Diagramy przypadków użycia przedstawiają usługi
systemu świadczone aktorom, bez wskazywania
konkretnych rozwiązań technicznych.
Diagram przypadków użycia
Stosowanie diagramów przypadków użycia w
dokumentacji wymagań spełnia następujące zadania:

umożliwia analizę obszaru zastosowań, dziedziny
przedmiotowej,

pozwala na opracowanie przyszłego projektu systemu,

stanowi przystępną i zrozumiałą platformę komunikacji i
współpracy udziałowców systemu  aktorów, twórców
systemu, inwestorów, właścicieli,

są rodzajem umowy, kontraktu pomiędzy udziałowcami,
co do zakresu i funkcjonalności przyszłego systemu,

stanowi podstawę testowania systemu na dalszych
etapach jego cyklu życia.
Projektowanie systemów informatycznych
Projektowanie systemów informatycznych
Metody obiektowe
Diagram przypadków użycia
Diagram przypadków użycia
Główne techniki modelowania obiektowego
Główne techniki modelowania obiektowego
Diagram klas Diagram sekwencji
Obiekty i powiązania
(czynności)
między nimi
Kolejność przesyłanych komunikatów
Diagram przypadków użycia
Funkcje systemu
z punktu widzenia użytkowników
Główne techniki modelowania obiektowego
Główne techniki modelowania obiektowego
Diagram klas Diagram sekwencji
(czynności)
Diagram przypadków użycia
Definicja

Reprezentacja systemu lub podsystemu,
Reprezentacja systemu lub podsystemu,
pokazująca funkcje realizowane przez system z
pokazująca funkcje realizowane przez system z
punktu widzenia użytkownika
punktu widzenia użytkownika

Ang.: Use Case Diagram
Ang.: Use Case Diagram

Jest odpowiednikiem diagramu przepływu
Jest odpowiednikiem diagramu przepływu
danych w modelowaniu strukturalnym
danych w modelowaniu strukturalnym

Nie pokazuje technologii przetwarzania danych
Nie pokazuje technologii przetwarzania danych
Przykład
Obsługa zamówień
Złóż Dostarcz
zamówienie przesyłki
Dostawca
Klient
Zwróć towar
Przyślij nam
Sprawdz
stan
towar
zamówienia
Firma kurierska
Anuluj
zamówienie
Oblicz koszt
Przedstawiciel
przesyłki
Handlowy
Dostarcz
katalog
Pracownik
Symbole podstawowe
Przypadek użycia
Aktor
System Powiązanie
Symbole: Aktor

Dowolny byt będący w interakcji z systemem, np.
człowiek, inny program, sprzęt elektroniczny,
składnica danych, sieć komputerowa, firma,
jednostka organizacyjna

Leży poza systemem

Aktor pełni określoną rolę w systemie:

osoba może być reprezentowana przez wielu aktorów
(wiele ról)

wiele osób może być reprezentowanych przez jednego
aktora (jedna rola)

~ Odpowiednik terminatora (encji zewnętrznej) na
diagramie przepływu danych
Symbole: Aktor (c.d.)

Symbole graficzne:
Xyz

Konwencje nazewnicze:

rzeczownik (może być z innymi wyrazami), np.: Klient,
Kierownik, Firma Kurierska, Bank, Dział Sprzedaży,
System Magazynowy
Symbole: Aktor (c.d.)

Identyfikacja aktorów:

Kto korzysta z systemu?

Kto instaluje system?

Kto uruchamia system?

Kto pielęgnuje system?

Kto wyłącza system?

Jakie inne systemy korzystają z tego systemu?

Kto pobiera dane z tego systemu?

Kto dostarcza dane do systemu?
Symbole: Przypadek użycia

Zespół czynności realizowanych przez system w celu
wytworzenia określonego wyniku, mającego
znaczenie dla aktora

Jest całością zadania widzianego z punktu widzenia
aktora

Zwykle obejmuje działania niezbyt odległe w czasie

Zwykle obejmują działania obsługiwane przez
jednego aktora

Zwykle jest inicjowany przez aktora

Odpowiednik procesu na diagramie przepływu
danych
Symbole: Przypadek użycia (c.d.)

Symbole graficzne:
Symbole graficzne:
Abc

Konwencje nazewnicze:
Konwencje nazewnicze

czasownik + dopełnienie:
Złóż zamówienie, Odbierz towar, Oblicz wartość
podatku, Wyślij zawiadomienie
Symbole: Przypadek użycia (c.d.)

Identyfikacja przypadków użycia:
Identyfikacja przypadków użycia

Jakich funkcji oczekuje aktor od systemu?

Którzy aktorzy tworzą nowe dane, modyfikują lub
usuwają istniejące?

Którzy aktorzy czytają zapamiętane dane?

Jak system zawiadamia aktora o zmianach w swoim
wewnętrznym stanie?

Jak system będzie powiadamiany o zewnętrznych
zdarzeniach?
Symbole: System

Pokazuje granice systemu (lub podsystemu)
obejmując przypadki użycia i pozostawiając aktorów
na zewnątrz

Jeden diagram  jeden system
Symbole: System (c.d.)

Symbole graficzne:
Abc

Konwencje nazewnicze:

rzeczownik odczasownikowy + dopełnienie:
Przyjmowanie zamówienia, Realizacja przewozu,
Zarządzanie zadaniami, Obsługa płatności

rzeczownik: Zamówienia, Płatności
Symbole: Powiązanie

Reprezentuje aktora z powiązanym przypadkiem
użycia

Pokazuje, jaki aktor bierze udział przy realizacji
danego przypadku użycia

Nie ma nazwy (podpisu)
Symbole: Powiązanie (c.d.)

Symbole graficzne:
Przykład  jeszcze raz
Obsługa zamówień
Złóż Dostarcz
zamówienie przesyłki
Dostawca
Klient
Zwróć towar
Przyślij nam
Sprawdz
stan
towar
zamówienia
Firma kurierska
Anuluj
zamówienie
Oblicz koszt
Przedstawiciel
przesyłki
Handlowy
Dostarcz
katalog
Pracownik
Zasady

Każdy diagram ma nazwę (tytuł)

Każdy aktor, przypadek użycia i system ma unikalną
nazwę

Nazwa każdego obiektu powinna dokładnie
odzwierciedlać jego cechy

Nazwy obiektów nie odwołują się zwykle do
konkretnych wystąpień obiektów
Zasady c.d.

Nie mogą występować aktorzy lub przypadki użycia
nie powiązane z innymi elementami

Powiązanie w formie strzałki pokazuje kierunek
przepływu danych

Diagramy zwykle nie mają początku ani końca - nie
pokazują kolejności realizowanych działań

Aktor leży poza granicami systemu  ułatwia
pokazanie jakie są granice
Dokumentowanie przypadków użycia

Opis przypadku użycia zawiera o nim szczegółowe
informacje:

Warunki wstępne  jakie warunki muszą być spełnione,
aby przypadek użycia mógł być zrealizowany

Przebieg zdarzeń  lista działań charakteryzujących
przypadek użycia

Warunki końcowe  co jest efektem realizacji przypadku
użycia

Odpowiednik specyfikacji procesu z diagramu
przepływu danych
Bardzo rozbudowany diagram
Co z tym zrobić?

Ograniczyć liczbę przypadków użycia na jednym
diagramie

Przypadki użycia ująć w pakiety (podsystemy)

Utworzyć model wielopoziomowy  hierarchiczny
(podobnie do diagramów przepływu danych)
Pakiety - podsystemy
System obsługi zamówień
Składanie Realizacja
zamówień zamówień
Przypadki użycia w pakiecie
Składanie zamówień
Składanie zamówień
Złóż
zamówienie
Sprawdz
stan
zamówienia
Dostarcz
katalog
Przedstawiciel
Klient
Anuluj
zamówienie
Handlowy
Zwróć towar
Złóż skargę
Przypadki użycia w pakiecie
Realizacja zamówień
Realizacja zamówień
Dostarcz
przesyłki
Pobierz
informacje
o towarze
Firma
Oblicz koszt System
Aktualizuj
przesyłki
kurierska
magazynowy
ilość
towaru
Wydrukuj
etykietę
Przyjmij
towar
teleadresową
od dostawców
System
Pracownik
księgowy
Obciąż konto
Uznaj konto
Dodatkowe symbole

Związek zawierania

Związek rozszerzania

Dziedziczenie
Związek zawierania

Pokazuje, że jeden przypadek użycia zawiera drugi
Anuluj
zamówienie
<>
Znajdz

Klient
zamówienie
 Anuluj zamówienie zawiera  Znajdz
zamów. -
 Znajdz
zamówienie jest częścią  Anuluj
zamówienie
Związek rozszerzania

Pokazuje, że jeden przypadek użycia w niektórych
sytuacjach może być rozszerzony przez inny
Złóż
zamówienie
<>
Podaj adres
Klient
wysyłki
 Podaj adres wys. rozszerza  Złóż zamówienie -
Czasami  Złóż zamówienie wymaga również
realizacji  Podaj adres wysyłki
Związek rozszerzania c.d.

Konieczne jest:

zdefiniowanie warunku, którego spełnienie decyduje o
rozszerzeniu przypadku użycia

miejsca rozszerzania
Złóż zamówienie
Extension Points
Nowy klient: przed
krokiem 6.
<>
(Nowy klient)
[klient pierwszy raz składa zamówienie]
Klient
Podaj adres
wysyłki
Dziedziczenie (uogólnianie)

To związek  jest rodzaju - jeden element jest
rodzajem drugiego elementu

Pomiędzy aktorami  jeden aktor odgrywa wszystkie
role drugiego aktora, może dodatkowo odgrywać
inne role

Pomiędzy przypadkami użycia  jeden przypadek
użycia jest uszczegółowioną wersją drugiego;
uszczegółowiony dziedziczy zachowanie ogólnego i
może dodawać dodatkowe zachowania
Dziedziczenie - c.d.
Złóż
zamówienie
Złóż
zamówienie
przez WWW
Złóż
zamówienie
Klient
Sprawdz
stan
przez telefon
zamówienia
Przygotuj
raport
o sprzedaży
Przedstawiciel
Handlowy
Przykład
Obsługa zamówień
Aktualizauj
Złóż
zamówienie <>
stan konta
<>
<>
<> System
Zwróć towar
Klient
Aktualizauj
<>
księgowy
<>
ilość towaru
Anuluj
<>
zamówienie <>
Pobierz
inform.
Sprawdz
stan
o towarze
System
zamówienia
Przedstawiciel
magazynowy
Przyjmij
Dostarcz
Handlowy
towar
katalog
<>
od dostawców
Złóż skargę
Przygotuj i
Pracownik
wyślij
przesyłkę
Firma kurierska
Diagramy klas
Definicja

Diagram klas odwzorowuje świat rzeczywisty
obejmując obiekty świata rzeczywistego i
powiązania między nimi

Ang.: Class Diagram

Jest rozszerzoną formą diagramu związków encji z
modelowania strukturalnego

Główne elementy diagramu:

klasa (class)

związek (association)
Przykład
Klient Zamówienie
złożenie
1 0..*
nazwa data
adres stan
Płatność
1..* 1 policzPodatek
kwota
policzSumę
jest opłacane
1
posiada
1..*
PozycjaZam Towar
ilosc waga
0..* 1
Karta Gotówka Czek
stawkaVat opis
zawiera
numer ilośćGotówki nazwa
policzWartosc getCena
dataWażności bankId
policzWagę getWaga
autoryzuj autoryzuj
Symbole

klasa

związek
Symbole: Klasa

Jest reprezentacją obiektu świata rzeczywistego

Cechy klasy:

nazwa (unikalna)

zestaw atrybutów

zestaw metod

Może implementować działanie elementów innych
diagramów:

aktora:

Samochód  Silnik, Karoseria, Hamulec

przypadku użycia:

Wyślij towar  Wysyłka, Towar, Opłata
Symbole: Klasa (c.d.)

Formy zapisu klas:
Klient
Klient
+ klient_id
+ klient_id
+ nazwa
Klient + nazwa
+ zlozZamowienie
+ zlozZamowienie
# podajAdres
# podajAdres
Klasa implementuje
osoby składające
zamówienia
Symbole: Klasa (c.d.)

Atrybuty  właściwości klasy

nazwa (polimorfizm)

typ danych

widoczność

+ publiczny (public) - wszystkie obiekty w systemie

# chroniony (protected) - obiekty z danej klasy i klas potomnych
(dziedziczących)

- prywatny (private) - obiekty z danej klasy

~ pakietowy (package) - instancje klasy z tego samego pakietu

zasięg

egzemplarzowy (instance)  odrębne wartości dla
poszczególnych obiektów klasy

klasyfikatorowy (classifier)  jedna wartość wspólna dla
wszystkich obiektów klasy
Symbole: Klasa (c.d.)

Metody - operacje, które klasa może wykonać lub
które na danej klasie może wykonać osoba lub
inna klasa

nazwa (unikalna w obrębie klasy i klas nadrzędnych)

mogą używać parametrów (wej., wyj.)

mogą zwracać wartość określonego typu

widoczność  jak w przypadku atrybutów

zasięg  jak w przypadku atrybutów
Symbole: Związek

Ilustruje związek znaczeniowy między klasami

Cechy związku:

nazwa (unikalna?) - nieobowiązkowa

kierunek

liczebność/udział

brak atrybutów, ale możliwe klasy powiązane
Symbole: Związek (c.d.)

Liczebność:

0..1  zero lub jeden

1  dokładnie jeden

0..*  zero lub więcej

1..*  jeden lub więcej

n  dokładnie n (n>1)

*  wiele (niezalecane)

0..n  od zera do n (n>1)

1..n  od jeden do n (n>1)

n..m  od n do m (n>1, m>1)

n..*  n lub więcej (n>1)
Klasa powiązana
Przykład
0..* 1..*
Kandydat Kierunek
Zdawanie
Dodatkowe symbole

Zależność

Agregacja

Kompozycja

Dziedziczenie
Symbole: Zależność

Pokazuje, że zachowanie jednej klasy wpływa na
zachowanie innej

Nie pokazuje powiązania między danymi (na
zasadzie relacji w bazie danych)

Symbol
Symbole: Agregacja

Pokazuje, że dana klasa składa się z innych  obiekty
jednej klasy zawierają obiekty innej klasy, np.:

drużyna  zawodnik

grupa  student
Drużyna Zawodnik
Symbole: Kompozycja

Silniejsza odmiana agregacji:

jeden komponent może należeć tylko do jednej całości

czas życia komponentu jest zdeterminowany przez czas
życia całości:

tylko całość może utworzyć nową część

jeśli całość zostanie zniszczona, niszczone są wszystkie jej
części

Przykład

biurko  blat

klawiatura - przycisk
Biurko Blat
Agregacja i Kompozycja
Przykład
Symbole: Dziedziczenie

Pokazuje, że dana klasa zachowuje się podobnie do
innej i posiada dodatkowe cechy (atrybuty i metody)

Przykład:

zwierzę  ssak  kot

osoba  student
Zwierzę
Ssak
Przykład  jeszcze raz
Klient Zamówienie
złożenie
1 0..*
nazwa data
adres stan
Płatność
1..* 1 policzPodatek
kwota
policzSumę
jest opłacane
1
posiada
1..*
PozycjaZam Towar
ilosc waga
0..* 1
Karta Gotówka Czek
stawkaVat opis
zawiera
numer ilośćGotówki nazwa
policzWartosc getCena
dataWażności bankId
policzWagę getWaga
autoryzuj autoryzuj
Kontekst

Istotny jest kontekst odwzorowania świata
rzeczywistego:

inaczej w odniesieniu do systemu administracji
samorządowej

inaczej w odniesieniu do przedsiębiorstwa

inaczej w odniesieniu do użytkownika domowego

...
Zasady

Atrybut opisujący klasę umieszczamy jedynie w tej
klasie

Nie umieszczamy atrybutów, których wartość
możemy wyliczyć na podstawie innych atrybutów

Atrybut powinien mieć jedną wartość

Jeśli nie jesteśmy pewni liczebności w związku,
bezpieczniej jest umieścić większą niż mniejszą

Nie pokazuj klas z dwoma blokami (częściami) 
metody czy atrybuty

Nazwy metod powinny zawierać czasownik
Zasady (c.d.)

Jeśli na liście atrybutów lub metod nie pokazano
wszystkich elementów to należy umieścić '...' dla
oznaczenia istnienia dodatkowych

Umieszczaj atrybuty/metody statyczne (static,
classifier) przed egzemplarzowymi (instance) i
oznaczaj podkreśleniem

Atrybuty i metody w kolejności malejącej
widoczności

Przy parametrach, które są obiektami  jedynie
nazwa (bez typu)

Unikaj stosowania stereotypów, które są słowami
kluczowymi w językach programowania
Zasady (c.d.)

Zawsze pokazuj liczebność

Unikaj liczebności '*'

Związki nietrwałe (not persistent  transitory)
pokazuj za pomocą zależności (dependency)

Twórz jedynie powiązania bezpośrednie

Jeśli konieczne, używaj oznaczenia kierunku czytania
nazwy związku

Jeśli istnieją dwa związki między tymi samymi
klasami, dodaj role

Umieszczaj klasy dziedziczące pod nadrzędnymi
Zasady (c.d.)

Jeśli dwie klasy dziedziczą z innej, to powinny się
różnić między sobą

Podklasa dziedziczy wszystko

Kompozycje stosuj do rzeczy fizycznych

biurko  blat (TAK)

drużyna  zawodnik (NIE)

Nie trać dużo czasu na analizowanie konieczności
zastosowania agregacji lub kompozycji
Diagramy sekwencji
Definicja

Jego celem jest pokazanie jednostek
współpracujących przy realizacji zadania oraz
komunikatów wymienianych między nimi

Inna nazwa: diagram przebiegu

Ang.: Sequence Diagram

Stanowią formę specyfikacji pojedynczego
(zazwyczaj) przypadku użycia

Zawiera wymiar czasu (oś pionowa)  czynności
realizowane póz
niej umieszczane są niżej
Elementy diagramu

Elementy diagramu:

aktor (actor)

obiekt (object)

komunikat (message)
Symbole

aktor

obiekt

komunikat
Symbole: Aktor

Repezentuje byt (osoba, organizacja, inny system,
itp.) będący w interakcji z modelowanym systemem

Oznacza to samo, co na diagramie przypadków
użycia

Symbol:
Klient
Symbole: Obiekt

Stanowi wydzieloną część systemu, pełniącą
określoną rolę w systemie

Przykładowe kategorie obiektów:

części interfejsu,

elementy struktury danych

elementy warstwy sieciowej (komunikacyjnej)

elementy modułów programowych

elementy funkcji systemu
Symbole: Obiekt (c.d.)

Możliwe jawne określenie klasy obiektu (classifier)

Opcje nazewnicze:

tylko nazwa obiektu

nazwa obiektu i klasy

tylko nazwa klasy (bez nazwy obiektu)

Każdy obiekt ma linię życia (lifeline)

Możliwe oznaczenia na linii życia:

tworzenie obiektu (create)

aktywacja (activation)

niszczenie obiektu (destroy)
Symbole: Komunikat

Ilustruje sygnał przesyłany między dwoma
elementami diagramu:

aktorem a obiektem

dwoma obiektami

Komunikat może zawierać np.:

polecenie wykonania określonej operacji

dane przesyłane do innego elementu

odpowiedz

Symbole: Komunikat (c.d.)

Rodzaje komunikatów:

prosty (niezdefiniowany)

synchroniczny

asynchroniczny

zwrotny

tworzący obiekt

niszczący obiekt

Jeśli czasy nadania i odebrania komunikatu są różne
(długi czas transmisji) to komunikat oznaczamy linią
ukośną
Poziomy szczegółowości

Możliwe jest tworzenie kilku diagramów sekwencji,
które pokazują różne poziomy szczegółowości tego
samego scenariusza:

poziom ogólny  pokazuje komunikację aktora (-ów) z
systemem

poziom szczegółowy  pokazuje, z którymi elementami
systemu komunikuje się aktor

poziom bardzo szczegółowy  pokazuje wiele
komunikatów pomiędzy elementami systemu

Możliwe jest tworzenie kilku diagramów sekwencji
w celu pokazania różnych scenariuszy realizacji
jednej operacji/funkcji
Poziomy szczegółowości
Przykład  Poziom systemu*
y
ródło: Visual Paradigm
Poziomy szczegółowości
Przykład  Poziom podsystemu*
y
ródło: Visual Paradigm
Poziomy szczegółowości
Przykład  Poziom trzeci*
y
ródło: Visual Paradigm
Zasady

Nazywaj aktorów w sposób spójny z diagramami
przypadków użycia

Nazywaj obiekty/klasy w sposób spójny z
diagramami klas

Po lewej stronie umieszczaj aktorów, którzy są
ludz
mi lub organizacjami

Po prawej stronie umieszczaj aktorów, którzy są
innymi systemami reagującymi na działanie
modelowanego systemu

Po lewej stronie umieszczaj aktorów, którzy są
systemami inicjującymi interakcję z modelowanym
Zasady (c.d.)

Aktor może mieć tę samą nazwę co klasa

Jeśli nie jest to niezbędne  nie umieszczaj
niszczenia (destroy) obiektu

Umieszczaj nazwę obiektu jeśli występuje odwołanie
do niej w komunikacie

Umieszczaj nazwę obiektu jeśli istnieje wiele
obiektów tej samej klasy

Jeśli umieszczono kilka obiektów o tej samej nazwie,
muszą pochodzić z różnych klas

Przy aktorach i obiektach/klasach umieszczaj
stereotypy informujące o warstwie systemu, w której
one działają
Zasady (c.d.)

Umieszczaj najważniejsze komunikaty (zwykle)

Jeśli komunikat jest wysyłany do obiektu/klasy,
który jest implementowany jako składnik
oprogramowania (klasa, interfejs, komponent),
nazywaj komunikat z użyciem składni języka
programowania

Jeśli komunikat wymaga przekazania parametrów,
podaj ich nazwy, a nie same typy danych

Komunikaty wychodzące od aktorów, którzy są
osobami lub organizacjami, nazywaj w sposób
opisowy (zdaniem)
Zasady (c.d.)

Komunikaty przesyłane do klas (nie obiektów)
implementowane są jako metody statyczne

Przy włączaniu innych przypadków użycia do
aktualnie modelowanego stosuj komunikaty ze
stereotypem <>

Komunikat tworzący obiekt oznaczaj stereotypem
<>

Aktywacja nie jest obowiązkowym elementem linii
życia, ale ułatwia zrozumienie diagramu  podkreśla
czas trwania danej operacji
Dziękuję za uwagę
Proszę o pytania...