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

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

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

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

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

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

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

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

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

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

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

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ą

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

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

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

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

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

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

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

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

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

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

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

Model wywołanie-powrót

Model menedżera

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

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

Wybiórcze rozgłaszanie

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

Sterowanie z przerwaniami

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

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

Obiektowy system fakturowania

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

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

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

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

Model kompilatora

System przetwarzania języka

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

Model odniesienia OSI Application

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

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