Inżynieria oprogramowania - 10 Slide 1
Projektowanie architektoniczne
. Ustanawianie ogólnej struktury
systemu oprogramowania
Inżynieria oprogramowania - 10 Slide 2
Cele
. Wprowadzenie koncepcji projektowania
architektonicznego i omówienie jego znaczenia
. Wyjaśnienie dlaczego do udokumentowania
architektury systemu wymagane są różne modele
. Opis typów modeli architektonicznych, które mogą
być użyte
. Omówienie w jaki sposób charakterystyczne dla
różnych dziedzin modele architektoniczne mogą być
użyte jako podstawa dla linii produktów i do
porównania architektur oprogramowania
Inżynieria oprogramowania - 10 Slide 3
Zawartość
. Strukturalizacja systemu
. Modele sterowania
. Rozkład na moduły
. Architektury charakterystyczne dla różnych
dziedzin
Inżynieria oprogramowania - 10 Slide 4
Architektura oprogramowania
. Projektowanie architektoniczne to faza procesu
projektowania w której identyfikuje się
podsystemy stanowiące system oraz ustala się
strukturę sterowania i komunikacji podsystemów
. Produktem tej fazy procesu projektowania jest
opis architektury oprogramowania
Inżynieria oprogramowania - 10 Slide 5
Projektowanie architektoniczne
. Pierwsza faza procesu projektowania systemu
. Łączy proces projektowania i specyfikacji
. Często wykonywane równolegle do niektórych
działań związanych ze specyfikacją
. Dotyczy identyfikacji najważniejszych
komponentów systemu i komunikacji między
nimi
Inżynieria oprogramowania - 10 Slide 6
Zalety jawnej architektury
. Komunikacja z uczestnikami
. Architektura może służyć za podstawę dyskusji w gronie
użytkowników systemu
. Analiza systemu
. Możliwość przeprowadzenia analizy czy system może spełniać
swoje niefunkcjonalne wymagania
. Użycie wielokrotne w wielkiej skali
. Architektura może być wielokrotnie używana w wielu
systemach
Inżynieria oprogramowania - 10 Slide 7
Proces projektowania architektonicznego
. Strukturalizacja systemu
. System jest dzielony na kilka podstawowych podsystemów i
identyfikuje się sposoby komunikacji pomiędzy tymi
podsystemami
. Modelowanie sterowania
. Określanie modelu związków sterowania pomiędzy różnymi
częściami systemu
. Podział na moduły
. Zidentyfikowane podsystemy dzielone są na moduły
Inżynieria oprogramowania - 10 Slide 8
Podsystemy i moduły
. Podsystem jest systemem, którego działanie jest
niezależne od usług oferowanych przez inne
podsystemy
. Moduł jest komponentem systemu, który oferuje
usługi innym komponentom lecz nie może być
traktowany jako oddzielny system
Inżynieria oprogramowania - 10 Slide 9
Modele architektoniczne
. Podczas procesu projektowania mogą powstawać
różne modele architektoniczne
. Każdy model przedstawia różne perspektywy
architektury
Inżynieria oprogramowania - 10 Slide 10
Modele architektoniczne
. Statyczny model strukturalny który przedstawia
najważniejsze komponenty systemu
. Model dynamiczny procesu który przedstawia
strukturę procesów systemu
. Model interfejsów który definiuje podsystem
interfejsów
. Model związków np. model przepływu danych
Inżynieria oprogramowania - 10 Slide 11
Atrybuty architektury
. Efektywność
. Umieszczenie działań w niewielkiej liczbie podsystemów, które
komunikują się między sobą w najmniejszym stopniu
. Zabezpieczenie
. Użycie architektury warstwowej z krytycznymi aktywami w
wewnętrznych warstwach
. Bezpieczeństwo
. Izolowanie komponentów krytycznych z uwagi na bezpieczeństwo
. Dostępność
. Zawarcie w architekturze komponentów nadmiarowych
. Zdatność do pielęgnacji
. Użycie drobnoziarnistych, samodzielnych komponentów
Inżynieria oprogramowania - 10 Slide 12
Strukturalizacja systemu
. Interesuje się dekompozycją systemu na
oddziałujące ze sobą podsystemy
. Projekt architektoniczny jest normalnie
przedstawiany jako diagram blokowy
prezentujący przegląd struktury systemu
. Bardziej specyficzne modele przedstawiają w jaki
sposób podsystemy współdzielą dane, jak są
rozproszone i jak się porozumiewają
Inżynieria oprogramowania - 10 Slide 13
System sterujący robotem
System
wizyjny
Sterownik
alarmu
Sterownik
chwytacza
System
identyfikacji
przedmiotów
System
wyboru
opakowania
System
pakujący
Sterownik
taśmociągu
Inżynieria oprogramowania - 10 Slide 14
Model repozytorium
. Podsystemy muszą wymieniać między sobą dane,
a to może odbywać się w dwojaki sposób:
. Współdzielone dane przetrzymywane są w centralnej bazie
danych i mogą być dostępne dla wszystkich podsystemów
. Każdy podsystem utrzymuje swoją własną bazę danych i
udostępnia ją innym podsystemom
. Kiedy duża ilość danych ma być współdzielona,
wtedy model repozytorium jest używany
najczęściej
Inżynieria oprogramowania - 10 Slide 15
Architektura zestawu narzędzi CASE
Edytor
projektów
Generator
kodu
Edytor
programów
Generator
raportów
Translator
projektów
Analizator
projektów
Repozytorium
przedsięwzięcia
Inżynieria oprogramowania - 10 Slide 16
Charakterystyki modelu repozytorium
. Zalety
. Efektywny sposób współdzielenia dużej ilości danych
. Podsystemy nie muszą interesować się w jaki sposób dane są
wytwarzane
. Scentralizowane zarządzanie, np. tworzenie kopii zapasowej,
zabezpieczenie itd.
. Model współdzielenia jest publikowany jako schemat
repozytorium
. Wady
. Podsystemy muszą uzgodnić model danych repozytorium.
Prowadzi to nieuchronnie do kompromisów
. Ewolucja danych jest trudna i droga
. Brak możliwości dla specyficznej polityki zarządzania
. Trudności w sprawnym rozproszeniu
Inżynieria oprogramowania - 10 Slide 17
Architektura klient-serwer
. Model systemu rozproszonego, który przedstawia
w jaki sposób dane i przetwarzanie są rozdzielone
między zbiór procesów
. Zbiór samodzielnych serwerów, które oferują
specyficzne usługi takie jak drukowanie,
zarządzanie danymi itd.
. Zbiór klientów, którzy korzystają z tych usług
. Sieć, która umożliwia klientom dostęp do
serwerów
Inżynieria oprogramowania - 10 Slide 18
Biblioteka filmów i zdjęć
Sieć szerokopasmowa
Klient 1 Klient 2 Klient 3 Klient 4
Serwer
katalogu
Katalog
Serwer
filmów
Pliki z
filmami
Serwer
zdjęć
Zdjęcia w postaci
cyfrowej
Serwer
hipertekstu
Sieć
hipertekstowa
Inżynieria oprogramowania - 10 Slide 19
Charakterystyki modelu klient-serwer
. Zalety
. Proste rozpowszechnianie danych
. Efektywne użycie systemów sieciowych. Wymaga tańszego sprzętu
. Łatwo dodać nowy serwer lub zmodyfikować istniejący
. Wady
. Brak modelu danych współdzielonych gdyż podsystemy używają
różnej organizacji danych, wymiana danych może być nieefektywna
. Nadmiarowe zarządzanie w każdym serwerze
. Brak centralnego rejestru nazw i usług . może to powodować trudności
w dowiadywaniu się jakie serwery i jakie usługi są dostępne
Inżynieria oprogramowania - 10 Slide 20
Model maszyny abstrakcyjnej
. Używany do modelowania wzajemnego
oddziaływania podsystemów
. Organizuje system w zbiór warstw (zwanych też
maszynami abstrakcyjnymi) z których każda
dostarcza zbiór usług
. Wspomaga tworzenie przyrostowe podsystemów
w różnych warstwach. Zmiana interfejsu warstwy
wpływa tylko na sąsiednie warstwy
. Ten sposób strukturalizacji systemu okazuje się
być trudny
Inżynieria oprogramowania - 10 Slide 21
System zarządzania wersjami
Zarządzanie wersjami
Zarządzanie obiektami
System bazy danych
System
operacyjny
Inżynieria oprogramowania - 10 Slide 22
Modele sterowania
. Interesują się przepływem sterowania pomiędzy
podsystemami.
. Sterowanie scentralizowane
. Jeden podsystem jest całościowo odpowiedzialny za sterowanie,
uruchamia i zatrzymuje inne podsystemy
. Sterowanie zdarzeniowe
. Każdy podsystem może reagować na zewnętrznie generowane
zdarzenia występujące w innych podsystemach lub w otoczeniu
systemu
Inżynieria oprogramowania - 10 Slide 23
Sterowanie scentralizowane
. Podsystem sterujący bierze odpowiedzialność za
zarządzanie działaniem innych podsystemów
. Model wywołanie-powrót
. Model podprogramu .z góry na dół. w którym sterowanie
zaczyna się na szczycie hierarchii podprogramów i przechodzi
w dół. Stosowany w systemach sekwencyjnych
. Model menadżera
. Stosowany w systemach współbieżnych. Jeden z komponentów
systemu steruje zatrzymywaniem, rozpoczynaniem i
koordynacją innych procesów systemu. Może być
zaimplementowany w systemach sekwencyjnych
Inżynieria oprogramowania - 10 Slide 24
Model wywołanie - powrót
Procedura 1.1 Procedura 1.2 Procedura 3.1 Procedura 3.2
Procedura 1 Procedura 2 Procedura 3
Program
główny
Inżynieria oprogramowania - 10 Slide 25
Sterowanie systemem czasu
rzeczywistego
Procesy
detektorów
Procesy
efektorów
Sterownik
systemu
Procesy
obliczeniowe
Interfejs
użytkownika
Obsługa
awarii
Inżynieria oprogramowania - 10 Slide 26
Systemy sterowane zdarzeniami
. Sterowane przez zewnętrznie generowane
zdarzenia
. Dwa główne modele sterowania zdarzeniowego
. Modele rozgłaszania. Zdarzenie jest ogłoszeniem dla
wszystkich podsystemów. Każdy podsystem który może
obsłużyć to zdarzenie reaguje na nie
. Modele z przerwaniami. Używane w systemach czasu
rzeczywistego gdzie przerwania są wykrywane przez obsługę
przerwań i przekazywane do innego komponentu w celu
przetworzenia
Inżynieria oprogramowania - 10 Slide 27
Model rozgłaszania
. Skuteczny w wypadku integracji podsystemów
rozproszonych na różnych komputerach w sieci
. Podsystemy rejestrują swoje zainteresowanie
specyficznymi zdarzeniami. Kiedy takie zdarzenia
zachodzą, sterowanie jest przekazywane do podsystemu,
który może je obsłużyć
. Strategia sterowania nie jest wbudowana w procedury
obsługi zdarzeń i komunikatów. Podsystemy decydują,
które zdarzenia są dla nich interesujące
. Podsystemy nie wiedzą czy i kiedy zdarzenie będzie
obsłużone
Inżynieria oprogramowania - 10 Slide 28
Rozgłaszanie wybiórcze
Procedura obsługi zdarzeń
Podsystem 1 Podsystem 2 Podsystem 3 Podsystem 4
Inżynieria oprogramowania - 10 Slide 29
Systemy sterowane przerwaniami
. Używane w systemach czasu rzeczywistego gdzie istotą
jest szybka odpowiedź na konkretne zdarzenie
. Istnieją znane typy przerwań oraz procedury ich obsługi
. Każdy rodzaj przerwania skojarzony jest z miejscem w
pamięci a przełącznik sprzętowy powoduje przekazanie
sterowania do procedury obsługi tego przerwania
. Pozwala na szybką odpowiedź lecz wadą jest złożoność
programowania i trudności z zatwierdzaniem
Inżynieria oprogramowania - 10 Slide 30
Sterowanie z przerwaniami
Procedura
obsługi 1
Proces 1 Proces 2 Proces 3 Proces 4
Procedura
obsługi 2
Procedura
obsługi 3
Procedura
obsługi 4
przerwania
wektor
przerwań
Inżynieria oprogramowania - 10 Slide 31
Rozkład na moduły
. Następny strukturalny poziom gdzie podsystemy
są dzielone na moduły
. Dwa modele służące do podziału podsystemu na
moduły:
. Model obiektowy - system dzielony jest na zbiór
porozumiewających się obiektów
. Model przepływu danych - system dzielony jest na moduły
funkcjonalne które przetwarzają dane wejściowe na dane
wyjściowe. Znany także jako model potokowy
. Jeśli jest to możliwe, decyzja co do
współbieżności powinna być opóźniona do czasu
aż moduły nie zostaną zaimplementowane
Inżynieria oprogramowania - 10 Slide 32
Modele obiektowe
. Podział systemu na zbiór luźno uzależnionych od
siebie obiektów z dobrze zdefiniowanymi
interfejsami
. Podział obiektowy uwzględnia identyfikację klas
obiektów, ich atrybuty i operacje
. Obiekty tworzone są z klas a niektóre modele
sterowania służą do koordynacji działań obiektów
Inżynieria oprogramowania - 10 Slide 33
System fakturowania
Klient
nr klienta
nazwisko
adres
okres
kredytowania
Płatność
nr faktury
data
kwota
nr klienta
Pokwitowanie
nr faktury
data
kwota
nr klienta
Faktura
nr faktury
data
kwota
nr klienta
wystaw()
wyślijUpomnienie()
przyjmijPłatność()
wyślijPokwitowanie()
Inżynieria oprogramowania - 10 Slide 34
Model przepływu danych
. Przekształcenia funkcjonalne przetwarzają dane
wejściowe na dane wyjściowe
. Nazywany też modelem potoków i filtrów (tak
jak powłoka UNIX.a)
. Warianty tego podejścia są bardzo powszechne.
Gdy przekształcenia są sekwencyjne, jest to
sekwencyjny model wsadowy który szeroko
stosowany jest w systemach przetwarzania
danych
. Nie jest odpowiedni dla systemów interakcyjnych
Inżynieria oprogramowania - 10 Slide 35
System fakturowania
Odczytaj
wystawione
faktury
Znajdź
przeterminowane
faktury
Zidentyfikuj
płatność
Wystaw
pokwitowania
Wystaw
upomnienia Upomnienia
Pokwitowania
Faktury Płatność
Inżynieria oprogramowania - 10 Slide 36
Architektury charakterystyczne
dla różnych dziedzin
. Modele architektoniczne, które są specyficzne dla
konkretnych dziedzin zastosowań
. Dwa typy modeli charakterystycznych dla dziedzin
. Modele ogólne które są abstrakcjami kilku rzeczywistych systemów i
które obejmują zasadnicze charakterystyki tych systemów
. Modele odniesienia które są jeszcze bardziej abstrakcyjne, modele
wyidealizowane. Są sposobem informowania o klasie systemu
. Modele ogólne są zazwyczaj modelami typu dół-góra
(bottom-up); modele odniesienia są modelami góra-
dół (top-down)
Inżynieria oprogramowania - 10 Slide 37
Modele ogólne
. Model kompilatora jest dobrze znanym
przykładem modelu ogólnego składającym się z
. Analizatora leksykalnego
. Tabeli symboli
. Analizatora składniowego
. Drzewa składni
. Analizatora znaczeniowego
. Generatora kodów
. Model ogólny kompilatora może być
zorganizowany zgodnie z różnymi modelami
architektonicznymi
Inżynieria oprogramowania - 10 Slide 38
Model kompilatora
Analiza
leksykalna
Analiza
składniowa
Analiza
znaczeniowa
Generowanie
kodu
Tabela
symboli
Inżynieria oprogramowania - 10 Slide 39
System przetwarzania języka
Generator
prezentacji
Edytor
Optymalizator
Generator
kodu
Analizator
leksykalny
Analizator
składniowy
Analizator
znaczeniowy
Drzewo składni
abstrakcyjnej
Repozytorium
Definicja
gramatyki
Tabela
symboli
Definicja
wyniku
Inżynieria oprogramowania - 10 Slide 40
Architektury odniesienia
. Modele odniesienia wywodzą się z badań
dziedziny zastosowań a nie z istniejących
systemów
. Mogą służyć jako podstawa implementacji
systemu lub do porównywania różnych
systemów. Występują jako standard
. Model OSI jest warstwowym modelem dla
komunikacji systemów
Inżynieria oprogramowania - 10 Slide 41
Model odniesienia OSI
Medium komunikacyjne
Program użytkowy
Prezentacja
Sesja
Transport
Sieć
Łącze danych
Fizyczna
Program użytkowy
Prezentacja
Sesja
Transport
Sieć
Łącze danych
Fizyczna
Sieć
Łącze danych
Fizyczna
7
6
5
4
3
2
1
Inżynieria oprogramowania - 10 Slide 42
Główne tezy
. Architekt oprogramowania jest odpowiedzialny
za opracowanie modelu struktury systemu,
modelu sterowania i modelu podziału na
podsystemy
. Wielkie systemy rzadko odpowiadają
pojedynczemu modelowi architektonicznemu
. Modelami podziału systemu są m.in. modele
repozytorium, modele klient-serwer i modele
maszyn abstrakcyjnych
. Modele sterowania obejmują sterowanie
scentralizowane i sterowanie zdarzeniami
Inżynieria oprogramowania - 10 Slide 43
Główne tezy
. Modele podziału na moduły obejmują modele
przepływu danych i modele obiektowe
. Architektoniczne modele charakterystyczne dla
dziedzin są abstrakcjami w ramach dziedziny
zastosowań. Mogą być konstruowane z
istniejących systemów lub mogą być
wyidealizowanymi modelami odniesienia