Projektowanie architektoniczne

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