Programowanie obiektowe (UML)

Komentarze

Transkrypt

Programowanie obiektowe (UML)
Programowanie
Obiektowe
Język UML
Programowanie obiektowe (UML)
Wstęp
UML (Unified Modeling Language), zunifikowany język do modelowania, jest następcą i
syntezą notacji występujących w obiektowych metodykach analizy i projektowania
systemów informatycznych, które pojawiły się w końcu lat 80-tych i na początku lat 90tych.
Jest on oparty o pojęcia obiektowości, takie jak obiekty, klasy, atrybuty, związki,
agregacje, dziedziczenie, metody i inne.
UML powstał w wyniku połączonych wysiłków trzech znanych metodologów: Grady Boocha,
Ivara Jacobsona i Jamesa Rumbaugh'a. Są oni autorami popularnych metodyk: OODA
(Booch), Objectory (Jacobson) i OMT (Rumbaugh).
UML jest zestawem pojęć oraz notacji graficznych (diagramów), które pozwalają
wszechstronnie odwzorować modelowaną dziedzinę problemu, założenia projektowanego
systemu informatycznego, oraz większość istotnych aspektów jego konstrukcji.
UML jest obecnie wspomagany przez wiele narzędzi CASE. Został on także zaakceptowany
jako przemysłowy standard przez ciało standardyzacyjne OMG rozwijające standard
CORBA.
2
Programowanie obiektowe (UML)
Diagram przypadków użycia
Przypadki użycia (use cases) były w sposób intuicyjny stosowane w tradycyjnym
projektowaniu systemów informatycznych na długo przed pojawieniem się metodyk
obiektowych.
Kariera przypadków użycia w literaturze z zakresu projektowania SI zaczęła się od
wprowadzenia dla nich specjalnej nazwy, przypisaniu tej nazwie określonego znaczenia i
rozpropagowanie tego pojęcia jako specjalnego paradygmatu projektowania.
Przypadek użycia jest to pewna nazwana lub dobrze określona interakcja pomiędzy
użytkownikiem a systemem komputerowym.
Przypadek użycia odwzorowuje pewną funkcję systemu w taki sposób, w jaki będą ją
widzieć jego przyszli użytkownicy. Dla dużych systemów o wielu złożonych i wzajemnie
powiązanych funkcjach tego rodzaju podejście ma ogromny sens. Pozwala ono zapomnieć
o strukturze/architekturze systemu i jego detalach technicznych i skoncentrować
się na zewnętrznych funkcjach systemu.
3
Programowanie obiektowe (UML)
Diagram przypadków użycia
Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej
zdrowe od podejść „technokratycznych”, ponieważ sprzyja ono punktowi widzenia, w
którym centralnym ośrodkiem zainteresowania staje się człowiek - przyszły
użytkownik systemu - a nie budowa mechanizmu systemu.
Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich niepowodzeń
było zbytnie skoncentrowanie się projektantów na detalach technicznych, z pominięciem
lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami a systemem
komputerowym.
4
Programowanie obiektowe (UML)
Diagram przypadków użycia
Podejście od strony przypadków użycia ma przede wszystkim na względzie określenie
wymagań na projektowany system.
Celem tej metody jest:
• Głębsze zrozumienie użycia systemu będącego przedmiotem procesu projektowania.
• Zwiększenie stopnia świadomości analityków i projektantów co do celów tego systemu.
• Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu.
• Weryfikacja poprawności i kompletności projektu.
• Ustalenie wszystkich strukturalnych i funkcjonalnych własności systemu.
• Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu.
• Dostarczenie podstawy do sporządzenia planu testów systemu.
5
Programowanie obiektowe (UML)
Diagram przypadków użycia
Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji
aktorów, którzy go używają. Nie włącza jakichkolwiek szczegółów, co pozwala
wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Diagram
przypadków użycia zawiera znaki graficzne oznaczające aktorów (ludziki) oraz
przypadki użycia (owale z wpisanym tekstem).
Przypadek uzycia
Aktor
Te oznaczenia połączone są liniami odwzorowującymi powiązania poszczególnych aktorów z
poszczególnymi przypadkami użycia.
Przypadek uzycia
Aktor
6
Programowanie obiektowe (UML)
Diagram przypadków użycia
Podstawowym zastosowaniem takich diagramów jest dialog z użytkownikami zmierzający
do sformułowania wymagań na system. Stąd wynika, że diagramy i opis przypadków
użycia muszą być bardzo naturalne, proste i nie mogą wprowadzać elementów
komputerowej egzotyki i żargonu.
W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy
pomocy notacji lub diagramów obiektowych.
Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich przy
pomocy notacji wprowadzanych w innych diagramach UML. Należy podkreślić, że
tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni
analitycy tworzą różne modele.
Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów
związanych w jakiś sposób z projektowanym systemem. Każdy aktor używać lub będzie
używać systemu na kilka specyficznych sposobów (przypadków użycia).
Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja lub inny
system komputerowy.
7
Programowanie obiektowe (UML)
Diagram przypadków użycia
Należy zwrócić uwagę, że metoda modeluje aktorów, a nie konkretne osoby.
Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem.
Jeden aktor może odpowiadać wielu osobom, np. urzędnik.
Aktor jest:
• pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń
powodujących uruchomienie przypadku użycia.
• odbiorcą informacji wyprodukowanych przez przypadki użycia.
Aktor reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik, np. kierownik,
urzędnik, klient. Można tworzyć aktorów abstrakcyjnych, na podobieństwo klas
abstrakcyjnych. Np. aktor „urzędnik” jest nadklasą dla aktorów „kasjer” i „dyrektor”;
powiązania z konkretnymi przypadkami użycia mogą być ustalone zgodnie z tą hierarchią
klas aktorów.
8
Programowanie obiektowe (UML)
Diagram przypadków użycia
Przypadek użycia reprezentuje:
• sekwencję operacji lub transakcji wykonywanych przez system w trakcie interakcji
z użytkownikiem; np. potwierdzenie pisma, złożenie zamówienia.
• przepływ zdarzeń w systemie i są uruchamiane (inicjowane) przez aktorów.
Przypadek użycia jest zwykle charakteryzowany przez krótką nazwę. Opis przypadku użycia
może być jednak dowolnie rozbudowany, w szczególności może zawierać następujące
fragmenty:
• Jak i kiedy przypadek użycia zaczyna się i kończy.
• Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce
i co jest przesyłane.
• Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak
i kiedy zapamiętuje dane w systemie.
• Wyjątki przy przepływie zdarzeń.
9
Programowanie obiektowe (UML)
Diagram przypadków użycia
Typowa dokumentacja przypadków użycia powinna zawierać następujące elementy:
• Krótki opis przypadku użycia.
• Przepływ zdarzeń opisany nieformalnie.
• Związki pomiędzy przypadkami użycia.
• Uczestniczące obiekty.
• Specjalne wymagania (np. czas odpowiedzi, wydajność).
• Obrazy interfejsu użytkownika.
• Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów).
• Diagramy interakcji dla każdego aktora.
10
Programowanie obiektowe (UML)
Diagram przypadków użycia
UML wprowadza także bardzo proste powiązania pomiędzy przypadkami użycia, oznaczane
strzałkami dodatkowymi napisami «extend» (rozszerza), <<include>> (zawiera).
Przypadek użycia podłączony przez strzałkę «extend» oznacza, że niekiedy (nie zawsze)
dany przypadek użycia jest rozszerzony przez inny przypadek użycia.
Przypadek użycia podłączony przez strzałkę «include» oznacza, że pewien przypadek
zawiera zachowanie innego przypadku, który warto jest wyodrębnić ze względu na
późniejszą możliwość uniknięcia wielokrotnej implementacji tego fragmentu.
<<extend>>
Request Catalog
Place Order
<<include>>
Order Product
<<include>>
Arrange Payment
11
Programowanie obiektowe (UML)
Diagram przypadków użycia
Pewne fragmenty diagramu przypadków są grupowane jako podsystemy. Graficznie
granice systemu (system boundary) oznaczane sa jako prostokąt otaczający wszystkie
elementy wchodzące w skład systemu.
<<extend>>
Customer
Request Catalog
Place Order
<<include>>
Order Product
Salesperson
<<include>>
Arrange Payment
Selling system
12
Programowanie obiektowe (UML)
Diagram przypadków użycia
Między aktorami i przypadkami użycia mogą zachodzić relacje generalizacji. Relacja ta
oznacza iż pewien byt jest uogólnieniem innego lub innych. Z drugiej strony można
powiedzieć, że określone byty są szczególnymi przypadkami swojej generalizacji.
Oddanie indeksu
Przekazanie dokumentu
Oddanie karty zaliczeniowej
Przekazanie podania
Przekazanie podania o urlop
Kierownik
Osoba
Pracownik
Kierownik katedry
Pracownik naukowy
13
Programowanie obiektowe (UML)
Diagram przypadków użycia
Między aktorami, a przypadkami mogą istnieć relacje o różnej krotności. Krotność powiązania
dotyczy obu stron relacji wiążącej. Wyróżnia się następujące krotności:
1
– dokładnie jeden
0..1
– 0 lub 1
1..*
– 1 lub więcej
n..m
– nie mniej niż n i nie więcej niż m
*
– dowolna ilość
1
Customer
*
<<extend>>
1
Request Catalog
*
1
Salesperson
*
<<include>>
Order Product
Place Order
<<include>>
Arrange Payment
Selling system
14
Programowanie obiektowe (UML)
Diagram przypadków użycia
W celu umieszczenia dodatkowych komentarzy umieszcza się notki zakotwiczone do bytów
których dotyczą.
Pracownik sklepu
lub akwizytor
Asocjacja jeden do wielu
1
Customer
*
<<extend>>
1
Request Catalog
*
1
Salesperson
*
<<include>>
Order Product
Place Order
<<include>>
Arrange Payment
Selling system
Granice systemu
15
Programowanie obiektowe (UML)
Diagram klas
Diagram klas (dawniej: diagram asocjacji klas lub model obiektowy) jest pojęciem
kluczowym we wszystkich metodykach obiektowych. Często diagram klas odpowiada
diagramowi encja-związek rozbudowanym o dodatkowe elementy.
W odróżnieniu od diagramów encja-związek diagramy klas posiadają metody przypisane do
specyfikowanych klas. Poza tym pojawiają się w diagramach klas różnorodne pomocnicze
oznaczenia.
Diagram klas pokazuje klasy w postaci pewnych oznaczeń graficznych powiązanych w sieć
zależnościami należącymi do trzech kategorii:
• Dziedziczenie (inheritance) - ustalenie związku generalizacji/specjalizacji pomiędzy
klasami.
• Asocjacja (association) - dowolny związek pomiędzy obiektami dziedziny przedmiotowej,
który ma znaczenie dla modelowania.
• Agregacja (aggregation) - stosunek całość-część pomiędzy obiektami z modelowanej
dziedziny przedmiotowej jest to szczególny przypadek asocjacji.
16
Programowanie obiektowe (UML)
Diagram klas
Diagram klas w identycznej wersji jest stosowany zarówno do zapisu wyników analizy jak i do
specyfikowania założeń projektowych. Diagramy klas są podstawą dowolnej analizy i
dowolnego projektu.
Żaden projekt obiektowy nie może się obejść bez diagramu klas.
Podstawowe zastosowania diagramów klas:
• Zapis modelu pojęciowego. Diagramy reprezentują pojęcia w dziedzinie zastosowań, które
aktualnie podlegają analizie. Model pojęciowy nie musi być związany z jakimkolwiek
oprogramowaniem.
• Sformalizowana specyfikacja danych i metod. Jest ona bardziej związana z
oprogramowaniem, ale dotyczy jego zewnętrznego opisu (interfejsów) bez wchodzenia w
szczegóły implementacyjne. Często podkreślaną zaletą obiektowości jest hermetyzacja,
polegająca na oddzieleniu specyfikacji od implementacji. Dla wielu celów zależy nam
wyłącznie na określeniu cech zewnętrznych pewnych bytów programistycznych (obiektów,
metod, itd.), bez wchodzenia w szczegóły.
• Implementacja. W tym zastosowaniu diagram klas może służyć bezpośrednio jako
graficzny środek pokazujący szczegóły implementacji klas, np. w C++.
17
Programowanie obiektowe (UML)
Diagram klas
Elementy składowe diagramów klas.
Klasa:
Podstawowa postać graficzna:
Klasa
Postacie graficzne przykładowych stereotypów klas:
Aktor:
Aktor biznesowy:
Klasa
Klasa
Dokument biznesowy:
Klasa
Tabela:
Klasa
18
Programowanie obiektowe (UML)
Diagram klas
Elementy składowe klasy:
Klasa abstrakcji:
Klasa
Klasa
Atrybuty:
Operacje:
Atrybut_Publiczny
Atrybut_Prywatny : int = 5
Atrybut_Chroniony : unsigned
Statyczny : float
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)
Operacja_Prywatna() : int
Operacja_Chroniona(Parametr)
19
Programowanie obiektowe (UML)
Diagram klas
Szablon klasy:
T
Klasa
Atrybut_Publiczny
Atrybut_Prywatny : int = 5
Atrybut_Chroniony : unsigned
Statyczny : float
<<bind>>
Przypisanie
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)
Operacja_Prywatna() : int
Operacja_Chroniona(Parametr)
Dodaj(T) : bool
20
Programowanie obiektowe (UML)
Diagram klas
Pakiet:
Pakiety służą do grupowania elementów diagramów.
Pakiet A
Klient
Pakiet B
Dostawca
21
Programowanie obiektowe (UML)
Diagram klas
Interfejs:
Interfejs reprezentuje zestaw operacji, które określają usługi oferowane przez klasę.
Nie posiadają atrybutów i powiązań. Posiadają tylko operacje. Mogą one posiadać związki
generalizacji.
Klasa
Atrybut_Publiczny
Atrybut_Prywatny : int = 5
Atrybut_Chroniony : unsigned
Statyczny : float
Interfejs
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)
Operacja_Prywatna() : int
Operacja_Chroniona(Parametr)
22
Programowanie obiektowe (UML)
Diagram klas
Użycie interfejsu przez klasę.
Postać rozwinięta:
<<Interface>>
Kartoteka
DanePersonalne
<<use>>
getImie() : AnsiString
getNazwisko() : AnsiString
Osoba
Numer : long
Imie : AnsiString
Nazwisko : AnsiString
getImie() : AnsiString
getNazwisko() : AnsiString
Postać uproszczona:
Osoba
Kartoteka
Numer : long
Imie : AnsiString
Nazwisko : AnsiString
<<use>>
DanePersonalne
getImie() : AnsiString
getNazwisko() : AnsiString
getImie() : AnsiString
getNazwisko() : AnsiString
23
Programowanie obiektowe (UML)
Diagram klas
Związki:
W
•
•
•
•
diagramie klas występują następujące typy powiązań.
powiązanie,
zależność,
generalizacja,
realizacja.
24
Programowanie obiektowe (UML)
Diagram klas
Powiązanie:
Powiązanie jest związkiem strukturalnym, który pokazuje że obiekty jednego elementu są
połączone z obiektami innego.
Książka
Biblioteka
Połączenie można uzupełnić o następujące elementy:
• nazwa,
• rola,
• liczebność,
• nawigacja,
• agregacja,
• rodzaj agregacji,
• kwalifikacja,
• klasa powiązania,
• ograniczenia.
25
Programowanie obiektowe (UML)
Diagram klas
Nazwa powiązania:
Udostępnianie
Element
Rola:
Element
+Książka
Udostępnianie
Element
+Książka
Udostępnianie
Element
+Książka
0..*
Zbiór
+Biblioteka
Zbiór
1
0..*
Nawigacja:
#Biblioteka
1
0..*
Liczebność:
Zbiór
Udostępnianie
+Biblioteka
Zbiór
1
26
Programowanie obiektowe (UML)
Diagram klas
Agregacja:
Element
+Książka
Udostępnianie
0..*
Agregacja całkowita:
Element
+Książka
Element
+Książka
Zbiór
1
Udostępnianie
+Biblioteka
Zbiór
1
0..*
Kwalifikacja:
+Biblioteka
Udostępnianie
ID_Elementu : long
+Biblioteka
Zbiór
1
0..*
Klasa powiązania:
Element
+Książka
Udostępnianie
ID_Elementu : long
#Biblioteka
Zbiór
1
0..*
Położenie
27
Programowanie obiektowe (UML)
Diagram klas
Ograniczenia:
Element
+Książka
Udostępnianie
ID_Elementu : long
#Biblioteka
Zbiór
1
0..n
{ordered}
Położenie
Rodzaje ograniczeń:
• implicit – związek nie jest jawny (pojęciowy),
• ordered – zbiór obiektów jest uporządkowany,
• changeable – wiązanie między obiektami mogą być dodawane, usuwane i modyfikowane,
• addOnly – nowe wiązania można dodawać do zbioru wartości atrybutu, ale raz dodane
nie mogą być modyfikowane ani usuwane,
• frozen – wartość nie może być zmieniana po zainicjowaniu obiektu, żadne nowe elementy
nie mogą być dodane do zbioru wartości.
28
Programowanie obiektowe (UML)
Diagram klas
Ograniczenia:
Osoba
Numer : long
Imie : AnsiString
Nazwisko : AnsiString
getImie() : AnsiString
getNazwisko() : AnsiString
Pracuje
0..*
{subset}
Kieruje
1
0..*
Przedsiębiortstwo
0..*
Konto
{xor}
Osoba
Numer : long
Imie : AnsiString
Nazwisko : AnsiString
getImie() : AnsiString
getNazwisko() : AnsiString
0..*
1
{subset}
Kieruje
0..*
Przedsiębiortstwo
0..*
29
Programowanie obiektowe (UML)
Diagram klas
Zależność:
Zależność jest to związek użycia. Zmiany dokonane w definicji jednego elementu mogą mieć
wpływ na inny element.
Pakiet A
<<Interface>>
Pakiet B
Kartoteka
<<use>>
DanePersonalne
getImie() : AnsiString
getNazwisko() : AnsiString
Klient
Dostawca
30
Programowanie obiektowe (UML)
Diagram klas
Stereotypy ograniczeń:
• bind
• derive
• friend
• use
• access
• import
31
Programowanie obiektowe (UML)
Diagram klas
Stereotyp zależności: bind
Źródło tworzy egzemplarz wzorca docelowego z użyciem danych parametrów aktualnych.
T
Klasa
Atrybut_Publiczny
Atrybut_Prywatny : int = 5
Atrybut_Chroniony : unsigned
Statyczny : float
<<bind>>
Przypisanie
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)
Operacja_Prywatna() : int
Operacja_Chroniona(Parametr)
Dodaj(T) : bool
32
Programowanie obiektowe (UML)
Diagram klas
Stereotyp zależności: derive
Źródło można wyznaczyć na podstawie celu.
DataUrodzenia
<<derive>>
Wiek
Stereotyp zależności: friend
Źródło można szczególny dostęp do wnętrza celu.
Pracownik
ID_Pracownik : long
Stanowisko : AnsiString
<<friend>>
ListaPłac
33
Programowanie obiektowe (UML)
Diagram klas
Stereotyp zależności: use
Znaczenie bytu źródłowego zależy od znaczenia części publicznej celu
<<Interface>>
Kartoteka
<<use>>
DanePersonalne
getImie() : AnsiString
getNazwisko() : AnsiString
Stereotyp zależności: access
Źródło ma prawo dostępu do bytów pakietu docelowego.
Pakiet A
<<access>>
Pakiet B
Stereotyp zależności: import
Zawartość publiczna pakietu docelowego zostaje dołączona do źródła.
Pakiet A
<<import>>
Pakiet B
34
Programowanie obiektowe (UML)
Diagram klas
Generalizacja:
Generalizacja jest to związek między elementem ogólnym, a specyficznym jego rodzajem.
Potomek dziedziczy strukturę i zachowanie po przodku (uwzględniając zakresy
widoczności).
Osoba
Numer : long
Imie : AnsiString
Nazwisko : AnsiString
getImie() : AnsiString
getNazwisko() : AnsiString
Kierownik
Pracownik
ID_Pracownik : long
Stanowisko : AnsiString
PracownikNaukowy
StopienNaukowy : AnsiString
Nadzór
{incomplete}
<<implementation>>
Dziekan
Potomek dziedziedziczy calą
implementację, ale nie udostępnia jako
publicznych jego interfejsów i nie
realizuje ich. (Dziedziczenie prywatne).
35
Programowanie obiektowe (UML)
Diagram klas
Ograniczenia generalizacji:
• disjoint – obiekty przodka mogą mieć nie więcej niż jednego potomka jako typ.
• overlapping – obiekty mogą posiadać dwóch lub więcej potomków jako typ
• complete – wszyscy potomkowie w uogólnieniu zostali w modelu uwzględnieniu i nie
wolno dodawać żadnych nowych potomków.
• incomplete – nie wszyscy potomkowie w uogólnieniu zostali w modelu uwzględnieniu i
wolno dodawać nowych potomków.
Kierownik
Pracownik
ID_Pracownik : long
Stanowisko : AnsiString
PracownikNaukowy
StopienNaukowy : AnsiString
Nadzór
{incomplete}
<<implementation>>
Dziekan
Potomek dziedziedziczy calą
implementację, ale nie udostępnia jako
publicznych jego interfejsów i nie
realizuje ich. (Dziedziczenie prywatne).
36
Programowanie obiektowe (UML)
Diagram klas
Realizacja:
Realizacja jest to związek znaczeniowy między klasyfikatorami, z których jeden określa
kontrakt, a drugi zapewnia wywiązanie się z niego:
Realizacja
Osoba
<<Interface>>
DanePersonalne
getImie() : AnsiString
getNazwisko() : AnsiString
Numer : long
Imie : AnsiString
Nazwisko : AnsiString
getImie() : AnsiString
getNazwisko() : AnsiString
Picture
Display
37
Programowanie obiektowe (UML)
Diagram obiektów
Diagram obiektów służy do modelowania statycznych aspektów perspektywy projektowej
lub procesowej. Wyobrażają one stan systemu w danej chwili.
Uwzględnia się na nim:
• zbiór obiektów,
• stan obiektów,
• związki między obiektami.
p1 : Przedsiębiortstwo
k2 :
Konto
o1 :
Osoba
k1 :
Konto
o2 :
Osoba
k4 :
Konto
o4 :
Osoba
o3 :
Osoba
k3 :
Konto
38
Programowanie obiektowe (UML)
Diagram sekwencji
Diagram sekwencji (diagram przebiegu) służy do modelowania dynamicznych aspektów
perspektywy projektowej lub procesowej. Uwypukla się na nim kolejność komunikatów w
czasie.
k : Klient
Uwzględnia się na nich:
• obiekty,
• czas życia obiektów,
• komunikaty.
Rodzaje komunikatów:
• przejście do następnego kroku,
• wywołanie procedury,
• asynchroniczne przejście,
• powrót z procedury.
: BazaDanych
1: <<create>>
t : Transakcja
2: Set(x,y,z)
3: Weryfikacja
4: Write(a,5,8)
5: Write(b,Kowalski)
6: Potwierdzenie
7: <destroy>>
39
Programowanie obiektowe (UML)
Diagram sekwencji
Przykład:
: Klient
: Bankomat
: BazaDanych
1: Włożenie karty
2: Prośba o PIN
3: Podanie PIN
4: Weryfikacja PIN
5: Potwierdzenie PIN
6: Pytanie o kwotę
7: Podanie kwoty
8: <<create>>
: Transakcja
9: Realizacja
10: Werfikacja
13: Wypłata gotówki
12: Zakończona
11: Transakcja zapisana
14: <<destroy>>
40
Programowanie obiektowe (UML)
Diagram kooperacji
Diagram kooperacji służy do pokazania organizacji obiektów uczestniczących w interakcji.
: Transakcja
7: Podanie kwoty
3: Podanie PIN
1: Włożenie karty
: Klient
2: Prośba o PIN
8: <<create>>
14: <<destroy>>
12: Zakończona
9: Realizacja
10: Weryfikacja
11: Transakcja zapisana
: Bankomat
4: Weryfikacja PIN
: BazaDanych
5: Potwierdzenie PIN
6: Pytanie o kwotę
13: Wypłata gotówki
41
Programowanie obiektowe (UML)
Diagram czynności
Diagram czynności służy do modelowania dynamicznych aspektów systemu. Przedstawia
się na nim sekwencyjne lub współbieżne kroki procesu. Można też zobrazować zmiany
zachodzące w obiektach w różnych fazach przepływu sterowania.
Punkt startowy:
Przepływ obiektu:
Punkt końcowy:
Stan obiektu:
Czynność:
Obiekt
[Stan obiektu]
Czynność
Tor
Przejście:
Tor:
Punkt synchronizacji:
Decyzja:
42
Programowanie obiektowe (UML)
Diagram czynności
Przykład:
Klient
Sprzedawca
Magazyn
Żądanie obsługi
Odbiór zlecenia
Płatność
zlecenia
Realizacja zlecenia
Dostarczenie
Odbiór
43
Programowanie obiektowe (UML)
Diagram czynności
Klient
Sprzedawca
Magazyn
Klient
Sprzedawca
Magazyn
Przykład:
Żądanie obsługi
Żądanie obsługi
Zlecenie
[złożone]
Odbiór zlecenia
Zlecenie
[wprowadzone]
Odbiór zlecenia
Realizacja zlecenia
Płatność
Realizacja zlecenia
Płatność
Zlecenie
[zrealizowane]
Dostarczenie
Dostarczenie
Zlecenie
[dostarczone]
Odbiór
Odbiór
44
Programowanie obiektowe (UML)
Diagram czynności
Przykład:
Włącz zasilanie
[System niesprawny]
Wyłącz zasilanie
Zatrzymaj się
[System sprawny]
Uruchom silnik
Sprawdz drogę
[Cel osiągnięty]
[Droga zajęta]
Wyszukaj nową drogę
[Droga wolna]
Jedz
[Cel nieosiagniety]
45
Programowanie obiektowe (UML)
Diagram stanów
Diagram stanów służy do modelowania dynamicznych aspektów systemu. Uwzględnia się
historię życia egzemplarzy, klasy, przypadku użycia lub systemu. Egzemplarze reagują na
zdarzenia, jak sygnały wywołania operacji i upływ czasu. Po zajściu zdarzenia są
wykonywane czynności, które zależą od bieżącego stanu obiektu. Czynności powodują
zmianę stanu lub przekazanie wartości. Stan jest to okoliczność lub sytuacja, w jakiej się
znajduje.
Stan początkowy:
Stan końcowy:
Stan:
Błąd logowania
do / ShowMessage("Login error")
Przejście
Zdarzenie:
Wprowadzono hasło
46
Programowanie obiektowe (UML)
Diagram stanów
Przykład:
WyszukanieUżytkownika
do / SearchUser
Wprowadzanie loginu
Wprowadzono Login
entry / ShowLoginWindow
Zakończono wyszukiwanie [Znaleziono] Zakończono wyszukiwanie [Nie znaleziono]
Zmiana użytkownika/ Logout
Błąd logowania
po 10 sek./ Terminate program
do / ShowMessage("Login error")
Zakończenie programu/ Terminate Program
Praca z programem
Zakończono weryfikację [Błędne hasło]/ disable program
Wprowadzanie Hasła
do / ShowPassWindow
Wprowadzono hasło
Weryfikacja hasła
do / Verify
Zakończono weryfikację/ enable program
47

Podobne dokumenty