IN-POS 6. Objektové metody návrhu systémů

• 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

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

• Structural patterns
  • řeší dělení rozhraní a implementace
  • kompozice objektů

• Behavioral patterns
  • řeší dynamické interakce mezi třídami/objekty
  • dělba zodpovědnosti

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

• = 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ě.

• 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é modely
  • = komponentové standardy
  • definují specifickou reprezentaci, interakci a kompozici SW komponent
  • Příkaldy 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

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í)

<red 90% red|Kontrakt>
Dohoda mezi dvěma subjekty akceptující podmínky, na kterých je možné užívat práva.
</box>

• 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

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

  context <classifier> 
  inv [<constraint name>]: 
  <Boolean OCL expression> 

  context <classifier>::<operation> (<parameters>) 
  pre|post [<constraint name>]: 
  <Boolean OCL expression> 

• = 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

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í)

viz: http://statnice.dqd.cz/mgr-szz:in-gra:21-gra#oo_modely

• slidy pa103 (jaro 2019)