Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze
Předchozí verze
mgr-szz:in-pos:6-pos [2019/06/10 09:23]
lachmanfrantisek návrhové vzory
mgr-szz:in-pos:6-pos [2020/04/12 16:56] (aktuální)
Řádek 20: Řádek 20:
 </​box>​ </​box>​
  
- 
-=== 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** 
  
  
Řádek 180: Řádek 141:
  
  
 +=== 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**
  
  
Řádek 185: Řádek 184:
 ==== Softwarové architektury ==== ==== Softwarové architektury ====
  
-==== Rozhraní ​komponent, ​signatury ​omezující podmínky služeb, OCL ====+  * Zásadní návrhová rozhodnutí. 
 +  * Základní struktura systému složená z komponent, ​jejich vztahů ​principů pro návrh a implementaci. 
 +  * Abstrakce na systémové úrovni.
  
-==== Komponentové systémy a modely, ​kvalitativní ​aspekty služeb (QoS) ====+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 === 
 + 
 +<box 90% blue|Layers>​ 
 +  * 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 
 + 
 +<note tip> 
 +**Layers (vrstvy)** -- organizace kódu 
 +**Tiers** -- místo nasazení vrstev 
 +</​note>​ 
 +</​box>​ 
 + 
 + 
 +<box 90% blue|Pipes and Filters>​ 
 +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ů 
 +</​box>​ 
 + 
 +<box 90% blue|Blackboard>​ 
 +Více zdrojů se střídavě zapojuje do řešení problému. 
 +</​box>​ 
 + 
 +<box 90% blue|Broker>​ 
 +{{https://​image.slidesharecdn.com/​sasession11-140914043516-phpapp01/​95/​software-architecture-session11-73-638.jpg}} 
 +</​box>​ 
 + 
 +<box 90% blue|Model-View-Controller (MVC)> 
 +{{:​mgr-szz:​in-pos:​mvc.png?​300|}} 
 +</​box>​ 
 + 
 +<box 90% blue|Model-View-Presenter (MVP)> 
 +{{:​mgr-szz:​in-pos:​mvp.png?​300|}} 
 +</​box>​ 
 + 
 +<box 90% blue|Model-View-ViewModel>​ 
 +{{:​mgr-szz:​in-pos:​mvv.png?​300|}} 
 +</​box>​ 
 + 
 +==== 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 reprezentaciinterakci 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í) 
 + 
 + 
 +<box 90% red|Kontrakt>​ 
 +Dohoda mezi dvěma subjekty akceptující podmínky, na kterých je možné užívat práva. 
 +</​box>​ 
 + 
 +=== 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 
 + 
 +<box 90% blue|Invariants>​ 
 +syntax: ​    
 +    context <​classifier>​ 
 +    inv [<​constraint name>​]:​ 
 +    <Boolean OCL expression>​ 
 +</​box>​ 
 + 
 +<box 90% blue|Preconditions/​Postconditions>​ 
 +syntax: 
 + 
 +    context <​classifier>::<​operation>​ (<​parameters>​) 
 +    pre|post [<​constraint name>​]:​ 
 +    <Boolean OCL expression>​ 
 +</​box>​ 
 + 
 +=== 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 
 + 
 +<box 90% blue|WSDL>​ 
 +Web services Description Language 
 +  * postaven nad XML 
 +  * popisuje rozhraní pro Web Services 
 +  * vzájemně převoditelné s IDL 
 +</​box>​ 
 + 
 +==== 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í) 
 + 
 + 
 +<box 90% red|Service Level Agreement (SLA)> 
 +Definuje společné pochopení pro služby, priority, zodpovědnosti,​ garance a záruky. 
 +</​box>​
  
 ==== Objektové metody vývoje softwaru, RUP ==== ==== Objektové metody vývoje softwaru, RUP ====
 +
 +viz: http://​statnice.dqd.cz/​mgr-szz:​in-gra:​21-gra#​oo_modely
 +
  
 ===== Zdroje ===== ===== Zdroje =====
  
   * slidy pa103 (jaro 2019)   * slidy pa103 (jaro 2019)
mgr-szz/in-pos/6-pos.1560151428.txt.gz · Poslední úprava: 2020/04/12 16:56 (upraveno mimo DokuWiki)
Nahoru
CC Attribution-Noncommercial-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0