Programowanie Programowanie ObiektoweObiektowe
JJęęzyk UMLzyk UML
2
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 90-tych.
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)WstWstęępp
3
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ędzyuż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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
4
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
5
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
6
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).
Te oznaczenia połączone są liniami odwzorowującymi powiązania poszczególnych aktorów zposzczególnymi przypadkami użycia.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
Aktor
Przypadek uzycia
Aktor
Przypadek uzycia
7
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 przypomocy 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ówzwią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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
8
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
9
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ń.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
10
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
11
UML wprowadza także bardzo proste powiązania pomiędzy przypadkami użycia, oznaczanestrzał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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
Place Order
Order Product Arrange Payment
Request Catalog
<<include>> <<include>>
<<extend>>
12
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
Place Order
Order Product Arrange Payment
Request Catalog
CustomerSalesperson
Selling system
<<include>> <<include>>
<<extend>>
13
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
PracownikOsoba
Pracownik naukowy
Kierownik
Kierownik katedry
Przekazanie dokumentu
Oddanie indeksu
Oddanie karty zaliczeniowej
Przekazanie podania
Przekazanie podania o urlop
14
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 jeden0..1 – 0 lub 11..* – 1 lub więcejn..m – nie mniej niż n i nie więcej niż m* – dowolna ilość
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
Place Order
Order Product Arrange Payment
Request Catalog
Customer Salesperson
Selling system
<<include>> <<include>>
<<extend>>1
*
1 * 1*
15
W celu umieszczenia dodatkowych komentarzy umieszcza się notki zakotwiczone do bytów których dotyczą.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia
Place Order
Order Product Arrange Payment
Request Catalog
Customer Salesperson
Selling system
Asocjacja jeden do wielu
Granice systemu
Pracownik sklepu lub akwizytor
<<include>> <<include>>
<<extend>>1
*
1 * 1*
16
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
17
Diagram klas w identycznej wersji jest stosowany zarówno do zapisu wyników analizy jak i dospecyfikowania 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++.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
18
Elementy składowe diagramów klas.Klasa:
Podstawowa postać graficzna:
Postacie graficzne przykładowych stereotypów klas:
Aktor: Aktor biznesowy:
Dokument biznesowy:
Tabela:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Klasa
Klasa Klasa
Klasa
Klasa
19
Elementy składowe klasy:
Klasa abstrakcji:
Atrybuty:
Operacje:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Klasa
KlasaAtrybut_PublicznyAtrybut_Prywatny : int = 5Atrybut_Chroniony : unsignedStatyczny : float
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)
20
Szablon klasy:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Przypisanie<<bind>>
T
KlasaAtrybut_PublicznyAtrybut_Prywatny : int = 5Atrybut_Chroniony : unsignedStatyczny : float
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)Dodaj(T) : bool
21
Pakiet:
Pakiety służą do grupowania elementów diagramów.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Pakiet A Pakiet B
Klient Dostawca
22
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
KlasaAtrybut_PublicznyAtrybut_Prywatny : int = 5Atrybut_Chroniony : unsignedStatyczny : float
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)
Interfejs
23
Użycie interfejsu przez klasę.
Postać rozwinięta:
Postać uproszczona:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
OsobaNumer : longImie : AnsiStringNazwisko : AnsiString
getImie() : AnsiStringgetNazwisko() : AnsiString
DanePersonalne
getImie() : AnsiStringgetNazwisko() : AnsiString
Kartoteka <<use>>
OsobaNumer : longImie : AnsiStringNazwisko : AnsiString
getImie() : AnsiStringgetNazwisko() : AnsiString
DanePersonalne
getImie() : AnsiStringgetNazwisko() : AnsiString
<<Interface>>
Kartoteka <<use>>
24
Związki:
W diagramie klas występują następujące typy powiązań.• powiązanie,• zależność,• generalizacja,• realizacja.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
25
Powiązanie:
Powiązanie jest związkiem strukturalnym, który pokazuje że obiekty jednego elementu sąpołączone z obiektami innego.
Połączenie można uzupełnić o następujące elementy:• nazwa,• rola,• liczebność,• nawigacja,• agregacja,• rodzaj agregacji,• kwalifikacja,• klasa powiązania,• ograniczenia.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Książka Biblioteka
26
Nazwa powiązania:
Rola:
Liczebność:
Nawigacja:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Element Zbiór10..*
Udostępnianie+Książka +Biblioteka
0..* 1
Element Zbiór10..*
Udostępnianie+Książka +Biblioteka
0..* 1
Element Zbiór10..*
Udostępnianie+Książka #Biblioteka
0..* 1
Element Udostępnianie Zbiór
27
Agregacja:
Agregacja całkowita:
Kwalifikacja:
Klasa powiązania:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Element Zbiór10..*
Udostępnianie+Książka +Biblioteka
0..* 1
Element Zbiór1
ID_Elementu : long0..*
Udostępnianie+Książka+Biblioteka
0..* 1ID_Elementu : long
Element Zbiór10..*
Udostępnianie+Książka +Biblioteka
0..* 1
ZbiórElement1
ID_Elementu : long
0..*
#Biblioteka
1
+Książka
0..*
ID_Elementu : longUdostępnianie
Położenie
28
Ograniczenia:
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
ZbiórElement1
ID_Elementu : long
0..n
#Biblioteka+Książka Udostępnianie
Położenie
10..n
ID_Elementu : long
{ordered}
29
Ograniczenia:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
OsobaNumer : longImie : AnsiStringNazwisko : AnsiString
getImie() : AnsiStringgetNazwisko() : AnsiString
Przedsiębiortstwo0..*0..*
0..*1
Pracuje
Kieruje0..* 0..*
1 0..*
{subset}
OsobaNumer : longImie : AnsiStringNazwisko : AnsiString
getImie() : AnsiStringgetNazwisko() : AnsiString
1
0..*
0..*1
0..*0..*Kieruje
{subset}
0..*
0..*Przedsiębiortstwo
{xor}
Konto
30
Zależność:
Zależność jest to związek użycia. Zmiany dokonane w definicji jednego elementu mogą miećwpływ na inny element.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Pakiet A Pakiet B
Klient Dostawca
DanePersonalne
getImie() : AnsiStringgetNazwisko() : AnsiString
<<Interface>>
Kartoteka <<use>>
31
Stereotypy ograniczeń:• bind• derive• friend• use• access• import
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
32
Stereotyp zależności: bind
Źródło tworzy egzemplarz wzorca docelowego z użyciem danych parametrów aktualnych.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
Przypisanie
T
KlasaAtrybut_PublicznyAtrybut_Prywatny : int = 5Atrybut_Chroniony : unsignedStatyczny : float
Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)Dodaj(T) : bool
<<bind>>
33
Stereotyp zależności: derive
Źródło można wyznaczyć na podstawie celu.
Stereotyp zależności: friend
Źródło można szczególny dostęp do wnętrza celu.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
DataUrodzenia Wiek<<derive>>
PracownikID_Pracownik : longStanowisko : AnsiString
<<friend>> ListaPłac
34
Stereotyp zależności: use
Znaczenie bytu źródłowego zależy od znaczenia części publicznej celu
Stereotyp zależności: access
Źródło ma prawo dostępu do bytów pakietu docelowego.
Stereotyp zależności: import
Zawartość publiczna pakietu docelowego zostaje dołączona do źródła.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
DanePersonalne
getImie() : AnsiStringgetNazwisko() : AnsiString
<<Interface>>
Kartoteka <<use>>
<<access>>Pakiet A Pakiet B
Pakiet A <<import>> Pakiet B
35
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).
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
OsobaNumer : longImie : AnsiStringNazwisko : AnsiString
getImie() : AnsiStringgetNazwisko() : AnsiString
PracownikID_Pracownik : longStanowisko : AnsiString
PracownikNaukowyStopienNaukowy : AnsiString
Dziekan
Potomek dziedziedziczy calą implementację, ale nie udostępnia jako publicznych jego interfejsów i nie realizuje ich. (Dziedziczenie prywatne).
<<implementation>>
{incomplete}
Kierownik
Nadzór
36
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
{incomplete}
Kierownik
Nadzór
<<implementation>>
Potomek dziedziedziczy calą implementację, ale nie udostępnia jako publicznych jego interfejsów i nie realizuje ich. (Dziedziczenie prywatne).DziekanPracownikNaukowy
StopienNaukowy : AnsiString
PracownikID_Pracownik : longStanowisko : AnsiString
37
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:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas
OsobaNumer : longImie : AnsiStringNazwisko : AnsiString
getImie() : AnsiStringgetNazwisko() : AnsiString
DanePersonalne
getImie() : AnsiStringgetNazwisko() : AnsiString
<<Interface>>
Realizacja
Picture
Display
38
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram obiektDiagram obiektóóww
o1 : Osoba
k1 : Konto
p1 : Przedsiębiortstwo
o2 : Osoba
k2 : Konto
o4 : Osoba
k4 : Konto
k3 : Konto
o3 : Osoba
39
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.
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.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram sekwencjiDiagram sekwencji
k : Klient
t : Transakcja
: BazaDanych
1: <<create>>
4: Write(a,5,8)
5: Write(b,Kowalski)
7: <destroy>>
6: Potwierdzenie
2: Set(x,y,z)3: Weryfikacja
40
Przykład:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram sekwencjiDiagram sekwencji
: Klient : Bankomat : BazaDanych
: Transakcja8: <<create>>
1: Włożenie karty
2: Prośba o PIN
3: Podanie PIN4: Weryfikacja PIN
5: Potwierdzenie PIN
6: Pytanie o kwotę
7: Podanie kwoty
9: Realizacja
11: Transakcja zapisana12: Zakończona
10: Werfikacja
14: <<destroy>>13: Wypłata gotówki
41
Diagram kooperacji służy do pokazania organizacji obiektów uczestniczących w interakcji.
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram kooperacjiDiagram kooperacji
: Bankomat : Klient : BazaDanych
: Transakcja
10: Weryfikacja
4: Weryfikacja PIN
5: Potwierdzenie PIN
1: Włożenie karty
2: Prośba o PIN
3: Podanie PIN
6: Pytanie o kwotę
7: Podanie kwoty
13: Wypłata gotówki
8: <<create>> 12: Zakończona
14: <<destroy>>
9: Realizacja
11: Transakcja zapisana
42
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ść:
Przejście: Tor:
Punkt synchronizacji:
Decyzja:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram czynnoDiagram czynnośścici
Czynność
Obiekt[Stan obiektu]
Tor
43
Przykład:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram czynnoDiagram czynnośścici
Klient Sprzedawca Magazyn
Żądanie obsługi
Płatność
Odbiór zlecenia
Realizacja zlecenia
Odbiór
Dostarczenie
Żądanie obsługi
Płatność
Odbiór zlecenia
Realizacja zlecenia
Odbiór
Dostarczenie
44
Przykład:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram czynnoDiagram czynnośścici
Klient Sprzedawca Magazyn
Żądanie obsługi
Płatność
Odbiór
Odbiór zlecenia
Dostarczenie
Realizacja zlecenia
Zlecenie[złożone]
Zlecenie[wprowadzone]
Zlecenie[zrealizowane]
Zlecenie[dostarczone]
Klient Sprzedawca Magazyn
Żądanie obsługi
Płatność
Odbiór zlecenia
Realizacja zlecenia
Odbiór
Dostarczenie
45
Przykład:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram czynnoDiagram czynnośścici
[System sprawny]
[System niesprawny]
[Droga wolna][Droga zajęta]
[Cel osiągnięty]
[Cel nieosiagniety]
Włącz zasilanie
Wyłącz zasilanie
Uruchom silnik
Jedz
Sprawdz drogę
Wyszukaj nową drogę
Zatrzymaj się
46
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:
Przejście
Zdarzenie: Wprowadzono hasło
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram stanDiagram stanóóww
Błąd logowania
do / ShowMessage("Login error")
47
Przykład:
Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram stanDiagram stanóóww
Wprowadzono Login
Zakończono wyszukiwanie [Nie znaleziono]Zakończono wyszukiwanie [Znaleziono]
Wprowadzono hasło
Zakończono weryfikację [Błędne hasło]/ disable program
Zakończono weryfikację/ enable program
po 10 sek./ Terminate program
Zmiana użytkownika/ Logout
Zakończenie programu/ Terminate Program
Wprowadzanie loginu
entry / ShowLoginWindow
Wprowadzanie Hasła
do / ShowPassWindow
WyszukanieUżytkownika
do / SearchUser
Błąd logowania
do / ShowMessage("Login error")
Weryfikacja hasła
do / Verify
Praca z programem