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

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

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

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

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

...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

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

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

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)

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

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

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.

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

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

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

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

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

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

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ń

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

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

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

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

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

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

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

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

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

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

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

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

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

Dziękuję