Programowanie obiektowe (UML)
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