specjalizacja generalizacja

(1)

Wykład :

Techniki i narzędzia modelowania systemów (notacje graficzne)

InŜynieria

Oprogramowania

mgr inŜ. Jacek Kołodziej, mgr inŜ. Grzegorz Młynarczyk

Opracowano na podstawie:

InŜynieria oprogramowania – wykład : mgr inŜ. Grzegorz Młynarczyk, WSZIB, Kraków

InŜynieria oprogramowania – wykład : dr hab. inŜ. Kazimierz Subieta, PJWSTK , Warszawa InŜynieria oprogramowania: Andrzej Jaszkiewicz, Wyd.Helion 1997

Projektowanie systemów informacyjnych – wykład: Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa

Software Engineering, 7th edition, Ian Sommerville 2004

(2)

Motto

Droga prosta jest najkrótsza,

ale na ogół wymaga najwięcej czasu, aby dojść nią do celu.

Georg Christoph Lichtenberg (1742 - 1799)

(3)

Przykłady zastosowań notacji graficznych na róŜnych etapach realizacji projektu

Techniki i narzędzia modelowania systemów (notacje graficzne)

Model cyklu Ŝycia projektów

Faza specyfikacji wymagań

Faza analizy

Techniki obiektowe

Techniki strukturalne

Faza projektowania

Komponenty

Podsumowane

(4)

Przykłady zastosowań notacji graficznych na róŜnych etapach realizacji projektu

Techniki i narzędzia modelowania systemów (notacje graficzne)

Faza analizy

Techniki obiektowe

Modelowanie statyczne

Faza projektowania

Komponenty

Podsumowane

(5)

Faza analizy

Typy notacji:

Język naturalny

Strukturalizowany zapis tekstowy i numeryczny (np.:PDL)

Notacje graficzne

szczególne znaczenie,

inŜynieria oprogramowania wzoruje się na innych dziedzinach techniki, takich jak elektronika i mechanika.

zalety notacji graficznych potwierdzają badania psychologiczne.

Funkcje:

Narzędzie pracy analityka i projektanta, zapis i analiza pomysłów

Współpraca z uŜytkownikiem

Komunikacja z innymi członkami zespołu

Podstawa implementacji oprogramowania

Zapis dokumentacji technicznej

Notacje powinny być przejrzyste, proste, precyzyjne, łatwo zrozumiałe,

umoŜliwiające modelowanie złoŜonych zaleŜności.

(6)

Faza analizy

Metodyki obiektowe

Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych.

Podstawowym składnikiem jest diagram klas, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek.

Diagram klas zawiera: klasy, w ramach klas specyfikacje atrybutów i metod, związki generalizacji, związki asocjacji i agregacji, liczności tych związków, róŜnorodne ograniczenia oraz inne oznaczenia.

Uzupełnieniem tego diagramu są inne: diagramy dynamiczne uwzględniające stany i przejścia pomiędzy tymi stanami, diagramy interakcji ustalające zaleŜności pomiędzy wywołaniami metod, diagramy funkcjonalne (będące zwykle pewną mutacją diagramów przepływu danych), itd.

Koncepcja przypadków uŜycia (use cases) zakłada odwzorowanie struktury systemu z punktu widzenia jego uŜytkownika.

(7)

Faza analizy

Diagramy definiowane w UML

Diagramy przypadków uŜycia (use case)

Diagramy klas, w tym diagramy pakietów (class diagram)

Diagramy zachowania się (behavior)

Diagramy stanów (state diagram)

Diagramy aktywności (activity diagram)

Diagramy sekwencji (sequence diagram)

Diagramy współpracy (collaboration diagram)

Diagramy implementacyjne

Diagramy komponentów (component diagram)

Diagramy wdroŜeniowe (deployment diagram)

Diagramy te zapewniają mnogość perspektyw systemu podczas analizy i rozwoju.

Twórcy UML wychodzą z załoŜenia, Ŝe Ŝadna pojedyncza perspektywa spojrzenia na projektowany system nie jest wystarczająca.

(8)

Proces tworzenia modelu obiektowego

Kolejne zadania:

Identyfikacja klas i obiektów

Identyfikacja związków pomiędzy klasami

Identyfikacja i definiowanie pól (atrybutów)

Identyfikacja i definiowanie metod i komunikatów

Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest ustalona i zaleŜy zarówno od stylu pracy, jak i od konkretnego problemu.

Inny schemat realizacji procesu budowy modelu obiektowego polega na rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie następuje identyfikacja klas, związków, atrybutów i metod.

Rozpoznaniu funkcji systemu słuŜą modele funkcjonalne (diagramy przepływu danych) oraz model przypadków uŜycia.

(9)

Faza analizy

Typowe klasy:

przedmioty namacalne (samochód, czujnik)

role pełnione przez osoby (pracownik, wykładowca, student)

zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie zamówienia, dostawa),

interakcje pomiędzy osobami i/lub systemami o których system przechowuje informacje (poŜyczka, spotkanie, sesja),

lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów

grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części)

organizacje (firma, wydział, związek)

wydarzenia (posiedzenie sejmu, demonstracja uliczna)

koncepcje i pojęcia (zadanie, miara jakości)

dokumenty (faktura, prawo jazdy)

klasy będące interfejsami dla systemów zewnętrznych

klasy będące interfejsami dla urządzeń sprzętowych

(10)

W wielu przypadkach przy definicji klasy naleŜy dokładnie ustalić, z jakiego rodzaju abstrakcją obiektu mamy do czynienia.

Np. klasa „samochód”. MoŜe chodzić o:

• egzemplarz samochodu wyprodukowany przez pewną fabrykę

• model samochodu produkowany przez fabrykę

• pozycję w katalogu samochodów opisujący własności modelu

• historię stanów pewnego konkretnego samochodu

NaleŜy zwrócić uwagę na następujące aspekty:

• czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej?

• czy mamy do czynienia z konkretnym obiektem w pewnym odcinku czasu?

• czy mamy do czynienia z opisem tego obiektu (dokument, metadane)?

• czy mamy do czynienia z pewnym zbiorem konkretnych obiektów?

Faza analizy

(11)

W wielu przypadkach przy definicji klasy naleŜy dokładnie ustalić, z jakiego rodzaju abstrakcją obiektu mamy do czynienia.

Np. klasa „samochód”. MoŜe chodzić o:

• egzemplarz samochodu wyprodukowany przez pewną fabrykę

• model samochodu produkowany przez fabrykę

• pozycję w katalogu samochodów opisujący własności modelu

• historię stanów pewnego konkretnego samochodu

Podobnie z klasą „gazeta”. MoŜe chodzić o:

• konkretny egzemplarz gazety kupiony przez czytelnika

• konkretne wydanie gazety (niezaleŜne od ilości egzemplarzy)

• tytuł i wydawnictwo, niezaleŜne od egzemplarzy i wydań

• partię egzemplarzy danej gazety dostarczaną codziennie do kiosku NaleŜy zwrócić uwagę na następujące aspekty:

• czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej?

• czy mamy do czynienia z konkretnym obiektem w pewnym odcinku czasu?

• czy mamy do czynienia z opisem tego obiektu (dokument, metadane)?

• czy mamy do czynienia z pewnym zbiorem konkretnych obiektów?

Faza analizy

(12)

Klasa - notacja (1)

Okno Okno

rozmiar

czy_widoczne

rozmiarOkno

czy_widoczne wyświetl() schowaj()

rozmiar: ObszarOkno czy_widoczne:

Boolean wyświetl() schowaj()

Cztery pola:

nazwy,

atrybutów,

metod

uŜytkownika, np. w celu specyfikowania odpowiedzialności klasy.

MoŜliwe są róŜne poziomy szczegółowości.

stereotyp nazwa_ klasy lista_wart_etyk

stereotyp , dostępność

nazwa_atrybutu : typ = wart_początkowa lista_wart_etyk

stereotyp dostępność

nazwa_metody (lista_arg) : typ_wart_zwracanej

(13)

Klasa; notacja (2)

dostępność jest określana przez trzy symbole:

+ publiczna

- prywatna

# chroniona

lista_arg: rodzaj nazwa_arg : typ = wart_początkowa

rodzaj definiuje sposób, w jaki metoda korzysta z danego argumentu:

in: metoda moŜe czytać argument, ale nie moŜe go zmieniać

out: moŜe zmieniać, nie moŜe czytać

inout: moŜe czytać i zmieniać

Wszystkie elementy specyfikacji klasy za wyjątkiem nazwy klasy są opcjonalne.

Nazwa klasy to z reguły rzeczownik w liczbie pojedynczej.

(14)

«trwała» Prostokąt punkt1: Punkt

punkt2: Punkt

«konstruktor»

Prostokąt (p1: Punkt, p2: Punkt)

«zapytania»

obszar (): Real aspekt(): Real

. . .

«aktualizacje»

przesuń(delta: Punkt)

przeskaluj(współczynnik: Real)

Przykłady klas

Okno

{abstrakcyjna, autor=Kowalski status=przetestowane}

+rozmiar: Obszar = (100,100)

#czy_widoczne: Boolean = false +rozmiar_domyślny: Prostokąt

#rozmiar_maksymalny: Prostokąt -xwskaźnik: XWindow*

+wyświetl() +schowaj() +utwórz()

-dołączXWindow(xwin: XWindow*)

Stereotypy zostały tu uŜyte do metaklasyfikacji metod.

«»

(15)

Dziedziczenie (1)

specjalizacja generalizacja

Pracownik Osoba

Asystent Adiunkt Docent Profesor Asystent Adiunkt Docent Profesor Pracownik

Osoba

Dziedziczenie (ang. inheritance) to operacja polegająca na tworzeniu nowej klasy na bazie klasy juŜ istniejącej.

Dziedziczenie pozwala na tworzenie drzewa klas lub innych struktur bez pętli.

(16)

Dziedziczenie (2)

Struktura typu pętla jest zabroniona

Pracownik Student

Osoba

Student_asystent

Struktura typu krata jest dopuszczalna Student_asystent Pracownik

Student

(17)

Dziedziczenie (3)

Nazwisko Ulica Wiek()

Pensja Pokój Zdjęcie

ObliczPensja() NowaPensja(...) Album

RokObliczStyp(...) WstawZliczenie()

JPEG GIF

Obraz

Rozmiar PolaŜ(...) OSOBA

STUDENT PRACOWNIK

Atrybut Zdjęcie klasy PRACOWNIK, jest obiektem, członkiem klasy JPEG.

(18)

Dziedziczenie wielokrotne

Dziedziczenie wielokrotne (ang. multiple inheritance) to operacja polegająca na dziedziczeniu po więcej niŜ jednej klasie bazowej.

Dziedziczenie wielokrotne moŜliwe jest na przykład w języku C++.

W Javie dziedziczenie wielokrotne uzyskujemy przez zastosowanie tzw. interfejsów.

Pomimo zalet dziedziczenia wielokrotnego zaleca się go unikać wszędzie tam gdzie jest to moŜliwe, a stosowanie go jest uznawane za złą praktykę programistyczną.

Samochód Koła : int

SprawdźCiśnienieOgumienia()

Łódź Wyporność : int MierzZanurzenie()

Amfibia Wyporność : int MierzZanurzenie()

(19)

Pojazd { prędkość eksploatacyjna wynosi 50% prędkości maksymalnej }

max_prędkość max_prędkość

prędk_eksploat()

Amfibia

Samochód Jacht

prędk_eksploat()

Pojazd wodny Pojazd lądowy

Konflikt nazw:

Który atrybut max_prędkość ma odziedziczyć amfibia?

Czy znaczenie metody prędk_eksploat() zaleŜy od ścieŜki dziedziczenia?

Rozwiązania:

mechanizm zmiany nazwy dziedziczonej cechy;

konflikt jest traktowany jako błąd (Eiffel)

Najczęściej wielodziedziczenie jest konsekwencją braku koncepcji ról

Dziedziczenie wielokrotne Problemy

(20)

Klasa abstrakcyjna a konkretna (1)

Osoba prawna

Osoba fizyczna Firma

Sekwencja

pierwszy następny

Sekwencja int ...

Sekwencja char .

Klasa abstrakcyjna:

nie ma (nie moŜe mieć) bezpośrednich wystąpień

słuŜy wyłącznie jako nadklasa dla innych klas.

stanowi wspólną część definicji grupy klas o podobnej semantyce.

Klasa konkretna moŜe mieć

(ma prawo mieć) wystąpienia bezpośrednie.

Instancje (obiekty)

(21)

Atrybuty (1) Cechy

nazwisko : string wiek : integer

Klasa z atrybutami Obiekty (wystąpienia klasy) z wartościami atrybutów

Osoba :Osoba

nazwisko = Kowalski wiek = 24

:Osoba nazwisko = Nowak wiek = 35

Atrybut:

moŜe być nazwanąwartością lub obiektem (podobiekt),

atrybut, będący wartością, nie posiada toŜsamości,

wartości atrybutów są przechowywane przez obiekty, poniewaŜ nie naleŜą do inwariantów klasy.

Uwaga! Sformułowanie “wartość atrybutu” w przypadku, gdy atrybut jest podobiektem jest pewnym uproszczeniem.

Atrybuty klasy Osoba

(22)

Atrybuty (2)

Dlaczego obiekty są rozróŜnialne

Osoba

id_osoby Pesel : nr

nazwisko : string wiek : integer Pesel : nr

nazwisko : string wiek : integer

Osoba

Atrybut unikalnie identyfikujący obiekt (klucz) nie jest wymagany, poniewaŜ:

kaŜdy obiekt posiada toŜsamość, implementowaną poprzez wewnętrzny unikalny identyfikator obiektu,

w przypadku narzędzi implementacyjnych jest automatycznie generowany w momencie powoływania obiektu do Ŝycia i niewidoczny dla uŜytkownika.

identyfikator nie ma (nie powinien mieć) znaczenia w dziedzinie problemu.

(23)

Pracownik

imięnazwisko

nazwisko panieńskie [0..1]

data ur.

/wiek

adres zamieszkania

płećstosunek do słuŜby wojsk. [0..1]

lista poprz. miejsc pracy [0..*]

adres firmy zdjęcie

Atrybuty (3)

Jakie mogą być ???

proste: imię, nazwisko, nazwisko panieńskie, wiek, płeć, stosunek do słuŜby wojskowej

złoŜone: data ur. , adresy, lista poprzednich miejsc pracy, zdjęcie

opcjonalne: nazwisko panieńskie, stosunek do słuŜby wojsk, lista poprzednich miejsc pracy

powtarzalne: lista poprzednich miejsc pracy

pochodne: wiek

klasy: adres firmy

atrybut będący obiektem: zdjęcie

(24)

nazwisko wiek

zmień pracę zmień_adres

nazwa_pliku

długość w bajtach ostatnia_zmiana drukuj

kolor pozycja

przesuń ( delta: Wektor )

wewnątrz ( p: Punkt ): Boolean obróć ( kąt )

Osoba Plik Obiekt geometryczny

Metody

Specyfikacja metod(1)

Metoda moŜe mieć argumenty (oprócz obiektu, który jest argumentem implicite).

Sygnatura (specyfikacja) metody włącza liczbę i typ argumentów plus typ wyniku metody.

Wszystkie metody implementujące daną operację muszą mieć tę samą sygnaturę.

(25)

nazwisko wiek

zmień pracę zmień_adres

nazwa_pliku

długość w bajtach ostatnia_zmiana drukuj

kolor pozycja

przesuń ( delta: Wektor )

wewnątrz ( p: Punkt ): Boolean obróć ( kąt )

Osoba Plik Obiekt geometryczny

Metody

Specyfikacja metod(2)

Interpretacja braku specyfikacji argumentów metod:

moŜe ich być dowolnie duŜo

moŜe ich nie być.

Brak specyfikacji argumentów na etapie analizy:

metoda ich nie posiada,

w danym momencie nie interesujemy się jeszcze nimi.

To samo dotyczy wartości zwracanej przez metodę.

(26)

Wykładowca

imię

nazwisko data ur.

/wiek

adres zamieszkania płeć

stosunek do słuŜby wojsk. [0..1]

lista poprz. miejsc pracy [0..*]

adres firmy

policz wiek (imię, nazwisko) policz wiek

czy pracował w (nazwa firmy) znajdź najstarszego

policz wiek (imię, nazwisko)

Metody

Rodzaje metod

Metody Abstrakcyjne

Klasa Wykładowca nie posiada metod

abstrakcyjnych, bowiem jako jedyna klasa na diagramie musi byćklasąkonkretną.

Metody Obiektu: policz wiek, czy pracował w (nazwa firmy)

Metoda obiektu operuje na atrybutach jednego

obiektu - tego dla którego została wywołana.

Obiekt jest argumentem domyślnym metody

obiektu.

Metody Klasy: policz wiek (imię, nazwisko), znajdź najstarszego

Metoda klasy operuje na ekstensji klasy:

czyli posiada dostęp do atrybutów

wszystkich obiektów członków danej klasy.

(27)

Metody mają tu identyczną sygnaturę, ale róŜne implementacje (ciała).

Pracownik nazwisko ...

zwolnij() ...

Samodzielny prac.naukowy zwolnij()

Decyzja o zwolnieniu w gestii dyrekcji

Decyzja o zwolnieniu w gestii sekretariatu PAN

Metody

Przesłanianie metod (1)

Przesłanianie (overriding)

metoda z klasy bardziej wyspecjalizowanej moŜe przesłonić metodę z klasy bardziej ogólnej;

wybierana jest metoda znajdująca się najbliŜej obiektu, w sensie hierarchii dziedziczenia.

(28)

Prostopadłościan ^Walec

pole podstawy wysokość

Bryła

policz objętość {objętość = pole podstawy * wysokość}

StoŜek

policz objętość {objętość = 1/3 pola podstawy * wysokość} {incomplete}

{abstract}

Metody

Przesłanianie jest ściśle powiązane z polimorfizmem metod.

Przesłanianie wymaga dynamicznego wiązania.

Przesłanianie jest waŜnym elementem wspomagającym ponowne uŜycie.

(29)

Bryła

StoŜek

{abstract}

Metody

Polimorfizm w programowaniu funkcyjnym to moŜliwość stosowania tej samej funkcji dla róŜnych typów parametrów.

Najprostsza funkcja polimorficzna:

function f (x){

return x;

}

(30)

Bryła

StoŜek

{abstract}

Metody

Polimorfizm w programowaniu obiektowym to wykazywanie przez metodę róŜnych form działania w zaleŜności od tego jaki typ obiektu jest wskazywany przez wskaźnik lub referencję (pomijając typ wskaźnika lub referencji).

(31)

Bryła

StoŜek

{abstract}

Metody

Dwie metody implementujące operację policz objętość.

Metoda policz objętość w klasie Bryła nie moŜe być metodą abstrakcyjną.

(32)

Związek między klasami Powiązanie i asocjacja

Powiązanie

Fizyczny lub pojęciowy związek między obiektami,

Odwzorowanie relacji między istniejącymi bytami w analizowanej dziedzinie przedmiotowej.

Asocjacja

Grupa powiązań posiadających wspólną strukturę i semantykę.

Powiązanie jest wystąpieniem asocjacji.

Asocjacja, która łączy dwie klasy nazywana jest binarną.

(33)

:Osoba Kasia

:Firma Krawiecka pracuje_w

:Osoba Jasio

:Firma Szewska :Osoba

Ewa pracuje_w

pracuje_w

Obiekty i powiązania na diagramie obiektów Osoba

imię

Firma rodzaj

pracuje_w

Klasy i asocjacja na diagramie klas

Asocjacje mogą teŜ łączyć więcej niŜ dwie klasy, tzw. asocjacje n-arne.

Związek między klasami Powiązanie i asocjacja

(34)

Firma 1 pracuje_dla 1..* Osoba

Asocjacja Oznaczenia

Czarny trójkącik

określa kierunek (czytania) wyznaczony przez nazwęasocjacji.

W danym przypadku określa on, Ŝe osoba pracuje dla firmy, a nie firma pracuje dla osoby.

Nazwy asocjacji, takie jak np. pracuje_dla, wyznaczają znaczenie tej asocjacji w modelu pojęciowym opisującym dziedzinę przedmiotową.

Liczność asocjacji:

oznacza, ile obiektów innej klasy moŜe byćpowiązane z jednym obiektem danej klasy;

zwykle określa sięto poprzez paręliczb (znaków), oznaczającą minimalną i maksymalną liczbę takich obiektów.

(35)

Grupa Student

Termin od

do

* ^1..15

Grupa * 1..15 Student całość część

Asocjacja Agregacje

Jest rodzajem asocjacji;

zadaniem agregacji jest modelowanie związku całość-część.

agregacja jest asocjacją: dla obu jej końców są określane liczności, a takŜe moŜe mieć atrybuty, np.:

agregacja jest wykorzystywana do modelowania związku całość-część

(36)

Członek

bibl. Personel

Pozycja

Czasopismo

KsiąŜka

Egzemplarz ksiąŜki Osoba

/liczba wyp. akt. pozycji

* 0..1

{ liczba wyp. akt.

pozycji <= 12 } { liczba wyp. akt.

pozycji <= 6 } 1..*

WypoŜyczenie

data wypoŜyczenia { data zwrotu - data wypoŜyczenia

<= 3 tygodnie }

*

* wypoŜyczył

Asocjacja

Przykład diagramu klas

(37)

Przykłady zastosowań notacji graficznych na róŜnych etapach realizacji projektu

Techniki i narzędzia modelowania systemów (notacje graficzne)

Faza analizy

Techniki obiektowe

Stany dynamiczne

Faza projektowania

Komponenty

Aplikacje WWW

Podsumowane

(38)

Modelowanie dynamiczne

Diagram stan – ang. State Diagram

Maszyna, automat stanów to:

to graf skierowanym:

wierzchołki stanowią stany obiektu,

łuki - przejścia między stanami, będące odpowiedzią na zdarzenie.

charakteryzuje klasę i specyfikuje reakcje instancji klasy (obiektu) na przychodzące zdarzenia,

model historii Ŝycia (opis wszystkich moŜliwych stanów i przejść) dla obiektu danej klasy.

odwzorowanie przypadku(ów) uŜycia, operacji, kolaboracji - przepływu sterowania ( częściej stosowane są diagramy aktywności).

Obiekt : toŜsamość, stan i zachowanie:

moŜe być traktowany jako automat o skończonej liczbie stanów,

jest pewną maszyną, znajdującą się w określonej chwili w jednym z wyróŜnionych stanów, wpływa takŜe na otoczenie

(39)

Diagramy tego rodzaju wykorzystywane są do opisu zachowania obiektu

Obrazują moŜliwe stany obiektu, zdarzenia jakie mogą być odbierane przez obiekt i akcje jakie mogą zostać wykonane w odpowiedzi na zdarzenia

W większości obiektowych metodyk diagramy stanów wykorzystywane są do obrazowania zachowania pojedyńczych obiektów

Diagram stan – ang. State Diagram

(40)

Stan (ang. state) w terminologii diagramów pojęcie stanu naleŜy rozumieć jako stan obiektu, w którym wykonuje on pewną akcję lub oczekuje na zdarzenie, określony przez wartości poszczególnych atrybutów klasy tego obiektu

Zestaw wartości wszystkich (?) atrybutów oraz aktualnych powiązań danego obiektu z innymi obiektami w pewnej chwili czasowej. Stan obiektu trwa w czasie aŜ do momentu zajścia zdarzenia, które spowoduje zmianę aktualnego stanu na inny. Innymi słowy, stan to “zdjęcie migawkowe”

jednej sytuacji, w której znalazł się nasz system informatyczny. Często abstrahuje się od pewnych składników stanu, lub “zlepia się” wiele stanów w jeden.

Np. stanem obiektu STUDENT jest zestaw wartości:

(NAZWISKO: Brzeczyszczykiewicz, IMIE: Adam, STATUS: Powtarza)

Diagram stanu – notacja / terminologia

(41)

Nazwa Stanu entry /akcja1/akcja2/…

do /aktywność1/aktywność2/…

exit /akcja1/akcja2/...

akcja - operacja, której nie moŜna przerwać lista akcji - akcja1/akcja2/…

- traktowana jest, jak pojedyncza operacja, aktywność - operacja, którą moŜna przerwać, lista aktywności - podobnie, jak lista akcji,

Diagram stanu – notacja / terminologia

entry - słowo kluczowe specyfikujące operacje, zawszewykonywane na wejściu do stanu (rodzaj setup’u),

exit - operacje zawsze wykonywane na wyjściu ( rodzaj porządkowania “po”), do - operacje wykonywane w trakcie.

(42)

Modelowanie dynamiczne Diagram stanu – typy

prosty (simple) nie posiada substruktury

złoŜony sekwencyjny (sequential composite state)

złoŜony z jednego lub więcej podstanów, z których tylko jeden jest aktywny,

w czasie aktywnosci całego stanu złoŜonego

początkowy (initial state)

pseudostan słuŜący do oznaczenia punktu startowego

końcowy pseudostan słuŜący do oznaczenia punktu złoŜony współbieŜny

(concurrent composite state)

podzielony na dwa lub więcej współbieŜnych podstanów; wszystkie podstany są jednocześnie aktywne, gdy aktywny jest stan złoŜony (jako całość)

(43)

Zmiana stanu (ang. state transition)

– przejście z obecnego stanu do stanu następnego w wyniku zdarzenia lub zakończenia akcji wykonywanej przez obiekt w obecnym stanie.

Samo zdarzenie nie trwa w czasie, ale fakt zaistnienia zdarzenia jest rejestrowany i trwa aŜ do momentu, gdy jakiś podmiot go “skonsumuje”

(innymi słowy zdarzenie nie musi być obsłuŜone od razu w momencie wystąpienia - moŜe być wpisane na listę zdarzeń oczekujących na obsługę).

Wszystko, co wywołuje pewne skutki w systemie moŜe być modelowane jako zdarzenie.

Diagram stanu – zmiana stanu

(44)

op (a : T)

when(wyraŜenie)

nazwa_syg (a : T)

after (czas)

Diagram stanu – typy zdarzeń

Wołanie:

otrzymanie przez obiekt synchronicznego Ŝądania wykonania operacji - najbardziej podstawowy rodzaj zdarzenia

Zmiana

spełnienie warunku typu Boolean, np. when (x =10); zdarzenie typu zmiana jest uŜyteczne np. do modelowania sytuacji, gdy obiekt zmienia stan po otrzymaniu odpowiedzi na wysłany przez siebie komunikat

Sygnał

otrzymania przez obiekt asynchronicznego Ŝądania wykonania operacji; uŜyteczne do modelowania zdarzeń przychodzących z zewnątrz systemu

Czas

upłynięcie czasu określonego w sposób bezwzględny lub względny, np. after (5 sec.)

(45)

Stan początkowy i końcowy – dwa specjalne stany określające odpowiednio początek diagramu stanów dla danego obiektu oraz jego koniec. Diagram moŜe mieć jeden i tylko jeden stan początkowy i wiele stanów końcowych. Stan początkowy oznacza stan obiektu zaraz po jego utworzeniu, natomiast stan końcowy oznacza stan obiektu tuŜ przed jego usunięciem z systemu.

Diagram stanu – początek i koniec

(46)

Diagram stanu – przykład (1)

(47)

(48)

(49)

Urządzenie niesprzedane

Urządzenie sprzedane kupno urządzenia przez klienta

klient zwrócił urządzenie after (data gwarancji)

Kolejka białych

Kolejka czarnych

ruch białych ruch czarnych

remis

białe wygrywają when (szach mat)

when (pat)

when (szach mat)

Diagram typu:

cykl Ŝycia obiektu

Diagram typu:

przepływ sterowania

(50)

Jazda do przodu na 1-szym

biegu

Jazda do przodu na 2-gim

biegu

Jazda do tyłu Samochód zatrzymany wybrano 1-szy bieg

naciśnięto hamulec

wybrano następny bieg

wybrano poprzedni bieg

naciśnięto hamulec

naciśnięto hamulec wybrano

wsteczny bieg

(51)

Stan złoŜony współbieŜny

synchronizacja wewnętrzna

synchronizacja zewnętrzna

Takie wyjście ze stanu teŜ jest moŜliwe (sytuacja nietypowa).

Oba diagramy są ównowaŜne.

(52)

WspółbieŜność - obiekty zagregowane

Samochód

Zapłon Bieg Hamulec Gaz hamulec

puszczony Hamulec

Włącz.

Wył.

hamulec naciśnięty

Źródła współbieŜności:

obiekty mogą być zagregowane,

pewne operacje w ramach jednego obiektu moŜna wykonywać współbieŜnie,

obiekty mogą działać asynchronicznie.

(53)

WspółbieŜność - obiekty zagregowane

KaŜdy obiekt wchodzący w skład agregatu posiada tu własny diagram stanu. MoŜna je łączyć, tworząc diagram dla agregatu samochód (uwzględniając współbieŜność operacji).

Zapłon

Wył. Zapala Włącz.

kluczyk do max w prawo

[Biegi w pozycji 0]

kluczyk do poz wył

Biegi ....

Gaz ....

(54)

WspółbieŜność w ramach jednego obiektu

Gotowy do działania

Maszyna stanu dla automatu do wypłacania pieniędzy

Wypłata do/wydaj gotówkę

do/oddaj kartę

Podział na

współbieŜne procesy

Synchronizacja:

wszystkie współbieŜne procesy muszą się zakończyć, aby automat był

ponownie gotowy do działania

(55)

(56)

Opis zachowania pojedyńczych obiektów

Nie powinny być stosowane do opisu zachowania grupy wzajemnie współpracujących obiektów (w takich przypadkach powininy być stosowane diagramy innego rodzaju np. activity)

Nie powinny być stosowane dla kaŜdej klasy istniejącej w modelu a tylko dla tych, które wykazują złoŜone zachowanie. W takich przypadkach diagramy stanów pomagają w zrozumieniu charakterystyki i zachowania obiektów

Wykorzystywne są często do opisu interfejsu uŜytkownika

Diagram stanu – podsumowanie

(57)

Pozwalają na utworzenie opisu interakcji obiektów systemu podczas realizacji danego zadania: przypadku uŜycia czy jednego konkretnego scenariusza danego przypadku uŜycia.

Nie dla wszystkich przypadków uŜycia moŜe zachodzić potrzeba konstruowania diagramów interakcji, ale mogą okazać się szczególnie uŜyteczne np. do komunkacji wewnątrz zespołu projektowego (jak zresztą wszystkie rodzaje diagramów) czy teŜ do rozwaŜenia opcjonalnych realizacji w “trudnych przypadkach”.

Niektóre narzędzia CASE potrafią wykorzystać te diagramy do generacji kodu, co moŜe stanowić waŜny powód dla ich konstruowania.

Modelowanie dynamiczne Diagramy interakcji

(58)

Przykłady diagramów:

diagramy współpracy (kolaboracji)

diagramy sekwencji

Bazują na diagramie klas,

pokazują prawie tą samą informację, w nieco inny sposób.

Niektóre narzędzia CASE potrafią generować tylko jeden typ diagramu.

Decyzja, który rodzaj diagramów konstruować, zaleŜy od poŜądanego aspektu interakcji.

Diagramy interakcji – współpracy i sekwencji

(59)

:Personel bibl.

:Członek

bibl. :KsiąŜka

:Egzemplarz KsiąŜki

Diagramy współpracy pokazują w jaki sposób system realizwane są przypadki uŜycia.

Współpracujące obiekty, połączone liniami ( “linkami”) , tworzą rodzaj

“kolektywu”, zwanego tu kolaboracją.

Linki odpowiadają powiązaniom, czyli wystąpieniom asocjacji z diagramu klas, a to oznacza, Ŝe odpowiednia asocjacja musi istnieć na diagramie klas.

Modelowanie dynamiczne Diagramy współpracy

(60)

:Członek

bibl. :KsiąŜka

Modelowanie dynamiczne Diagramy współpracy

Prosty diagram współpracy, bez uwidaczniania interakcji między obiektami, stanowi coś w rodzaju “wystąpienia fragmentu diagramu klas”; pokazuje aktora, relewantne obiekty i powiązania między nimi. MoŜliwe jest pokazanie więcej niŜ jednego obiektu danej klasy.

MoŜna tu pokazywać teŜ informacje w rodzaju:

kierunek nawigowania,

nazwy linków,

itp., jak w modelu klas

pod warunkiem, Ŝe zwiększą, a nie zmniejszą czytelność diagramu.

(61)

Diagramy współpracy mogą dodatkowo pokazywać interakcje zachodzące między obiektami zaangaŜowanymi w realizację danego przypadku uŜycia.

Sekwencja interakacji oznacza tu sekwencję komunikatów przesyłanych między współpracującymi obiektami.

Diagramy współpracy - interakcje

(62)

:KsiąŜka :Członek

bibl.

PoŜycz (tytuł)

1: CzyMoŜnaPoŜyczyć

2: CzyTytułDostępny

2.1: ZaznaczWypoŜyczenie

linia Ŝycia obiektu

czas

aktywne

Ŝycie obiektu

Kolejność obiektów nie ma tu znaczenia, ale warto zadbać o

ść

Diagramy sekwencji ang. Sequence Diagram

(63)

bibl.

PoŜycz (tytuł)

2.1: ZaznaczWypoŜyczenie

Diagramy sekwencji - przekazywanie sterowania

(64)

bibl.

PoŜycz (tytuł)

2.1: ZaznaczWypoŜyczenie Na diagramach sekwencji, wyraźniej niŜ na diagramach współpracy,

moŜna pokazać przekazywanie sterowania.

Diagramy sekwencji - przekazywanie sterowania

(65)

:Sterowanie

:Dzwoniący :Odbierający

podniesienie słuchawki ton w słuchawce

wybór cyfry

łączenie

ton dzwonka uruchomienie dzwonka podniesienie słuchawki koniec tonu koniec dzwonienia

. . .

a b c d d’

{b - a < 1 sec.}

{c - b < 10 sec.}

Rozmowa jest łączona poprzez sieć {d’ - d < 5 sec.}

Diagramy sekwencji ograniczenia czasowe