1 Inżynieria Oprogramowania 6. Projektowanie architektoniczne26/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 sterowaniaRozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie
4 Plan Wstęp Strukturalizacja systemu Modele sterowaniaRozkł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 architektonicznegoKomunikacja 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 sterowaniapodział 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 Dokumentacjakilka 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 architektoniczneIstnieją 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 sterowaniaRozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie
12 Przykład Jednak, model a. jest narzędziem komunikacjiModel 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 abstrakcyjnejCharakterystyczne: 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 sterowaniaRozkł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 IModel 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 IIModel 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 IModel 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 IIModel 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 sterowaniaRozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie
23 Dwa modele rozkładu na modułyModel 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 danychZalety 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 sterowaniaRozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie
27 Doświadczenie i wielokrotne użycieDwa 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 IWersja 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 IIWersja 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 – OSIOSI: 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 sterowaniaRozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie
32 Podsumowanie Architektura oprogramowania – zrąb do strukturalizacjimoż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ę