Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Inżynieria Oprogramowania WSZiBSemestr IV
Zalety projektowania obiektowego
Łatwe zarządzanie
Możliwość powtórnego użycia klas obiektów –projektowanie/programowanie komponentowe
W wielu przypadkach występuje stosunkowo prostemapowanie pomiędzy elementami rzeczywistegośrodowiska systemu a obiektami
Wsparcie ze strony narzędzi programistycznych orazistnienie standardu notacji obiektowej (UML)
Inżynieria Oprogramowania WSZiBSemestr IV
Obiekty - komunikacja
Koncepcyjnie obiekty komunikują się poprzez przesyłaniewiadomości/komunikatów gdzie nazwa wiadomości określausługę do wykonania. Wiadomość zawiera również informacjeniezbędne do wykonania operacji oraz posiada możliwośćzwracania wartości będących wynikiem wykonania operacji
W praktyce przekazywanie wiadomości realizowne jest jakowywołanie metod zdefiniowanych w klasie obiektu:
Nazwa metody == nazwa wiadomości
Informacja == wartości paremetrów metody
Wynik operacji == wartość zwracana przez metodę
Inżynieria Oprogramowania WSZiBSemestr IV
Proces tworzenia modelu obiektowego
Identyfikacja kontekstu (środowiska) pracy systemu
Określenie przypadków (modeli) wykorzystaniasystemu
Budowa obiektowego modelu architektury systemu:
Identyfikacja klas i obiektów
Identyfikacja związków klas i obiektów
Identyfikacja atrybutów klas
Identyfikacja i definiowanie metod i komunikatów –interfejsy obiektów
Inżynieria Oprogramowania WSZiBSemestr IV
Przykład - system gromadzenia informacji pogodowych - opis
System gormadzenia informacji pogodowych (weather forecastsystem) służy do automatycznej generacji map pogodowych napodstawie danych gromadzonych przez zdalne stacje pogodowe(weather station) i inne źródła informacji pogodowych takie jaksatelity i balony obserwcyjne. Każda stacja pogodowa przesyłazgromadzone dane do centralnego komputera w odpowiedzi najego zapytanie. Komputer centralny weryfikuje otrzymane daneoraz integruje wszystkie dane przesłane z różnych źródeł.Zgromadzone w ten sposób dane przechowywane są warchiwum danych. Na podstwie zapisanych informacji i bazymap system generuje lokalne mapy pogodowe dla różnychobszarów. Stworzone mapy mogą być drukowane na ploterzelub wyświetlane w różnych formatach.
Inżynieria Oprogramowania WSZiBSemestr IV
Opis stacji pogodowej (weather station)
Stacja pogodowa (weather station) jest zbiorem przyrządówpomiarowych kontrolowanych za pomocą specjalizowanegooprogramowania. Przyrządy pomiarowe gromadzą danepogodowe (np. temperaturę powietrza, wilgotność itp.), którenastępnie zostają poddane wstępnej analizie i w odpowiedzi nażądanie zostają przesłane do centralnego komputera. W składprzyrządów pomiarowych wchodzą termometry mierzącetemperaturę powietrza i ziemi, prędkość wiatru, ciśnienie orazilość opadów. Dane z poszczególnych przyrządów odczytywanesą w pięciominutowych odstępach. W momencie gdy zostanieodebrane żądanie przesyłu danych, oprogramowanie stacjipogodowej przetwarza zgromadzone dane i przesyła wynikiprzetwarzania do komputera centralnego.
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja kontekstu pracy systemu
Kontekst pracy systemuokreśla poszczególneelementy wchodzącew skład systemu lubstanowiące jego otoczenie,z którym systemwchodzi w interakcję
Inżynieria Oprogramowania WSZiBSemestr IV
Określenie przypadków wykorzystania systemu – przykład stacji pogodowej
Dynamiczny model określającysposób interakcji systemuz poszczególnymi elementamiotaczającego środowiska
Inżynieria Oprogramowania WSZiBSemestr IV
Opis przypadku użycia (ang. use-case)System: stacja pogodowa (weather station)
Use-case: send report
Aktorzy: podsystem data collection
Przetwarzanie: w odpowiedzi na żądanie stacja pogodowa przesyła dane zgromadzone
przez poszczególne przyrządy pomiarowe w ostatnim okresie
gromadzenia danych. Przesyłane dane dotyczą minimalnej, maksymalnej
i średniej temperatury powietrza i ziemi, minimalnego, maksymalnego i
średniego ciśnienia powietrza, minimalnej, maksymalnej i średniej
prędkości wiatru, całkowitej ilości opadów
Zdarzenie: podsystem data collection zestawia modemowe połączenie do stacji
pogodowej i przesyła żądanie transmisji zgromadzonych danych
Odpowiedź: zgromadzone w ostatnim okresie dane zostają przesłane do podsystemu
data collection
Komentarz: podystem data collection wysyła żądania przesłania raportów do stacji
pogodowych w odstępach nie krótszych niż 10 minut
Inżynieria Oprogramowania WSZiBSemestr IV
Budowa obiektowego modelu architektury systemu
Identyfikacja związkówklas i obiektów
Identyfikacja i definiowanieatrybutów
Identyfikacjaklas i obiektów
Identyfikacja metodi komunikatów
Inżynieria Oprogramowania WSZiBSemestr IV
Logiczny model architektury systemu dla stacji pogodowej
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja klas i obiektów – metoda klasyczna (1/2)
Poszukiwanie klas obiektów polegające na obserwacji, klas iobiektów w innych systemach. Na podstawie analizy listytypowych klas określa się klasy obiektów w analizowanymsystemie. Do typowych klas można zaliczyć:
przedmiot namacalne (np.: samochód, czujnik)
role pełnione przez osoby (np.: pracownik, student, wykładowca)
zdarzenia, o których system przechowuje informacje (np.:zamówienie, dostawa)
interakcje pomiędzy osobami, systemami, o których systemprzechowuje informacje (np.: spotkanie, konferencja)
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja klas i obiektów – metoda klasyczna (2/2)
lokalizacje – miejsca przeznaczone dla ludzi lub przedmiotów (np.:magazyn, mieszkanie)
grupy przedmiotów namacalnych (np.: czujniki, studenci)
organizacje (np.: firma, wydział, uczelnia)
koncepcje (np.: miara jakości)
dokumenty (np.: faktura, prawo jazdy)
interfejsy dla sytemów zewnętrznych lub urządzeń
Należy zwrócić uwagę, że pewne elementy mogą posiadaćdwojakie znaczenie w zależności od interpretacji np.: pracownikmoże oznaczać klasę opisującą jeden z elementów systemu(np.: w systemie finansowo-księgowym) jak również systemzewnętrzny – użytkownika systemu
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja klas i obiektów – metoda analizy opisu w języku naturalnym
Na podstawie sporządzonego w fazie analizy wymagańopisu systemu określa się klasy obiektów oraz związane znimi operacje. W opisie wyróżnia się rzeczowniki (wraz zopisującymi je przymiotnikami) oraz czasowniki.Rzeczowniki traktuje sie jako potencjalne klasy, obiektylub atrybuty. Czasowniki to potencjalne metody lub związkipomiędzy klasami.
Ze względu na niejednoznaczność i wieloznaczność językanaturalnego może powstać wiele czasami niepotrzebnychklas obiektów lub łączących je releacji.
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja klas i obiektów – metoda analizy funkcji (przypadków użycia)
Analizie poddawane są kolejne use-case’ystworzone w fazie analizy wymagań. Napodstawie opisu skojarzonego z każdym use-case’m tworzony jest scenariusz interakcjiobiektów jednocześnie wprowadzając niezbędneklasy i metody.
Inżynieria Oprogramowania WSZiBSemestr IV
Weryfikacja klas i obiektów (1/2)
Weryfikując konieczność wprowadzenia danejklasy należy wziąć pod uwagę następująceczynniki:
Brak atrybutów i metod – z reguły oznacza to, że klasaznajduje się poza zakresem odpowiedzialności systemu
Nieliczne pojedyńcze atrybuty i metody – istniejemożliwość, że pola i metody mogą zostać umieszczonew innej klasie
Inżynieria Oprogramowania WSZiBSemestr IV
Weryfikacja klas i obiektów (1/2)
Tylko jeden obiekt danej klasy – w pewnychprzypadkach może to oznaczać zbyt rozbudowanąhierachię dziedziczenia. Przykładowo dobrą klasą jest„samochód” ze specjalizacją np.: „samochód ciężarowy”natomiast błędną specjalizacją jest np.: „samochódstudenta X”
Brak związków z innymi klasami – z reguły oznacza to,że klasa znajduje się poza zakresem odpowiedzialnościsystemu
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja atrybutów klas (1/3)
Identyfikując pola klas należy spróbowaćodpowiedzieć na następujące pytania:
Jakie informacje potrzebne są do opisu klasy w ramachdziedziny problemu (np. klasa student wymagaatrybutów określających imię, nazwisko, nr albumu itp.)
Jakie dane będą potrzebne obiektom danej klasy dorealizacji zadań (np.: klasa określająca grupęstudentów musi posiadać kolekcję przechowującą np.:identyfikatory studentów należących do danej grupy)
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja atrybutów klas (2/3)
Jakie pola należy wprowadzić, aby opisać stany w jakichmogą znajdować się obiekty danej klasy (np.: klasaopisująca wiadomości email może posiadać atrybutokreślający stan jako wysłany, odebrany, zwrócony)
Na podstawie opisu w języku naturalnym można poprzezanalizę występowania rzeczowników określić podstawoweatrybuty klas
Interfejs GUI zaakceptowany przez użytkownika możedostarczyć bardziej szczegółowych informacji na tematwprowadzanych, edytowanych i prezentowanych danych,które powinny być przechowywane jako atrybutyodpowiednich klas
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja atrybutów klas (3/3) –przykład błędów w umieszczaniu atrybutów w hierachii klas
Atrybut umieszczony zbytwysoko w hierachii gdyżnie każdy student pracuje
Atrybuty umieszczony zbyt nisko w hierachii przez coniepotrzebnie powtarzają się w definicji klas pochodnychpomimo tego, że określają tę samą właściwość
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja metod i komunikatów klas
Metody klas możemy zgrubnie podzielić na dwiekategorie:
Algorytmicznie proste
Algorytmicznie złożone
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja metod i komunikatów klas
Metody algorytmicznie proste:
Konstruktory/destruktory oraz metody inicjalizującestan obiektów klasy
Metody służące do pobierania wartości publicznychatrybutów klasy
Metody służące do ustawiania wartości atrybutów klas
Metody służące do implementacji związków pomiędzyklasami (np.: agregacji)
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja metod i komunikatów klas
Metody algorytmicznie złożone:
Metody służące do realizacji obliczeń
Metody służące do monitorowania pracy systemów i urządzeń zewnętrznych
.... (wszystkie inne nie będące metodami prostymi)
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja metod i komunikatów klas – analiza przypadków użycia (1/3)
Definiowanie metod klas poprzez analizę sposoburealizacji funkcji systemu wynikających z analizyposzczególnych use-case’ów
Scenariusz przepływu komunikatów (wywołańmetod) między obiektami systemu tworzony jestwedług następującego schematu:
Wybranie jednego z komunikatów otrzymywanychprzez system (zwykle jeden z use-caseów)
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja metod i komunikatów klas – analiza przypadków użycia (2/3)
Określenie klasy, która otrzyma komunikat (jeżeli klasajeszcze nie istnieje należy ją stworzyć)
Wybranie metody, która będzie obsługiwała komunikatlub stworzenie nowej
Określenie czy do realizacji funkcji wystarczy jednametoda. Jeżeli metoda nie jest elementarna należyokreślić jakie obiekty i odpowiednie ich metody będąbrały udział w jej realizacji (krok ten może zostaćwykonany w kolejnej iteracji)
Inżynieria Oprogramowania WSZiBSemestr IV
Identyfikacja metod i komunikatów klas – analiza przypadków użycia (3/3)
Inżynieria Oprogramowania WSZiBSemestr IV
Diagramy interakcji (ang. interaction diagrams)
Diagramy interakcji: Sequence diagram
Collaboration diagram
Diagramy interakcji należą do grupy pięciu diagramówwykorzytywanych w UML do modelowania dynamicznychaspektów systemów
Każdy diagram interakcji prezentuje dynamiczne zależnościpomiędzy obiektami wchodzącymi w skład systemu, którewzjemnie wymieniając komunikaty (ang. message)współdziałają w realizacji określonej funkcjonalnościsystemu.
Inżynieria Oprogramowania WSZiBSemestr IV
Diagramy interakcji - komunikaty
Komunikat stanowi jedyną metodę wymiany informacjipomiędzy obiektami
Komunikat wysłany do obiektu pewnej klasy oznaczażądanie wykonania jednej z metod tej klasy
Komunikat może być wysłany przez system zewnętrzny lubprzez obiekt jednej z klas systemu
Wysłanie komunikatu może wiązać się z przekazaniempewnych danych wejściowych do wywoływanej metodyoraz z pobraniem danych wyjściowych zwracanych przezmetodę
Nazwa komunikatu jest nazwą wywoływanej metody
Inżynieria Oprogramowania WSZiBSemestr IV
Diagramy typu sequence (1/5)
Diagramy typu sequence prezentują przepływkomunikatów pomiędzy wspołdziałającymiobiektami zwracając uwagę na kolejność komunikatów wczasie
Zazwyczaj stosowane są do opisywania szczegółówzachowania obiektów systemu i systemów zewnętrznych wramach pojedyńczych use case’ów
Diagramy sequence zawierają następujące elementy:
Obiekty
Komunikaty
Inżynieria Oprogramowania WSZiBSemestr IV
Diagramy typu sequence (2/5)
Nazwa klasy obiektu
Linia życia obiektu
Nazwa obiektu(instancji klasy)
Inżynieria Oprogramowania WSZiBSemestr IV
Diagramy typu sequence (3/5)
Powrót z wykonania metodyPrzesłanie komunikatu -synchroniczne wywołanie
metody
Komunikat tworzący nową instancję klasy
Obiekty
Czas
Inżynieria Oprogramowania WSZiBSemestr IV
Diagramy typu sequence (4/5)
Rodzaje komuniaktów:
Synchroniczne
Asynchroniczne
Tworzące nowe instancje klas
Usuwające istniejące instancje klas
Powroty z wywołania metod
Inżynieria Oprogramowania WSZiBSemestr IV
Diagramy typu sequence (5/5)
Usunięcie instancjiKomunikat asynchroniczny
Inżynieria Oprogramowania WSZiBSemestr IV
Diagram sequence opisany skryptem
Użytkownik żąda wyświetlenia diagramu
Wyświetlane są wszystkie figury,z których składa się diagram
Użytkownik może wydać kolejnepolecenie po zakończeniu realizacji
wyświetlania diagramu
Skrypt
Inżynieria Oprogramowania WSZiBSemestr IV
Podstawowe błędy popełniane w diagramach typu sequence
Symbol komunikatu błędnie użyty do zobrazowania przepływu danych
Inżynieria Oprogramowania WSZiBSemestr IV
Podstawowe błędy popełniane w diagramach typu sequence
Symbol komunikatu błędnie użyty do zobrazowania zdarzenia