4 tech mode faza proj drukartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_O...W Javie...

InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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ówInŜynieria oprogramowania – wykład : dr hab. inŜ. Kazimierz Subieta, PJWSTK , WarszawaInŜynieria oprogramowania: Andrzej Jaszkiewicz, Wyd.Helion 1997Projektowanie systemów informacyjnych – wykład: Ewa Stemposz, Kazimierz SubietaInstytut Podstaw Informatyki PAN, WarszawaSoftware Engineering, 7th edition, Ian Sommerville 2004


Motto

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

Georg Christoph Lichtenberg (1742 - 1799)


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


� Model cyklu Ŝycia projektów� Faza specyfikacji wymagań� Faza analizy

� Techniki obiektowe � Techniki strukturalne

� Faza projektowania� Komponenty

� Podsumowane





� Techniki obiektowe � Modelowanie statyczne

� Techniki strukturalne� Faza projektowania

� Komponenty� Podsumowane


Faza analizyTypy 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.


Faza analizyMetodyki 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.


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.


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.


Faza analizy Identyfikacja klas i obiektów

� 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


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?



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?



Klasa - notacja (1)

Okno Oknorozmiarczy_widoczne

Oknorozmiarczy_widocznewyświetl()schowaj()

Oknorozmiar: Obszarczy_widoczne: Booleanwyś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.

stereotypnazwa_ klasylista_wart_etyk

stereotyp , dostępnośćnazwa_atrybutu : typ = wart_początkowa

lista_wart_etyk

stereotyp dostępnośćnazwa_metody (lista_arg) : typ_wart_zwracanej

lista_wart_etykt


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.


«trwała» Prostok ąt

punkt1: Punktpunkt2: Punkt

«konstruktor»Prostokąt (p1: Punkt, p2: Punkt)

«zapytania»obszar (): Realaspekt(): Real...

«aktualizacje»przesuń (delta: Punkt)przeskaluj(współczynnik: Real)

Przykłady klasOkno

{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.

«»


Dziedziczenie (1)

spec

jaliz

acja

gene

raliz

acja

Pracownik

Osoba

Asystent Adiunkt ProfesorDocent Asystent Adiunkt ProfesorDocent

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.


Dziedziczenie (2)

Struktura typu pętlajest zabroniona

PracownikStudent

Osoba

Student_asystent

Struktura typu kratajest dopuszczalna

Student_asystent Pracownik

Student


Dziedziczenie (3)

NazwiskoUlicaWiek()

PensjaPokójZdjęcieObliczPensja()NowaPensja(...)

AlbumRokObliczStyp(...)WstawZliczenie()

JPEG GIF

Obraz

Rozmiar

PolaŜ(...)

OSOBA

STUDENT PRACOWNIK

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


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ódKoła : intSprawdźCiśnienieOgumienia()

ŁódźWyporność : intMierzZanurzenie()

AmfibiaWyporność : intMierzZanurzenie()


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

max_prędkość max_prędkośćprędk_eksploat()

AmfibiaSamochód Jacht

prędk_eksploat()

Pojazd wodnyPojazd 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 wielokrotneProblemy


Klasa abstrakcyjna a konkretna (1)

Osoba prawna

Osoba fizyczna Firma

Sekwencja

pierwszynastępny

Sekwencja int

... implementacje

Sekwencja char

...implementacje

� 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)


Atrybuty (1)Cechy

nazwisko : stringwiek : integer

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

Osoba :Osoba

nazwisko = Kowalskiwiek = 24

:Osoba

nazwisko = Nowakwiek = 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


Atrybuty (2)Dlaczego obiekty są rozróŜnialne

Osoba

id_osobyPesel : nrnazwisko : stringwiek : integer

Pesel : nrnazwisko : stringwiek : 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.


Pracownik

imięnazwiskonazwisko panieńskie [0..1]data ur./wiekadres zamieszkaniapłećstosunek do słuŜby wojsk. [0..1]lista poprz. miejsc pracy [0..*]adres firmyzdję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


nazwiskowiek

zmień pracęzmień_adres

nazwa_plikudługość w bajtachostatnia_zmiana

drukuj

kolorpozycja

przesuń ( delta: Wektor )wewnątrz ( p: Punkt ): Booleanobróć ( kąt )

Osoba Plik Obiekt geometryczny

MetodySpecyfikacja 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ę.


nazwiskowiek

zmień pracęzmień_adres

nazwa_plikudługość w bajtachostatnia_zmiana

drukuj

kolorpozycja

przesuń ( delta: Wektor )wewnątrz ( p: Punkt ): Booleanobróć ( kąt )

Osoba Plik Obiekt geometryczny

MetodySpecyfikacja 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ę.


Wykładowca

imięnazwiskodata ur./wiekadres zamieszkaniapł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)

MetodyRodzaje 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.


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

Pracowniknazwisko...zwolnij()...

Samodzielny prac.naukowy

zwolnij()

Decyzja o zwolnieniuw gestii dyrekcji

Decyzja o zwolnieniuw gestii sekretariatu PAN

MetodyPrzesł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.


Prostopadłościan Walec

pole podstawywysokość

Bryła

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

StoŜek

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

{incomplete}

{abstract}


� Przesłanianie jest ściśle powiązane z polimorfizmemmetod.

� Przesłanianie wymaga dynamicznego wiązania.

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




Bryła


StoŜek


{incomplete}

{abstract}





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;}




Bryła


StoŜek


{incomplete}

{abstract}





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).




Bryła


StoŜek


{incomplete}

{abstract}





Dwie metody implementujące operacjępolicz obj ętość. Metoda policz obj ętość w klasieBryła nie moŜe być metodąabstrakcyjną.


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ą.


:OsobaKasia

:FirmaKrawiecka

pracuje_w

:OsobaJasio

:FirmaSzewska

:OsobaEwa

pracuje_w pracuje_w

Obiekty i powiązaniana diagramie obiektów

Osobaimię

Firmarodzaj

pracuje_w

Klasy i asocjacjana diagramie klas

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

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


Firma Osobapracuje_dla 1..*1

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.


Grupa Student

Terminoddo

* 1..15

Grupa Student* 1..15

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ęść


Członekbibl. Personel

Pozycja

CzasopismoKsiąŜka

EgzemplarzksiąŜki

Osoba

/liczba wyp. akt. pozycji

*0..1

{ liczba wyp. akt.pozycji <= 12 }

{ liczba wyp. akt.pozycji <= 6 } 1..*

WypoŜyczeniedata wypoŜyczeniadata zwrotu

{ data zwrotu - data wypoŜyczenia<= 3 tygodnie }

*

*

wypoŜyczył

Asocjacja Przykład diagramu klas





� Techniki obiektowe � Stany dynamiczne


� Komponenty� Aplikacje WWW

� Podsumowane


Modelowanie dynamiczneDiagram 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


� Diagramy tego rodzaju wykorzystywane są do opisu zachowania obiektu

� Obrazują moŜliwe stany obiektu, zdarzenia jakie mogą być odbierane przezobiekt 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

Modelowanie dynamiczneDiagram stan – ang. State Diagram


� 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 nazdarzenie, określony przez wartości poszczególnych atrybutów klasy tegoobiektu

� 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)

Modelowanie dynamiczneDiagram stanu – notacja / terminologia


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,

Modelowanie dynamiczneDiagram 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.


Modelowanie dynamiczneDiagram stanu – typy

prosty (simple) nie posiada substruktury

złoŜony sekwencyjny(sequential compositestate)

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 oznaczeniapunktu startowego

końcowy(final state)

pseudostan słuŜący do oznaczenia punktufinalnego

złoŜony współbie Ŝny(concurrent compositestate)

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


� Zmiana stanu (ang. state transition) – przejście z obecnego stanu do stanu następnego w wyniku zdarzenialub 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.

Modelowanie dynamiczneDiagram stanu – zmiana stanu


op (a : T)

when (wyraŜenie)

nazwa_syg (a : T)

after (czas)

Modelowanie dynamiczneDiagram 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.)


� Stan początkowy i końcowy – dwa specjalne stany określająceodpowiednio początek diagramu stanów dla danego obiektu oraz jegokoniec. Diagram moŜe mieć jeden i tylko jeden stan początkowy i wielestanów końcowych. Stan początkowy oznacza stan obiektu zaraz po jegoutworzeniu, natomiast stan końcowy oznacza stan obiektu tuŜ przed jegousunięciem z systemu.

Modelowanie dynamiczneDiagram stanu – pocz ątek i koniec


Modelowanie dynamiczneDiagram stanu – przykład (1)


Urządzenieniesprzedane

Urządzeniesprzedane

kupno urządzenia przez klienta

klient zwrócił urządzenieafter (data gwarancji)

Kolejkabiałych

Kolejkaczarnych

ruch białychruch czarnychremis

białe wygrywają

when (szach mat)

when (pat)

when (pat)

when (szach mat)

Diagram typu: cykl Ŝycia obiektu

Diagram typu: przepływ sterowania




Jazda do przoduna 1-szym

biegu

Jazda do przoduna 2-gim

bieguJazda do tyłu

Samochódzatrzymany

wybrano 1-szy bieg

naciśnięto hamulec

wybrano następnybieg

wybranopoprzednibieg

naciśniętohamulec

naciśniętohamulec

wybranowsteczny bieg


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

synchronizacjawewn ętrzna

synchronizacjazewnętrzna

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

Oba diagramy są ównowaŜne.


WspółbieŜność - obiekty zagregowane

Samochód

Zapłon Bieg Hamulec Gaz hamulecpuszczony

Hamulec

Włącz.Wył.

hamulecnaciś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.


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ł. Włącz.Zapala

kluczyk do max w prawo[Biegi w pozycji 0]

kluczyk do poz wył

Biegi....

Gaz....


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

Gotowydo 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


� 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ć stosowanediagramy innego rodzaju np. activity)

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

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

Modelowanie dynamiczneDiagram stanu – podsumowanie


� 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 dynamiczneDiagramy interakcji


� 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.

Modelowanie dynamiczneDiagramy interakcji – współpracy i sekwencji


:Personelbibl.

:Członekbibl.

: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 dynamiczneDiagramy współpracy


:Personelbibl.

:Członekbibl.

:KsiąŜka


Modelowanie dynamiczneDiagramy 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.


� 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.

Modelowanie dynamiczneDiagramy współpracy - interakcje


:Personelbibl.

:KsiąŜka:Członekbibl.


PoŜycz (tytuł)

1: CzyMoŜnaPoŜyczyć

2: CzyTytułDostępny

2.1: ZaznaczWypoŜyczenie

linia Ŝycia obiektu

czas

aktywneŜycie obiektu

Kolejność obiektównie ma tu znaczenia, ale warto zadbać o czytelność.

Modelowanie dynamiczneDiagramy sekwencji ang. Sequence Diagram


:Personelbibl.

:KsiąŜka:Członekbibl. :Egzemplarz KsiąŜki

PoŜycz (tytuł)




Modelowanie dynamiczneDiagramy sekwencji - przekazywanie sterowania


:Personelbibl.

:KsiąŜka:Członekbibl. :Egzemplarz KsiąŜki

PoŜycz (tytuł)




Na diagramach sekwencji, wyraźniej niŜ na diagramach współpracy, moŜna pokaza ć przekazywanie sterowania.

Modelowanie dynamiczneDiagramy sekwencji - przekazywanie sterowania


: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.}

Modelowanie dynamiczneDiagramy sekwencji ograniczenia czasowe


Modelowanie dynamiczneDiagram aktywno ści ang. Activity Diagram

� Diagramy aktywności w swej zasadniczej idei są dokładnie tym samym, co diagramy przepływu sterowania (flowcharts, control flowdiagrams). Jedyną róŜnicą koncepcyjną jest to, Ŝe pojawiają się na nich elementy synchronizacji równoległych procesów (w dośćuproszczonej formie, która dla pewnych celów moŜe byćniewystarczająca).

� Diagramy aktywności są szczególnym przypadkiem diagramów stanów.


Modelowanie dynamicznePodsumowanie

� Pomoc dla projektanta w tworzeniu adekwatnego do zadania modelu obiektowego (diagramu klas).

� Analiza zachowania systemu w trakcie realizacji jego zadań i identyfikowaniu nowych czy teŜ korekcie juŜ istniejących elementów modelu, np.: klas, ich atrybutów czy metod oraz asocjacji między klasami.

� Struktura, opisywana przez model obiektowy, musi zapewnić moŜliwość realizacji zadań postawionych przed systemem.

� Diagramy kolaboracji, stanowiące w pewnym sensie wystąpienia fragmentu diagramu klas, lepiej przedstawiają związki między obiektami biorącymi udział w realizacji danego przypadku uŜycia. Łatwiej teŜ moŜna tu odwzorować efekty oddziaływania na pojedynczy obiekt - wykorzystując np. łańcuch własności.

� Diagramy sekwencji lepiej przedstawiają zaleŜności czasowe, bardziej niŜdiagramy kolaboracji nadają się do modelowania systemów czasu rzeczywistego i złoŜonych scenariuszy.

� Diagramy aktywności to odwzorowanie przepływu sterowania z synchronizacjąrównoległych procesów (w dość uproszczonej formie, która dla pewnych celów moŜe być niewystarczająca).






� Techniki strukturalne� DFD� ERD

� Faza projektowania� Komponenty

� Podsumowane


Faza analizy Techniki proceduralne

� Programowanie proceduralne to paradygmat programowania:� zalecający dzielenie kodu na procedury, � czyli fragmenty wykonujące ściśle określone operacje.

� Procedury:� Nie powinny korzystać ze zmiennych globalnych (w miarę moŜliwości),

lecz pobierać i przekazywać wszystkie dane (czy teŜ wskaźniki do nich) jako parametry wywołania.

� Instrukcje goto mogą być wprawdzie uŜywane w procedurach, ale w Ŝadnym wypadku celem wskoczenia w środek innej procedury.


Faza analizyProgramowanie strukturalne

� Programowanie strukturalne to paradygmat programowania:� zalecający hierarchiczne dzielenie kodu na moduły, które komunikują się

jedynie poprzez dobrze określone interfejsy. � Jest to rozszerzenie koncepcji programowania proceduralnego.� jest to raczej pewna poddyscyplina lub podzbiór programowania

proceduralnego zalecająca stosowanie konstrukcji języka takich jak pętle i instrukcje warunkowe, oraz unikanie instrukcji goto i wielokrotnych punktów wejścia i wyjścia z kodu danego podbloku programu.


Faza analizyProgramowanie strukturalne

� W analizie strukturalnej opartej na popularnej metodzie E. Yourdona [1989] język do modelowania zawiera następujące elementy:

� diagramy przepływu danych - DFD (data flow diagrams),� specyfikacje procesów - PSPEC (process specifications),� diagramy relacyjne danych - ERD (entity-relationship diagrams),� diagram przejść przez stany - STD (state-transition diagram),� słownik danych - DD (data dictionary).


Data Flow Diagram - diagramy przepływów danych

� SłuŜą do prezentowania sposobu w jaki dane przepływają oraz sąprzetwarzane w systemie. Opisują równieŜ procesy przetwarzające dane� Stanowią podstawę wielu istniejących modeli� Prosta, intuicyjna i łatwa w zrozumieniu notacja� Zastosowania:

� Modelowanie przetwarzania danych na róŜnych poziomach począwszy od bardzo zgrubnych do bardzo szczegółowych modeli

� Opis architektury systemu obrazujący przepływ danych pamiędzyposzczególnymi elementami systemu

� Nie powinno się stosować diagramów tego rodzaju do opisu i definicji interfejsów


Data flow - podstawowe elementy

� Zbiorniki danych (ang. data stores) - składowa systemu przechowującadane

� Procesy (ang. process) - dowolne operacje wykonywane przez system. W wyniku wykonania operacji moŜe następować modyfikacja danych


Data flow - podstawowe elementy

� Systemy zewnętrzne (ang. external systems) - zewnętrzne, w stosunku do modelowanego, system z którym wymieniane są dane.

� Przepływ danych (ang. data flow) - opisuje dane przesyłane międzyprocesami, systemami zewnętrznymi i zbiornikami danych


Data flow - przykład (1/3)


References

Applicant

ProcessApplication

Application

ApplicationList ApplicationDetails

Administrator

Approval Code, Reference Updates

ReviewApplication

For ReviewApplication

ReviewedApplication

ApplicationStatus

Notification



Approval Code, Reference Updates

Administrator

For ReviewApplication

ApplicationList

ReviewedApplication

ApplicationStatus

Notification

Applicant

CheckPermissible

StatusChange

PermittedStatus

Change

PermissionTable

PermissibleApplication

ProcessReferences

ImPermissibleApplication

Rejection Notice

Create StatusNotification

Approve/Reject

References



Data flow - niedopuszczalne przepływy danych


Specyfikacja procesów PSPEC (process specifications)

� Specyfikacji podlegają procesy elementarne tzn. takie, których nie dekomponuje się na diagramy DFD niŜszego poziomu.

� Istnieje znaczna dowolność co do sposobu specyfikacji procesów:� nazwę procesu (indeks procesu, np. w konwencji "kropkowej" - 3.5.7)

� dane wejściowe

� dane wyjściowe� opis algorytmu (najczęściej w języku quasi-programowania zmieszanym z językiem

naturalnym)



Start:Wprowadzenie

zamówienia

Stan:zweryfikowane

Stan:wysłane

WeryfikacjaZamówienia

WysłanieopóŜnione

t>10 dnizrealizowane

Otrzymanie produktu



� Sygnalizowanie stanu zapasów

Akceptowany stan zapasów

Nieakceptowany stan zapasów - alarm

Tranzakcja S Stan - sprzedaz<próg

Tranzakcja SStan - sprzedaŜ > próg

Tranzakcja DStan +D <próg


ERD - Analiza relacyjna

W modelu relacyjnym odwzorowanie percepcjiświata jest ograniczoneśrodkamiimplementacyjnymi. W rezultacie, schemat relacyjny gubi część semantyki danych. Model obiektowy podtrzymuje te zgodności, przybliŜając semantykę danych do światarzeczywistego.

Model pojęciowy Model struktur danych

... ... ...... ... ...... ... ...

... ... ...... ......... ... ...

Percepcjaświata


ERD - Analiza relacyjna

W modelu relacyjnym odwzorowanie percepcjiświata jest ograniczoneśrodkamiimplementacyjnymi. W rezultacie, schemat relacyjny gubi część semantyki danych. Model obiektowy podtrzymuje te zgodności, przybliŜając semantykę danych do światarzeczywistego.

Model pojęciowy Model struktur danych

... ... ...... ... ...... ... ...

... ... ...... ......... ... ...

Percepcjaświata

Długofalową tendencją w rozwoju systemów zarządzanaia bazami danych jest uzyskanie zgodności pomiędzy tymi modelami.

Chodzi o uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości(percepcją świata),

a myśleniem o danych i procesach, które na danych zachodzą.


FirmaNazwaLokal [1..*]

PracownikZawód [*]

OsobaNazwiskoImię [1..*]Adres [1..*]

Zatrudnienie

Wypłata [*] Ocena [*]

Firma (NrF, Nazwa)

Lokal (NrF, Lokal) Zatrudnienie (NrF, NrP)

Pracownik (NrP, NrOs)

Ocena (NrOceny, Ocena, NrF, NrP)

Wypłata (NrWypłaty, Wypłata, NrF, NrP) Osoba (NrOs, Nazwisko)

Zawód (Zawód, NrP)

Imi ę (NrOs, Imię) Adres (NrOs, Adres)

1..* *Pojęciowyschematobiektowy:

Schematrealizacyjny(relacyjny):

Schemat relacyjny jest trudniejszy do zinterpretowania- w efekcie większa ilość błędów.


Diagram relacyjny danych ERD - Elementy

� Relacja� Zakończenia

� Obiekt

� Obiekt słaby

� Obiekt Asocjacyjny

� Relacja wzajemnego wyłączania się


Diagram relacyjny PrzykładyPrzykład systemu organizacji zamówień

Customer

Order

SalesRepresentative

Stock

Supplier

Product-Supplier

PrepayCustomer

CreditCustomer

Return

DamagedReturn

WrongSize Return

WrongColor Return

OrderLine Item

ShipLine Item

Shipment

ReturnLine Item

Places

Handles

Is For

Obtained from

Is SupplierFor

Returns

Consists Of

AssociatedWith

Contains

Is For

Consists Of

ForRelated To


Podstawowe rezultaty fazy analizy� Poprawiony dokument opisujący wymagania� Słownik danych zawierający specyfikację modelu� Dokument opisujący stworzony model, zawierający:

� diagram klas� diagram przypadków uŜycia� diagramy sekwencji komunikatów (dla wybranych sytuacji)� diagramy stanów (dla wybranych sytuacji)� raport zawierający definicje i opisy klas, atrybutów, związków,� metod, itd.

� Harmonogram fazy projektowania� Wstępne przypisanie ludzi i zespołów do zadań







� Komponenty� Podsumowane


ProjektowanieSpecyfikacja i analiza

wymagań

Projektowanie

Implementacja,Testowanie modułów

IntegracjaWalidacja

WdroŜenie,Utrzymanie

Specyfikacja i analizawymagań Projektowanie Implementacja Testowanie

WdroŜenieUtrzymanie

Faza strategiczna Analiza Instalacja

Dokumentacja


Projektowanie

� Celem projektowania jest opracowanie szczegółowego opisu implementacji systemu.

� W odróŜnieniu od analizy:� duŜą role odgrywa środowisko implementacji. � Projektanci muszą więc posiadać dobrą znajomość języków,

bibliotek, i narzędzi stosowanych w trakcie implementacji.

� DąŜenie do tego, aby struktura projektu zachowała ogólną strukturę modelu stworzonego w poprzednich fazach (analizie). � Niewielkie zmiany w dziedzinie problemu powinny implikować

niewielkie zmiany w projekcie.


ProjektowanieZadania wykonywane w fazie projektowania

� Uszczegółowienie wyników analizy. � Projekt musi być wystarczająco szczegółowy aby mógł być podstawą

implementacji. � Stopień szczegółowości zaleŜy od poziomu zaawansowania programistów.

� Projektowanie składowych systemów nie związanych z dziedziną problemu

� Optymalizacja systemu

� Dostosowanie do ograniczeń i moŜliwości środowiska implementacji

� Określenie fizycznej struktury systemu.


ProjektowanieProjektowanie składowych systemu nie związanych z dziedziną problemu

Składowadziedzinyproblemu

Składowadziedzinyproblemu

Składowazarządzania

danymi


danymi

Składowazarządzaniazadaniami

Składowazarządzaniazadaniami

Składowainterfejsu

uŜytkownika

Składowainterfejsu

uŜytkownika


pamięcią


pamięcią

(do 90% nakładów;obecnie poprzez GUI)

(kompilatorsystem operac.)

(kompilatorsystem operac.)

(SZBD)

� składowej interfejsu uŜytkownika� składowej zarządzania danymi

(przechowywanie trwałych danych)� składowej zarządzania pamięcią

operacyjną� składowej zarządzania zadaniami

(podział czasu procesora)


Projektowanie Określenie fizycznej struktury systemu

Oznaczenia (Booch)

Nazwa Nazwa

NazwaDeklaracja: Definicja:Modułgłówny:

� Określenie struktury kodu źródłowego, tj. wyróŜnienie plików źródłowych, zaleŜności pomiędzy nimi oraz rozmieszczenie skłądowychprojektu w plikach źródłowych.

� Podział systemu na poszczególne aplikacje� Fizyczne rozmieszczenie danych i aplikacji na stacjach roboczych i

serwerach.


Projektowanie Przykład zaleŜności kompilacji dla C++

Symbol.h Symbol.c

Punkt.h


Projektowanie Graficzny opis sprz ętowej konfiguracji systemu

Serwer bazdanych działu

kontroli jakości

Główny serwer bazy danych

przedsiębiorstwa

Serwer bazdanych działumarketingu

Serwer aplikacji działu

marketingu

Serwer bazdanych działufinansowego

Serwer plików działu

finansowego

PC

PC

PC

PC

Płace

PC

PC

PC

PC

Działmarketingu

PC PCPC

Zakupy


Projektowanie Podstawowe rezultaty fazy projektowania

� Poprawiony dokument opisujący wymagania� Poprawiony model

� Uszczegółowiona specyfikacja projektu zawarta w słowniku danych� Dokument opisujący stworzony projekt składający się z (dla obiektowych):

� diagramu klas� diagramów interakcji obiektów

� diagramów stanów

� innych diagramów, np. diagramów modułów, konfiguracji

� zestawień zawierających:

� definicje klas� definicje atrybutów

� definicje danych złoŜonych i elementarnych

� definicje metod


Projektowanie Podstawowe rezultaty fazy projektowania

� Zasoby interfejsu uŜytkownika, np. menu, dialogi� Projekt bazy danych

� Projekt fizycznej struktury systemu� Poprawiony plan testów� Harmonogram fazy implementacji

4 tech mode faza proj drukartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_O...W Javie...

Documents

Transcript of 4 tech mode faza proj drukartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_O...W Javie...