Inżynieria Oprogramowania 6. Projektowanie architektoniczne

Prezentacja na temat: "Inżynieria Oprogramowania 6. Projektowanie architektoniczne"— Zapis prezentacji:

1 Inżynieria Oprogramowania 6. Projektowanie architektoniczne
26/03/2017 Inżynieria Oprogramowania 6. Projektowanie architektoniczne Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW

2 Źródła Materiały dra Waldemara Karwowskiego, wykładowcy w poprzednich semestrach Ian Sommerville, Inżynieria Oprogramowania, WNT, Warszawa 2003

3 Plan Wstęp Strukturalizacja systemu Modele sterowania
Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

4 Plan Wstęp Strukturalizacja systemu Modele sterowania
Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

5 Co to jest Wielkie systemy są podzielone na podsystemy, powiązane poprzez interfejsy. Ustalanie podsystemów ustalanie zrębu sterowania ustalanie zrębu komunikacji jest właśnie projektowaniem architektonicznym Wynik: architektura systemu

6 ...pomimo, że... ...specyfikacja systemu nie powinna zawierać żadnych informacji projektowych, to w praktyce jest to nierealne (za wyjątkiem małych systemów) Zatem, podział architektoniczny nadaje strukturę i porządkuje specyfikację Model architektoniczny jest punktem początkowym dla specyfikacji części systemu

7 Zalety projektowania architektonicznego
Komunikacja z uczestnikami prezentacja abstrakcji na wysokim poziomie podstawa do dyskusji Analiza systemu duży wpływ na spełnianie wymagań efektywność niezawodność zdatność do pielęgnacji Użycie wielokrotne w wielkiej skali opis zwarty i łatwy do opanowania można przekazać innym, podobnym systemom

8 Wspólne czynności Strukturalizacja systemu Modelowanie sterowania
podział na podsystemy Modelowanie sterowania Podział podsystemów na moduły Podsystem: jego usługi nie zależą od usług innych podsystemów Moduł: komponent oferujący >= jedną usługę korzysta z usług innych modułów

9 Wynik projektowania Dokumentacja
kilka graficznych modeli opis system jako złożony z podsystemów każdy podsystem jako złożony z modułów Modele graficzne – z różnych perspektyw, np. statyczny model strukturalny dynamiczny model procesu interfejsy związki: przepływ danych, sterowania Języki opisu architektury lub UML (raczej)

10 Modele architektoniczne
Istnieją modele typowe Rzeczywiste architektury są modyfikowane Zależą od wymagań: Efektywność – mało komunikacji, zatem modele gruboziarniste Zabezpieczenie – struktura warstwowa, zasoby krytyczne w wewnętrznych warstwach, z wysokim poziomem weryfikacji zabezpieczeń (zabezpieczanie danych) Bezpieczeństwo – operacje bezpieczeństwa w niewielu podsystemach (odporność na błędne dane) Dostępność – komponenty nadmiarowe możliwością wymiany podczas pracy Zdatność do pielęgnacji – drobnoziarniste, samodzielne komponenty; unikanie dzielonych struktur danych

11 Plan Wstęp Strukturalizacja systemu Modele sterowania
Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

12 Przykład Jednak, model a. jest narzędziem komunikacji
Model strukturalny architektury systemu robota pakującego System wizyjny System identyfikacji przedmiotów Sterownik chwytaka Sterownik alarmu System pakujący System wyboru opakowania Sterownik taśmociągu Krytyka: nie widać natury związków ani właściwości komponentów Jednak, model a. jest narzędziem komunikacji umożliwia analizę ... itd.

13 Model repozytorium Charakterystyczne: wspólna baza danych przykład: zintegrowany zestaw narzędzi CASE Blackboard systems... Edytor projektów Generator kodu Translator projektów Repozytorium Edytor programów Analizator projektów Generator raprotów Efektywnie współdzieli wiele danych Ale, model danych trzeba uzgodnić Producenci danych nie martwią się o sposób wykorzystania Ale, zmiana modelu może być b. trudna, gdy danych jest dużo Kopie zapasowe, dostęp po awarii itp. są scentralizowane Ale, podsystemy mogą mieć różne wymagania co do tego Łatwa integracja nowych danych, o ile możliwe tłumaczenie Ale, trudno rozproszyć repozytorium na kilku maszynach

14 Model klient-serwer Charakterystyczne: serwery i klienci, połączenie przez sieć przykład: wielodostępny system hipertekstowy Klient 1 Klient 2 Klient 3 Sieć szerokopasmowa Serwer filmów Pliki filmów Serwer obrazów Pliki obrazów Serwer hipertekstu Pliki hipertekstowe Serwery nie znają klientów Dane różnych typów Ale, model danych każdego serwera jest inny Architektura rozproszona Łatwo dodawać klientów, trudniej serwery Ale, klienci i serwery muszą się rozumieć Ale, przepustowość sieci jest ograniczeniem

15 Model maszyny abstrakcyjnej
Charakterystyczne: każda warstwa jest maszyną abstrakcyjną przykład: system zarządzania wersjami Zarządzanie wersjami Zarządzanie obiektami System bazy danych System operacyjny Ułatwia przyrostowe tworzenie systemów niektóre usługi danej warstwy udostępnia się użytkownikom Możliwa jest wymiana warstwy – przy zachowaniu interfejsów w tym, zmianę maszyny fizycznej (jedna warstwa) Zmiana interfejsu wpływa na tylko dwie warstwy Ale, trudna strukturalizacja: niektóre usługi (np. obsługa plików) udostępniane przez głębszą warstwę – rujnuje strukturę Ale, kłopoty z efektywnością wielopoziomowa interpretacja poleceń, lub sięganie do głębszych warstw

16 Plan Wstęp Strukturalizacja systemu Modele sterowania
Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

17 Wstęp Model strukturalny nie obejmuje sterowania – to osobne zagadnienie Dwa ogólne podejścia sterowanie scentralizowane jeden podsystem steruje, włącza i wyłącza, przekazuje sterowanie i oczekuje jego powrotu sterowanie zdarzeniowe każdy podsystem może reagować na zdarzenia zdarzenia występują w otoczeniu lub w podsystemach

18 Sterowanie scentralizowane I
Model 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 To jest model sterowania To nie jest model strukturalny! Sterowanie wraca tam, skąd przyszło inne działanie to zła praktyka Trudno obsłużyć wyjątki

19 Sterowanie scentralizowane II
Model menedżera Detektory Efektory Detektory Efektory Detektory Efektory Sterownik Procesy obliczeniowe Procesy obliczeniowe Interfejs użytkownika Obsługa awarii Dobry w „miękkich” systemach czasu rzeczywistego Sprawdza stan systemów i decyduje Nazwa: model pętli zdarzeń

20 Sterowanie zdarzeniowe I
Model rozgłaszania Podsystem 1 Podsystem 2 Podsystem 3 Procedura obsługi zdarzeń Dobry w integracji systemów rozproszonych Istnieje centralny rejestr zdarzeń interesujących różne podsystemy Ale, nie wiadomo, kiedy zdarzenie będzie obsłużone Ale, po obsłużeniu mogą być konflikty wyników

21 Sterowanie zdarzeniowe II
Model z przerwaniami Przerwania 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 Dobry w systemach czasu rzeczywistego Szybka reakcja na zdarzenia Można łączyć z modelem scentralizowanym Ale, złożone programowanie, trudna modyfikacja Ale, nie każdy przypadek można zasymulować Ale, liczba przerwań zwykle ograniczona sprzętowo

22 Plan Wstęp Strukturalizacja systemu Modele sterowania
Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

23 Dwa modele rozkładu na moduły
Model obiektowy zbiór porozumiewających się obiektów Model przepływu danych – potokowy moduły funkcjonalne pobierają dane i zwracają wyniki potoki i filtry, gdy przekształcenia są reprezentowane przez oddzielne procesy

24 Model obiektowy Zalety Wady dość niezależna implementacja
łatwo zrozumiałe wielokrotne wykorzystanie Wady konieczna znajomość interfejsów duża granulacja trudno modelować duże, złożone byty

25 Model przepływu danych
Zalety intuicyjny – wejście/wyjście, algorytmy jak w matematyce łatwo dodawać nowe przekształcenia łatwa implementacja sekwencyjna lub równoległa Wady konieczne ścisłe uzgadnianie formatów trudno tworzyć serwisy interakcyjne

26 Plan Wstęp Strukturalizacja systemu Modele sterowania
Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

27 Doświadczenie i wielokrotne użycie
Dwa rodzaje modeli architektonicznych charakterystycznych dla dziedzin Modele ogólne – abstrakcje istniejących systemów Modele odniesienia – abstrakcje wyższego rzędu, bardzo ogólne koncepcje Większość modeli charakterystycznych jest traktowana przez firmy jako cenna własność, cenna = tajna

28 Przykład modelu ogólnego – kompilator I
Wersja przepływu danych Tabela symboli Analiza leksykalna Analiza składniowa Analiza znaczeniowa Generowanie kodu Dobra w przetwarzaniu wsadowym

29 Przykład modelu ogólnego – kompilator II
Wersja repozytorium Analizator leksykalny Analizator składniowy Analizator znaczeniowy Generator prezentacji Optymalizator Drzewo składni Definicja gramatyki Repozytorium Tabela symboli Definicja wyniku Edytor Generator kodu Dobra w zintegrowanym środowisku konwersacyjnym

30 Przykład modelu odniesienia – OSI
OSI: Open Systems Interconnection, Hubert Zimmermann, 1980 – próba unifikacji sieci 7 Program użytkowy Program użytkowy 6 Prezentacja Prezentacja 5 Sesja Sesja 4 Transport Transport 3 Sieć Sieć Sieć 2 Łącze danych Łącze danych Łącze danych 1 Fizyczna Fizyczna Fizyczna Medium komunikacyjne Dobry model, niezależny od medium komunikacyjnego Choć praktycznie nie zastosowany, ułatwił zaprojektowanie istniejących protokołów

31 Plan Wstęp Strukturalizacja systemu Modele sterowania
Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

32 Podsumowanie Architektura oprogramowania – zrąb do strukturalizacji
można opracować modele: strukturalny, sterowania, podziału Modele strukturalne, np.: repozytorium, klient-serwer, maszyna abstrakcyjna Modele sterowania, np.: model scentralizowany, model zdarzeń Modele podziału na moduły, np.: model przepływu danych, model obiektowy Istnieją architektoniczne modele charakterystyczne dla dziedziny – warto znać i wybierać (lecz większość tajna) modele ogólne, modele odniesienia Wielkie systemy mają różnorodne, złożone struktury

33 Dziękuję