Projektowanie architektoniczne Przedstawienie koncepcji architektury oprogramowania i projektowania

Projektowanie architektoniczne Przedstawienie koncepcji architektury oprogramowania i projektowania architektonicznego. 1

Projektowanie architektoniczne n n Wielkie systemy są zwykle podzielone na podsystemy, które oferują pewien zbiór powiązanych ze sobą interfejsów. Wymagane jest projektowanie architektoniczne, którego wynikiem jest opis architektury oprogramowania 2

Procesy projektowania architektonicznego n n Proces projektowania architektonicznego polega na ustaleniu podstawowego zrębu (framework) systemu. Podział architektoniczny jest niezbędny do strukturalizacji i porządkowania specyfikacji. Model architektoniczny jest zwykle punktem początkowym do specyfikowania rozmaitych części systemu. Obejmuje identyfikację najważniejszych komponentów systemu i komunikacji między nimi. 3

Czynności procesu projektowania architektonicznego n Strukturalizacja systemu ¨ System jest dzielony na kilka podstawowych podsystemów, przy czym podsystem jest niezależną jednostką oprogramowania. Identyfikuje się tu komunikację między podsystemami. n Modelowanie sterowania ¨ Określa się ogólny model związków sterowania między częściami systemu. n Podział na moduły ¨ Każdy zidentyfikowany podsystem jest dzielony na moduły. Architekt musi wskazać typy modułów i ich połączenia. 4

Podsystemy i moduły n n Podsystem jest systemem na swoich własnych prawach; jego usługi nie zależą od usług oferowanych przez inne podsystemy. Podsystemy składają się z modułów i mają interfejsy używane do komunikacji z innymi podsystemami. Moduł jest zwykle komponentem systemu, który oferuje co najmniej jedną usługę innym modułom. Korzysta z usług innych modułów. Zwykle nie jest traktowany jako niezależny system. Moduły są zwykle zbudowane z kilku innych, prostszych komponentów systemu. 5

Opracowywanie modeli architektonicznych obejmuje: n n Statyczny model strukturalny obejmuje komponenty lub podsystemy, które można zbudować jako niezależne jednostki. Model dynamiczny procesu, w którym przedstawia się podział systemu na procesy czasu wykonania. Model interfejsów, w którym definiuje się usługi oferowane przez każdy podsystem za pośrednictwem jego interfejsu publicznego. Model związków, który obejmuje związki, takie jak przepływ danych między podsystemami. 6

Własności architektury systemu zależą od wymagań niefunkcjonalnych systemu n n n Efektywność ¨ Krytyczne operacje w niewielkiej liczbie podsystemów. Zabezpieczenie ¨ Należy zastosować w architekturze strukturę warstwową. Bezpieczeństwo ¨ Operacje dotyczące bezpieczeństwa powinny znaleźć się w jednym podsystemie lub w niewielkiej liczbie podsystemów. Dostępność ¨ Należy uwzględnić w architekturze komponenty nadmiarowe. Zdatność do pielęgnacji ¨ Architektura systemu powinna składać się z drobnoziarnistych, samodzielnych komponentów. 7

Model repozytorium n n Aby efektywnie współpracować, podsystemy wchodzące w skład systemu mogą wymieniać między sobą informacje na dwa podstawowe sposoby: ¨ Wszystkie współdzielone dane znajdują się w centralnej bazie danych, z której mogą korzystać wszystkie podsystemy. Model systemu oparty na współdzielonej bazie danych jest czasem nazywany modelem repozytorium. ¨ Każdy podsystem prowadzi własną bazę danych. Dane są przekazywane innym podsystemom przez wysyłanie komunikatów. Większość systemów używających dużej ilości danych jest zbudowanych wokół centralnej bazy danych lub repozytorium. Ten model jest więc przystosowany do zastosowań, w których dane są generowane przez jeden podsystem, a używane przez inny. 8

Zalety i wady współdzielonego repozytorium n n n n Jest to efektowny sposób współdziałania dużych ilości danych. Nie ma potrzeby jawnej transmisji danych z jednego podsystemu do drugiego. Twórcy podsystemów musza jednak uzgodnić model danych repozytorium. Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. Ewolucja może być jednak trudna. Czynności takie jak tworzenie kopii zapasowej, sterowanie zabezpieczeniami i dostępem oraz odtwarzanie po awarii są scentralizowane. Różne podsystemy mogą mieć jednak odmienne wymagania stawiane zabezpieczeniom oraz strategii odtwarzania i kopiom zapasowym. Model współdziałania jest widoczny przez schemat repozytorium. Integracja nowych narzędzi jest bardzo łatwa. Może być jednak trudno rozproszyć repozytorium na kilku maszynach. 9

Model klient-serwer n Architektoniczny model klient-serwer jest modelem rozproszonego systemu, w którym dane i przetwarzanie są rozdzielone między zbiór procesorów. Głównymi komponentami tego modelu są: 1. 2. 3. Zbiór samodzielnych serwerów oferujących usługi innym podsystemom. Przykładami są serwery wydruku realizujące usługi drukowania, serwery plików realizujące usługi zarządzania plikami. Zbiór klientów, którzy korzystają z usług oferowanych przez serwery. Zwykle same w sobie są podsystemami. Sieć, która daje klientom dostęp do tych usług. 10

Zalety i wady modelu klient-serwer n n Największa zaleta modelu klient-serwer polega na tym, że jest to architektura rozproszona. Umożliwia to efektywne użycie systemów sieciowych z dużą liczba rozproszonych procesorów. Łatwo jest dodać nowy serwer i zintegrować go z resztą systemu albo aktualizować serwery bez wpływania na inne części systemu. Do odniesienia pełnych korzyści z integracji nowego serwera może być jednak konieczne wprowadzenie pewnych zmian w istniejących klientach i serwerach. Nie ma dzielonego modelu danych i podsystemy porządkują zwykle swoje dane na różne sposoby. Oznacza to potrzebę określenia specyficznego modelu danych dla każdego serwera, który umożliwi zoptymalizowanie jego efektywności. 11

Model warstwowy n n n Model warstwowym (zwany czasem modelem maszyny abstrakcyjnej) opisuje sprzęganie podsystemów. Układa system w ciągi warstw, z których każda oferuje pewne usługi. Każda warstwa jest maszyną abstrakcyjną, której język maszynowy (usługi oferowane przez tą warstwę) służy do implementacji następnego poziomu maszyny abstrakcyjnej. Częstym sposobem implementacji języka jest na przykład zdefiniowanie „idealnej maszyny” i kompilowanie tego języka do kodu na tę maszynę. Następnym krokiem translacji jest zmiana tego kodu maszyny abstrakcyjnej na prawdziwy kod maszynowy. 12

Modele sterowania n n Modele do strukturalizacji systemu opisują sposób podziału systemu na podsystemy. Aby podsystemy pracowały jako jeden system, należy nimi sterować tak, żeby ich usługi były dostarczone we właściwe miejsce i we właściwym czasie. Mamy dwa podejścia: Sterowanie scentralizowane ¨ n Jeden podsystem jest całościowo odpowiedzialny za sterowanie; to on uruchamia i zatrzymuje inne podsystemy. Sterowanie zdarzeniowe ¨ Informacja o sterowaniu nie jest wbudowana w jeden podsystem. Każdy podsystem może reagować na zdarzenia zachodzące na zewnątrz. Te zdarzenia mogą występować w innych podsystemach lub w otoczeniu systemu. 13

Sterowanie scentralizowane n n W modelu sterowania scentralizowanego jeden z podsystemów jest wybrany do roli sterownika systemu i odpowiada za zarządzanie działaniem innych podsystemów. Model wywołanie-powrót ¨ n Jest to dobrze znany model podprogramów, w którym sterowanie zaczyna się na wierzchołku hierarchii podprogramów i przez wywołania podprogramów przechodzi do niższych poziomów drzewa. . Model menedżera ¨ Ten model można zastosować w wypadku systemów współbieżnych. Jeden z komponentów systemu jest wybierany do roli menedżera systemu i steruje rozpoczynaniem, zatrzymywaniem i koordynacją innych procesów systemu. 14

Systemy sterowane zdarzeniami n n Modele sterowania zdarzeniowego są zdarzeniami pochodzącymi z zewnątrz. Dwa modele sterowania zdarzeniowego: sterowane Modele rozgłaszania. W takich modelach zdarzenie jest w zasadzie ogłoszeniem dla wszystkich podsystemów. Każdy podsystem, który może obsłużyć to zdarzenie, reaguje na nie. ¨ Modele z przerwaniami. Są używane wyłącznie w systemach czasu rzeczywistego, gdzie zewnętrzne przerwania są wykrywane przez obsługę przerwań. Następnie są one przekazywane do innego komponentu, który je przetworzy. ¨ 15

Modele rozgłaszania n n n Podsystemy rejestrują swoje zainteresowanie specyficznymi zdarzeniami. Gdy takie zdarzenia zajdą, sterowanie jest przekazywane do podsystemu, który może je obsłużyć. Różnica między tym modelem a modelem scentralizowanym polega na tym, że strategia sterowania nie jest wbudowana w procedury obsługi zdarzeń i komunikatów. 16

Model sterowania z przerwaniami n n n Każdy rodzaj przerwania jest skojarzony z miejscem w pamięci, gdzie przechowuje się adres procedury obsługi. Po otrzymaniu przerwania określonego typu przełącznik sprzętowy powoduje natychmiastowe przekazanie sterowania do procedury obsługi tego przerwania. W odpowiedzi na zdarzenie sygnalizowane przez przerwanie procedura obsługi może uruchomić lub zatrzymać pewne procesy. 17

Rozkład na moduły n n Po zaprojektowaniu architektury strukturalnej następnym krokiem procesu projektowania architektonicznego jest podział podsystemów na moduły. Nie ma precyzyjnego sposobu podziału systemu na moduły. Dwa modele służą do podziału podsystemu na moduły: ¨ Model obiektowy. System jest dzielony na zbiór porozumiewających się obiektów. ¨ Model przepływu danych. System jest dzielony na moduły funkcjonalne, które pobierają dane wejściowe i w jakiś sposób przetwarzają je na dane wyjściowe. 18

Modele obiektowe n Model obiektowy architektury systemu dzieli system na zbiór luźno uzależnionych od siebie obiektów z dobrze zdefiniowanymi interfejsami. n Obiekty korzystają z usług oferowanych przez inne obiekty. n Podział obiektowy uwzględnia klasy obiektów, ich atrybuty i operacje. 19

Model obiektowy systemu fakturowania Klient nr klienta nazwisko adres okres kredytowania nr faktury data kwota nr klienta Pokwitowanie Faktura nr faktury data kwota nr klienta wystaw() Wyślij. Upomnienie() przyjmij. Płatność() wyślij. Pokwitowanie() 20

Modele przepływu danych n n n W modelu przepływu danych przekształcenia funkcyjne przetwarzają swoje dane wejściowe na dane wyjściowe. Dane przepływają od jednego do drugiego procesu i są przekształcane w miarę swojej wędrówki przez cały ciąg. Każdy krok przetwarzania jest implementowany jako przekształcenie. Dane wejściowe przepływają przez te przekształcenia do chwili wytworzenia z nich danych wyjściowych. Przekształcenia mogą działać sekwencyjnie lub równolegle. Przekształcenie może przetwarzać dane jedna po drugiej lub w postaci jednego wsadu. 21

Model przepływu danych – system fakturowania Wystaw pokwitowania Odczytaj wystawione faktury Zidentyfikuj płatności Znajdź przeterminowane faktury Faktury Pokwitowanie Wystaw upomnienia Upomnienia Płatności 22

Architektury charakterystyczne dla różnych dziedzin n n Istnieją modele architektoniczne specyficzne dla konkretnych dziedzin zastosowań. Egzemplarze takich systemów różnią się w szczegółach, można jednak wielokrotnie używać wspólnej struktury architektonicznej do budowania nowych systemów. Takie modele architektoniczne noszą nazwę architektur charakterystycznych dla dziedziny. Dwa rodzaje modeli architektonicznych: modele ogólne ¨ modele odniesienia. ¨ 23

Modele ogólne n n Najbardziej znanym przykładem architektonicznego modelu ogólnego jest model kompilatora. Istnieją tysiące kompilatorów. Każdy kompilator powinien zawierać następujące moduły: ¨ ¨ ¨ analizator leksykalny tabela symboli analizator składniowy drzewo składni analizator znaczeniowy generator kodu. 24

Modele odniesienia n n Ogólne modele architektoniczne odzwierciedlają architekturę istniejących systemów. Modele odniesienia są natomiast wynikami badań dziedziny zastosowania. Reprezentują wyidealizowane architektury obejmujące wszystkie udogodnienia, jakie system mógłby oferować. Architektury odniesienia mogą służyć jako podstawa implementacji systemu. 25

Architektura modelu odniesienia OSI do komunikacji systemów otwartych 7 Program użytkowy 6 Prezentacja 5 Sesja 4 Transport 3 Sieć 2 1 Łącze danych Fizyczna Sieć Łącze danych Fizyczna Medium komunikacyjne 26

Projektowanie obiektowe n n n To strategia projektowania, w ramach której projektanci systemu myślą w kategoriach „bytów”, a nie operacji albo funkcji. 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. Obiekty ukrywają informację o reprezentacji stanu i w ten sposób ograniczają do niego dostęp. Proces projektowania obiektowego obejmuje zaprojektowanie klas obiektów i związków między tymi klasami. Gdy projekt przybierze już postać działającego programu, potrzebne obiekty są tworzone na podstawie definicji klas. 27

Zalety projektowania obiektowego n n Systemy powinny być łatwe w pielęgnacji, ponieważ obiekty są niezależne. Można je poznawać i modyfikować jako samodzielne byty. Zmiana implementacji obiektu lub dodanie usług nie powinno mieć wpływu na obiekty systemowe. 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. 28

Wyjaśnienie podstawowych pojęć dot. strategii obiektowych n n n Analiza obiektowa polega na opracowaniu modelu obiektowego dziedziny zastosowania. Rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem. 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. 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. 29

Obiekty n 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ń. n 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. 30

Obiekt pracownik Pracownik nazwisko : string adres : string data. Urodzenia : Date numer. Pracownika : integer PESEL : string dział : Dział przełożony : Pracownik wynagrodzenie : integer tatus: zwolniony, {current, left, retired} stan : {zatrudniony, tax. Code: integer emerytowany}. . . NIP : integer. . . join () leave () dołącz() retire () opuść() change. Details ( przejdźNa. Emeryturę() zmieńSzczegóły() 31

UML n 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. 32

Komunikacja pomiędzy obiektami n n n 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. Kopie informacji potrzebnych do wykonania usługi i wyniki jej wykonania są przekazywane jako parametry. W niektórych systemach rozproszonych komunikację obiektów implementuje się po prostu jako tekstowe komunikaty wymieniane przez obiekty. Obiekt odbiorca analizuje składniowo komunikat, rozpoznaje usługę i przekazane dane, m a następnie realizuje żądaną usługę. 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. // Wywołaj metodę obiektu biura, która przekazuje następną wartość z bufora w = bufor. Cykliczny. pobierz() // Wywołaj metodę obiektu termostatu, która ustala utrzymywaną temperaturę termostat. ustaw. Temperaturę(20); 33

Hierarchia dziedziczenia (uogólnień) n n 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. Szczegółowa klasa obiektów jest w pełni zgodna z ogólną klasą obiektów, ale zawiera więcej informacji. W UML uogólnienie obrazuje się za pomocą obrazów strzałki wskazującej klasę macierzystą. W obiektowych językach programowania uogólnienie zwykle implementuje się za pomocą mechanizmu dziedziczenia. Klasa potomna dziedziczy atrybuty i operacje po klasie macierzystej. 34

Zalety dziedziczenia n 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. n 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. 35

Powiązania pomiędzy klasami obiektów n n 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. W UML oznaczeniem powiązania jest kreska między klasami obiektów, która może mieć dodatkowe adnotacje. 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. 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. 36

Obiekty współbieżne n n n Ogólny model oddziaływania obiektów umożliwia ich współbieżne wykonywanie w równoległych procesach. Obiekty mogą działać na tym samym komputerze lub być obiektami rozproszonymi na różnych maszynach. 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. 37

Dwa rodzaje implementacji obiektów współbieżnych n n 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. 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. 38

Etapy procesu projektowania obiektowego n n n Zrozumienie i zdefiniowanie kontekstu oraz modelu użytkowania systemu. Zaprojektowanie architektury systemu. Identyfikacja głównych obiektów systemu. Opracowanie modeli projektowych. Wyspecyfikowanie interfejsów obiektów. 39

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

Architektura warstwowa systemu tworzącego mapy pogody <<subsystem>> Wyświetlanie danych <<subsystem>> Archiwizacja danych <<subsystem>> Przetwarzanie danych <<subsystem>> 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ł 41

Podsystemy w systemie tworzącym mapy pogody <<subsystem>> Gromadzenie danych Obserwator <<subsystem>> Wyświetlanie danych Satelita Interfejs użytkownika Wyświetlacz map Mapa Drukarka map Wspólne Stacja meteorologiczna Balon <<subsystem>> Archiwizacja danych <<subsystm>> Przetwarzanie danych Sprawdzanie danych Składowanie danych Integracja danych Składnica map Składnica danych 42

Kontekst systemu i modele użytkowania n n n 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. Kontekst systemu jest modelem statycznym, w którym opisuje się inne systemy obecne w tym środowisku. Model użytkowania systemu jest modelem dynamicznym, w którym opisuje się, w jaki sposób system porozumiewa się ze swoim środowiskiem. 43

Architektura stacji meteorologicznej Stacja meteorologiczna <<subsystem>> Interfejs Obsługuje całą komunikację zewnętrzną <<subsystem>> Gromadzenie danych Gromadzi i podsumowuje dane <<subsystem>> Przyrządy Pakiet przyrządów do zbierania surowych danych 44

Identyfikacja obiektów i sposoby n n n n W praktyce ta czynność polega na wynajdowaniu klas obiektów. Projekt jest pisany w kategoriach tych klas. 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. Wykorzystanie analizy gramatycznej opisu systemu w języku naturalnym. Obiekty i atrybuty są rzeczownikami, a operacje i usługi czasownikami. 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. 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. 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. 45

Przykłady klas obiektów w systemie stacji meteorologicznej Dane. Meteorologiczne Stacja. Meteorologiczna temperatury. Powietrza temperatury. Gruntu siły. Wiatru kierunki. Wiatru cisnienia opad identyfikator raport. Pogodowy () dostrój (przyrządy) testuj () uruchom (przyrządy) wyłącz (przyrządy) Termometr gruntowy temperatura testuj () dostrój () gromadź () podsumuj () Wiatromierz Siła. Wiatru kierunek. Wiatru test () Barometr ciśnienie wysokość test () dostrój () 46

Modele projektowe i ich rodzaje n Modele projektowe obejmują obiekty lub klasy obiektów systemu oraz, gdy ma to sens, różne rodzaje związków między tymi bytami. n 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. n Model statyczny, który służy do opisu statycznej struktury systemu w kategoriach klas obiektów systemowych i ich związków. n Modele dynamiczne, które służą do opisu dynamicznej struktury systemu. Widać z nich interakcje między obiektami systemowymi. 47

Przykłady modeli projektowych n n n 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. 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. 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. 48

Przykład modelu dynamicznego: model przebiegu n n Jednym z najbardziej przydatnych i zrozumiałych modeli dynamicznych, który można opracować, jest model przebiegu. 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. ¨ 49

Przebieg operacji gromadzenia danych : Sterownik Komunikacji : Stacja Meteorologiczna : Dane Meteorologiczne żądanie (raport) potwierdzenie () raportuj () podsumuj () odpowiedź (raport) wyślij (raport) potwierdzenie () 50

Modele maszyn stanowych n Można wykorzystać model maszyny stanowej, w którym widać, jak egzemplarz zmienia swój stan w zależności od otrzymywanych komunikatów. n Do zapisu modeli maszyn stanowych w UML oferuje diagramy stanów, które jako pierwszy wymyślił Harel (1987). 51

Diagram stanów obiektu Stacja. Meteorologiczna Działanie dostrój () Dostrajanie dostrojony Wyłączony uruchom () Oczekiwanie wyłącz () testuj () Testowanie koniec transmisji zegar koniec gromadzenia Gromadzenie koniec testu Transmitowanie raport. Pogodowy () Podsumowywanie podsumowanie gotowe 52

Specyfikowanie interfejsów obiektów n n 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. Projektanci powinni unikać informacji o reprezentacji interfejsów w swoich projektach interfejsów. Ten sam obiekt może mieć kilka interfejsów, które są sposobami postrzegania oferowanych metod. 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. 53

Ewolucja projektu n n n Ważną zaletą podejścia obiektowego do projektowania jest uproszczenie procesu wprowadzania zmian w projekcie. Wynika to z tego, że reprezentacja stanu obiektu nie wpływa na projekt. Zmiana wstępnie ustalonych wewnętrznych szczegółów obiektu prawdopodobnie wpłynie na inne obiekty systemowe. 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. 54

Modyfikacja projektu n n n Do obiektu Stacja. Meteorologiczna na tym samym poziomie co obiekt Dane. Meteorologiczne należy dodać obiekt o nazwie Jakość powietrza. Należy dodać operację raport Jakości powietrza, której działanie polega na wysłaniu danych o zanieczyszczeniach do głównego komputera. Należy dodać obiekty reprezentujące przyrządy do pomiaru poziomu zanieczyszczeń. W tym wypadku pomiarom będą podlegać tlenek azotu, dym i benzen. 55

Nowe obiekty do monitorowania zanieczyszczeń Stacja. Meteorologiczna Jakość powietrza Identifier poziom. Tlenku. Azotu poziom. Dymu poziom. Benzenu raport. Pogodowy () raport. Jakości. Powietrza () dostrój (przyrządy) testuj () uruchom (przyrządy) wyłącz (przyrządy) gromadź () podsumuj () Przyrządy do pomiaru zanieczyszczeń Miernik. Tlenku. Azotu Miernik. Dymu Miernik. Benzenu 56

Strukturalizacja systemu n n Pierwsza faza projektowania architektonicznego polega zwykle na podziale systemu na zbiór oddziałujących ze sobą podsystemów. Na najbardziej abstrakcyjnym poziomie projekt architektoniczny można przedstawić w postaci diagramu blokowego, na którym każdy prostokąt odpowiada podsystemowi. Prostokąty wewnątrz prostokąta oznaczają, że taki podsystem dalej podzielono na podsystemy. Strzałki wskazują, m że dane lub sterowanie są przekazywane między podsystemami zgodnie z kierunkiem grotu. 57