Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 1 Projektowanie architektoniczne l Przedstawienie koncepcji architektury oprogramowania.

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 1 Projektowanie architektoniczne l Przedstawienie koncepcji architektury oprogramowania."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 1 Projektowanie architektoniczne l Przedstawienie koncepcji architektury oprogramowania i projektowania architektonicznego.

2 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 2 Cele l Wiedzieć, dlaczego projektowanie architektoniczne oprogramowania jest tak ważne. l Wiedzieć, że do udokumentowania architektury systemu można użyć różnych modeli. l Znać kilka typów architektury oprogramowania, obejmujących strukturę systemu oraz rozkład sterowania i rozkład na moduły.

3 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 3 Zawartość l Strukturalizacja systemu l Modele sterowania l Rozkład na moduły l Architektury charakterystyczne dla różnych dziedzin

4 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 4 Projektowanie architektoniczne l Wielkie systemy są zwykle podzielone na podsystemy, które oferują pewien zbiór powiązanych ze sobą interfejsów. l Wymagane jest projektowanie architektoniczne, którego wynikiem jest opis architektury oprogramowania.

5 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 5 Procesu projektowania architektonicznego l Proces projektowania architektonicznego polega na ustaleniu podstawowego zrębu systemu. l Podział architektoniczny jest niezbędny do strukturalizacji i porządkowania specyfikacji. l Model architektoniczny jest zwykle punktem początkowym do specyfikowania rozmaitych części systemu. l Obejmuje identyfikację najważniejszych komponentów systemu i komunikacji między nimi.

6 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 6 Trzy zalety jawnego projektowania l Komunikacja z uczestnikami Architektura jest prezentacją systemu na wysokim poziomie, która może służyć za podstawę dyskusji w gronie różnych uczestników. l Analiza systemu Ujawnienie architektury systemu we wczesnej fazie budowania systemu daje możliwość przeprowadzenia pewnej analizy. Decyzje projektowania architektonicznego mają znaczący wpływ na to, czy system może spełnić krytyczne wymagania dotyczące efektywności, niezawodności i zdatności do pielęgnacji, czy nie. l Użycie wielokrotne w wielkiej skali Architektura systemu jest zwartym i łatwym do opanowania opisem organizacji systemu i współpracy jego komponentów. Architekturę można przekazywać innym systemom, które mają podobne wymagania.

7 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 7 Czynności procesy projektowania architektonicznego l 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. l Modelowanie sterowania Określa się ogólny model związków sterowania między częściami systemu. l Podział na moduły Każdy zidentyfikowany podsystem jest dzielony na moduły. Architekt musi wskazać typy modułów i ich połączenia.

8 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 8 Podsystemy i moduły l 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. l 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.

9 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 9 Dokumentacja projektu architektonicznego l Wynikiem procesu projektowania architektonicznego jest dokumentacja, która składa się z kilku graficznych przedstawień modeli systemu oraz tekstu opisowego. l Ta dokumentacja powinna zawierać opis systemu jako struktury złożonej z podsystemów i każdego podsystemu jako struktury złożonej z modułów. l Różne graficzne modele systemu przedstawiają rozmaite perspektywy architektury.

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

11 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 11 Style architektoniczne l Projektowanie architektoniczne można przeprowadzić zgodnie z konkretnym modelem lub stylem architektonicznym. l Ważna jest znajomość modeli, ich zastosowań, wad oraz zalet. l Architektury większości wielkich systemów nie odpowiadają jednak żadnemu wybranemu stylowi.

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

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

14 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 14 Diagram blokowy systemu sterującego robotem System wizyjny System identyfikacji przedmiotów Sterownik alarmu Sterownik chwytacza System pakujący System wyboru opakowania Sterownik taśmociągu

15 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 15 Model repozytorium l 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. l 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.

16 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 16 Architektura zintegrowanego zestawu narzędzi CASE Translator projektów Edytor programów Generator raportów Analizator projektów Generator kodu Edytor projektów Repozytorium przedsięwzięcia

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

18 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 18 Model klient-serwer l 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. 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. 2. Zbiór klientów, którzy korzystają z usług oferowanych przez serwery. Zwykle same w sobie są podsystemami. 3. Sieć, która daje klientom dostęp do tych usług.

19 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 19 Architektura systemu biblioteki filmów i zdjęć Klient 4Klient 3Klient 2Klient 1 Serwer katalogu Katalog Serwer filmów Pliki z filmami Serwer zdjęć Zdjęcia w postaci cyfrowej Serwer hipertekstu Sieć hipertekstowa Sieć szerokopasmowa

20 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 20 Zalety i wady modelu klient- serwer l 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. l 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.

21 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 21 Model warstwowy l Model warstwowym (zwany czasem modelem maszyny abstrakcyjnej) opisuje sprzęganie podsystemów. l Układa system w ciągi warstw, z których każda oferuje pewne usługi. l 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. l Częstym sposobem implementacji języka jest na przykład zdefiniowanie „idealnej maszyny” i kompilowanie tego języka do kodu na tę maszynę. l Następnym krokiem translacji jest zmiana tego kodu maszyny abstrakcyjnej na prawdziwy kod maszynowy.

22 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 22 Model warstwowy systemu zarządzania wersjami Zarządzanie wersjami Zarządzanie obiektami System bazy danych System operacyjny

23 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 23 Modele sterowania l 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: l Sterowanie scentralizowane Jeden podsystem jest całościowo odpowiedzialny za sterowanie; to on uruchamia i zatrzymuje inne podsystemy. l 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.

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 24 Sterowanie scentralizowane l W modelu sterowania scentralizowanego jeden z podsystemów jest wybrany do roli sterownika systemu i odpowiada za zarządzanie działaniem innych podsystemów. l Model wywołanie-powrót 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.. l 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.

25 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 25 Model sterowania wywołanie-powrót Procedura 3.2Procedura 3.1Procedura 1.2Procedura 1.1 Procedura 3Procedura 2Procedura 1 Program główny

26 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 26 Model menedżera - scentralizowany model sterowania dla systemu czasu rzeczywistego Obsługa awarii Interfejs użytkownika Sterownik systemu Procesory efektorów Procesory detektorów Procesory obliczeniowe

27 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 27 Systemy sterowane zdarzeniami l Modele sterowania zdarzeniowego są sterowane zdarzeniami pochodzącymi z zewnątrz. l Dwa modele sterowania zdarzeniowego: 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.

28 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 28 Modele rozgłaszania l Podsystemy rejestrują swoje zainteresowanie specyficznymi zdarzeniami. l Gdy takie zdarzenia zajdą, sterowanie jest przekazywane do podsystemu, który może je obsłużyć. l 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.

29 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 29 Model sterowania z rozgłaszaniem Podsystem 1 Podsystem 2 Podsystem 3 Podsystem 4 Procedura obsługi zdarzeń

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

31 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 31 Model sterowania z przerwaniami Proces 4 Proces 3 Proces 2 Proces 1 Procedura obsługi 1 Procedura obsługi 4 Procedura obsługi 3 Procedura obsługi 2 Przerwania Wektor przerwań

32 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 32 Rozkład na moduły l 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. l 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.

33 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 33 Modele obiektowe l Model obiektowy architektury systemu dzieli system na zbiór luźno uzależnionych od siebie obiektów z dobrze zdefiniowanymi interfejsami. l Obiekty korzystają z usług oferowanych przez inne obiekty. l Podział obiektowy uwzględnia klasy obiektów, ich atrybuty i operacje.

34 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 34 Model obiektowy systemu fakturowania Klient nr klienta nazwisko adres okres kredytowania Pokwitowanie nr faktury data kwota nr klienta Płatność nr faktury data kwota nr klienta Faktura nr faktury data kwota nr klienta wystaw() WyślijUpomnienie() przyjmijPłatność() wyślijPokwitowanie()

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

36 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 36 Model przepływu danych systemu fakturowania Wystaw upomnienia Wystaw pokwitowania Zidentyfikuj płatności Odczytaj wystawione faktury PłatnościFaktury Upomnienia Pokwitowanie Znajdź przeterminowane faktury

37 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 37 Architektury charakterystyczne dla różnych dziedzin l Istnieją modele architektoniczne specyficzne dla konkretnych dziedzin zastosowań. l 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. l Takie modele architektoniczne noszą nazwę architektur charakterystycznych dla dziedziny. l Dwa rodzaje modeli architektonicznych: modele ogólne modele odniesienia.

38 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 38 Modele ogólne l Najbardziej znanym przykładem architektonicznego modelu ogólnego jest model kompilatora. Istnieją tysiące kompilatorów. l Każdy kompilator powinien zawierać następujące moduły: analizator leksykalny tabela symboli analizator składniowy drzewo składni analizator znaczeniowy generator kodu.

39 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 39 Model przepływu danych kompilatora Tabela symboli Analiza składniowa Analiza leksykalna Analiza znaczeniowa Generowanie kodu

40 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 40 Model repozytorium systemu przetwarzania języka Generator kodu Optymalizator Edytor Generator prezentacji Analizator znaczeniowy Analizator składniowy Analizator leksykalny Drzewo składni abstrakcyjnej Tabela symboli Definicja gramatyki Definicja wyniku Repozytorium

41 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 41 Modele odniesienia l Ogólne modele architektoniczne odzwierciedlają architekturę istniejących systemów. l Modele odniesienia są natomiast wynikami badań dziedziny zastosowania. l Reprezentują wyidealizowane architektury obejmujące wszystkie udogodnienia, jakie system mógłby oferować. l Architektury odniesienia mogą służyć jako podstawa implementacji systemu.

42 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 42 Architektura modelu odniesienia OSI do komunikacji systemów otwartych Medium komunikacyjne Program użytkowy Prezentacja Sesja Transport Sieć Łącze danych Fizyczna Sieć Łącze danych Fizyczna Program użytkowy Prezentacja Sesja Transport Sieć Łącze danych Fizyczna

43 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 43 Główne tezy l Architektura oprogramowania jest zasadniczym zrębem do strukturalizacji systemu. W trakcie projektowania architektonicznego można opracować różne modele architektoniczne, na przykład model strukturalny, model sterowania i model podziału. l Wielkie systemy rzadko odpowiadają jednemu modelowi architektonicznemu. Są różnorodne i obejmują różne modele na rozmaitych poziomach abstrakcji. l Modelami podziału systemu są m.in. model repozytorium, model klient-serwer i model maszyny abstrakcyjnej. Repozytorium jest modelem współdzielenia danych we wspólnej składnicy. W modelach klient-serwer dane są zwykle rozproszone. W modelach warstwowych każda warstwa jest zaimplementowana za pomocą udogodnień swojej warstwy podstawowej.

44 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 44 Główne tezy l Modelami sterowania są model scentralizowany i model zdarzeniowy. W modelach scentralizowanych decyzje dotyczące sterowania są podejmowane na podstawie stanu systemu. W modelach zdarzeniowych systemami sterują zdarzenia zewnętrzne. l Modelami podziału na moduły są model przepływu danych i model obiektowy. Modele przepływu danych są funkcjonalne; modele obiektowe są oparte na luźno zależnych od siebie bytach, które zarządzają swoim stanem i operacjami. l Architektoniczne modele charakterystyczne dla dziedziny są abstrakcjami w ramach dziedziny zastosowań. Mogą być modelami ogólnymi, które są budowane z istniejących systemów lub modelami odniesienia, które są wyidealizowanymi abstrakcyjnymi modelami dziedziny.


Pobierz ppt "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 10Slide 1 Projektowanie architektoniczne l Przedstawienie koncepcji architektury oprogramowania."

Podobne prezentacje


Reklamy Google