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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 2
Motto
Droga prosta jest najkrótsza, ale na ogół wymaga najwięcej czasu, aby dojść nią do celu.
Georg Christoph Lichtenberg (1742 - 1799)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 4
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 � Modelowanie statyczne
� Techniki strukturalne� Faza projektowania
� Komponenty� Podsumowane
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 5
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 6
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 9
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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 Identyfikacja klas i obiektów
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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 Identyfikacja klas i obiektów
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 12
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 14
«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.
«»
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 15
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 16
Dziedziczenie (2)
Struktura typu pętlajest zabroniona
PracownikStudent
Osoba
Student_asystent
Struktura typu kratajest dopuszczalna
Student_asystent Pracownik
Student
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 17
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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ódKoła : intSprawdźCiśnienieOgumienia()
ŁódźWyporność : intMierzZanurzenie()
AmfibiaWyporność : intMierzZanurzenie()
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 19
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 20
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)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 21
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 22
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 23
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 24
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ę.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 25
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ę.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 26
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 27
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 28
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}
MetodyPrzesłanianie metod (2)
� 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 .
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 29
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}
MetodyPrzesłanianie metod (2)
� 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 .
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;}
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 30
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}
MetodyPrzesłanianie metod (2)
� 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 .
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).
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 31
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}
MetodyPrzesłanianie metod (2)
� 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 .
Dwie metody implementujące operacjępolicz obj ętość. Metoda policz obj ętość w klasieBryła nie moŜe być metodąabstrakcyjną.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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ą.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 33
: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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 34
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 35
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ęść
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 36
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 37
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 � Stany dynamiczne
� Techniki strukturalne� Faza projektowania
� Komponenty� Aplikacje WWW
� Podsumowane
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 38
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 39
� 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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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 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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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,
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 42
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ść)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 43
� 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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 44
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.)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 45
� 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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 46
Modelowanie dynamiczneDiagram stanu – przykład (1)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 47
Modelowanie dynamiczneDiagram stanu – przykład (2)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 48
Modelowanie dynamiczneDiagram stanu – przykład (3)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 49
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
Modelowanie dynamiczneDiagram stanu – przykład (4)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 50
Modelowanie dynamiczneDiagram stanu – przykład (5)
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 51
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 52
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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ł. Włącz.Zapala
kluczyk do max w prawo[Biegi w pozycji 0]
kluczyk do poz wył
Biegi....
Gaz....
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 54
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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ć 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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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 dynamiczneDiagramy interakcji
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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.
Modelowanie dynamiczneDiagramy interakcji – współpracy i sekwencji
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 59
: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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 60
:Personelbibl.
:Członekbibl.
:KsiąŜka
:Egzemplarz KsiąŜki
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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.
Modelowanie dynamiczneDiagramy współpracy - interakcje
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 62
:Personelbibl.
:KsiąŜka:Członekbibl.
:Egzemplarz KsiąŜki
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 63
:Personelbibl.
:KsiąŜka:Członekbibl. :Egzemplarz KsiąŜki
PoŜycz (tytuł)
1: CzyMoŜnaPoŜyczyć
2: CzyTytułDostępny
2.1: ZaznaczWypoŜyczenie
Modelowanie dynamiczneDiagramy sekwencji - przekazywanie sterowania
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 64
:Personelbibl.
:KsiąŜka:Członekbibl. :Egzemplarz KsiąŜki
PoŜycz (tytuł)
1: CzyMoŜnaPoŜyczyć
2: CzyTytułDostępny
2.1: ZaznaczWypoŜyczenie
Na diagramach sekwencji, wyraźniej niŜ na diagramach współpracy, moŜna pokaza ć przekazywanie sterowania.
Modelowanie dynamiczneDiagramy sekwencji - przekazywanie sterowania
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 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.}
Modelowanie dynamiczneDiagramy sekwencji ograniczenia czasowe
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 66
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 67
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).
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 68
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 � Stany dynamiczne
� Techniki strukturalne� DFD� ERD
� Faza projektowania� Komponenty
� Podsumowane
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 69
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 70
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 71
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).
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 72
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 73
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 74
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 76
References
Applicant
ProcessApplication
Application
ApplicationList ApplicationDetails
Administrator
Approval Code, Reference Updates
ReviewApplication
For ReviewApplication
ReviewedApplication
ApplicationStatus
Notification
Data flow - przykład (1/3)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 77
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 - przykład (1/3)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 79
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)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 80
Specyfikacja procesów PSPEC (process specifications)
Start:Wprowadzenie
zamówienia
Stan:zweryfikowane
Stan:wysłane
WeryfikacjaZamówienia
WysłanieopóŜnione
t>10 dnizrealizowane
Otrzymanie produktu
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 81
Specyfikacja procesów PSPEC (process specifications)
� 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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 82
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 83
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ą.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 84
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 85
Diagram relacyjny danych ERD - Elementy
� Relacja� Zakończenia
� Obiekt
� Obiekt słaby
� Obiekt Asocjacyjny
� Relacja wzajemnego wyłączania się
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 86
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 87
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ń
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 88
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 � Stany dynamiczne
� Techniki strukturalne� Faza projektowania
� Komponenty� Podsumowane
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 89
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 90
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 91
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 92
ProjektowanieProjektowanie składowych systemu nie związanych z dziedziną problemu
Składowadziedzinyproblemu
Składowadziedzinyproblemu
Składowazarządzania
danymi
Składowazarządzania
danymi
Składowazarządzaniazadaniami
Składowazarządzaniazadaniami
Składowainterfejsu
uŜytkownika
Składowainterfejsu
uŜytkownika
Składowazarządzania
pamięcią
Składowazarządzania
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)
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 93
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.
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 94
Projektowanie Przykład zaleŜności kompilacji dla C++
Symbol.h Symbol.c
Punkt.h
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 95
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
InŜynieria Oprogramowania WSZiBSemestr IV, slajd 96
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
Top Related