Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "Inżynieria Oprogramowania 6. Projektowanie architektoniczne Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW www.lchmiel.pl."— Zapis prezentacji:

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

2 Inżynieria oprogramowania 6. Projektowanie architektoniczne 2/32 Źródła Materiały dra Waldemara Karwowskiego, wykładowcy w poprzednich semestrach Ian Sommerville, Inżynieria Oprogramowania, WNT, Warszawa 2003

3 Inżynieria oprogramowania 6. Projektowanie architektoniczne 3/32 Plan Wstęp Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

4 Inżynieria oprogramowania 6. Projektowanie architektoniczne 4/32 Plan Wstęp Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

5 Inżynieria oprogramowania 6. Projektowanie architektoniczne 5/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 6/32...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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 7/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 8/32 Wspólne czynności Strukturalizacja systemu 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 9/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 10/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 11/32 Plan Wstęp Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

12 Inżynieria oprogramowania 6. Projektowanie architektoniczne 12/32 Przykład Model strukturalny architektury systemu robota pakującego System wizyjny System identyfikacji przedmiotów Sterownik chwytakaSterownik 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 13/32 Model repozytorium Charakterystyczne: wspólna baza danych przykład: zintegrowany zestaw narzędzi CASE Repozytorium Edytor projektów Generator kodu Analizator projektówGenerator raprotów Edytor programówTranslator projektó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 Blackboard systems...

14 Inżynieria oprogramowania 6. Projektowanie architektoniczne 14/32 Model klient-serwer Charakterystyczne: serwery i klienci, połączenie przez sieć przykład: wielodostępny system hipertekstowy 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 Sieć szerokopasmowa Klient 1Klient 2Klient 3 Serwer filmów Pliki filmów Serwer obrazów Pliki obrazów Serwer hipertekstu Pliki hipertekstowe

15 Inżynieria oprogramowania 6. Projektowanie architektoniczne 15/32 Zarządzanie wersjami Model maszyny abstrakcyjnej Charakterystyczne: każda warstwa jest maszyną abstrakcyjną przykład: system zarządzania wersjami 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 Zarządzanie obiektami System bazy danych System operacyjny

16 Inżynieria oprogramowania 6. Projektowanie architektoniczne 16/32 Plan Wstęp Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

17 Inżynieria oprogramowania 6. Projektowanie architektoniczne 17/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 18/32 Sterowanie scentralizowane I Model wywołanie-powrót Program główny Procedura 2Procedura 1Procedura 3 Procedura 1.1Procedura 1.2Procedura 3.1Procedura 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 19/32 Sterowanie scentralizowane II Model menedżera Sterownik Detektory Efektory Procesy obliczeniowe Obsługa awarii Interfejs użytkownika Dobry w miękkich systemach czasu rzeczywistego Sprawdza stan systemów i decyduje Nazwa: model pętli zdarzeń

20 Inżynieria oprogramowania 6. Projektowanie architektoniczne 20/32 Sterowanie zdarzeniowe I Model rozgłaszania 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 Procedura obsługi zdarzeń Podsystem 1Podsystem 2Podsystem 3

21 Inżynieria oprogramowania 6. Projektowanie architektoniczne 21/32 Sterowanie zdarzeniowe II Model z przerwaniami 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 Proces 1 Procedura obsługi 1 Wektor przerwań Proces 2 Procedura obsługi 2 Proces 3 Procedura obsługi 3 Proces 4 Procedura obsługi 4 Przerwania

22 Inżynieria oprogramowania 6. Projektowanie architektoniczne 22/32 Plan Wstęp Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

23 Inżynieria oprogramowania 6. Projektowanie architektoniczne 23/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 24/32 Model obiektowy Zalety 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 25/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 26/32 Plan Wstęp Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

27 Inżynieria oprogramowania 6. Projektowanie architektoniczne 27/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 28/32 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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 29/32 Repozytorium Przykład modelu ogólnego – kompilator II Wersja repozytorium Tabela symboli Generator prezentacji Edytor Generator kodu Optymalizator Dobra w zintegrowanym środowisku konwersacyjnym Drzewo składni Definicja gramatyki Definicja wyniku Analizator znaczeniowy Analizator leksykalny Analizator składniowy

30 Inżynieria oprogramowania 6. Projektowanie architektoniczne 30/32 Przykład modelu odniesienia – OSI OSI: Open Systems Interconnection, Hubert Zimmermann, 1980 – próba unifikacji sieci Dobry model, niezależny od medium komunikacyjnego Choć praktycznie nie zastosowany, ułatwił zaprojektowanie istniejących protokołów Medium komunikacyjne Fizyczna Łącze danych Sieć Transport Prezentacja Sesja Program użytkowy Łącze danych Sieć Łącze danych Sieć Transport Prezentacja Sesja Program użytkowy

31 Inżynieria oprogramowania 6. Projektowanie architektoniczne 31/32 Plan Wstęp Strukturalizacja systemu Modele sterowania Rozkład na moduły Architektury charakterystyczne dla różnych dziedzin Podsumowanie

32 Inżynieria oprogramowania 6. Projektowanie architektoniczne 32/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 Inżynieria oprogramowania 6. Projektowanie architektoniczne 33/32 Dziękuję


Pobierz ppt "Inżynieria Oprogramowania 6. Projektowanie architektoniczne Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW www.lchmiel.pl."

Podobne prezentacje


Reklamy Google