Inżynieria oprogramowania

Transkrypt

1 Inżynieria oprogramowania część VIII Prototypowanie oprogramowania Prototypowanie oprogramowania Zawartość: Prototypowanie w procesie tworzenia oprogramowania Metody błyskawicznego prototypowania Prototypowanie interfejsu użytkownika Ian Sommerville Inżynieria oprogramowania Slajd nr 2 1

2 Prototypowanie oprogramowania Prototyp oprogramowania pomaga w dwóch czynnościach inżynierii wymagań: Określenie wymagań. Prototypy systemu umożliwiają użytkownikom eksperymentowanie, w celu sprawdzenia czy system pomaga im w pracy. Dzięki temu użytkownicy wpadają na nowe pomysły itp. Zatwierdzanie wymagań. Prototyp może ujawnić błędy i pominięcia w zaproponowanych wymaganiach. Inne cele: Szkolenia użytkowników Testowanie systemu Ian Sommerville Inżynieria oprogramowania Slajd nr 3 Prototypowanie oprogramowania Ian Sommerville Inżynieria oprogramowania Slajd nr 4 2

3 Prototypowanie oprogramowania Prototypowanie Prototypowanie ewolucyjne zaczyna się od zbudowania prostego systemu spełniającego wymagania użytkowników. Jest on następnie modyfikowany w marę poznawania wymagań. Ostatecznie staje się systemem, którego oczekiwano. Prototypowanie z porzuceniem służy do udoskonalania i wyjaśnienia specyfikacji. Po napisaniu specyfikacji prototyp jest porzucany. Cele Celem prototypowania ewolucyjnego jest dostarczenie użytkownikowi działającego systemu. Celem prototypowania z porzuceniem jest zatwierdzenie i dostarczenie wymagań. Ian Sommerville Inżynieria oprogramowania Slajd nr 5 Prototypowanie oprogramowania Ian Sommerville Inżynieria oprogramowania Slajd nr 6 3

4 Prototypowanie ewolucyjne Zalety prototypowania ewolucyjnego Przyspieszone dostarczenie systemu. Włączenie użytkownika w budowę systemu Wspólne cechy błyskawicznych metod tworzenia oprogramowania: Przeplatanie procesu specyfikowania, projektowania i implementowania System budowany jest w postaci ciągu przyrostów Stosuje się narzędzia CASE i języki 4GL Interakcyjna metoda budowy interfejsów. Ian Sommerville Inżynieria oprogramowania Slajd nr 7 Prototypowanie ewolucyjne Problemy z prototypowaniem ewolucyjnym Kłopoty z zarządzaniem. prototypy ewoluują tak szybko że nie nadąża się z dokumentacją. Kłopoty z pielęgnacją. Ustawiczne zmiany powodują uszkodzenia struktury prototypowanego systemu. Kłopoty z umową. Zwykły model umowy klienta z wytwórcą oprogramowania oparty jest na specyfikacji systemu. Klienci nie znają zakresu prac. Dostawcy nie chcą się zgodzić na stałą cenę. Ian Sommerville Inżynieria oprogramowania Slajd nr 8 4

5 Prototypowanie ewolucyjne Ian Sommerville Inżynieria oprogramowania Slajd nr 9 Przyrostowy proces tworzenia Tworzenie przyrostowe likwiduje pewne niedogodności charakterystyczne dla prototypowania ewolucyjnego Tworzenie przyrostowe jest łatwiejsze w zarządzaniu, ponieważ przestrzega się w nim standardów budowy oprogramowania. Ian Sommerville Inżynieria oprogramowania Slajd nr 10 5

6 Przyrostowy proces tworzenia Ian Sommerville Inżynieria oprogramowania Slajd nr 11 Prototypowanie z porzuceniem Najczęściej stosowany przy budowie systemów sprzętowych. Posługując się komponentami z półki sprawdzamy projekt przed podjęciem decyzji o kosztownych zakupach. Przy budowie oprogramowania prototyp nie służy do oceny projektu ale pomaga w opracowaniu wymagań. Prototyp najczęściej tworzymy przy pomocy innych narzędzi niż projekt. W prototypie porzucanym można pominąć kryteria efektywności i jakości na rzecz szybkiego rezultatu Ian Sommerville Inżynieria oprogramowania Slajd nr 12 6

7 Prototypowanie z porzuceniem Ian Sommerville Inżynieria oprogramowania Slajd nr 13 Metody błyskawicznego prototypowania Tworzenie za pomocą dynamicznych języków wysokiego poziomu Języki programowania bazy danych Scalanie komponentów i programów użytkowych Ian Sommerville Inżynieria oprogramowania Slajd nr 14 7

8 Języki programowania bazy danych Języki 4-tej generacji 4GL (Narzędzia) Języki zapytań do bazy danych Generator interfejsów Arkusz kalkulacyjny Generator raportów Ian Sommerville Inżynieria oprogramowania Slajd nr 15 Języki programowania bazy danych Ian Sommerville Inżynieria oprogramowania Slajd nr 16 8

9 Scalanie komponentów i programów użytkowych Ian Sommerville Inżynieria oprogramowania Slajd nr 17 Prototypowanie interfejsu użytkownika Generatory interfejsów Prototyp HTML owy lub PHP Ian Sommerville Inżynieria oprogramowania Slajd nr 18 9

10 Inżynieria oprogramowania część IX Projektowanie architektoniczne Projektowanie architektoniczne Zawartość: Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Ian Sommerville Inżynieria oprogramowania Slajd nr 20 10

11 Projektowanie architektoniczne Wielkie systemy są zwykle podzielone na podsystemy, które oferują pewien zbiór powiązanych z sobą interfejsów. W początkowej fazie procesu projektowania identyfikuje się podsystemy, ustala się zrąb sterowania oraz komunikacji pomiędzy podsystemami. Faza ta jest nazywana projektowaniem architektonicznym. Produktem tej fazy jest opis architektury oprogramowania. Przypomnimy jak wygląda model procesu projektowania Ian Sommerville Inżynieria oprogramowania Slajd nr 21 Projektowanie architektoniczne Specyfikacja wymagań Czynności projektowe Projektowanie architektury Specyfikowanie abstrakcyjne Projektowanie interfejsów Projektowanie komponentów Projektowanie struktur danych Projektowanie algorytmów Architektura systemu Specyfikacja oprogramowania Specyfikacja interfejsów Specyfikacja komponentów Specyfikacja struktur danych Specyfikacja algorytmów Produkty projektowania Ian Sommerville Inżynieria oprogramowania Slajd nr 22 11

12 Projektowanie architektoniczne Czynności procesu projektowania: Projektowanie architektury. Identyfikuje i dokumentuje podsystemy tworzące system oraz związki między nimi. Specyfikowanie abstrakcyjne. Opracowuje się abstrakcyjną specyfikację usług i ograniczeń każdego podsystemu. Projektowanie interfejsów. Projektuje się i dokumentuje interfejsy każdego podsystemu z innymi podsystemami. Specyfikacja musi być jednoznaczna ponieważ umożliwia korzystanie z podsystemów bez znajomości ich działania. Projektowanie komponentów. Przypisuje się usługi do różnych komponentów i projektuje interfejsy tych komponentów. Ian Sommerville Inżynieria oprogramowania Slajd nr 23 Projektowanie architektoniczne Czynności procesu projektowania: Projektowanie struktur danych. Szczegółowo specyfikuje się i projektuje struktury danych użyte w implementacji systemu. Projektowanie algorytmów. Szczegółowo specyfikuje się i projektuje algorytmy służące do realizacji usług. Ian Sommerville Inżynieria oprogramowania Slajd nr 24 12

13 Projektowanie architektoniczne Model architektoniczny jest punktem początkowym do specyfikowania rozmaitych części systemu. Proces projektowania architektonicznego polega na ustaleniu podstawowego zrębu systemu. Obejmuje identyfikację najważniejszych komponentów systemu i komunikację między nimi. Ian Sommerville Inżynieria oprogramowania Slajd nr 25 Projektowanie architektoniczne Zalety jawnego projektowania i dokumentowania architektury oprogramowania: 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 analizy systemu. Decyzje projektowania architektonicznego mają znaczący wpływ na to, czy system spełni krytyczne wymagania dotyczące efektywności, niezawodności zdatności do pielęgnacji, czy nie Ian Sommerville Inżynieria oprogramowania Slajd nr 26 13

14 Projektowanie architektoniczne Zalety jawnego projektowania i dokumentowania architektury oprogramowania c.d.: 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 przekazać innym systemom, które mają podobne wymagania. Pomaga to w użyciu wielokrotnym oprogramowania. Ian Sommerville Inżynieria oprogramowania Slajd nr 27 Projektowanie architektoniczne Wspólne czynności dla wszystkich procesów projektowania architektonicznego: Strukturalizacja systemu. System jest dzielony na kilka podstawowych podsystemów. Podsystem jest niezależną jednostką oprogramowania. Identyfikuje się 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. Ian Sommerville Inżynieria oprogramowania Slajd nr 28 14

15 Projektowanie architektoniczne Rozróżnienie między podsystemami i modułami: 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. Nie traktujemy go jako oddzielnego podsystemu. Moduły są zbudowane z kilku innych, prostszych komponentów systemu. Ian Sommerville Inżynieria oprogramowania Slajd nr 29 Projektowanie architektoniczne Wynikiem procesu projektowania architektonicznego jest dokumentacja projektu architektonicznego, składająca się z graficznych przedstawień modelu systemu oraz tekstu opisowego. Dokumentacja ta powinna zawierać opis systemu jako struktury złożonej z podsystemów i każdego podsystemu jako struktury złożonej z modułów. Modele graficzne mogą przedstawiać różne perspektywy systemu. Ian Sommerville Inżynieria oprogramowania Slajd nr 30 15

16 Projektowanie architektoniczne Zakres modelu architektonicznego: 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 wg. czasu wykonania. Najczęściej różni się od modelu statycznego. 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. Ian Sommerville Inżynieria oprogramowania Slajd nr 31 Projektowanie architektoniczne Architektura systemu ma wpływ na efektywność, niezawodność, łatwość pielęgnacji,.... Wybrany dla danego zastosowania styl i struktura mogą więc zależeć 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 komunikujących się między sobą w niewielkim stopniu. Oznacza to użycie komponentów gruboziarnistych co umożliwia zmniejszenie komunikacji między nimi. Zabezpieczenie. Jeśli zabezpieczenie jest krytycznym wymaganiem to należy zastosować architekturę warstwową i najbardziej krytyczne zasoby zabezpieczyć w najniższych warstwach. Ian Sommerville Inżynieria oprogramowania Slajd nr 32 16

17 Projektowanie architektoniczne Architektura systemu c.d.: Bezpieczeństwo. Jeśli bezpieczeństwo jest krytycznym wymaganiem, to należy tak zaprojektować architekturę aby operacje dotyczące bezpieczeństwa znalazły się w jednym podsystemie lub w niewielkiej ich liczbie. Zmniejszy to koszty i kłopoty związane z zatwierdzeniem bezpieczeństwa. Dostępność. Jeśli dostępność jest krytycznym wymaganiem, to w architekturze należy uwzględnić komponenty nadmiarowe, tak aby można było podmieniać i modyfikować komponenty bez zatrzymania systemu. Zdolność do pielęgnacji. Jeśli zdolność do pielęgnacji jest krytycznym wymaganiem to architektura powinna się składać z drobnoziarnistych samodzielnych komponentów, które można łatwo zmieniać. Niestety między architekturami często występują konflikty. Ian Sommerville Inżynieria oprogramowania Slajd nr 33 Strukturalizacja systemu. Pierwsza faza projektowania architektonicznego polega na podziale systemu na zbiór oddziałujących ze sobą podsystemów. Projekt architektoniczny przedstawia się za pomocą diagramu blokowego, na którym każdy prostokąt oznacza podsystem. Ian Sommerville Inżynieria oprogramowania Slajd nr 34 17

18 System sterowania robotem pakującym przedmioty System wizyjny System identyfikacji przedmiotów Sterownik ramienia Sterownik chwytacza System wyboru opakowania System pakujący Sterownik taśmociągu Ian Sommerville Inżynieria oprogramowania Slajd nr 35 Model repozytorium Aby efektywnie współpracować, podsystemy wchodzące w skład systemu muszą wymieniać między sobą informacje: Wszystkie współdzielone dane znajdują się w jednej bazie danych Każdy podsystem prowadzi swoją bazę danych. Dane są przekazywane innym podsystemom przez wysyłanie komunikatów Ian Sommerville Inżynieria oprogramowania Slajd nr 36 18

19 Architektura zintegrowanego zestawu narzędzi CASE Edytor projektów Generator kodu Translator projektów Repozytorium przedsięwzięcia Edytor programów Analizator projektów Generator raportów Ian Sommerville Inżynieria oprogramowania Slajd nr 37 Model repozytorium Wady i zalety współdzielonego repozytorium: Efektywny sposób współdziałania dużych ilości danych. Nie ma potrzeby jawnej transmisji z jednego podsystemu do drugiego. Twórcy podsystemów muszą uzgodnić model danych repozytorium. Prowadzi to do kompromisów między specyficznymi potrzebami każdego narzędzia. Integracja może być trudna Podsystemu produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. Ewolucja może być trudna, ponieważ duże ilości informacji powstają zgodnie z ustalonym modelem danych Łatwość tworzenia kopii zapasowych, sterowanie zabezpieczeniami i dostępem przy pomocy menedżera repozytorium Ian Sommerville Inżynieria oprogramowania Slajd nr 38 19

20 Model repozytorium Wady i zalety współdzielonego repozytorium c.d.: Różne podsystemy mogą mieć odmienne wymagania stawiane zabezpieczeniom oraz inne strategie odtwarzania z kopii zapasowych Model współdzielenia jest widoczny przez schemat repozytorium. Integracja nowych narzędzi jest bardzo łatwa o ile jest zgodna z przyjętym modelem danych Proces rozproszenia repozytorium po kilku narzędziach może być trudny Ian Sommerville Inżynieria oprogramowania Slajd nr 39 Model klient-serwer Architektoniczny model klient-serwer jest modelem rozproszonym systemu w którym dane i przetwarzanie jest rozproszone między zbiór procesorów. Główne komponenty systemu: Zbiór samodzielnych procesorów oferujących usługi innym podsystemom. Przykładami są systemy realizujące usługi drukowania, serwery plików, serwery kompilujące. 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 programów klient. Sieć dająca klientowi dostęp do serwerów Ian Sommerville Inżynieria oprogramowania Slajd nr 40 20

21 Biblioteka filmów i zdjęć Klient 1 Klient 2 Klient 3 Klient 4 Sieć ethernet Serwer katalogu Serwer filmów Serwer zdjęć Serwer hiper-txt Katalog Katalog Katalog Katalog Ian Sommerville Inżynieria oprogramowania Slajd nr 41 Model maszyny abstrakcyjnej Model maszyny abstrakcyjnej (zwany czasami modelem warstwowym) opisuje sprzęganie podsystemów. Układa system w ciąg 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. Implementowanie języka często polega na kompilowaniu opisu na tzw. język maszyny idealnej a następnie na kod maszynowy. Podejście warstwowe ułatwia podejście przyrostowe Wadą jest wolny dostęp do warstw wewnętrznych i zmniejszenie przez to wydajności. Ian Sommerville Inżynieria oprogramowania Slajd nr 42 21

22 Model maszyny abstrakcyjnej zarządzania wersjami Zarządzanie wersjami Zarządzanie obiektami System bazy danych System operacyjny Ian Sommerville Inżynieria oprogramowania Slajd nr 43 Modele sterowania Modele do strukturalizacji opisują podział systemu na moduły. Aby podsystemy pracowały jako jeden system system, należy nimi sterować, tak aby ich usługi były dostarczane we właściwe miejsce i we właściwym czasie. Modele strukturalne nie obejmują informacji o sterowaniu. Modele sterowania na poziomie architektonicznym opisują przepływy sterowania między podsystemami. Ian Sommerville Inżynieria oprogramowania Slajd nr 44 22

23 Modele sterowania Możemy wyróżnić dwa ogólne podejścia do sterowania: Sterowanie scentralizowane. Jeden podsystem jest całościowo odpowiedzialny za sterowanie; to on uruchamia i zatrzymuje inne podsystemy. Może przekazać sterowanie innemu podsystemowi, ale będzie oczekiwał zwrotu odpowiedzialności za sterowanie. Sterowanie zdarzeniowe. Informacja o sterowaniu nie jest wbudowana w podsystem, ale każdy system może może reagować na zdarzenia zachodzące na zewnątrz. Te zdarzenia mogą występować w innych podsystemach lub w otoczeniu systemu. Wszystkie powyższe modele struktury mogą być zorganizowane za pomocą sterowania scentralizowanego jak i zdarzeniowego. Ian Sommerville Inżynieria oprogramowania Slajd nr 45 Sterowanie scentralizowane W modelu scentralizowanym jeden z podsystemów jest wybrany do roli sterownika systemu i odpowiada za działanie innych podsystemów. Modele te dzielimy na dwie klasy w zależności od tego czy systemy są sekwencyjne czy współbieżne. Model call-return. 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 ten można zastosować jedynie do systemów sekwencyjnych. Model przedstawiony na następnym slajdzie nie jest modelem strukturalnym. Podprogram 1.1 nie musi być częścią składową programu 1. Ian Sommerville Inżynieria oprogramowania Slajd nr 46 23

24 Model call-return Ian Sommerville Inżynieria oprogramowania Slajd nr 47 Model menedżera Model scentralizowany c.d.: Model menedżera. Stosowany jedynie do 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. Proces jest podsystemem lub modułem, który może działać równolegle z innymi procesami. Model często używany do systemów real time (czasu rzeczywistego). Ian Sommerville Inżynieria oprogramowania Slajd nr 48 24

25 Model sterowania dla systemów Real-time Ian Sommerville Inżynieria oprogramowania Slajd nr 49 Systemy sterowane zdarzeniami Istnieje wiele rodzajów oprogramowań sterowanych zdarzeniami. Zdarzenia w tych modelach najczęściej przychodzą z zewnątrz. Zdarzenie nie oznacza po prostu binarnego sygnału. Może to być sygnał przyjmujący pewien zakres wartości. 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. Ian Sommerville Inżynieria oprogramowania Slajd nr 50 25

26 Systemy sterowane zdarzeniami Omówimy 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 najczęściej w systemach czasu rzeczywistego, gdzie zewnętrzne przerwania są wykrywane przez obsługę przerwań. Następnie są przekazywane do innego komponentu, który je przetworzy Ian Sommerville Inżynieria oprogramowania Slajd nr 51 Model sterowania z rozgłaszaniem Podsystem 1 Podsystem 2 Podsystem 3 Podsystem 4 Procedura obsługi zdarzeń i komunikatów Ian Sommerville Inżynieria oprogramowania Slajd nr 52 26

27 Model sterowania z przerwaniami Ian Sommerville Inżynieria oprogramowania Slajd nr 53 Rozkład na moduły Po zaprojektowaniu architektury strukturalnej następnym procesem projektowania architektonicznego jest podział podsystemów na moduły. Na tym poziomie można zastosować modele omówione na początku dzisiejszego wykładu. Ponieważ komponenty modułów są mniejsze niż podsystemy możemy zastosować inne modele dla podzielonego systemu: 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 przetwarzają je na dane wyjściowe. Model ten bywa nazywany modelem potokowy. Ian Sommerville Inżynieria oprogramowania Slajd nr 54 27

28 Modele obiektowe Model obiektowy architektury systemu dzieli się na zbiór luźno uzależnionych od siebie obiektów z dobrze zdefiniowanymi interfejsami. Obiekty korzystają z usług oferowanych przez inne obiekty. Na następnym slajdzie pokazano przykład architektonicznego modelu obiektowego dla systemu fakturowania. System wystawia klientom faktury, przyjmuje zapłaty, drukuje pokwitowania płatności i upomnienia o niezapłaconych fakturach. Ian Sommerville Inżynieria oprogramowania Slajd nr 55 Model obiektowy w systemie fakturowania Ian Sommerville Inżynieria oprogramowania Slajd nr 56 28

29 Model przepływu danych W modelu przepływu danych przekształcenia funkcyjne przetwarzają dane wejściowe na dane wyjściowe. Dane przepływają od do drugiego procesu i są przekształcane w miarę swej 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 wsadu. Ian Sommerville Inżynieria oprogramowania Slajd nr 57 Model przepływu danych Ian Sommerville Inżynieria oprogramowania Slajd nr 58 29

30 Model przepływu danych system fakturowania Ian Sommerville Inżynieria oprogramowania Slajd nr 59 Model przepływu danych system fakturowania Zalety modelu przepływu danych: Umożliwia użycie wielokrotne przekształceń Jest intuicyjna dla wielu ludzi, którzy myślą o swojej pracy w kategorii 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. Ian Sommerville Inżynieria oprogramowania Slajd nr 60 30

31 Architektury charakterystyczne dla różnych dziedzin Istnieją dwa rodzaje modeli architektonicznych charakterystyczna dla dziedziny: Modele ogólne, które są abstrakcjami systemów takich jak: modele architektoniczne, systemy gromadzenia danych, systemy monitorowania, itd. Modele odniesienia, które są jeszcze bardziej abstrakcyjne i opisują większe klasy systemów. Ian Sommerville Inżynieria oprogramowania Slajd nr 61 Modele ogólne Najbardziej znanym przykładem architektonicznego modelu ogólnego jest model kompilatora. Moduły kompilatora: Analizator leksykalny, który pobiera symbole języka wejściowego i przekształca je w postać wewnętrzną. Tabela symboli budowana przez analizator leksykalny przechowuje informację o nazwach i typach użytych w programie. Analizator składniowy, który sprawdza składnie kompilowanego języka. Korzysta z definicji gramatyki i buduje drzewo składni. Drzewo składni, które wewnętrzną strukturą danych reprezentującą kompilowany program. Analizator znaczeniowy, który korzystając z informacji drzewa składni i tabeli symboli sprawdza znaczeniową poprawność programu wejściowego Generator kodu, który przechodzi drzewo składni i generuje kod maszynowy. Ian Sommerville Inżynieria oprogramowania Slajd nr 62 31

32 Model przepływu danych kompilatora Tabela symboli Analiza leksykalna Analiza składniowa Analiza znaczeniowa Generowanie kodu Ian Sommerville Inżynieria oprogramowania Slajd nr 63 Model repozytorium systemu przetwarzania języka Analizator leksykalny Analizator składniowy Analizator znaczeniowy Generator prezentacji Drzewo składni abstrakcyjnej Definicja gramatyki Optymalizator Edytor Tabela symboli Definicja wyniku Generator kodu Ian Sommerville Inżynieria oprogramowania Slajd nr 64 32

33 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 potencjalnie może oferować. Architektury odniesienia mogą służyć jako podstawa implementacji systemu. Taki był motyw powstania modelu referencyjnego OSI (Zimmerman, 1980) do komunikacji systemów otwartych. Ten model był z założenia standardem. System zgodny z tym modelem powinien móc się skontaktować z innymi zgodnymi systemami. Model OSI jest siedmiowarstwowym modelem komunikacji systemów otwartych. Ian Sommerville Inżynieria oprogramowania Slajd nr 65 Architektura modelu OSI Aplikacja Ian Sommerville Inżynieria oprogramowania Slajd nr 66 33