Toto je starší verze dokumentu! —-

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í

vzor (pattern)

Obecné řešení pro opakující se problém, tak aby jej bylo možné aplikovat v různém kontextu.

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.

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

Abstract Factory

Vytváření skupiny souvisejících objektů.

Builder

Postupné vytváření komplexních objektů.

Factory Method

Virtuální konstruktor.

Prototype

Instanciace objektů přes klonování „prototypu“.

Singleton

Tvorba maximálně jedné instance pro celý systém.
  • Structural patterns
    • řeší dělení rozhraní a implementace
    • kompozice objektů

Adapter

Překlad rozhraní.

Bridge

Abstrakce pro spojení více implementací.

Composite

Tvorba rekurzivní hierarchie objektů.

Decorator

Transparentní rozšíření objektů.

Facade

Zjednodušení a agregace rozhraní komplexního subsystému.

Flaywight

Sdílení mnoha objektů.

Proxy

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

Chain of Responsibility

Delegování žádosti na zodpovědného poskytovatele.

Command

Realizace žádostí/příkazů.

Interpreter

Interpretr jazyka pro malé gramatiky.

Mediator

Koordinace komunikace mezi zúčastněnými.

Memento

Uchování a obnovení stavu.

Observer

Update několika objektů při změně „sledovaného“.

State

Objekty, jejichž chování závisí na stavu.

Strategy

Abstrakce pro volbu jednoho z více algoritmů.

Template Method

Algoritmus s několika kroky implementovanými v podtřídě.

Visitor

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

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

Layers (vrstvy) – organizace kódu
Tiers – místo nasazení vrstev

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ů

Blackboard

Více zdrojů se střídavě zapojuje do řešení problému.

Broker

image.slidesharecdn.com_sasession11-140914043516-phpapp01_95_software-architecture-session11-73-638.jpg

Model-View-Controller (MVC)

Model-View-Presenter (MVP)

Model-View-ViewModel

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

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

<red 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

Invariants

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

Preconditions/Postconditions

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

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

WSDL

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

Service Level Agreement (SLA)

Definuje společné pochopení pro služby, priority, zodpovědnosti, garance a záruky.

Objektové metody vývoje softwaru, RUP

Zdroje

  • slidy pa103 (jaro 2019)
mgr-szz/in-pos/6-pos.1560506829.txt.gz · Poslední úprava: 2019/06/14 12:07 autor: lachmanfrantisek
Nahoru
CC Attribution-Noncommercial-Share Alike 3.0 Unported
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