Inżynieria Programowania - Projektowanie architektoniczne

Podobne dokumenty
Inżynieria oprogramowania

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Inżynieria Programowania - Projektowanie architektoniczne. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Wykład 1 Inżynieria Oprogramowania

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Struktura systemu operacyjnego. Opracował: mgr Marek Kwiatkowski

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Wykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014

problem w określonym kontekście siły istotę jego rozwiązania

Zasady organizacji projektów informatycznych

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Wykład I. Wprowadzenie do baz danych

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Opis Architektury Systemu Galileo

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Modelowanie i Programowanie Obiektowe

Historia modeli programowania

Programowanie współbieżne i rozproszone

Etapy życia oprogramowania

Wybrane działy Informatyki Stosowanej

Grupy pytań na egzamin inżynierski na kierunku Informatyka

PROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Wykład Ćwiczenia Laboratorium Projekt Seminarium

XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery

Wzorce Strukturalne. Adapter: opis. Tomasz Borzyszkowski

DLA SEKTORA INFORMATYCZNEGO W POLSCE

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Teraz bajty. Informatyka dla szkół ponadpodstawowych. Zakres rozszerzony. Część 1.

Emulator sterowników PLC serii FX

SYSTEMY OPERACYJNE: STRUKTURY I FUNKCJE (opracowano na podstawie skryptu PP: Królikowski Z., Sajkowski M. 1992: Użytkowanie systemu operacyjnego UNIX)

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Dobór systemów klasy ERP

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

SYSTEMY OPERACYJNE. kik.pcz.czest.pl/so. (C) KIK PCz Materiały pomocnicze 1 PROWADZI: PODSTAWOWA LITERATURA: ZAJĘCIA: STRONA

Wprowadzenie do kompilatorów

PROGRAM PRAKTYKI ZAWODOWEJ. Technikum Zawód: technik informatyk

Projektowanie logiki aplikacji

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Kurs programowania. Wstęp - wykład 0. Wojciech Macyna. 22 lutego 2016

Modelowanie i analiza systemów informatycznych

Inżynieria Programowania Zarządzanie projektem

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

Większe możliwości dzięki LabVIEW 2009: programowanie równoległe, technologie bezprzewodowe i funkcje matematyczne w systemach czasu rzeczywistego

Podstawy Programowania Obiektowego

Przedsięwzięcia Informatyczne w Zarządzaniu

Czujniki obiektowe Sterowniki przemysłowe

Inżynieria Programowania Inżynieria wymagań

Bazy danych 2. Wykład 1

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

Zagadnienia egzaminacyjne INFORMATYKA. Stacjonarne. I-go stopnia. (INT) Inżynieria internetowa STOPIEŃ STUDIÓW TYP STUDIÓW SPECJALNOŚĆ

SZKOLENIE: Administrator baz danych. Cel szkolenia

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

InPro SIEMENS AX wsparcie dla Systemów Telewizji Przemysłowej

Programowanie Układów Logicznych kod kursu: ETD6203. Szczegóły realizacji projektu indywidualnego W dr inż.

Technologie informacyjne - wykład 12 -

UML w Visual Studio. Michał Ciećwierz

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Mechatronika i inteligentne systemy produkcyjne. Modelowanie systemów mechatronicznych Platformy przetwarzania danych

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Programowanie zespołowe

Informatyka Studia II stopnia

Mateusz Kurleto NEOTERIC. Analiza projektu B2B Kielce, 18 października 2012

Numeron. System ienergia

LEKCJA TEMAT: Zasada działania komputera.

Wstęp do Informatyki. Klasyfikacja oprogramowania

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

InPro BMS InPro BMS SIEMENS

Świat rzeczywisty i jego model

Inżynieria Programowania Testowanie oprogramowania. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki.

HP Service Anywhere Uproszczenie zarządzania usługami IT

TWÓJ BIZNES. Nasz Obieg Dokumentów

INFORMATYKA PLAN STUDIÓW NIESTACJONARNYCH. Podstawy programowania Systemy operacyjne

Referat pracy dyplomowej

Wprowadzenie. Dariusz Wawrzyniak 1

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Faza analizy (modelowania) Faza projektowania

5. Model komunikujących się procesów, komunikaty

KOŁO NAUKOWE INFORMATYKÓW SYSTEMY KONTROLI WERSJI CZ.1 16 XII 2009 OPRACOWAŁ: PRZEMYSŁAW PARDEL

Sterowniki Programowalne (SP)

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC

Programowanie obiektowe

Metody Kompilacji Wykład 1 Wstęp

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Transkrypt:

Inżynieria Programowania - Projektowanie architektoniczne Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 22 października 2016

1 2 3 4 5 Architektury charakterystyczne dla różnych dziedzin

1 2 3 4 5 Architektury charakterystyczne dla różnych dziedzin

1 2 3 4 5 Architektury charakterystyczne dla różnych dziedzin

1 2 3 4 5 Architektury charakterystyczne dla różnych dziedzin

1 2 3 4 5 Architektury charakterystyczne dla różnych dziedzin

Motto Lekarz może pogrzebać swoje pomyłki, ale architekt może tylko doradzić klientowi by posadził winnice. Frank Lloyd Wright

Projektowanie architektoniczne jest wstępną fazą projektowania, w której wyróżnia się podsystemy, ustala schemat sterowania i sposób komunikacji podsystemów.

Zalety Jawne projektowanie i dokumentowanie architektury oprogramowania posiada następujące zalety: 1 Komunikacja z uczestnikami - architektura opisuje cechy wysokopoziomowe projektu i dlatego może służyć jako punkt wyjścia do dyskusji z różnymi uczestnikami systemu. 2 Analiza systemu - opracowanie we wstępnej fazie architektury projektu umożliwia wstępną analizę systemu i określenie, czy jego zakładana struktura pozwala na spełnienie stawianych przed nim wymagań niefunkcjonalnych. 3 Wielokrotne użycie w szerokiej skali - opis architektoniczny jest ze względu na swą wysokopoziomowość dosyć uniwersalny i może służyć jako podstawa do budowy systemów o podobnych założeniach.

Zalety Jawne projektowanie i dokumentowanie architektury oprogramowania posiada następujące zalety: 1 Komunikacja z uczestnikami - architektura opisuje cechy wysokopoziomowe projektu i dlatego może służyć jako punkt wyjścia do dyskusji z różnymi uczestnikami systemu. 2 Analiza systemu - opracowanie we wstępnej fazie architektury projektu umożliwia wstępną analizę systemu i określenie, czy jego zakładana struktura pozwala na spełnienie stawianych przed nim wymagań niefunkcjonalnych. 3 Wielokrotne użycie w szerokiej skali - opis architektoniczny jest ze względu na swą wysokopoziomowość dosyć uniwersalny i może służyć jako podstawa do budowy systemów o podobnych założeniach.

Zalety Jawne projektowanie i dokumentowanie architektury oprogramowania posiada następujące zalety: 1 Komunikacja z uczestnikami - architektura opisuje cechy wysokopoziomowe projektu i dlatego może służyć jako punkt wyjścia do dyskusji z różnymi uczestnikami systemu. 2 Analiza systemu - opracowanie we wstępnej fazie architektury projektu umożliwia wstępną analizę systemu i określenie, czy jego zakładana struktura pozwala na spełnienie stawianych przed nim wymagań niefunkcjonalnych. 3 Wielokrotne użycie w szerokiej skali - opis architektoniczny jest ze względu na swą wysokopoziomowość dosyć uniwersalny i może służyć jako podstawa do budowy systemów o podobnych założeniach.

Proces projektowania architektonicznego W procesie projektowania architektonicznego wyróżniamy trzy podstawowe czynności: 1 - system dzieli się nad podsystemy i określa się sposób komunikacji między nimi. 2 Modelowanie sterowania - określa się ogólny model związków sterowania między częściami systemu. 3 Podział na moduły - każdy podsystem dzielony jest na moduły.

Proces projektowania architektonicznego W procesie projektowania architektonicznego wyróżniamy trzy podstawowe czynności: 1 - system dzieli się nad podsystemy i określa się sposób komunikacji między nimi. 2 Modelowanie sterowania - określa się ogólny model związków sterowania między częściami systemu. 3 Podział na moduły - każdy podsystem dzielony jest na moduły.

Proces projektowania architektonicznego W procesie projektowania architektonicznego wyróżniamy trzy podstawowe czynności: 1 - system dzieli się nad podsystemy i określa się sposób komunikacji między nimi. 2 Modelowanie sterowania - określa się ogólny model związków sterowania między częściami systemu. 3 Podział na moduły - każdy podsystem dzielony jest na moduły.

Podsystemy i moduły Podsystem Podsystem jest częścią systemu, której usługi nie zależą od innych usług, oferowanych przez inne podsystemy. Podsystemy składają się z modułów i mają określony interfejs służący do komunikowania się z innymi podsystemami. Pojedynczy podsystem może być rozpatrywany jako samodzielny system. Moduł Moduł jest komponentem systemu, oferującym co najmniej jedną usługę. Korzysta on z usług innego modułu i zazwyczaj nie może być rozpatrywany jako niezależny system. Pojedynczy moduł zwykle składa się z innych modułów.

Dokumentacja architektury systemu Dokumentacja architektury systemu może składać się z następujących graficznych przedstawień modeli: 1 Statyczny model strukturalny obejmuje komponenty lub podsystemy, które można zbudować jako niezależne jednostki. 2 Model dynamiczny procesu, w którym przedstawia się podział systemu na procesy czasu wykonania. 3 Model interfejsów, w którym definiuje się usługi oferowane przez każdy podsystem za pośrednictwem jego interfejsu publicznego. 4 Model związków, który obejmuje związki, takie jak przepływ danych między podsystemami.

Dokumentacja architektury systemu Dokumentacja architektury systemu może składać się z następujących graficznych przedstawień modeli: 1 Statyczny model strukturalny obejmuje komponenty lub podsystemy, które można zbudować jako niezależne jednostki. 2 Model dynamiczny procesu, w którym przedstawia się podział systemu na procesy czasu wykonania. 3 Model interfejsów, w którym definiuje się usługi oferowane przez każdy podsystem za pośrednictwem jego interfejsu publicznego. 4 Model związków, który obejmuje związki, takie jak przepływ danych między podsystemami.

Dokumentacja architektury systemu Dokumentacja architektury systemu może składać się z następujących graficznych przedstawień modeli: 1 Statyczny model strukturalny obejmuje komponenty lub podsystemy, które można zbudować jako niezależne jednostki. 2 Model dynamiczny procesu, w którym przedstawia się podział systemu na procesy czasu wykonania. 3 Model interfejsów, w którym definiuje się usługi oferowane przez każdy podsystem za pośrednictwem jego interfejsu publicznego. 4 Model związków, który obejmuje związki, takie jak przepływ danych między podsystemami.

Dokumentacja architektury systemu Dokumentacja architektury systemu może składać się z następujących graficznych przedstawień modeli: 1 Statyczny model strukturalny obejmuje komponenty lub podsystemy, które można zbudować jako niezależne jednostki. 2 Model dynamiczny procesu, w którym przedstawia się podział systemu na procesy czasu wykonania. 3 Model interfejsów, w którym definiuje się usługi oferowane przez każdy podsystem za pośrednictwem jego interfejsu publicznego. 4 Model związków, który obejmuje związki, takie jak przepływ danych między podsystemami.

Zależności Od architektury systemu mogą zależeć następujące wymagania niefunkcjonalne: 1 Efektywność - najczęściej podnosi się poprzez zastosowanie do wykonywania krytycznych operacji niewielkiej liczby komponentów gruboziarnistych, które rzadko się komunikują. 2 Bezpieczeństwo (poufność) - zazwyczaj osiąga się poprzez zastosowanie struktury warstwowej. Najbardziej krytyczne elementy umieszcza się w warstwach wewnętrznych, gdzie należy uwzględnić wysoki poziom weryfikacji. 3 Bezpieczeństwo (niezawodność) operacje dotyczące bezpieczeństwa należy zamknąć w jednym podsystemie lub w niewielkiej liczbie podsystemów. 4 Dostępność - stosuje się komponenty redundantne. 5 Konserwacja - stosuje się dużą liczbę drobnoziarnistych, samodzielnych komponentów, które łatwo zmieniać.

Zależności Od architektury systemu mogą zależeć następujące wymagania niefunkcjonalne: 1 Efektywność - najczęściej podnosi się poprzez zastosowanie do wykonywania krytycznych operacji niewielkiej liczby komponentów gruboziarnistych, które rzadko się komunikują. 2 Bezpieczeństwo (poufność) - zazwyczaj osiąga się poprzez zastosowanie struktury warstwowej. Najbardziej krytyczne elementy umieszcza się w warstwach wewnętrznych, gdzie należy uwzględnić wysoki poziom weryfikacji. 3 Bezpieczeństwo (niezawodność) operacje dotyczące bezpieczeństwa należy zamknąć w jednym podsystemie lub w niewielkiej liczbie podsystemów. 4 Dostępność - stosuje się komponenty redundantne. 5 Konserwacja - stosuje się dużą liczbę drobnoziarnistych, samodzielnych komponentów, które łatwo zmieniać.

Zależności Od architektury systemu mogą zależeć następujące wymagania niefunkcjonalne: 1 Efektywność - najczęściej podnosi się poprzez zastosowanie do wykonywania krytycznych operacji niewielkiej liczby komponentów gruboziarnistych, które rzadko się komunikują. 2 Bezpieczeństwo (poufność) - zazwyczaj osiąga się poprzez zastosowanie struktury warstwowej. Najbardziej krytyczne elementy umieszcza się w warstwach wewnętrznych, gdzie należy uwzględnić wysoki poziom weryfikacji. 3 Bezpieczeństwo (niezawodność) operacje dotyczące bezpieczeństwa należy zamknąć w jednym podsystemie lub w niewielkiej liczbie podsystemów. 4 Dostępność - stosuje się komponenty redundantne. 5 Konserwacja - stosuje się dużą liczbę drobnoziarnistych, samodzielnych komponentów, które łatwo zmieniać.

Zależności Od architektury systemu mogą zależeć następujące wymagania niefunkcjonalne: 1 Efektywność - najczęściej podnosi się poprzez zastosowanie do wykonywania krytycznych operacji niewielkiej liczby komponentów gruboziarnistych, które rzadko się komunikują. 2 Bezpieczeństwo (poufność) - zazwyczaj osiąga się poprzez zastosowanie struktury warstwowej. Najbardziej krytyczne elementy umieszcza się w warstwach wewnętrznych, gdzie należy uwzględnić wysoki poziom weryfikacji. 3 Bezpieczeństwo (niezawodność) operacje dotyczące bezpieczeństwa należy zamknąć w jednym podsystemie lub w niewielkiej liczbie podsystemów. 4 Dostępność - stosuje się komponenty redundantne. 5 Konserwacja - stosuje się dużą liczbę drobnoziarnistych, samodzielnych komponentów, które łatwo zmieniać.

Zależności Od architektury systemu mogą zależeć następujące wymagania niefunkcjonalne: 1 Efektywność - najczęściej podnosi się poprzez zastosowanie do wykonywania krytycznych operacji niewielkiej liczby komponentów gruboziarnistych, które rzadko się komunikują. 2 Bezpieczeństwo (poufność) - zazwyczaj osiąga się poprzez zastosowanie struktury warstwowej. Najbardziej krytyczne elementy umieszcza się w warstwach wewnętrznych, gdzie należy uwzględnić wysoki poziom weryfikacji. 3 Bezpieczeństwo (niezawodność) operacje dotyczące bezpieczeństwa należy zamknąć w jednym podsystemie lub w niewielkiej liczbie podsystemów. 4 Dostępność - stosuje się komponenty redundantne. 5 Konserwacja - stosuje się dużą liczbę drobnoziarnistych, samodzielnych komponentów, które łatwo zmieniać.

Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Przykład diagramu blokowego - system sterowania robotem System wizyjny System identyfikacji przedmiotów Sterownik alarmu Sterownik chwytacza System wyboru opakowania System pakujący Sterownik taśmociągu

Model repozytorium Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Większość systemów użytkujących duże ilości danych jest zbudowana wokół centralnej bazy danych. Taki model architektury nazywamy modelem repozytorium. Jest on przystosowany do systemów, w których dane są generowane przez jeden podsystem, a użytkowane przez inny.

Model repozytorium - przykład Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Edytor projektów Generator kodu Translator projektów Repozytorium przedsięwzięcia Edytor programów Analizator projektów Generator raportów

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Efektywny sposób współdzielenia dużych ilości danych. - Konieczny jest wspólny model danych repozytorium, który należy narzucić wszystkim podsystemom. + Podsystemy produkujące dane nie muszą zajmować się sposobem użycia tych danych przez inne podsystemy. - Ewolucja systemu może być trudna ze względu na narzucony model danych. + Scentralizowanie czynności związanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp. - Model repozytorium wymusza te same strategie dotyczące zabezpieczeń, sporządzania kopii zapasowych, itp. + Model współdzielenia jest widoczny przez repozytorium, więc integracja nowych narzędzi jest prosta, o ile obsługują ustalony model danych. - Wykonanie rozproszonej wersji repozytorium może być trudne.

Model klient-serwer Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Główne komponenty modelu klient-serwer: zbiór samodzielnych serwerów oferujących usługi innym podsystemom. zbiór klientów korzystających z usług oferowanych przez serwery. sieć, która służy do komunikacji między serwerami, a klientami; nie zawsze jest konieczna.

Model klient-serwer Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Główne komponenty modelu klient-serwer: zbiór samodzielnych serwerów oferujących usługi innym podsystemom. zbiór klientów korzystających z usług oferowanych przez serwery. sieć, która służy do komunikacji między serwerami, a klientami; nie zawsze jest konieczna.

Model klient-serwer Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Główne komponenty modelu klient-serwer: zbiór samodzielnych serwerów oferujących usługi innym podsystemom. zbiór klientów korzystających z usług oferowanych przez serwery. sieć, która służy do komunikacji między serwerami, a klientami; nie zawsze jest konieczna.

Model klient-serwer - przykład Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Klient 1 Klient 2 Klient 3 Klient 4 Sieć szerokopasmowa Serwer katalogu Serwer filmów Serwer zdjęć Serwer hipertekstu Katalog Pliki z filmami Zdjęcia w postaci cyfrowej Sieć hipertekstowa

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Model klient-serwer jest architekturą rozproszoną. - Brak wspólnego modelu danych.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Model klient-serwer jest architekturą rozproszoną. - Brak wspólnego modelu danych.

Model maszyny abstrakcyjnej Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Model maszyny abstrakcyjnej (model warstwowy) opisuje sprzęganie podsystemów. System jest ułożony w stos warstw, z których każda oferuje pewne usługi. Każda warstwa jest maszyną wirtualną (abstrakcyjną), której język maszynowy (usługi oferowane przez warstwę) służy do implementacji następnego poziomu maszyny abstrakcyjnej.

Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej Model maszyny abstrakcyjnej - przykład Zarządzanie wersjami Zarządzanie obiektami System bazy danych System operacyjny

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Model warstwowy ułatwia przyrostowe tworzenie oprogramowania. + Architektura warstwowa jest łatwa do przenoszenia i modyfikowania. - Podejście warstwowe jest trudne w zastosowaniu. - Systemy oparte na czystym modelu warstwowym mogą być niewydajne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Model warstwowy ułatwia przyrostowe tworzenie oprogramowania. + Architektura warstwowa jest łatwa do przenoszenia i modyfikowania. - Podejście warstwowe jest trudne w zastosowaniu. - Systemy oparte na czystym modelu warstwowym mogą być niewydajne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Model warstwowy ułatwia przyrostowe tworzenie oprogramowania. + Architektura warstwowa jest łatwa do przenoszenia i modyfikowania. - Podejście warstwowe jest trudne w zastosowaniu. - Systemy oparte na czystym modelu warstwowym mogą być niewydajne.

Wady i zalety Model repozytorium Model klient-serwer Model maszyny abstrakcyjnej + Model warstwowy ułatwia przyrostowe tworzenie oprogramowania. + Architektura warstwowa jest łatwa do przenoszenia i modyfikowania. - Podejście warstwowe jest trudne w zastosowaniu. - Systemy oparte na czystym modelu warstwowym mogą być niewydajne.

Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Aby podsystemy pracowały jako jeden system, należy nimi sterować tak, żeby ich usługi były dostarczane we właściwe miejsce i we właściwym czasie. Wyróżnia się dwa podejścia do sterowania: 1 Sterowanie scentralizowane - za sterowanie odpowiada całkowicie jeden z podsystemów. 2 Sterowanie zdarzeniami - informacja o sterowaniu nie jest wbudowana w system, każdy z podsystemów może reagować na zdarzenia pochodzące z zewnątrz.

Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Aby podsystemy pracowały jako jeden system, należy nimi sterować tak, żeby ich usługi były dostarczane we właściwe miejsce i we właściwym czasie. Wyróżnia się dwa podejścia do sterowania: 1 Sterowanie scentralizowane - za sterowanie odpowiada całkowicie jeden z podsystemów. 2 Sterowanie zdarzeniami - informacja o sterowaniu nie jest wbudowana w system, każdy z podsystemów może reagować na zdarzenia pochodzące z zewnątrz.

Sterowanie scentralizowane Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Rozróżniamy dwie klasy systemów sterowania scentralizowanego, w zależności od tego czy podsystemy działają współbieżnie, czy sekwencyjnie: 1 Model wywołanie-powrót - stosowany jedynie w przypadku systemów sekwencyjnych. 2 Model menedżera - można stosować w przypadku systemów współbieżnych. Jeden z komponentów jest wybierany do roli menadżera, systemu, który zarządza innymi procesami. Inaczej nazywany modelem pętli zdarzeń.

Sterowanie scentralizowane Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Rozróżniamy dwie klasy systemów sterowania scentralizowanego, w zależności od tego czy podsystemy działają współbieżnie, czy sekwencyjnie: 1 Model wywołanie-powrót - stosowany jedynie w przypadku systemów sekwencyjnych. 2 Model menedżera - można stosować w przypadku systemów współbieżnych. Jeden z komponentów jest wybierany do roli menadżera, systemu, który zarządza innymi procesami. Inaczej nazywany modelem pętli zdarzeń.

Model sterowania wywołanie-powrót Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Program główny Procedura 1 Procedura 2 Procedura 3 Procedura 1.1 Procedura 1.2 Procedura 3.1 Procedura 3.2

Wady i zalety Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami + Łatwa analiza przepływu sterowania i deterministyczne działanie systemu. - Utrudniona obsługa wyjątków.

Wady i zalety Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami + Łatwa analiza przepływu sterowania i deterministyczne działanie systemu. - Utrudniona obsługa wyjątków.

Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Scentralizowane sterowanie z menedżerem - przykład Procesy detektorów Procesy efektorów Sterownik systemu Procesy obliczeniowe Interfejs użytkownika Obsługa awarii

Sterowanie zdarzeniami Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Dwa podstawowe modele sterowania zdarzeniami to: 1 Model rozgłaszania - zdarzenie jest ogłoszeniem dla wszystkich podsystemów. 2 Model z przerwaniami - zewnętrzne przerwania są wykrywane przez obsługę przerwań i przekazywane do odpowiedniego komponentu, gdzie są przetwarzane.

Sterowanie zdarzeniami Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Dwa podstawowe modele sterowania zdarzeniami to: 1 Model rozgłaszania - zdarzenie jest ogłoszeniem dla wszystkich podsystemów. 2 Model z przerwaniami - zewnętrzne przerwania są wykrywane przez obsługę przerwań i przekazywane do odpowiedniego komponentu, gdzie są przetwarzane.

Model rozgłaszania Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami Podsystem 1 Podsystem 2 Podsystem 3 Podsystem 4 Procedura obsługi zdarzeń

Wady i zalety Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami + Prostota ewolucji. - Brak informacji zwrotnej, co do tego, czy zdarzenie zostało obsłużone.

Wady i zalety Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami + Prostota ewolucji. - Brak informacji zwrotnej, co do tego, czy zdarzenie zostało obsłużone.

Model sterowania z przerwaniami Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami 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

Wady i zalety Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami + Szybkie odpowiedzi na zdarzenia. - Złożoność programowania i trudności z zatwierdzeniem.

Wady i zalety Sterowanie scentralizowane Model sterowania z menedżerem Sterowanie zdarzeniami + Szybkie odpowiedzi na zdarzenia. - Złożoność programowania i trudności z zatwierdzeniem.

dotyczy podsystemów. Można tego dokonać w oparciu między innymi o następujące modele: 1 Model obiektowy - system jest dzielony na zbiór komunikujących się obiektów. 2 Model przepływu danych - system jest dzielony na moduły funkcjonalne, które pobierają dane wejściowe i przetwarzają je na dane wyjściowe. Model ten nosi również nazwę modelu potokowego.

dotyczy podsystemów. Można tego dokonać w oparciu między innymi o następujące modele: 1 Model obiektowy - system jest dzielony na zbiór komunikujących się obiektów. 2 Model przepływu danych - system jest dzielony na moduły funkcjonalne, które pobierają dane wejściowe i przetwarzają je na dane wyjściowe. Model ten nosi również nazwę modelu potokowego.

Model obiektowy - przykład Klient Pokwitowanie nr klienta nazwisko adres okres kredytowania nr faktury data kwota nr klienta Faktura nr faktury data kwota nr klienta Płatność wystaw() wyślijupomnienie() przyjmijpłatność() wyślijpokwitowanie() nr faktury data kwota nr klienta

Wady i zalety + Obiekty są luźno od siebie uzależnione, więc można zmieniać ich implementacje nie wpływając na pozostałe obiekty. + Obiekty są często reprezentantami bytów świata rzeczywistego, co ułatwia zrozumienie systemu. + Opracowano języki programowania, które umożliwiają bezpośrednią implementację komponentów obiektowych. + Model obiektowy może być zastosowany zarówno w systemach współbieżnych, jak i sekwencyjnych. - Konieczność jawnego używania nazw i interfejsów obiektów, które dostarczają usług. - Trudno ocenić wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty. - Trudno reprezentować w postaci obiektów złożone byty.

Wady i zalety + Obiekty są luźno od siebie uzależnione, więc można zmieniać ich implementacje nie wpływając na pozostałe obiekty. + Obiekty są często reprezentantami bytów świata rzeczywistego, co ułatwia zrozumienie systemu. + Opracowano języki programowania, które umożliwiają bezpośrednią implementację komponentów obiektowych. + Model obiektowy może być zastosowany zarówno w systemach współbieżnych, jak i sekwencyjnych. - Konieczność jawnego używania nazw i interfejsów obiektów, które dostarczają usług. - Trudno ocenić wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty. - Trudno reprezentować w postaci obiektów złożone byty.

Wady i zalety + Obiekty są luźno od siebie uzależnione, więc można zmieniać ich implementacje nie wpływając na pozostałe obiekty. + Obiekty są często reprezentantami bytów świata rzeczywistego, co ułatwia zrozumienie systemu. + Opracowano języki programowania, które umożliwiają bezpośrednią implementację komponentów obiektowych. + Model obiektowy może być zastosowany zarówno w systemach współbieżnych, jak i sekwencyjnych. - Konieczność jawnego używania nazw i interfejsów obiektów, które dostarczają usług. - Trudno ocenić wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty. - Trudno reprezentować w postaci obiektów złożone byty.

Wady i zalety + Obiekty są luźno od siebie uzależnione, więc można zmieniać ich implementacje nie wpływając na pozostałe obiekty. + Obiekty są często reprezentantami bytów świata rzeczywistego, co ułatwia zrozumienie systemu. + Opracowano języki programowania, które umożliwiają bezpośrednią implementację komponentów obiektowych. + Model obiektowy może być zastosowany zarówno w systemach współbieżnych, jak i sekwencyjnych. - Konieczność jawnego używania nazw i interfejsów obiektów, które dostarczają usług. - Trudno ocenić wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty. - Trudno reprezentować w postaci obiektów złożone byty.

Wady i zalety + Obiekty są luźno od siebie uzależnione, więc można zmieniać ich implementacje nie wpływając na pozostałe obiekty. + Obiekty są często reprezentantami bytów świata rzeczywistego, co ułatwia zrozumienie systemu. + Opracowano języki programowania, które umożliwiają bezpośrednią implementację komponentów obiektowych. + Model obiektowy może być zastosowany zarówno w systemach współbieżnych, jak i sekwencyjnych. - Konieczność jawnego używania nazw i interfejsów obiektów, które dostarczają usług. - Trudno ocenić wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty. - Trudno reprezentować w postaci obiektów złożone byty.

Wady i zalety + Obiekty są luźno od siebie uzależnione, więc można zmieniać ich implementacje nie wpływając na pozostałe obiekty. + Obiekty są często reprezentantami bytów świata rzeczywistego, co ułatwia zrozumienie systemu. + Opracowano języki programowania, które umożliwiają bezpośrednią implementację komponentów obiektowych. + Model obiektowy może być zastosowany zarówno w systemach współbieżnych, jak i sekwencyjnych. - Konieczność jawnego używania nazw i interfejsów obiektów, które dostarczają usług. - Trudno ocenić wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty. - Trudno reprezentować w postaci obiektów złożone byty.

Wady i zalety + Obiekty są luźno od siebie uzależnione, więc można zmieniać ich implementacje nie wpływając na pozostałe obiekty. + Obiekty są często reprezentantami bytów świata rzeczywistego, co ułatwia zrozumienie systemu. + Opracowano języki programowania, które umożliwiają bezpośrednią implementację komponentów obiektowych. + Model obiektowy może być zastosowany zarówno w systemach współbieżnych, jak i sekwencyjnych. - Konieczność jawnego używania nazw i interfejsów obiektów, które dostarczają usług. - Trudno ocenić wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty. - Trudno reprezentować w postaci obiektów złożone byty.

Model przepływu danych - przykład Wystaw fakturę Pokwitowania Odczytaj wystawione faktury Zidentyfikuj płatności Faktury Płatności Znajdź przeterminowane faktury Wystaw upomnienia Upomnienia

Wady i zalety + Architektura potokowa umożliwia wielokrotne użycie przekształceń. + Jest intuicyjna dla wielu ludzi. + Ewolucja systemu polega na dodaniu nowych przekształceń i jest bardzo łatwa. + Jest łatwa do zaimplementowania zarówno w systemach sekwencyjnych, jak i współbieżnych. - Konieczne jest wprowadzenie wspólnego formatu danych zrozumiałego dla wszystkich przekształceń. - Nie nadaje się do systemów interaktywnych.

Wady i zalety + Architektura potokowa umożliwia wielokrotne użycie przekształceń. + Jest intuicyjna dla wielu ludzi. + Ewolucja systemu polega na dodaniu nowych przekształceń i jest bardzo łatwa. + Jest łatwa do zaimplementowania zarówno w systemach sekwencyjnych, jak i współbieżnych. - Konieczne jest wprowadzenie wspólnego formatu danych zrozumiałego dla wszystkich przekształceń. - Nie nadaje się do systemów interaktywnych.

Wady i zalety + Architektura potokowa umożliwia wielokrotne użycie przekształceń. + Jest intuicyjna dla wielu ludzi. + Ewolucja systemu polega na dodaniu nowych przekształceń i jest bardzo łatwa. + Jest łatwa do zaimplementowania zarówno w systemach sekwencyjnych, jak i współbieżnych. - Konieczne jest wprowadzenie wspólnego formatu danych zrozumiałego dla wszystkich przekształceń. - Nie nadaje się do systemów interaktywnych.

Wady i zalety + Architektura potokowa umożliwia wielokrotne użycie przekształceń. + Jest intuicyjna dla wielu ludzi. + Ewolucja systemu polega na dodaniu nowych przekształceń i jest bardzo łatwa. + Jest łatwa do zaimplementowania zarówno w systemach sekwencyjnych, jak i współbieżnych. - Konieczne jest wprowadzenie wspólnego formatu danych zrozumiałego dla wszystkich przekształceń. - Nie nadaje się do systemów interaktywnych.

Wady i zalety + Architektura potokowa umożliwia wielokrotne użycie przekształceń. + Jest intuicyjna dla wielu ludzi. + Ewolucja systemu polega na dodaniu nowych przekształceń i jest bardzo łatwa. + Jest łatwa do zaimplementowania zarówno w systemach sekwencyjnych, jak i współbieżnych. - Konieczne jest wprowadzenie wspólnego formatu danych zrozumiałego dla wszystkich przekształceń. - Nie nadaje się do systemów interaktywnych.

Wady i zalety + Architektura potokowa umożliwia wielokrotne użycie przekształceń. + Jest intuicyjna dla wielu ludzi. + Ewolucja systemu polega na dodaniu nowych przekształceń i jest bardzo łatwa. + Jest łatwa do zaimplementowania zarówno w systemach sekwencyjnych, jak i współbieżnych. - Konieczne jest wprowadzenie wspólnego formatu danych zrozumiałego dla wszystkich przekształceń. - Nie nadaje się do systemów interaktywnych.

Architektury charakterystyczne dla różnych dziedzin Istnieją architektury wspólne dla pewnych konkretnych dziedzin zastosowań. Ich egzemplarze różnią się w szczegółach, ale można używać wielokrotnie wspólnej struktury architektonicznej do budowy nowych systemów. Te architektury można podzielić na: 1 Modele ogólne - budowane metodą wstępującą, obejmują zasadnicze charakterystyki rzeczywistych systemów. 2 Modele odniesienia - budowane metodą zstępującą, są jeszcze bardziej abstrakcyjne niż modele ogólne. Są sposobem informowania projektantów o ogólnej strukturze systemów danej klasy.

Architektury charakterystyczne dla różnych dziedzin Istnieją architektury wspólne dla pewnych konkretnych dziedzin zastosowań. Ich egzemplarze różnią się w szczegółach, ale można używać wielokrotnie wspólnej struktury architektonicznej do budowy nowych systemów. Te architektury można podzielić na: 1 Modele ogólne - budowane metodą wstępującą, obejmują zasadnicze charakterystyki rzeczywistych systemów. 2 Modele odniesienia - budowane metodą zstępującą, są jeszcze bardziej abstrakcyjne niż modele ogólne. Są sposobem informowania projektantów o ogólnej strukturze systemów danej klasy.

Model ogólny kompilatora - przepływ danych Tabela symboli Analiza leksykalna Analiza składniowa Analiza znaczeniowa Generator kodu

Model ogólny kompilatora - repozytorium Analizator leksykalny Analizator składniowy Analizator znaczeniowy Repozytorium Generator prezentacji Drzewo składni abstrakcyjnej Definicja gramatyki Optymalizator Edytor Tablica symboli Definicja wyjścia Generator kodu

Model odniesienia - przykład 7 Program użytkowy Program użytkowy 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

Pytania?

Koniec Dziękuję Państwu za uwagę.