Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 1 Projektowanie obiektowe Projektowanie systemów przy wykorzystaniu oddziałujących na.

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 1 Projektowanie obiektowe Projektowanie systemów przy wykorzystaniu oddziałujących na."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 1 Projektowanie obiektowe Projektowanie systemów przy wykorzystaniu oddziałujących na siebie obiektów i ich klas

2 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 2 Cele l Dowiedzieć się, jak przedstawiać projekt oprogramowania w postaci zbioru oddziałujących na siebie obiektów, które mają stan i operacje. l Poznać najważniejsze czynności ogólnego procesu projektowania obiektowego. l Poznać różne modele, które można zastosować do udokumentowania projektu obiektowego. l Poznać podstawy prezentacji tych modeli w UML-u (ang. Unified Modeling Language).

3 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 3 Zawartość l Obiekty i klasy obiektów l Proces projektowania obiektowego l Ewolucja projektu

4 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 4 Projektowanie obiektowe l To strategia projektowania, w ramach której projektanci systemu myślą w kategoriach bytów, a nie operacji albo funkcji. l Działający system składa się z oddziałujących na siebie obiektów, które przechowują swój lokalny stan i oferują operacje na tej informacji o stanie. l Obiekty ukrywają informację o reprezentacji stanu i w ten sposób ograniczają do niego dostęp. l Proces projektowania obiektowego obejmuje zaprojektowanie klas obiektów i związków między tymi klasami. l Gdy projekt przybierze już postać działającego programu, potrzebne obiekty są tworzone na podstawie definicji klas.

5 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 5 System składający się z oddziałujących na siebie obiektów stan o3 o3:K3 stan o4 o4: K4 stan o1 o1: K1 stan o6 o6: K1 stan o5 o5:K5 stan o2 o2: K3 operacja3 ()operacja4 () operacja2 ()operacja6 ()operacja5 () operacja1 ()

6 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 6 Zalety projektowania obiektowego l Systemy powinny być łatwe w pielęgnacji, ponieważ obiekty są niezależne. l Można je poznawać i modyfikować jako samodzielne byty. l Zmiana implementacji obiektu lub dodanie usług nie powinno mieć wpływu na obiekty systemowe. l Obiekty są skojarzone z bytami, zwykle więc istnieje jasne odwzorowanie bytów świata rzeczywistego (np. komponentów sprzętowych) na sterujące nimi obiekty w systemie. Zwiększa to zrozumiałość i zarazem zdatność do pielęgnacji systemu.

7 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 7 Wyjaśnienie podstawowych pojęć dot. strategii obiektowych l Analiza obiektowa polega na opracowaniu modelu obiektowego dziedziny zastosowania. Rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem. l Projektowanie obiektowe polega na opracowaniu modelu obiektowego systemu oprogramowania, który będzie implementacją zidentyfikowanych wymagań. Obiekty projektu obiektowego są związane z rozwiązaniem problemu. l Programowanie obiektowe polega na realizacji projektu oprogramowania za pomocą języka programowania obiektowego. Języki obiektowe, takie jak Java, umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów.

8 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 8 Obiekty i klasy obiektów l Pojęcia obiekt i obiektowy są obecnie często używane. Stosuje się je do różnych typów bytów, metod projektowania, systemów i języków programowania. l Istnieje ogólna zgoda, że obiekt jest obudową informacji. Oddaje to definicja obiektu i klasy obiektów.

9 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 9 Obiekty Obiekt jest bytem, który ma stan i zbiór zdefiniowanych operacji działających na tym stanie. Stan jest reprezentowany jako zbiór atrybutów obiektu. Operacje skojarzone z obiektem służą do oferowania usług innym obiektom (klientom), które mogą żądać tych usług, gdy potrzebują wykonania pewnych obliczeń. Obiekty są tworzone zgodnie z definicja klasy obiektów. Definicja klasy obiektów służy jako szablon do tworzenia obiektów. Zawiera deklaracje wszystkich atrybutów i operacji, które należy skojarzyć z obiektem tej klasy.

10 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 10 UML l Notacja używana do oznaczenia klas obiektów jest zdefiniowana przez UML. Klasa obiektów jest przedstawiana jako nazwany prostokąt z dwoma sekcjami. Atrybuty obiektu są wymieniane w górnej sekcji. Operacje związane z obiektem są wymieniane w dolnej sekcji.

11 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 11 Obiekt pracownik tatus: {current, left, retired} taxCode: integer... join () leave () retire () changeDetails ( Pracownik nazwisko : string adres : string dataUrodzenia : Date numerPracownika : integer PESEL : string dział : Dział przełożony : Pracownik wynagrodzenie : integer stan : {zatrudniony, zwolniony, emerytowany} NIP : integer... dołącz() opuść() przejdźNaEmeryturę() zmieńSzczegóły()

12 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 12 Komunikacja pomiędzy obiektami l Obiekty porozumiewają się przez żądania usług (wywołania metod) od innych obiektów, i jeśli trzeba, wymianę informacji niezbędnych do realizacji usługi. l Kopie informacji potrzebnych do wykonania usługi i wyniki jej wykonania są przekazywane jako parametry. l W niektórych systemach rozproszonych komunikację obiektów implementuje się po prostu jako tekstowe komunikaty wymieniane przez obiekty. l Obiekt odbiorca analizuje składniowo komunikat, rozpoznaje usługę i przekazane dane,m a następnie realizuje żądaną usługę. l Jeśli obiekty istnieją jednak w ramach tego samego programu, to wywołania metod implementuje się w taki sam sposób jak wywołania procedur i funkcji w językach C lub Ada.

13 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 13 Przykłady komunikacji // Wywołaj metodę obiektu biura, która przekazuje następną wartość z bufora w = buforCykliczny.pobierz() // Wywołaj metodę obiektu termostatu, która ustala utrzymywaną temperaturę termostat.ustawTemperaturę(20);

14 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 14 Hierarchia dziedziczenia (uogólnień) l Klasy obiektów można ułożyć w hierarchię uogólnienia lub dziedziczenia, w której widać związek między ogólnymi i bardziej szczegółowymi klasami obiektów. l Szczegółowa klasa obiektów jest w pełni zgodna z ogólną klasą obiektów, ale zawiera więcej informacji. l W UML uogólnienie obrazuje się za pomocą obrazów strzałki wskazującej klasę macierzystą. l W obiektowych językach programowania uogólnienie zwykle implementuje się za pomocą mechanizmu dziedziczenia. Klasa potomna dziedziczy atrybuty i operacje po klasie macierzystej.

15 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 15 Hierarchia dziedziczenia Pracownik Kierownik zarządzaneBudżety dataPrzyjęcia Programista przedsięwzięcie językiProg Kierownik Przedsięwzięcia przedsięwzięcia Kierownik Działu dział Kierownik Strategiczny obowiązki

16 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 16 Zalety dziedziczenia l Klasy niższe w hierarchii mają te same atrybuty i operacje co ich klasy macierzyste, mogą jednak dodawać nowe atrybuty i operacje lub modyfikować niektóre z tych odziedziczonych. l Jeśli w modelu użyto nazwy klasy macierzystej, to obiekt systemu może być zdefiniowany jako obiekt tej klasy albo jednego z jej potomków.

17 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 17 Problems with inheritance l Object classes are not self-contained. they cannot be understood without reference to their super- classes l Designers have a tendency to reuse the inheritance graph created during analysis. Can lead to significant inefficiency l The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained

18 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 18 Inheritance and OOD l There are differing views as to whether inheritance is fundamental to OOD. View 1. Identifying the inheritance hierarchy or network is a fundamental part of object-oriented design. Obviously this can only be implemented using an OOPL. View 2. Inheritance is a useful implementation concept which allows reuse of attribute and operation definitions. Identifying an inheritance hierarchy at the design stage places unnecessary restrictions on the implementation l Inheritance introduces complexity and this is undesirable, especially in critical systems

19 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 19 Powiązania pomiędzy klasami obiektów l Obiekty należące do klas obiektów biorą udział w związkach z innymi obiektami. Związki te można modelować przez opisanie powiązań między klasami obiektów. l W UML oznaczeniem powiązania jest kreska między klasami obiektów, która może mieć dodatkowe adnotacje. l Powiązanie jest bardzo ogólnym związkiem i w UML często używa się go do wskazania, że atrybut obiektu jest powiązanym obiektem albo że implementacja metody korzysta z powiązanego obiektu. l Jednym z najczęściej występujących powiązań jest agregacja, która służy do wskazania, jak obiekty składa się z innych obiektów.

20 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 20 Model powiązań Kierownik DziałPracownik jest-członkiem jest-zarządzany-przez zarządza

21 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 21 Obiekty współbieżne l Ogólny model oddziaływania obiektów umożliwia ich współbieżne wykonywanie w równoległych procesach. l Obiekty mogą działać na tym samym komputerze lub być obiektami rozproszonymi na różnych maszynach. l W praktyce większość obiektowych języków programowania domyślnie przyjmuje model działania sekwencyjnego, w którym żądania usług obiektów, są implementowane w taki sam sposób jak wywołania funkcji.

22 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 22 Dwa rodzaje implementacji obiektów współbieżnych l Serwery Obiekty są tu realizowane jako równoległe procesy z metodami odpowiadającymi zdefiniowanym operacjom obiektu. Metody są uruchamiane w odpowiedzi na zewnętrzne komunikaty i mogą się wykonywać równolegle z metodami skojarzonymi z innymi obiektami. l Obiekty aktywne Stan obiektu może być zmieniony przez wewnętrzne operacje wykonywane przez obiekt w swoim wnętrzu. Proces reprezentujący obiekt nieustannie wykonuje te operacje, nigdy więc nie wstrzymuje swojego działania.

23 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 23 Przykład l Klasa obiektów reprezentuje transponder samolotu. l Transponder śledzi położeniem samolotu za pomocą systemu nawigacji satelitarnej. l Może reagować na komunikaty pochodzące z komputerów centrum kontroli lotów. l Udostępnia bieżące położenie samolotu w odpowiedzi na wywołanie metody podajPołożenie.

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 24 Implementacja obiektu aktywnego za pomocą wątków Javy Class Transponder extends Thread { Położenie bieżącePołożenie ; Współrzędne w1, w2 ; Satelita sat1, sat2 ; Nawigator nawigator ; public Położenie podajPołożenie () { return bieżącePołożenie ; } public void run () { while (true) { w1 = sat1.położenie() ; w2 = sat2.położenie() ; bieżącePołożenie = nawigator.wyznacz(w1, w2) ; } } // Transponder

25 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 25 Klasa macierzysta l Wątki w Javie pisze się przez wskazanie wbudowanej klasy Thread jako klasy macierzystej. l Wątki muszą mieć metodę run, którą system wykonawczy Javy uruchamia w chwili utworzenia obiektów będących wątkami.

26 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 26 Etapy procesu projektowania obiektowego l Zrozumienie i zdefiniowanie kontekstu oraz modelu użytkowania systemu. l Zaprojektowanie architektury systemu. l Identyfikacja głównych obiektów systemu. l Opracowanie modeli projektowych. l Wyspecyfikowanie interfejsów obiektów.

27 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 27 System mapy pogody System tworzący mapy pogody ma regularnie generować mapy pogody na podstawie informacji zgromadzonych przez zdalne, niestrzeżone stacje meteorologiczne i inne źródła danych, takie jak obserwatorzy pogody, balony i satelity. Stacje meteorologiczne przekazują dane do komputera obszaru w odpowiedzi na żądania przychodzące z tej maszyny. System komputera obszaru weryfikuje zebrane dane i integruje dane z różnych źródeł. Zintegrowane dane są archiwizowane. Na podstawie tego archiwum i bazy danych map komputerowych tworzy się lokalne mapy pogody. Mapy można drukować w celu rozpowszechniania na specjalnej drukarce do map lub wyświetlać w kilku różnych formatach.

28 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 28 System mapy pogody Z tego opisu wynika, ze zadaniem części systemu jest zbieranie danych, inna część zajmuje się integracja danych z różnych źródeł, a jeszcze inna tworzeniem map pogody. Na rysunku pokazano jedną z architektur tego systemu, którą można wywnioskować z tego opisu. Jest to architektura warstwowa, która odzwierciedla różne etapy przetwarzania zachodzącego w systemie: zbieranie danych, integrację danych, archiwizację danych i generowanie map. W tym wypadku architektura warstwowa jest właściwa, ponieważ każdy etap w swoim działaniu zależy jedynie od przetwarzania z poprzedniego etapu.

29 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 29 Architektura warstwowa systemu tworzącego mapy pogody > Wyświetlanie danych > Archiwizacja danych > Przetwarzanie danych > Gromadzenie danych Warstwa wyświetlania danych, której obiekty zajmują się przygotowaniem danych w postaci zrozumiałej dla człowieka Warstwa archiwizacji danych, której obiekty zajmują się składowaniem danych do późniejszego przetwarzania Warstwa przetwarzania danych, której obiekty zajmują się sprawdzaniem i integracją zgromadzonych danych Warstwa gromadzenia danych, której obiekty zajmują się zdobywaniem danych ze zdalnych źródeł

30 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 30 Podsystemy w systemie tworzącym mapy pogody > Gromadzenie danych Obserwator Balon Stacja meteoro- logiczna Satelita Wspólne > Przetwarzanie danych Sprawdzanie danych Integracja danych > Wyświetlanie danych Interfejs użytkownika Mapa Drukarka map Wyświetlacz map Składowanie danych Składnica map Składnica danych > Archiwizacja danych

31 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 31 Kontekst systemu i modele użytkowania l Pierwszym etapem procesu projektowania oprogramowania jest zrozumienie związków między projektowanym oprogramowaniem a jego środowiskiem zewnętrznym. Kontekst systemu i modele użytkowania stanowią dwa uzupełniające się modele związków pomiędzy systemem a jego środowiskiem. l Kontekst systemu jest modelem statycznym, w którym opisuje się inne systemy obecne w tym środowisku. l Model użytkowania systemu jest modelem dynamicznym, w którym opisuje się, w jaki sposób system porozumiewa się ze swoim środowiskiem.

32 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 32 Kontekst systemu tworzącego mapy pogody czyli podsystem gromadzenia danych > Gromadzenie danych Obserwator Balon Stacja meteoro- logiczna Satelita Wspólne > Przetwarzanie danych Sprawdzanie danych Integracja danych > Wyświetlanie danych Interfejs użytkownika Mapa Drukarka map Wyświetlacz map Składowanie danych Składnica map Składnica danych > Archiwizacja danych

33 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 33 Przypadki użycia stacji meteorologicznej Uruchom Wyłącz Raportuj Dostrój Testuj

34 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 34 Opis przypadku użycia Raportuj System Stacja meteorologiczna Przypadek użycia Raportuj Aktorzy System gromadzenia informacji meteorologicznych, Stacja meteorologiczna Dane Stacja meteorologiczna wysyła do systemu gromadzenia informacji meteorologicznych podsumowanie danych meteorologicznych odczytanych z przyrządów w określonym czasie. Wysyła się maksymalne, minimalne i średnie temperatury gruntu i powietrza, maksymalne, minimalne i średnie ciśnienia powietrza, maksymalną, minimalną i średnią prędkość wiatru, całkowity opad i kierunek wiatru próbkowany co pięć minut. Bodziec System gromadzenia informacji meteorologicznych nawiązuje połączenie modemowe ze stacją meteorologiczną i żąda przekazania danych. Reakcja Wysyłanie podsumowania danych do systemu gromadzenia informacji meteorologicznych. Komentarz Stacje meteorologiczne są zwykle proszone o raport raz na godzinę, ale ta częstotliwość może być inna dla różnych stacji i może w przyszłości ulec zmianie.

35 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 35 Projektowanie architektury l Po zdefiniowaniu oddziaływania projektowanego systemu oprogramowania z jego środowiskiem można przystąpić do projektowania architektury systemu. l Przykład architektury automatycznej stacji meteorologicznej przedstawionej za pomocą modelu warstwowego. Oto trzy warstwy oprogramowania takiej stacji meteorologicznej: Warstwa interfejsu, której zadaniem jest porozumiewanie się z innymi częściami systemu i oferowanie zewnętrznych interfejsów systemu. Warstwa gromadzenia danych, której zadaniem jest zarządzanie odczytem danych z przyrządów i podsumowywanie danych meteorologicznych przed przesłaniem ich do systemu tworzącego mapy. Warstwa przyrządów, która obudowuje wszystkie przyrządy służące do gromadzenia surowych danych o warunkach pogodowych.

36 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 36 Architektura stacji meteorologicznej Stacja meteorologiczna > Interfejs > Gromadzenie danych > Przyrządy Obsługuje całą komunikację zewnętrzną Gromadzi i podsumowuje dane Pakiet przyrządów do zbierania surowych danych

37 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 37 Identyfikacja obiektów l W praktyce ta czynność polega na wynajdowaniu klas obiektów. l Projekt jest pisany w kategoriach tych klas. l Nie uchronimy się przed udoskonalaniem tych wstępnie rozpoznanych klas obiektów i ponownym przeglądem tego etapu procesu po tym, jak osiągnie się głębsze zrozumienie projektu.

38 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 38 Sposoby identyfikacji l Wykorzystanie analizy gramatycznej opisu systemu w języku naturalnym. Obiekty i atrybuty są rzeczownikami, a operacje i usługi czasownikami. l Wykorzystanie namacalnych bytów (rzeczy) z dziedziny zastosowania takich jak samolot, ról takich jak kierownik, zdarzeń takich jak żądanie, interakcji takich jak spotkanie, miejsc takich jak biura, jednostek organizacyjnych jak firmy itp. l Wykorzystanie podejścia czynnościowego, w którym projektant zaczyna od zrozumienia ogólnego zachowania systemu. Różne zachowania przypisuje się do różnych części systemu. l Wykorzystanie analizy scenariuszy, w której rozpoznaje się i analizuje różne scenariusze w systemie. Po zanalizowaniu scenariusza zespół odpowiedzialny za tę analizę musi rozpoznać potrzebne obiekty, atrybuty i operacje.

39 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 39 Klasy obiektów stacji meteorologicznej l Klasa obiektów StacjaMeteorologiczna oferuje swojemu środowisku podstawowy interfejs stacji meteorologicznej. l Klasa obiektów DaneMeteorologiczne obudowuje podsumowanie danych odczytanych z różnych przyrządów stacji meteorologicznej. Skojarzone z nią operacje służą do gromadzenia i podsumowywania wymagań danych. l Klasy obiektów Termometr gruntowy, Wiatromierz i Barometr są bezpośrednio związane z przyrządami systemu. Odzwierciedlają namacalne byty sprzętowe systemu. Ich operacje służą do sterowania tym sprzętem.

40 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 40 Przykłady klas obiektów w systemie stacji meteorologicznej StacjaMeteorologiczna identyfikator raportPogodowy () dostrój (przyrządy) testuj () uruchom (przyrządy) wyłącz (przyrządy) DaneMeteorologiczne temperaturyPowietrza temperaturyGruntu siłyWiatru kierunkiWiatru cisnienia opad gromadź () podsumuj () Termometr gruntowy temperatura testuj () dostrój () Wiatromierz SiłaWiatru kierunekWiatru test () Barometr ciśnienie wysokość test () dostrój ()

41 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 41 Rozpoznanie dalszych obiektów i usług l Awarie przyrządów muszą być zgłaszane automatycznie. Wymaga to atrybutów i operacji do sprawdzania poprawnego działania przyrządów. l Liczba odległych stacji meteorologicznych jest duża. Trzeba więc umieć rozpoznać dane pochodzące z poszczególnych stacji. Stacje muszą zatem mieć identyfikatory.

42 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 42 Modele projektowe l Modele projektowe obejmują obiekty lub klasy obiektów systemu oraz, gdy ma to sens, różne rodzaje związków między tymi bytami. l Mają być abstrakcyjne, żeby zbędne szczegóły nie zakrywały związków między nimi a wymaganiami systemowymi. Muszą tez zawierać wystarczająco dużo szczegółów, żeby programiści mogli podejmować decyzje implementacyjne.

43 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 43 Rodzaje modeli projektowych l Model statyczny, który służy do opisu statycznej struktury systemu w kategoriach klas obiektów systemowych i ich związków. l Modele dynamiczne, które służą do opisu dynamicznej struktury systemu. Widać z nich interakcje między obiektami systemowymi.

44 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 44 Przykłady modeli projektowych l Modele podsystemów, w których uwzględnia się logiczne grupowanie obiektów w spójne podsystemy. Przedstawia się je na pewnego rodzaju diagramie klas, na którym każdy podsystem ma postać pakietu. Modele podsystemów są statyczne. l Modele przebiegu, w których uwzględnia się przebieg interakcji obiektów. W UML przedstawia się je w postaci diagramów przebiegu lub diagramów kooperacji. Modele przebiegu są dynamiczne. l Modele maszyn stanowych, z których wynika, w jaki sposób poszczególne obiekty zmieniają swój stan w odpowiedzi na zdarzenia. W UML przedstawia się je w postaci diagramów stanów. Modele maszyn stanowych są dynamiczne.

45 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 45 Przykład modelu podsystemów: powiązania obiektów stacji meteorologicznych > interfejs SterownikKomunikacji StacjaMeteorologiczna DaneMeteorologiczne > Gromadzenie danych Stan przyrządów > Przyrządy Termometr powietrza Termometr gruntowy Barometr Łopatka wiatrowa Wskaźnik opadu Wiatromierz

46 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 46 Przykład modelu dynamicznego: model przebiegu l Jednym z najbardziej przydatnych i zrozumiałych modeli dynamicznych, który można opracować, jest model przebiegu. l Dla każdego typu interakcji dokumentuje on przebieg zachodzących oddziaływań obiektów. Obiekty biorące udział w interakcji są ułożone poziomo. Każdy z nich pod spodem ma podczepioną pionową kreskę. Czas jest przedstawiony pionowo, tzn. czas biegnie w dół przerywanych pionowych linii. Interakcje między obiektami mają postać podpisanych strzałek łączących pionowe linie. Cienki prostokąt na linii życia obiektu reprezentuje okres, w którym ten obiekt steruje systemem.

47 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 47 Przebieg operacji gromadzenia danych :Sterownik Komunikacji :Stacja Meteorologiczna :Dane Meteorologiczne podsumuj () raportuj () wyślij (raport) żądanie (raport) potwierdzenie () odpowiedź (raport) potwierdzenie ()

48 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 48 Modele maszyn stanowych l Można wykorzystać model maszyny stanowej, w którym widać, jak egzemplarz zmienia swój stan w zależności od otrzymywanych komunikatów. l Do zapisu modeli maszyn stanowych w UML oferuje diagramy stanów, które jako pierwszy wymyślił Harel (1987).

49 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 49 Diagram stanów obiektu StacjaMeteorologiczna Wyłączony Działanie Transmitowanie Testowanie Dostrajanie Oczekiwanie Podsumowywanie Gromadzenie uruchom () wyłącz () zegar koniec gromadzenia koniec transmisji testuj () dostrój () dostrojony koniec testu PodsumowaniegotowePodsumowaniegotowe podsumowanie gotowe raportPogodowy ()

50 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 50 Specyfikowanie interfejsów obiektów l Ważną częścią procesu projektowania jest specyfikowanie interfejsów między różnymi komponentami. Trzeba wyspecyfikować interfejsy, aby można było równolegle projektować obiekty i komponenty. l Projektanci powinni unikać informacji o reprezentacji interfejsów w swoich projektach interfejsów. l Ten sam obiekt może mieć kilka interfejsów, które są sposobami postrzegania oferowanych metod. l W Javie można to bezpośrednio zrealizować, ponieważ interfejsy są deklarowane w oderwaniu od obiektów, a obiekty implementują interfejsy. Podobnie grupa obiektów może być dostępna przez jeden interfejs.

51 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 51 Opis interfejsu stacji meteorologicznej w Javie Interfejs StacjaMeteorologiczna { public StacjaMeteorologiczna () ; public void uruchom () ; public void uruchom (Przyrząd p) ; public void wyłącz () ; public void wyłącz (Przyrząd p) ; public void raportPogodowy () ; public void testuj () ; public void testuj (Przyrząd p) ; public void dostrój (Przyrząd p) ; public int podajID () ; } // StacjaMeteorologiczna

52 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 52 Ewolucja projektu l Ważną zaletą podejścia obiektowego do projektowania jest uproszczenie procesu wprowadzania zmian w projekcie. l Wynika to z tego, że reprezentacja stanu obiektu nie wpływa na projekt. Zmiana wstępnie ustalonych wewnętrznych szczegółów obiektu prawdopodobnie nie wpłynie na inne obiekty systemowe. l Co więcej, obiekty są luźno powiązane, wprowadzenie nowych obiektów jest zatem zwykle łatwe i nie prowadzi do istotnych konsekwencji dla reszty systemu.

53 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 53 Modyfikacja projektu l Do obiektu StacjaMeteorologiczna na tym samym poziomie co obiekt DaneMeteorologiczne należy dodać obiekt o nazwie Jakość powietrza. l Należy dodać operację raport Jakości powietrza, której działanie polega na wysłaniu danych o zanieczyszczeniach do głównego komputera. l Należy dodać obiekty reprezentujące przyrządy do pomiaru poziomu zanieczyszczeń. W tym wypadku pomiarom będą podlegać tlenek azotu, dym i benzen.

54 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 54 Nowe obiekty do monitorowania zanieczyszczeń Przyrządy do pomiaru zanieczyszczeń MiernikTlenkuAzotu MiernikBenzenu MiernikDymu StacjaMeteorologiczna Identifier raportPogodowy () raportJakościPowietrza () dostrój (przyrządy) testuj () uruchom (przyrządy) wyłącz (przyrządy) Jakość powietrza poziomTlenkuAzotu poziomDymu poziomBenzenu gromadź () podsumuj ()

55 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 55 l Projektowanie obiektowe jest sposobem projektowania oprogramowania, w którym zasadnicze komponenty projektu odpowiadają obiektom z ich prywatnym stanem i operacjami, a nie funkcjami. l Obiekt powinien mieć operacje konstruktowe i inspekcyjne, które umożliwiają odczyt stanu i jego modyfikację. Obiekt oferuje usługi (operacje korzystające z informacji o stanie) innym obiektom. Obiekty są tworzone w czasie wykonywania na podstawie specyfikacji zawartej w definicji klasy obiektów. l Obiekty można implementować sekwencyjnie lub współbieżnie. Obiekt współbieżny może być pasywny, wówczas jego stan jest zmieniany jedynie przez jego interfejs. Może być też obiektem aktywnym, który zmienia swój stan bez interwencji z zewnątrz. l Unified Modeling Language (UML) obejmuje wiele różnych notacji, które służą do dokumentowania interfejsów obiektów. Główne tezy

56 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 56 Główne tezy l Proces projektowania obiektowego obejmuje czynności projektowania architektury systemu, identyfikacji obiektów systemu, opisywania projektu za pomocą modeli obiektowych i dokumentowania interfejsów obiektów. l W trakcie procesu projektowania obiektowego można opracować wiele różnych modeli. W tej grupie są modele statyczne (modele klas, modele dziedziczenia, modele powiązań) i dynamiczne (modele przebiegu, modele maszyny stanowej). l Interfejsy obiektów należy precyzyjnie zdefiniować, żeby mogły z nich korzystać inne obiekty. Do dokumentowania interfejsów obiektu można użyć języka programowania, np. Javy. l Ważną zaletą projektowania obiektowego jest uproszczenie ewolucji systemu.


Pobierz ppt "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 12Slide 1 Projektowanie obiektowe Projektowanie systemów przy wykorzystaniu oddziałujących na."

Podobne prezentacje


Reklamy Google