Podstawy Inżynierii Oprogramowania. Wykład 8 Projektowanie architektury systemu

Transkrypt

1 Podstawy Inżynierii Oprogramowania Wykład 8 Projektowanie architektury systemu

2 Podręcznik projektowania architektoniczno-budowlanego - Normy podstawowe - Podstawy wymiarowania. Proporcje - Projektowanie - Realizacja budowy - Części budynku - Ogrzewanie. Wentylacja - Fizyka budowli. Ochrona budowli - Oświetlenie. Światło dzienne. Szkło - Okna. Drzwi - Schody. Dźwigi - Ulice - Ogrody - Dom. Pomieszczenia gospodarcze - Pomieszczenia mieszkalne - Pływalnie - Pralnie - Balkony - Drogi - Domy letniskowe - Rodzaje zabudowy mieszkaniowej - Schrony - Modernizacja starych budynków - Szkoły - Szkoły wyższe. Laboratoria - Ośrodki dla dzieci - Biblioteki. Biura. Banki - Budynki użyteczności publicznej - Sklepy - Magazyny - Warsztaty. Zakłady przemysłowe - Zmiana przeznaczenia - Budownictwo wiejskie - Koleje - Parkingi. Garaże. Stacje paliw - Porty lotnicze - Gastronomia - Hotele. Motele - Zoo - Teatry.Kina - Urządzenia sportowe - Szpitale - Domy seniora - Kościoły.Muzea - Cmentarze - Ochrona przeciwpożarowa - Miary. Normy 2

3 Inne podręczniki architekta Perspektywa wykresowa dla architektów Klasyczny podręcznik zawiera podstawowe wiadomości dotyczące procesu widzenia, metod rzutowania niezbędnych w celu opanowania zagadnień związanych z perspektywą, omawia również podstawowe elementy i konstrukcje perspektywiczne. Nowoczesne konstrukcje w budownictwie ogólnym Zagadnienia dotyczące realizacji budynków mieszkalnych mało- i średniokubaturowych oraz wielorodzinnych, a także hal przemysłowych, sportowych, widowiskowych, obiektów sakralnych Architektura mostów zintegrowanych (...) Opis rozwiązań konstrukcyjnych mostów oraz nasypów z uwzględnieniem osiadania gruntu nasypu i połączenia nasypu z konstrukcją obiektu, analizę zjawisk meteorologicznych i klimatycznych generujących oddziaływania termiczne na most, opis parcia i odporu gruntu, przemieszczeń przyczółków (...) 3

4 Application/software architecture Up to this point I have been able to design applications in my head. I would get a vision for what the application should do and how it should do it. I would visualize all the major components, how each of the components would be designed, how they would be tested, what the UI should contain, how the data would flow, etc. Then I would jot down a few notes and be off and running. Basically, I'm a cowboy coder. I don't use any formal methodologies. I always knew that someday this would catch up to me and now it has. I'm starting a project (an enterprise database application) that is too large and complex to get a good vision of in my head, and I'm just not sure where to start. Cowboy Coder (Friday, November 21, 2003) 4

5 Agenda Co to jest architektura systemu informatycznego? Definicje Typy architektury oprogramowania. Architektury dziedzinowe. Architektury systemów informatycznych przedsiębiorstwa. 5

6 Dlaczego architektura? Wielkie systemy są zwykle podzielone na podsystemy. Proces identyfikacji podsystemów nazywa się projektowaniem architektonicznym. Produktem jest architektura oprogramowania. 6

7 Architektura oprogramowania (definicja 1) Architektura oprogramowania jest produktem procesu wytwarzania, który daje zyski w przyszłości pod warunkiem, że jest dobrej jakości. 7

8 Architektura oprogramowania (definicja 2) Zbiór istotnych decyzji związanych z organizacją oprogramowania. Wybór elementów strukturalnych i ich interfejsów Współpraca pomiędzy tymi elementami dająca w wyniku zachowanie systemu Grupowanie elementów strukturalnych w podsystemy 8

9 Czego oczekujemy od architektury? Elastyczności Zaspokojenie obecnych i przyszłych wymagań, Zwiększenie możliwości rozbudowy systemu, Umożliwienie ponownego użycia w wielkiej skali, Hermetyzacja zależności pomiędzy elementami systemu. Modularności Powtórne użycie elementów, Wybór istniejących komercyjnych komponentów, Iteracyjne ewoluowanie systemu. 9

10 Podsystem i moduł Podsystem system na swoich własnych prawach. Nie zależą od usług oferowanych przez inne podsystemy. Wyposażone w interfejsy. Składają się z modułów. Moduł komponent systemu, który oferuje co najmniej jedną usługę innym modułom. Korzysta z usług innych modułów. Zwykle nie jest niezależny. 10

11 Dokumentowanie architektury Opis systemu jako struktury złożonej z podsystemów Opis podsystemów jako struktury złożonej z modułów. Opis może uwzględniać kilka punktów widzenia: Statyczny model struktury. Dynamiczny model procesów. Model interfejsów. Model powiązań pomiędzy podsystemami. 11

12 Decyzje architektoniczne Architektura ma wpływ na: Efektywność Gruboziarnistość, minimalizacja komunikacji między modułami. Bezpieczeństwo Lokalizacja krytycznych elementów w małej liczbie komponentów. Zabezpieczenie Warstwowość, lokalizacja krytycznych aktywów w wewnętrznych warstwach. Dostępność Nadmiarowe komponenty. Zdatność do pielęgnacji Drobnoziarnistość. 12

13 Architektura robota-pakowacza System wizyjny System identyfikacji przedmiotów Sterownik ramienia Sterownik chwytacza System wyboru opakowania System pakujący Sterownik taśmociągu 13

14 Architektura repozytorium danych Model scentralizowany Dane są współdzielone pomiędzy podsystemami Nazywany modelem repozytorium Model zdecentralizowany Każdy podsystem prowadzi własną bazę danych, dane są przesyłane na zasadzie komunikatów. Model zdecentralizowany fizycznie może być logicznie postrzegany jako scentralizowany 14

15 Model repozytorium Edytor projektów Generator kodu Translator projektów Repozytorium przedsięwzięcia Edytor programów Analizator projektów Generator raportów 15

16 Zalety współdzielonego repozytorium Efektywny sposób przechowywania dużej ilości danych. Podsystemy produkujące dane nie muszą zajmować się problemem ich przechowywania oraz użycia przez inne podsystemy. Zarządzanie bezpieczeństwem, kopiami zapasowymi jest scentralizowane. Model danych jest jeden (schemat repozytorium). 16

17 Wady współdzielonego repozytorium Podsystemy muszą uzgodnić model danych. Prowadzi to nieuchronnie do kompromisów. Integracja nowych podsystemów może być trudna (jeżeli ich schemat danych jest inny). Ewolucja schematu danych jest trudna. Polityka bezpieczeństwa i zarządzania danymi musi być jedna. 17

18 Architektura typu klient-serwer Model systemu rozproszonego. Zbiór serwerów Zbiór klientów Sieć komputerowa Serwer udostępnia określone usługi. Klienci korzystają z usług za pomocą komunikacji zdalnej. 18

19 Biblioteka w architekturze klientserwer Klient 1 Klient 2 Klient 3 Klient 4 Sieć komputerowa Serwer katalogu Serwer filmów Serwer obrazów Serwer WWW Katalog Pliki filmowe Zdjęcia w postaci cyfrowej Dane hipertekstowe 19

20 Zalety i wady architektury klientserwer Zalety Wady Możliwość rozszerzania zakresu usług. Rozdzielenie funkcjonalności zmniejszenie wymagań sprzętowych. Dane są w naturalny sposób rozproszone Brak wspólnego modelu danych rozproszonych Nadmiarowe zarządzanie każdym serwerem Brak centralnego rejestru usług i danych. 20

21 Maszyna abstrakcyjna model warstwowy Kładzie nacisk na sposób sprzęgania się komponentów. System zbiór warstw (maszyn abstrakcyjnych) Każda warstwa udostępnia usługi używane do implementacji kolejnej warstwy. 21

22 Typowe podejście warstwowe Podsystemy aplikacji Biznes Middleware Oprogramowanie systemowe Komponenty specyficzne dla konkretnej aplikacji Komponenty reprezentujące usługi specyficzne dla domeny (biznesu) wykorzystywane w wielu aplikacjach Usługi niezależne od platformy, często powiązane z przetwarzaniem rozproszonym (ODBC, OLE, edytory, generatory raportów, interfejsów) Infrastruktura system operacyjny, interfejsy do urządzeń, sterowniki, itd. 22

23 Przykład modelu warstwowego system zarządzania wersjami Warstwa zarządzania wersjami Warstwa zarządzania obiektami Warstwa bazy danych Warstwa systemu operacyjnego 23

24 Charakterystyka modelu warstwowego Zalety: Ułatwia przyrostowe tworzenie oprogramowania. Zachowując interfejs warstwy można zmienić ją na inną. Zmiana interfejsu warstwy ma wpływ tylko na warstwy sąsiednie. Umożliwia ukrycie zależności od konkretnej platformy Wady: Proces strukturalizacji może być trudny. Mogą wystąpić problemy z efektywnością. 24

25 Dekompozycja modularna Kolejny poziom strukturalny, w którym podsystemy są dzielone na moduły. Podział na moduły może odbywać się zgodnie z: Modelem obiektowym podsystem dekomponowany do postaci komunikujących się ze sobą obiektów Modelem przepływu danych podsystem dekomponowany do postaci modułów funkcjonalnych transformujących wejście na wyjście. 25

26 Dekompozycja obiektowa Struktura podsystemu jest zbiorem luźno powiązanych obiektów z dobrze zdefiniowanymi interfejsami. Dekompozycja zorientowana obiektowo związana jest z procesem identyfikacji klas obiektów, ich atrybutów oraz operacji. W trakcie implementacji obiekty są tworzone na podstawie klas. Działanie obiektów koordynowane jest przez określony model dynamiczny. 26

27 Własności dekompozycji obiektowej Obiekty są ze sobą luźno powiązane, dzięki czemu ich implementacja może być zmieniona bez wpływu na inne obiekty. Obiekty mogą odzwierciedlać elementy rzeczywistości. Najpowszechniej wykorzystywane języki programowania są zorientowane obiektowo. 27

28 Kontrola zachowania W procesie definiowania architektury związana z kontrolą przepływu sterowania pomiędzy podsystemami. Kontrola scentralizowana Jeden podsystem jest odpowiedzialny za wykonywanie zadań. Uruchamia i zatrzymuje pozostałe podsystemy Kontrola sterowana zdarzeniami Każdy z podsystemów może reagować na zewnętrzne zdarzenia (pochodzące od innych podsystemów lub z otoczenia systemu) 28

29 Kontrola scentralizowana (1) One subsystem to rule them all. Model wywołanie-powrót (ang. call-return). Dla systemów działających sekwencyjnie Model podprogramów, w którym sterowanie zaczyna się na wierzchołku hierarchii i przez wywołanie podprogramów przechodzi do najniższych poziomów drzewa wywołań. Program główny Procedura 1 Procedura 2 Procedura 3 Procedura 1.1 Procedura 1.2 Procedura 3.1 Procedura

30 Kontrola scentralizowana (2) One subsystem to rule them all. Model zarządcy (ang. manager), dla systemów współbieżnych: Jeden z podsystemów wybierany jest do roli managera i steruje rozpoczynaniem, zatrzymywaniem i koordynacją pozostałych procesów. Procesy detektorów Procesy efektorów Zarządca systemu Procesy obliczeniowe Interfejs użytkownika Obsługa błędów 30

31 Kontrola sterowana zdarzeniami (1) System/podsystem sterowany zewnętrznymi zdarzeniami nie zdeterminowanymi czasowo. Model rozgłaszania (ang. broadcast) Zdarzenie jest rozgłaszane do wszystkich podsystemów. Każdy z nich, który może obsłużyć to zdarzenie, reaguje na nie. Podsystem 1 Podsystem 2 Podsystem 3 Podsystem 4 Obsługa zdarzeń i komunikatów 31

32 Charakterystyka modelu rozgłaszania Przydatny w integracji podsystemów pracujących na różnych platformach i komunikujących się za pomocą sieci komputerowej. Podsystem rejestruje swoje zainteresowanie określonym zdarzeniem (tzw. model publisher-subscriber). W momencie pojawienia się zdarzenia, moduł obsługi przesyła zdarzenie do wszystkich zarejestrowanych. Strategia sterowania nie jest wbudowana w procedury obsługi zdarzeń. Prostota ewolucji. Podsystemu nie wiedzą czy zdarzenie będzie obsłużone, czy nie wystąpią konflikty, itp. 32

33 Kontrola sterowana zdarzeniami (2) System/podsystem sterowany zewnętrznymi zdarzeniami nie zdeterminowanymi czasowo. Model z przerwaniami (ang. interrupt-driven) Zewnętrzne przerwania są wykrywane przez obsługę przerwań i są przekazywane do komponentu, który je obsłuży. Przerwania Wektor przerwań Procedura obsługi 1 Procedura obsługi 2 Procedura obsługi 3 Procedura obsługi 4 Proces 1 Proces 2 Proces 3 Proces 4 33

34 Charakterystyka modelu z przerwaniami Wykorzystywane głównie w systemach czasu rzeczywistego, gdzie zdarzenia z otoczenia muszą być obsługiwane bardzo szybko. Typy przerwań oraz procedury ich obsługi są z góry znane. Każdy typ przerwania jest powiązany z odpowiednim miejscem w pamięci. Sprzętowy przełącznik powoduje przełączenie do procedury obsługi. Umożliwia implementacje szybkich odpowiedzi ale jest bardzo złożona programistycznie i dramatycznie trudna w zatwierdzaniu (testowaniu). Może być trudny w ewolucji (ograniczona liczba przerwań). 34

35 Architektury charakterystyczne dla różnych dziedzin Istnieją modele architektoniczne specyficzne dla konkretnych dziedzin zastosowań. Związane jest to z powtórnym użyciem w wielkiej skali. Egzemplarze systemów różnią się w szczegółach jednak można wielokrotnie użyć wspólnej struktury architektonicznej do budowania nowych systemów. 35

36 Klasyfikacja dziedzinowych modeli architektonicznych (1) Modele ogólne (ang. generic models) abstrakcje grupy rzeczywistych systemów definiujące ich bazową charakterystykę. Systemy gromadzenia danych, systemy monitorowania, systemy płacowe, systemy rezerwacji, systemy e-commerce (B2B, B2C), procesory tekstu, systemy czasu rzeczywistego, kompilatory, interpretery, itd. Powstają na podstawie analizy istniejących systemów w danej dziedzinie. 36

37 Model architektury kompilatora Analizator leksykalny Analizator składniowy Analizator semantyczny Upiększacz kodu Drzewo składni abstrakcyjnej Definicje gramatyki Optymalizator Edytor Tabela symboli Definicje kodu wynikowego Generator kodu Repozytorium 37

38 Model przepływu danych kompilatora Tabela symboli Drzewo składni Analiza leksykalna Analiza składniowa Analiza semantyczna Generacja kodu 38

39 Klasyfikacja dziedzinowych modeli architektonicznych (2) Modele odniesienia (ang. reference models) jeszcze bardziej abstrakcyjne obejmujące większe klasy systemów. Powstają na skutek analizy dziedziny. Reprezentują wyidealizowaną architekturę (co mogłoby być). Pełnią rolę standardu - mogą być traktowane jako model implementacji, a częściej wykorzystywane są jako środek do porównywania różnych systemów. 39

40 Model odniesienia ISO/OSI 7 Aplikacja Aplikacja 6 Prezentacja Prezentacja 5 Sesja Sesja 4 Transport Transport 3 Sieć Sieć Sieć 2 Łącze danych Łącze danych Łącze danych 1 Fizyczna Fizyczna Fizyczna Medium komunikacyjne 40

41 Model odniesienia dla narzędzi CASE (ECMA) Sloty na narzędzia Usługi zarządzania obiektami Usługi zarządzania zadaniami Usługi interfejsu użytkownika Usługi komunikacyjne 41

42 Trójwarstwowa architektura ANSI/SPARC dla baz danych Perspektywa 1 Perspektywa 2... Perspektywa n Poziom zewnętrzny Poziom pojęciowy Poziom fizyczny 42

43 Architektura w szerszym kontekście czyli jak to wszystko postrzega przemysł Z punktu widzenia przemysłu IT istnieją 4 typy architektury: Architektura biznesowa (ang. Business process architecture) Architektura technologii informatycznej (ang. Information technology (IT) architecture) Architektura informacyjna (ang. Information architecture) Architektura oprogramowania (ang. Application (software) architecture) Wszystkie razem określane są terminem Architektury systemów informatycznych przedsiębiorstwa (ang. Enterprise Architecture). 43

44 Architektura biznesowa Architektura biznesowa Definiuje strategię biznesową, model zarządzania i organizacji oraz kluczowe procesy biznesowe w przedsiębiorstwie 44

45 Architektura technologii informatycznej (IT) Architektura technologii informatycznej Definiuje elementy sprzętu i oprogramowania tworzące system informatyczny organizacji. Architektura biznesowa jest mapowana na architekturę IT. Powinna umożliwiać osiąganie celów biznesowych poprzez dobrze zdefiniowaną infrastrukturę, pozwalającą na rozwój i wdrażanie krytycznych aplikacji biznesowych Podstawa na której budowane są aplikacje (sprzęt, bazy danych, middleware) 45

46 Architektura informacyjna (danych) Architektura informacyjna Definiuje logiczne i fizyczne dane oraz zasoby służące zarządzaniu tymi danymi. Informacja jest dzisiaj najbardziej cennym aktywem organizacji od odpowiedniej architektury zarządzania informacją zależy istnienie organizacji 46

47 Architektura oprogramowania Architektura oprogramowania Jest wspólnym projektem poszczególnych aplikacji działających w przedsiębiorstwie, interakcji pomiędzy nimi oraz powiązań z procesami biznesowymi. Zazwyczaj zbudowana na czubku technologii IT, wykorzystuje jej zasoby. Nie ma wyraźnej granicy rozdzielającej elementy należące do architektury oprogramowania, IT czy danych. 47

48 Na koniec... Architecture is easy: you just stare at the paper until droplets of blood appear on your forehead. Unknown author 48

49 Do poczytania Sommerville I.: Inżynieria Oprogramowania, rozdział 10. Więcej nt. Architektury oprogramowania Kazman R., Klein M., Clements P.: Architektura oprogramowania. Metody oceny oraz analiza, Helion,

50 Bibliografia dla zainteresowanych M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, R. Stafford, Patterns of Enterprise Application Architecture, Addison-Wesley,