Projektowanie architektoniczne

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 1

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ść

• 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ługaw dziekanatach

ObsługainternetowaUzgadnianie

Przeglądarkadziennikó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

Repozytoriumprzedsięwzięcia

Translatorprojektów

Edytorprojektów

Generatorkodu

Analizatorprojektów

Generatorraportów

Edytorprogramó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

Sieć

Zawodnik 1 Zawodnik 2 Zawodnik 3 Zawodnik 4

Serwerdrukowania

Serwerzadań

Serwerweryfikacji

Serwerzapasowy


Klient-serwer Zalety

• 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

System operacyjny

System bazy danych

Zarządzanie obiektami

Zarządzanie wersjami


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

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram


Model menedżera

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses


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

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4


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

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector


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

issue ()sendReminder ()acceptPayment ()sendReceipt ()

invoice#dateamountcustomer

Invoice

invoice#dateamountcustomer#

Receipt

invoice#dateamountcustomer#

Payment

customer#nameaddresscredit period

Customer


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

Zadania

Wyniki

Błędy

Testy

Kompilacja Sprawdzanie


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

Lexicalanalysis

Syntacticanalysis

Semanticanalysis

Codegeneration

Symboltable


System przetwarzania języka

Syntaxanalyser

Lexicalanalyser

Semanticanalyser

Abstractsyntax tree

Grammardefinition

Symboltable

Outputdefinition

Pretty-printer

Editor

Optimizer

Codegenerator

Repository


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 OSIApplication

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

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

Documents

Projektowanie architektoniczne