Projektowanie architektoniczne

Prezentacja na temat: "Projektowanie architektoniczne"— Zapis prezentacji:

1 Projektowanie architektoniczne
Ustalanie zrębu całości systemu

2 Zawartość Strukturalizacja systemu Modele sterowania Rozkład na moduły
Architektury charakterystyczne dla różnych dziedzin

3 Architektura oprogramowania
Faza procesu projektowania, w której identyfikuje się podsystemy budowanego systemu oraz ustala się zrąb sterowania i komunikacji pomiędzy nimi nosi nazwę projektowania architektonicznego Produktem tej fazy jest architektura oprogramowania

4 Projektowanie architektoniczne
Wstępna faza projektowania systemu Łączy specyfikację z projektem Często wykonywana równolegle z czynnościami przygotowywania specyfikacji Zawiera zidentyfikowanie głównych komponentów systemu i metod komunikacji pomiędzy nimi

5 Zalety jawnej architektury
Komunikacja z uczestnikami Architektura może być używana jako podstawa do dyskusji z różnymi uczestnikami przedsięwzięcia Analiza systemu Środek za pomocą którego można częściowo sprawdzić czy system będzie spełniał krytyczne wymagania niefunkcjonalne Użycie wielokrotne w wielkiej skali Architektura może być używana do budowy wielu systemów

6 Proces projektowania architektonicznego
Strukturalizacja systemu System jest dzielony na kilka podstawowych podsystemów i jest identyfikowana komunikacja pomiędzy nimi Modelowanie sterowania Określa się model przepływu sterowania pomiędzy różnymi częściami systemu Podział na moduły Zidentyfikowane podsystemy dzielone są na moduły

7 Podsystemu i moduły Podsystem jest w pełni działającym systemem, którego usługi nie zależą od usług oferowanych przez inne podsystemy Moduł jest częścią systemu, która oferuje usługi innym modułom i nie może być rozważana jako oddzielny system

8 Modele architektoniczne
Podczas procesu projektowania architektonicznego mogą powstać różne modele Każdy z modeli przedstawia inny punkt widzenia architektury

9 Modele architektoniczne
Statyczny model strukturalny pokazuje główne komponenty systemu Model dynamiczny procesu przedstawia podział systemu na procesy czasu wykonania Model interfejsu pokazuje interfejsy podsystemów Model związku podobny do modelu przepływu danych

10 Style architektoniczne
Projektowanie architektoniczne można przeprowadzić zgodnie z ogólnym modelem lub stylem Znajomość takich styli może uprościć tworzenie architektury Niestety większość dużych systemów jest mieszana i nie pozwala na użycie tylko jednego stylu

11 Atrybuty stylów Wydajność Zabezpieczenie Bezpieczeństwo Dostępność
Lokalizacja operacji i minimalizacja komunikacji Zabezpieczenie Architektura warstwowa z danymi w wewnętrznej warstwie Bezpieczeństwo Izolacja operacji bezpieczeństwa w jednym miejscu Dostępność Włączenie do systemu komponentów nadmiarowych Zdatność do pielęgnacji Podział na drobnoziarniste, samowystarczalne komponenty

12 Strukturalizacja systemu
Polega na podziale systemu na współpracujące podsystemy Jest zazwyczaj przedstawiana w postaci przeglądowego diagramu blokowego opisującego strukturę systemu Można dodatkowo opracować dokładniejsze modele pokazujące jak podsystemy współdzielą dane i jak się ze sobą komunikują

13 Uniwersyteckie lektoraty
Obsługa w dziekanatach Uzgadnianie Obsługa internetowa Przeglądarka dzienników

14 Model repozytorium Podsystemy muszą wymieniać informacje. Może to się odbywać na dwa sposoby: Dzielone dane są przechowywane w centralnej bazie danych, która jest dostępna dla wszystkich podsystemów Każdy podsystem utrzymuje własną bazę danych i przekazuje dane bezpośrednio do innych systemów Kiedy danych dzielonych jest dużo stosuje się zazwyczaj centralną bazę danych

15 Architektura narzędzi CASE
Edytor projektów Generator kodu Translator projektów Repozytorium przedsięwzięcia Edytor programów Analizator projektów Generator raportów

16 Współdzielone repozytorium
Zalety Wygodna metoda dzielenia dużych ilości danych Podsystemy nie muszą się troszczyć o używanie danych Centralne zarządzanie (backupy, bezpieczeństwo) Model jest schematem danych Wady Podsystemy muszą uzgodnić repozytorium. Nieuchronne kompromisy Ewolucja jest trudna i droga Nie ma możliwości oddzielnych polityk zarządzania Trudne do rozproszenia

17 Architektura klient-serwer
Model systemów rozproszonych, który pokazuje jak dane są przetwarzane i dostarczane do różnych komponentów Zbiór samodzielnych serwerów dostarcza różnych usług jak drukowanie, ... Zbiór klientów używa tych serwerów Sieć pozwala na dostęp klientów do serwerów

18 Konkurs programistyczny
Zawodnik 1 Zawodnik 2 Zawodnik 3 Zawodnik 4 Sieć Serwer drukowania Serwer zadań Serwer weryfikacji Serwer zapasowy

19 Klient-serwer Zalety Wady Proste przesyłanie danych
Efektywne wykorzystanie sieci. Może wymagać tańszego sprzętu Łatwo dodawać nowe serwery lub ulepszać istniejące Wady Trudna i nieefektywna wymiana danych Oddzielna administracja każdego z serwerów Brak centralnej listy usług i nazw serwerów. Trudno sprawdzić które usługi są dostępne

20 Model maszyny abstrakcyjnej
Opisuje sprzęganie podsystemów Dzieli system na zbiór warstw (maszyn abstrakcyjnych) dostarczających usług Pomaga tworzyć system przyrostowo. Kiedy warstwa się zmienia tylko sąsiednie trzeba zmodyfikować Zazwyczaj trudno podzielić system w ten sposób

21 System zarządzania wersjami
Zarządzanie wersjami Zarządzanie obiektami System bazy danych System operacyjny

22 Modele sterowania Opisują przepływ sterowania pomiędzy podsystemami. Różnią się od modeli dekompozycji systemu Sterowanie scentralizowane Jeden system jest odpowiedzialny za uruchamianie i zatrzymywanie pozostałych podsystemów Sterowanie zdarzeniowe Każdy z podsystemów samodzielnie odpowiada na zdarzenia przychodzące z zewnątrz

23 Sterowanie scentralizowane
Jeden z podsystemów zarządza pozostałymi Model wywołanie-powrót Model zstępującego wywoływania podprogramów, w którym sterowanie zaczyna się na wierzchołku hierarchii i stopniowo jest przekazywane w dół. Odpowiedni dla systemów sekwencyjnych Model menedżera Odpowiedni dla systemów współbieżnych. Jeden komponent jest odpowiedzialny za uruchamianie, zatrzymywanie i koordynację innych systemów

24 Model wywołanie-powrót

25 Model menedżera

26 Systemy sterowane zdarzeniami
Sterowane zdarzeniami przychodzącymi z zewnątrz, gdzie system nie ma wpływu na czas zajścia zdarzenia Dwie podstawowe klasy modeli Modele rozgłaszania. Zdarzenie jest wysyłane do wszystkich podsystemów i każdy z nich może na nie zareagować Modele z przerwaniami. Używane w systemach czasu rzeczywistego gdzie przerwania są wykrywane przez obsługę przerwań i przekazywane do komponentów obsługujących Inne modele zawierają arkusze kalkulacyjne i systemy biznesowe

27 Modele rozgłaszania Przydatne w przypadku integrowania podsystemów rozproszonych w sieci Podsystemy zgłaszają zainteresowanie pewnym zdarzeniem, które jest im przekazywane kiedy zajdzie Polityka obsługi zdarzenie nie jest zawarta w zdarzeniu i programie obsługującym. Podsystemy decydują jakie zdarzenia przyjmować Podsystemy nie wiedzą czy i kiedy zdarzenie będzie obsłużone

28 Wybiórcze rozgłaszanie

29 Systemy sterowane przerwaniami
Używane w systemach czasu rzeczywistego, gdzie czas reakcji jest kluczowy Są określone typy przerwań i procedury ich obsługi Każdy typ przerwania jest skojarzony z miejscem w pamięci, gdzie przechowuje się adres procedury obsługi przerwania Pozwalają na szybką odpowiedź, ale są skomplikowane i trudne do zweryfikowania

30 Sterowanie z przerwaniami

31 Rozkład na moduły Kolejny poziom struktury w którym podsystemy są rozkładane na moduły Dwa typy rozkładu na moduły Model obiektowy, gdzie system jest dzielony na współpracujące moduły Model przepływu danych, gdzie system jest dzielony na moduły funkcjonalne przetwarzające wejście w wyjście Jeśli to możliwe, powinno się unikać decyzji o współbieżności aż do zaimplementowania modułów

32 Modele obiektowe System jest dzielony na zbiór luźno uzależnionych o siebie obiektów z dobrze opisanymi interfejsami Głównym celem jest identyfikacja klas, atrybutów i operacji Podczas implementacji klasy są tworzone na podstawie modelu klas i dodatkowego modelu kontroli przepływu sterowania

33 Obiektowy system fakturowania

34 Modele przepływu danych
Funkcyjne przekształcanie wejścia w wyjście Model potokowy (jak w powłoce) Często występują warianty tego modelu. Popularny szczególnie podczas wykonywania obliczeń Nieodpowiedni dla systemów interaktywnych

35 Zadania w olimpiadzie Błędy Kompilacja Sprawdzanie Wyniki Zadania
Testy

36 Architektury charakterystyczne dla różnych dziedzin
Modele architektoniczne dla konkretnych dziedzin zastosowań Dwie główne klasy Modele ogólne, które są abstrakcjami rzeczywistych systemów. Obejmują główne cechy charakterystyczne tych systemów Modele odniesienia, które są jeszcze bardziej abstrakcyjnymi i wyidealizowanymi modelami. Dostarczają ogólnych informacji o strukturze klasy systemów Modele ogólne są zazwyczaj wstępujące, a modele odniesienia zstępujące

37 Modele ogólne Bardzo dobrze znanym modelem ogólnym jest model kompilatora Analizator leksykalny Tablica symboli Analizator syntaktyczny Drzewo programu Analizator semantyczny Generator kodu Ogólny model kompilatora można użyć w różnych modelach architektonicznych

38 Model kompilatora

39 System przetwarzania języka

40 Modele odniesienia Modele odniesienia są wynikami analizy dziedziny a nie istniejących systemów Mogą być używane jako podstawa tworzenia systemu albo do porównania z innymi systemami. Przykładem jest model OSI komunikacji w sieci

41 Model odniesienia OSI Application

42 Główne tezy Architekt oprogramowania jest odpowiedzialny za stworzenie modelu, podział systemu na podsystemy i ustalenie komunikacji Duże systemy rzadko pasują do jednego modelu Systemy można dzielić zgodnie z architekturą klient-serwer modelem z repozytorium i maszyną abstrakcyjną Modele kontroli sterowania zawierają sterowanie centralne i zdarzeniowe

43 Główne tezy Podział systemu na moduły zawiera podziały obiektowe i przepływów danych Architektury charakterystyczne dla dziedziny mogą być ogólne jeśli powstały na podstawie analizy systemów lub odniesienia jeśli powstały na podstawie dziedziny