====== IN-POS 6. Objektové metody návrhu systémů ======
===== Zadání =====
* Návrhové vzory.
* Softwarové architektury.
* Rozhraní komponent, signatury a omezující podmínky služeb, OCL.
* Komponentové systémy a modely, kvalitativní aspekty služeb (QoS).
* Objektové metody vývoje softwaru, RUP.
* PA103
===== Vypracování =====
==== Návrhové vzory ====
Obecné řešení pro opakující se problém, tak aby jej bylo možné aplikovat v různém kontextu.
=== Návrhové vzory dle GoF ===
Podle knihy "Design Patterns: Elements of Reusable Object Oriented Software (1995)" (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides).
* Návrhové vzory
* Popis šablony, kterou lze použít pro řešení problému v různých situacích.
* Popisují úspěšné návrhy a softwarovou architekturu.
* Popisují statickou i dynamickou strukturu a komunikaci mezi objekty.
* Vzor je pouze "meta-model", je potřeba jej instanciovat.
* Jednotlivé vzory jsou pěkně vysvětlené zde: https://refactoring.guru/design-patterns/
3 kategorie:
* **Creational patterns**
* inicializace a konfigurace objektů
* lze skrýt specifika vytváření objektu
* lze oddálit určení přesné třídy při instanciaci
Vytváření skupiny souvisejících objektů.
Postupné vytváření komplexních objektů.
Virtuální konstruktor.
Instanciace objektů přes klonování "prototypu".
Tvorba maximálně jedné instance pro celý systém.
* **Structural patterns**
* řeší dělení rozhraní a implementace
* kompozice objektů
Překlad rozhraní.
Abstrakce pro spojení více implementací.
Tvorba rekurzivní hierarchie objektů.
Transparentní rozšíření objektů.
Zjednodušení a agregace rozhraní komplexního subsystému.
Sdílení mnoha objektů.
Aproximace objektů.
* **Behavioral patterns**
* řeší dynamické interakce mezi třídami/objekty
* dělba zodpovědnosti
Delegování žádosti na zodpovědného poskytovatele.
Realizace žádostí/příkazů.
Interpretr jazyka pro malé gramatiky.
Koordinace komunikace mezi zúčastněnými.
Uchování a obnovení stavu.
Update několika objektů při změně "sledovaného".
Objekty, jejichž chování závisí na stavu.
Abstrakce pro volbu jednoho z více algoritmů.
Algoritmus s několika kroky implementovanými v podtřídě.
Operace aplikované na různorodé struktury objektů.
=== Analytické vzory ===
Existují i vzory využitelné při fázi analýzy. Seznam kategorií od M. Fowlera:
* **Accountability**
* Party
* Organization Hierarchies
* Organization Structure
* Accountability
* Organization Structure
* Accountability Knowledge Level
* Party Type Generalization
* Hierarchic Accountability
* Operating Scopes
* Post
* **Observations and Measurements**
* Quantity
* Conversion Ratio
* Compound Units
* Measurement
* Observation
* Subtyping Observation Concepts
* Protocol
* **Observations for Corporate Finance**
* Enterprise Segment
* Measurement Protocol
* Range
* Phenomenon with Range
* **Referring to Objects**
* Name
* Identification Scheme
* Object Merge
* Object Equivalence
* **Inventory and Accounting**
* **Planning**
* **Trading**
* **Derivative Contracts**
* **Trading Packages**
==== Softwarové architektury ====
* = Zásadní návrhová rozhodnutí.
* = Základní struktura systému složená z komponent, jejich vztahů a principů pro návrh a implementaci.
* Abstrakce na systémové úrovni.
Zásadní prvky:
* **Modul** = část systému implementující nějakou funkcionalitu
* **Konektor** = komunikační kanály a rozhraní mezi moduly
* **Nasazení** = mapování modulů a konektorů na HW/SW zdroje.
Styly a vzory:
* **Návrhový vzor** = Obecné řešení pro problémy při návrhu a implementaci.
* **Architektonický styl** = Sumarizuje architektonické principy ovlivňující kód.
* **Architektonické vzory** = Obecná řešení pro návrh architektury.
* **Doménově specifické SW architektury** = Návrh kompletní struktury aplikace v dané doméně.
=== Architektonické vzory ===
* Rozdělení funkcionality do vrstev dle míry abstrakce.
* Vrstva:
* poskytuje službu vrstvě nad ní
* delegují pod-úkoly na vrstvu pod ní
* Varianty
* **Relaxed Layered System** -- Lze využít všechny nižší vrstvy, ne jen sousední.
* **Layering Through Inheritance** -- Vrstvy se navzájem dědí. (Vrstva dědí vrstvu, od které požaduje funkcionalitu.
* ➕ podpora standardizace => možná výměna vrstev
* ➕ dobře definovaná struktura
* ➖ nižší výkonost kvůli komunikační zátěži
* ➖ duplikace kódu na hranicích vrstev
**Layers (vrstvy)** -- organizace kódu
**Tiers** -- místo nasazení vrstev
Struktura pro procesy nad proudy dat.
* **pipes** (roury) = spojení mezi filtry
* **pasivní filtr** = "vytáhne" data z filtru nebo mu jsou data poslána jiným elementem
* **aktivní filtr** = aktivně vytahuje data z rour a posílá svůj výstup dál
* **data source** = vstup do systému
* **data sink** = výsledky celého procesu
* ➕ netřeba mezilehlých souborů
* ➕ flexibilita výměn filtrů, nebo přeuspořádání komponent
* ➕ možnost znovuvyužití komponent
* ➕ možnost prototypování
* ➕ lze paralelizovat zpracování
* ➖ sdílení stavu je drahé, nebo neefktivní
* ➖ transformace dat do/z formátu rour může být náročné
* ➖ zpráva chyb, výpadků
Více zdrojů se střídavě zapojuje do řešení problému.
{{https://image.slidesharecdn.com/sasession11-140914043516-phpapp01/95/software-architecture-session11-73-638.jpg}}
{{:mgr-szz:in-pos:mvc.png?300|}}
{{:mgr-szz:in-pos:mvp.png?300|}}
{{:mgr-szz:in-pos:mvv.png?300|}}
==== Rozhraní komponent ====
* **Komponenta**
* = Spustitelná jednotka běžící v běhovém prostředí (middleware).
* = Zaměnitelná část systému, která žádá a poskytuje určitou sadu operací.
* Tvořena mnoha objekty/třídami.
* Nepřímá komunikace přes rozhraní (konektory).
* Dobře definovaná komplexní rozhraní.
* black-box/gray-box
* Vyvíjeny nezávisle na ostatních komponentách.
* **Rozhraní (interface)**
* Kolekce operací, která specifikují požadované, nebo poskytované služby komponenty.
* **Port**
* Komunikační bod komponenty specifikovaný rozhraním.
* Spojeny vzájemně konektorem.
==== Komponentové systémy a modely ====
* Komponentové modely
* = komponentové standardy
* definují specifickou reprezentaci, interakci a kompozici SW komponent
* Příklady komerčních řešení:
* CCM/CORBA, EJB/J2EE, Microsoft's COM+/.NET
* Akademické modely:
* Fractal, KobrA, PCM, SOFA, DArwin, Wright, Koala, ACME
* Rozdíly:
* komponenta
* run-time x design-time jednotka
* dynamická x statická jednotka
* stateful x stateless
* rozhraní
* signatury x protokoly
* synchronní x asynchronní
* hierarchie
* flat x hierarchical
* assembling
* simple x multiple
* Komponentové frameworky
* = komponentový middleware
* = běhové prostředí
* Umožňují běh komponent v rámci daného standardu.
* Příklady:
* J2EE: JBoss, Glassfish
* Web Portals (JSR portlets): Liferay, WebSphere Portal
==== Signatury a omezující podmínky služeb, OCL ====
Požadavky na rozhraní:
* poskytuje kontact s vnějším světem
* je tvořeno signaturami operací (input/output parametry)
* dobrá dokumentace (včetně kontraktu)
* jednoduchá dostupnost
* specifikace kontraktu (podmínky užití)
Dohoda mezi dvěma subjekty akceptující podmínky, na kterých je možné užívat práva.
=== OO kontrakt ===
* sdílení předpokladů o třídách, komponentách, systémech
* přesná specifikace rozhraní
* popis služeb, které jsou poskytovány za určitých podmínek
* 3 typy podmínek:
* **Invarianty** = predikát, který musí být vždy platný.
* **Preconditions** = Musí být platné před spuštěním operace.
* **PostConditions** = Musí platit po dokončení operace.
* Podmínky lze modelovat různými způsoby:
* běžným jazykem
* matematická notace
* Object Constraint Language (OCL)
* Viditelnost operací a atributů
* public: +
* dostupné z libovolného externího kódu
* private: -
* dostupné ze samotné třídy
* protected: #
* dostupné z třídy a jejích dědiců
* package: ~
* dostupné z tříd v rámci balíku
=== OCL ===
Object Constraint Language
* OMG standard
* ➕ umožňuje lepší dokumentaci
* ➕ přesnost (má formální sémantiku)
* ➕ OO
* ➕ komunikace bez nedorozumnění
Využití:
* invarianty tříd a typů
* pre-/post-conditions operací
* navigace napříč ukazateli mezi objekty
* podpora operací nad kolekcemi
* testovací specifikace a požadavky
Syntax
* silně typovaný, deklarativní jazyk
* každý klasifikát z UML se stává OCL typem
* předdefinuje základní typy a kolekce
syntax:
context
inv []:
syntax:
context :: ()
pre|post []:
=== IDL ===
* = Interface Description Language
* = Interface Definition Language
* Specifikační jazyk pro popis rozhraní komponent nezávisle na programovacím jazyce.
* Nejedná se o programovací jazyk.
* Systémy postavené nad IDL:
* CORBA
* WSDL pro Web Services
* Mozilla's XPCOM
* Facebook's Thrift
Web services Description Language
* postaven nad XML
* popisuje rozhraní pro Web Services
* vzájemně převoditelné s IDL
==== Kvalitativní aspekty služeb (QoS) ====
SW požadavky:
* **Functional**
* definuje funkcionalitu systému a jeho komponent
* specifikuje chování mezi vstupem a výstupem
* **Non-functional**
* klade omezení a kriteria na implementaci
Kvalitativní aspekty SW architektur:
* **Performance**
* propustnost
* čas odezvy
* efektivnost využití zdrojů
* **Reliability**
* běh bez pádů
* dostupnost
* robustnost
* schopnost obnovy
* **Security**
* integrita
* důvěrnost
* dostupnost
* **Scalability**
* výkon
* paralelní komunikace
* škálování dat
* **Maintainability**
* změnitelnost
* upravitelnost
Taktiky zlepšení:
* Performance
* minimalizace počtu adaptérů a wrapperů (redukce zdrojů pro jeden požadavek)
* zmenšit komunikace zajišťenou rozhraním (více rozhraní pro stejnou funkcionalitu)
* separace dat od výpočtu (lepší optimalizace dat/algoritmů)
* nahrazení synchronní komunikace za asynchronní
* přesunutí často komunikujících komponent blíže k sobě
* Reliability
* kontrola externích závislostí
* zvěřejnění stavu komponent a definice invariantů
* chybové řízené
* zamezit vzniku single-point-of-failure
* health-state kontroly systému
* systém záloh a obnov
* Scalability
* jednoduchá, jasně definovaná rozhraní
* distribuované zdroje dat
* zjistit vhodná data pro replikace
* použití paralelního zpracování na vhodných místech
* zamezit bottleneck místům
* změnit přímé závislosti na nepřímé (např. synchronní volání za asynchronní)
* Maintainability
* rozdělení zodpovědnosti/Sloučení zodpovědnosti (jasná lokalizace zodpovědných částí)
* odebrání kódu řešící interakce (ne funkcionalitu) vně komponent do konektorů
* odebrání kódu řešící funkcionalitu z konektorů do komponent
* malé a kompaktní komponenty
* izolace dat od výpočtu (menší dopad změny jednoho, či druhého)
* odebrat zbytečné závislosti
* hierarchická architektura (umožňuje vhled na systém z různou abstrakcí)
Definuje společné pochopení pro služby, priority, zodpovědnosti, garance a záruky.
==== Objektové metody vývoje softwaru, RUP ====
viz: http://statnice.dqd.cz/mgr-szz:in-gra:21-gra#oo_modely
===== Zdroje =====
* slidy pa103 (jaro 2019)