Projektowanie architektoniczne

Prezentacja na temat: "Projektowanie architektoniczne"— Zapis prezentacji:

1 Projektowanie architektoniczne
Przedstawienie koncepcji architektury oprogramowania i projektowania architektonicznego.

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

3 Zawartość Strukturalizacja systemu Modele sterowania Rozkład na moduły
Architektury charakterystyczne dla różnych dziedzin

4 Projektowanie architektoniczne
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.

5 Proces projektowania architektonicznego
Proces projektowania architektonicznego polega na ustaleniu podstawowego zrębu 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.

6 Trzy zalety jawnego projektowania
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. 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. 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 Czynności procesu projektowania architektonicznego
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. Modelowanie sterowania Określa się ogólny model związków sterowania między częściami systemu. Podział na moduły Każdy zidentyfikowany podsystem jest dzielony na moduły. Architekt musi wskazać typy modułów i ich połączenia.

8 Podsystemy i moduły 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.

9 Dokumentacja projektu architektonicznego
Wynikiem procesu projektowania architektonicznego jest dokumentacja, która składa się z kilku graficznych przedstawień modeli systemu oraz tekstu opisowego. 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. Różne graficzne modele systemu przedstawiają rozmaite perspektywy architektury.

10 Opracowywanie modeli architektonicznych obejmuje:
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.

11 Style architektoniczne
Projektowanie architektoniczne można przeprowadzić zgodnie z konkretnym modelem lub stylem architektonicznym. Ważna jest znajomość modeli, ich zastosowań, wad oraz zalet. Architektury większości wielkich systemów nie odpowiadają jednak żadnemu wybranemu stylowi.

12 Własności architektury systemu zależą od wymagań niefunkcjonalnych systemu
Efektywność Jeśli efektywność jest krytycznym wymaganiem, to prawdopodobnie należy tak zaprojektować architekturę, aby umieścić krytyczne operacje w niewielkiej liczbie podsystemów, które komunikują się między sobą w najmniejszym stopniu, jak to tylko jest możliwe. Zabezpieczenie Jeśli zabezpieczenie jest krytycznym wymaganiem, to prawdopodobnie należy zastosować w architekturze strukturę warstwową. Najbardziej krytyczne aktywa należy zabezpieczyć w najbardziej wewnętrznych warstwach, w których uwzględni się wysoki poziom weryfikacji zabezpieczeń. Bezpieczeństwo Jeśli bezpieczeństwo jest krytycznym wymaganiem, to prawdopodobnie należy tak zaprojektować architekturę, aby operacje dotyczące bezpieczeństwa znalazły się w jednym podsystemie lub w niewielkiej liczbie podsystemów. Zmniejszy to koszty i kłopoty związane z zatwierdzeniem bezpieczeństwa oraz umożliwi zaoferowanie powiązanych systemów ochronnych.

13 Własności architektury systemu zależą od wymagań niefunkcjonalnych systemu c. d.
Dostępność Jeśli dostępność jest krytycznym wymaganiem, to prawdopodobnie należy uwzględnić w architekturze komponenty nadmiarowe, aby można było podmieniać i modyfikować komponenty bez zatrzymywania systemu. Zdatność do pielęgnacji Jeśli zdatność do pielęgnacji jest krytycznym wymaganiem, to prawdopodobnie architektura systemu powinna składać się z drobnoziarnistych, samodzielnych komponentów, które można łatwo zmienić. Producenci danych powinni być oddzieleni od konsumentów; należy unikać dzielonych struktur danych.

14 Strukturalizacja systemu
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ą, że dane lub sterowanie są przekazywane między podsystemami zgodnie z kierunkiem grotu.

15 Diagram blokowy systemu sterującego robotem
wizyjny Sterownik alarmu Sterownik chwytacza System identyfikacji przedmiotów System wyboru opakowania System pakujący Sterownik taśmociągu

16 Model repozytorium 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.

17 Architektura zintegrowanego zestawu narzędzi CASE
Edytor projektów Generator kodu Repozytorium przedsięwzięcia Edytor programów Translator projektów Analizator projektów Generator raportów

18 Zalety i wady współdzielonego repozytorium
Jest to efektowny sposób współdzielenia dużych ilości danych. Nie ma potrzeby jawnej transmisji danych z jednego podsystemu do drugiego. Twórcy podsystemów muszą jednak uzgodnić model danych repozytorium. Prowadzi to nieuchronnie do kompromisów między specyficznymi potrzebami każdego narzędzia. Kompromis może spowodować zmniejszenie efektywności. Integracja nowych podsystemów może być trudna lub nawet niemożliwa, jeśli ich modele nie pasują do uzgodnionego modelu. Ewolucja może być jednak trudna, ponieważ duże ilości informacji powstają zgodnie z ustalonym modelem danych. Tłumaczenie ich na nowy model na pewno będzie kosztowne, może być trudne, a nawet niemożliwe. Czynności takie jak tworzenie kopii zapasowej, sterowanie zabezpieczeniami i dostępem oraz odtwarzanie po awarii są scentralizowane. Menedżer repozytorium jest za nie odpowiedzialny. Twórcy narzędzi mogą skoncentrować się na ich zasadniczej funkcji i nie muszą zajmować się tymi sprawami.

19 Zalety i wady współdzielonego repozytorium c. d.
Różne podsystemy mogą mieć jednak odmienne wymagania stawiane zabezpieczeniom oraz strategii odtwarzania i kopiom zapasowym. Model repozytorium wymusza te same strategie we wszystkich podsystemach. Model współdziałania jest widoczny przez schemat repozytorium. Integracja nowych narzędzi jest bardzo łatwa, o ile są zgodne z przyjętym modelem danych. Może być jednak trudno rozproszyć repozytorium na kilku maszynach. Chociaż można rozproszyć logicznie scentralizowane repozytorium, mogą jednak powstać kłopoty z nadmiarowością i niespójnościami.

20 Model klient-serwer 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ą: 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. Może być kilka współbieżnie działających egzemplarzy programu klienta. Sieć, która daje klientom dostęp do tych usług.

21 Architektura systemu biblioteki filmów i zdjęć
Klient 1 Klient 2 Klient 3 Klient 4 Sieć szerokopasmowa Serwer zdjęć Zdjęcia w postaci cyfrowej Serwer katalogu Katalog Serwer filmów Pliki z filmami Serwer hipertekstu Sieć hipertekstowa

22 Zalety i wady modelu klient-serwer
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żą liczbą 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. Brak współdzielonego modelu odniesienia może powodować trudności przy integracji danych z nowego serwera.

23 Model warstwowy 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.

24 Model warstwowy systemu zarządzania wersjami
Zarządzanie wersjami Zarządzanie obiektami System bazy danych System operacyjny

25 Model warstwowy – zalety i wady
Ułatwia stosowanie przyrostowego tworzenia systemów. Po opracowaniu warstwy niektóre jej usługi można udostępnić użytkownikom. Łatwość zmiany i przenoszenia. Jeśli zachowa się interfejs warstwy, to można zamienić ją na inną. Gdy interfejs zmienia się, wówczas tylko sąsiednie warstwy są pod wpływem tej zmiany. Umożliwia ukrycie zależności od konkretnej maszyny w wewnętrznych warstwach, można je więc względnie tanio zaimplementować na innych maszynach. Tylko wewnętrzne, zależne od maszyny warstwy muszą być wówczas ponownie zaimplementowane. Warstowy sposób strukturalizacji systemu może być trudny. Podstawowe udogodnienia, na przykład zarządzanie plikami, które jest wymagane przez wszystkie maszyny abstrakcyjne, mogą być oferowane przez warstwy wewnętrzne. Usługi potrzebne użytkownikowi mogą zatem wymagać dostępu do maszyn abstrakcyjnych kilka poziomów poniżej najbardziej zewnętrznego. Rujnuje to model, ponieważ warstwa zewnętrzna nie zależy już jedynie od jej bezpośredniego poprzednika. Kłopoty z efektywnością – wielopoziomowa interpretacja poleceń

26 Modele sterowania 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 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. Modele sterowania uzupełniają modele struktury. Wszystkie powyższe modele strukturalne mogą być zrealizowane za pomocą sterowania scentralizowanego, jak i zdarzeniowego.

27 Sterowanie scentralizowane
W modelu sterowania scentralizowanego jeden z podsystemów jest wybrany do roli sterownika systemu i odpowiada za zarządzanie działaniem innych podsystemów. Modele te dzieli się na dwie klasy: 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. 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, gdzie proces jest podsystemem lub modułem, który może działać równolegle z innymi procesami.

28 Model sterowania wywołanie-powrót
Program główny Procedura 1 Procedura 2 Procedura 3 Procedura 1.1 Procedura 1.2 Procedura 3.1 Procedura 3.2

29 Procesory efektorów Procesory detektorów Sterownik systemu Procesory
Model menedżera - scentralizowany model sterowania dla systemu czasu rzeczywistego Procesory efektorów Procesory detektorów Sterownik systemu Procesory obliczeniowe Interfejs użytkownika Obsługa awarii

30 Systemy sterowane zdarzeniami
Modele sterowania zdarzeniowego są sterowane zdarzeniami pochodzącymi z zewnątrz. Różnica między zdarzeniem i zwykłymi danymi wejściowymi polega na tym, że proces obsługujący zdarzenie nie decyduje o czasie jego zajścia. 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.

31 Modele rozgłaszania 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. Podsystemy decydują, które zdarzenia są dla nich interesujące, a procedura obsługi zdarzeń i komunikatów sprawia, że te zdarzenia na pewno dotrą do podsystemów.

32 Model sterowania z rozgłaszaniem
Podsystem 1 Podsystem 2 Podsystem 3 Podsystem 4 Procedura obsługi zdarzeń

33 Model sterowania z przerwaniami
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. Systemy czasu rzeczywistego, które wymagają, aby zdarzenia z otoczenia były obsługiwane bardzo szybko, muszą być sterowane zdarzeniami. Jeśli system czasu rzeczywistego służy na przykład do sterowania systemami bezpieczeństwa samochodu, to musi wykrywać zderzenia i napełnić poduszkę powietrzną, zanim głowa kierowcy uderzy w kierownicę. Aby zapewnić błyskawiczną reakcję, należy użyć modelu z przerwaniami.

34 Model sterowania z przerwaniami
Wektor przerwań Procedura obsługi 1 Procedura obsługi 2 Procedura obsługi 3 Procedura obsługi 4 Proces 1 Proces 2 Proces 3 Proces 4

35 Wady i zalety modelu sterowanego przerwaniami
Ten model powinien być używany jedynie w wymagających systemach czasu rzeczywistego, w których natychmiastowa reakcja jest konieczna. Można go zastosować łącznie z modelem scentralizowanego zarządzania. Zaletą tego podejścia do sterowania jest to, że umożliwia implementację szybkich odpowiedzi na zdarzenia. Wadą są złożoność programowania i trudności z zatwierdzaniem. Symulacja wzorców zachowania przerwań w czasie może być niemożliwa w trakcie testowania. System zbudowany zgodnie z tym modelem może być trudny do modyfikacji, jeśli liczba przerwań jest ograniczona przez sprzęt. Po osiągnięciu tego limitu nie da się obsługiwać nowych zdarzeń. To ograniczenie można czasem obejść przez przypisanie kilku rodzajów zdarzeń do jednego przerwania i opracowanie procedury obsługi, która rozpoznaje rodzaj zdarzenia.

36 Rozkład na moduły 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. Dalej zaprezentuję dwa modele służące 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.

37 Modele obiektowe Model obiektowy architektury systemu dzieli system na zbiór luźno uzależnionych od siebie obiektów z dobrze zdefiniowanymi interfejsami. Obiekty korzystają z usług oferowanych przez inne obiekty. Podział obiektowy uwzględnia klasy obiektów, ich atrybuty i operacje. Model obiektowy będzie dokładnie omawiany na jednym z przyszłych wykładów.

38 Model obiektowy systemu fakturowania
Klient Pokwitowanie nr klienta nazwisko adres okres kredytowania nr faktury data kwota nr klienta Faktura nr faktury data kwota nr klienta wystaw() WyślijUpomnienie() przyjmijPłatność() wyślijPokwitowanie() Płatność nr faktury data kwota nr klienta

39 Zalety modelu obiektowego
Obiekty są od siebie luźno uzależnione, ich implementację można więc zmieniać, nie wpływając na inne obiekty. Obiekty często są reprezentacjami bytów świata rzeczywistego, zatem struktura systemu jest łatwa do zrozumienia. Te byty świata rzeczywistego są używane w wielu systemach, obiekty można więc wielokrotnie wykorzystywać. Opracowano obiektowe języki programowania, które umożliwiają bezpośrednią implementację komponentów architektonicznych.

40 Wady modelu obiektowego
Aby korzystać z usług, obiekty muszą jawnie odwoływać się do nazw i interfejsów innych obiektów. Jeśli do wykonania zaproponowanych zmian systemu konieczna jest zmiana interfejsu, to należy ocenić wpływ tej zmiany na wszystkich użytkowników. Podczas gdy obiekty bezpośrednio odpowiadają pewnym niewielkim bytom świata rzeczywistego, trudno jest reprezentować w postaci obiektów bardziej złożone byty.

41 Modele przepływu danych
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. Gdy przekształcenia te realizowane są przez oddzielne procesy, model ten jest wówczas nazwany modelem potoków i filtrów. UNIX, DOS.

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

43 Zalety modelu przepływu danych
Umożliwia użycie wielokrotne przekształceń. Jest intuicyjna dla wielu ludzi, którzy myślą o swej pracy w kategoriach przetwarzania wejścia i wyjścia. Ewolucja systemu polegająca na dodawaniu nowych przekształceń jest bardzo łatwa. Ta architektura jest łatwa do zaimplementowania zarówno jako system sekwencyjny, jak i współbieżny.

44 Wady modelu przepływu danych
Potrzeby wspólnego formatu do przekazywania danych, który jest zrozumiały dla wszystkich przekształceń. Każde przekształcenie musi mieć uzgodniony format przetwarzanych danych ze wszystkimi przekształceniami, z którymi się komunikuje. Innym rozwiązaniem jest przyjęcie standardowego formatu wszystkich przekazywanych danych. Ten drugi sposób jest jedynym sensownym w sytuacji, gdy przekształcenia są samodzielne i zdatne do użycia wielokrotnego. Każde przekształcenie musi zanalizować składniowo swoje dane wejściowe i zamienić swoje dane wyjściowe na uzgodnioną postać. Zwiększa to narzuty systemowe i sprawia, że nie można zintegrować przekształceń, które używają niezgodnych formatów danych.

45 Wady modelu przepływu danych c. d.
Za pomocą modelu przepływu danych trudno jest pisać systemy interakcyjne, ponieważ należy w nich uwzględnić strumień danych do przetwarzania. Proste tekstowe dane wejściowe i wyjściowe można w ten sposób wymodelować, natomiast graficzne interfejsy użytkownika posługują się bardziej skomplikowanymi formatami wejścia-wyjścia związanymi ze zdarzeniami, np. wciśnięcie przycisków myszy i wybory z menu. Trudno jest przetłumaczyć je na postać zgodną z modelem przepływu danych.

46 Architektury charakterystyczne dla różnych dziedzin
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.

47 Modele ogólne Są abstrakcjami kilku rzeczywistych systemów. Obejmują zasadnicze charakterystyki tych systemów. Wśród systemów czasu rzeczywistego można na przykład wyróżnić ogólne modele architektoniczne, takie jak systemy gromadzenia danych, systemy monitorowania itd. 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.

48 Model przepływu danych kompilatora
Tabela symboli Analiza leksykalna Analiza składniowa Analiza znaczeniowa Generowanie kodu

49 Model repozytorium systemu przetwarzania języka
Analizator składniowy Analizator leksykalny Analizator znaczeniowy Optymalizator Drzewo składni abstrakcyjnej Definicja gramatyki Generator prezentacji Tabela symboli Definicja wyniku Generator kodu Edytor Repozytorium

50 Modele odniesienia 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.

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

52 Główne tezy 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. Wielkie systemy rzadko odpowiadają jednemu modelowi architektonicznemu. Są różnorodne i obejmują różne modele na rozmaitych poziomach abstrakcji. 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.

53 Główne tezy c. d. 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. 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. 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.