Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Projektowanie architektoniczne l Ustalanie zrębu całości systemu.

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Projektowanie architektoniczne l Ustalanie zrębu całości systemu."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Projektowanie architektoniczne l Ustalanie zrębu całości systemu

2 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 2 Zawartość l Strukturalizacja systemu l Modele sterowania l Rozkład na moduły l Architektury charakterystyczne dla różnych dziedzin

3 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 3 Architektura oprogramowania l 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 l Produktem tej fazy jest architektura oprogramowania

4 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 4 Projektowanie architektoniczne l Wstępna faza projektowania systemu l Łączy specyfikację z projektem l Często wykonywana równolegle z czynnościami przygotowywania specyfikacji l Zawiera zidentyfikowanie głównych komponentów systemu i metod komunikacji pomiędzy nimi

5 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 5 Zalety jawnej architektury l Komunikacja z uczestnikami Architektura może być używana jako podstawa do dyskusji z różnymi uczestnikami przedsięwzięcia l Analiza systemu Środek za pomocą którego można częściowo sprawdzić czy system będzie spełniał krytyczne wymagania niefunkcjonalne l Użycie wielokrotne w wielkiej skali Architektura może być używana do budowy wielu systemów

6 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 6 Proces projektowania architektonicznego l Strukturalizacja systemu System jest dzielony na kilka podstawowych podsystemów i jest identyfikowana komunikacja pomiędzy nimi l Modelowanie sterowania Określa się model przepływu sterowania pomiędzy różnymi częściami systemu l Podział na moduły Zidentyfikowane podsystemy dzielone są na moduły

7 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 7 Podsystemu i moduły l Podsystem jest w pełni działającym systemem, którego usługi nie zależą od usług oferowanych przez inne podsystemy l Moduł jest częścią systemu, która oferuje usługi innym modułom i nie może być rozważana jako oddzielny system

8 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 8 Modele architektoniczne l Podczas procesu projektowania architektonicznego mogą powstać różne modele l Każdy z modeli przedstawia inny punkt widzenia architektury

9 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 9 Modele architektoniczne l Statyczny model strukturalny pokazuje główne komponenty systemu l Model dynamiczny procesu przedstawia podział systemu na procesy czasu wykonania l Model interfejsu pokazuje interfejsy podsystemów l Model związku podobny do modelu przepływu danych

10 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 10 Style architektoniczne l Projektowanie architektoniczne można przeprowadzić zgodnie z ogólnym modelem lub stylem l Znajomość takich styli może uprościć tworzenie architektury l Niestety większość dużych systemów jest mieszana i nie pozwala na użycie tylko jednego stylu

11 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 11 Atrybuty stylów l Wydajność Lokalizacja operacji i minimalizacja komunikacji l Zabezpieczenie Architektura warstwowa z danymi w wewnętrznej warstwie l Bezpieczeństwo Izolacja operacji bezpieczeństwa w jednym miejscu l Dostępność Włączenie do systemu komponentów nadmiarowych l Zdatność do pielęgnacji Podział na drobnoziarniste, samowystarczalne komponenty

12 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 12 Strukturalizacja systemu l Polega na podziale systemu na współpracujące podsystemy l Jest zazwyczaj przedstawiana w postaci przeglądowego diagramu blokowego opisującego strukturę systemu l Można dodatkowo opracować dokładniejsze modele pokazujące jak podsystemy współdzielą dane i jak się ze sobą komunikują

13 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 13 Uniwersyteckie lektoraty Obsługa w dziekanatach Obsługa internetowa Uzgadnianie Przeglądarka dzienników

14 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 14 Model repozytorium l 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 l Kiedy danych dzielonych jest dużo stosuje się zazwyczaj centralną bazę danych

15 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 15 Architektura narzędzi CASE Repozytorium przedsięwzięcia Translator projektów Edytor projektów Generator kodu Analizator projektów Generator raportów Edytor programów

16 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 16 Współdzielone repozytorium l 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 l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 17 Architektura klient-serwer l Model systemów rozproszonych, który pokazuje jak dane są przetwarzane i dostarczane do różnych komponentów l Zbiór samodzielnych serwerów dostarcza różnych usług jak drukowanie,... l Zbiór klientów używa tych serwerów l Sieć pozwala na dostęp klientów do serwerów

18 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 18 Konkurs programistyczny Sieć Zawodnik 1Zawodnik 2Zawodnik 3Zawodnik 4 Serwer drukowania Serwer zadań Serwer weryfikacji Serwer zapasowy

19 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 19 Klient-serwer l Zalety Proste przesyłanie danych Efektywne wykorzystanie sieci. Może wymagać tańszego sprzętu Łatwo dodawać nowe serwery lub ulepszać istniejące l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 20 Model maszyny abstrakcyjnej l Opisuje sprzęganie podsystemów l Dzieli system na zbiór warstw (maszyn abstrakcyjnych) dostarczających usług l Pomaga tworzyć system przyrostowo. Kiedy warstwa się zmienia tylko sąsiednie trzeba zmodyfikować l Zazwyczaj trudno podzielić system w ten sposób

21 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 21 System zarządzania wersjami System operacyjny System bazy danych Zarządzanie obiektami Zarządzanie wersjami

22 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 22 Modele sterowania l Opisują przepływ sterowania pomiędzy podsystemami. Różnią się od modeli dekompozycji systemu l Sterowanie scentralizowane Jeden system jest odpowiedzialny za uruchamianie i zatrzymywanie pozostałych podsystemów l Sterowanie zdarzeniowe Każdy z podsystemów samodzielnie odpowiada na zdarzenia przychodzące z zewnątrz

23 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 23 Sterowanie scentralizowane l Jeden z podsystemów zarządza pozostałymi l 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 l Model menedżera Odpowiedni dla systemów współbieżnych. Jeden komponent jest odpowiedzialny za uruchamianie, zatrzymywanie i koordynację innych systemów

24 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 24 Model wywołanie-powrót

25 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 25 Model menedżera

26 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 26 Systemy sterowane zdarzeniami l Sterowane zdarzeniami przychodzącymi z zewnątrz, gdzie system nie ma wpływu na czas zajścia zdarzenia l 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 l Inne modele zawierają arkusze kalkulacyjne i systemy biznesowe

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

28 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 28 Wybiórcze rozgłaszanie

29 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 29 Systemy sterowane przerwaniami l Używane w systemach czasu rzeczywistego, gdzie czas reakcji jest kluczowy l Są określone typy przerwań i procedury ich obsługi l Każdy typ przerwania jest skojarzony z miejscem w pamięci, gdzie przechowuje się adres procedury obsługi przerwania l Pozwalają na szybką odpowiedź, ale są skomplikowane i trudne do zweryfikowania

30 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 30 Sterowanie z przerwaniami

31 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 31 Rozkład na moduły l Kolejny poziom struktury w którym podsystemy są rozkładane na moduły l 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 l Jeśli to możliwe, powinno się unikać decyzji o współbieżności aż do zaimplementowania modułów

32 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 32 Modele obiektowe l System jest dzielony na zbiór luźno uzależnionych o siebie obiektów z dobrze opisanymi interfejsami l Głównym celem jest identyfikacja klas, atrybutów i operacji l Podczas implementacji klasy są tworzone na podstawie modelu klas i dodatkowego modelu kontroli przepływu sterowania

33 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 33 Obiektowy system fakturowania

34 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 34 Modele przepływu danych l Funkcyjne przekształcanie wejścia w wyjście l Model potokowy (jak w powłoce) l Często występują warianty tego modelu. Popularny szczególnie podczas wykonywania obliczeń l Nieodpowiedni dla systemów interaktywnych

35 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 35 Zadania w olimpiadzie Zadania Wyniki Błędy Testy KompilacjaSprawdzanie

36 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 36 Architektury charakterystyczne dla różnych dziedzin l Modele architektoniczne dla konkretnych dziedzin zastosowań l 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 l Modele ogólne są zazwyczaj wstępujące, a modele odniesienia zstępujące

37 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 37 Modele ogólne l Bardzo dobrze znanym modelem ogólnym jest model kompilatora Analizator leksykalny Tablica symboli Analizator syntaktyczny Drzewo programu Analizator semantyczny Generator kodu l Ogólny model kompilatora można użyć w różnych modelach architektonicznych

38 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 38 Model kompilatora

39 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 39 System przetwarzania języka

40 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 40 Modele odniesienia l Modele odniesienia są wynikami analizy dziedziny a nie istniejących systemów l Mogą być używane jako podstawa tworzenia systemu albo do porównania z innymi systemami. l Przykładem jest model OSI komunikacji w sieci

41 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 41 Model odniesienia OSI Application

42 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 42 Główne tezy l Architekt oprogramowania jest odpowiedzialny za stworzenie modelu, podział systemu na podsystemy i ustalenie komunikacji l Duże systemy rzadko pasują do jednego modelu l Systemy można dzielić zgodnie z architekturą klient-serwer modelem z repozytorium i maszyną abstrakcyjną l Modele kontroli sterowania zawierają sterowanie centralne i zdarzeniowe

43 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 43 Główne tezy l Podział systemu na moduły zawiera podziały obiektowe i przepływów danych l 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


Pobierz ppt "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Projektowanie architektoniczne l Ustalanie zrębu całości systemu."

Podobne prezentacje


Reklamy Google