# 4 Objektové metody návrhu systémů
###### tags: `řvss`, `informační-systémy`, `oop`

## Návrhové vzory

Návrhový vzor je obecné a znovupoužiteľné riešenie pri návrhu softvéru.

- popis alebo šablóna riešenia problému, ktorý môže byť riešený v rôznych situáciach
- uľahčuje znovupoužiteľnosť architektúr a návrhov SW
- zachytávajú, statickú a dynamickú štruktúru a spoluprácu medzi účastníkmi SW
- nie sú finálny návrh slúžia len ako model, ktorý je treba prispôsobiť pre danú situáciu
- priekopníci Gang of Four(GoF)

#### Problémy návrhových vzorov

- neplatí, že čím viac vzorov tým lepšie
- máme tendenciu stále používať posledný naučený vzor
- môžme použiť nesprávny vzor pre riešenie daného problému
- vysoké náklady pri redizajne SW pre použitie návrhové vzoru
- vzory majú častokrát podobnú vizuálnu štruktúru, preto je potrebné im rozumieť

#### Základná štruktúra vzorov

- názov
- problém(na čo je vzor vhodný)
- riešenie(popis vzoru)
- dôsledky(výhody nevýhody)

#### Klasifikácia vzorov podľa GoF

1. Creational Pattern
- problematika vytvárania objektov
- inicializácia a konfigurácia
- príklad
- class:
- Factory method
- object:
- Singleton
- Prototype
- Abstract Factory
- Builder
2. Structural Pattern
- oddeľujú rozhrania od implementácie
- kompozícia tried do hierarchií
- dedičnosť
- príklad
- class:
- Adapter(class)
- object:
- Adapter(object)
- Bridge
- Composite
- Decorater
- Facade
- Proxy
- Flyweight
3. Behavioral Pattern
- dynamická interakcia medzi triedami
- distribuovanie zodpovednosti
- príklad
- class:
- Interpreter
- object:
- Iterator
- Memento
- Observer
- State
- Strategy
- Visitor

### Creational Patterns

#### Singleton
- **Vytvára a sprostredkúva prístup k jednej zdieľanej inštancii dostupnej odkiaľkoľvek**
- pokiaľ niekto bude chcieť vytvoriť druhp inštanciu, vráti sa mu odkaz na už vytvorenú
- použije se mechanismus volání statických metod(public static)


Aplikovatelnosť:
- ak potrebujeme v celom systéme presne jednu inštanciu danej triedy, dostupnú cez dobre známy definovaný prístupový bod

Dôsledky:
- kontrolovaný prístup k inštancií
- redukcia menného priestoru

Kritika:
- singleton je niekedy spomínaný v anti-patterns, vytvoriť niečo globálne
- porušuje single responsibility principle

### Structural Patterns

#### Facade
- sprostredkuje prístup k podsystému
- namiesto priamej interakcie klientov s komplexnými komponentami subsystému, používa jednotné (často zjednodušené) API


Aplikovatelnosť:
- keď chcete poskytnúť jednoduché rozhranie pre komplexný podsystém
- keď chcete vrstviť svoje podsystémy, použite fasádu na definovanie vstupného bodu do každej úrovne podsystému

Dôsledky:
- Chráni klientov pred komponentmi podsystému, čím znižuje počet objektov, s ktorými klienti pracujú, a uľahčuje používanie podsystému.

### Behavioral Patterns

#### Memento
- zachytáva a ukladá interný stav objektu
- uložený stav objektu môže byť neskôr načítaný

Aplikovatelnost:
- ak chceme ukladať stav objektu (alebo jeho časti) pre načítanie neskôr
- a zároveň ak by priame rozhranie pre získanie stavu objektu zbytočne vystavovalo implementačné detaily

Důsledky:
- zachováva princípy zapuzdrenia (encapsulation)
- zjednodušuje pôvodcu (Originator) - nemusí si v sebe držať všetky verzie uložených stavov
- nevýhoda: používanie mementa môže býť náročné (kopírovanie veľkého množstva informácií)


## Interfaces
- Poskytuje kontakt s vonkajším svetom
- zobrazuje vlastne akú funkcionalitu môžme očakávať od danej komponenty a za akých podmienok
- obsahuje operácie, vstupné a výstupné parametre
- slúži ako kontrakt s okolitým svetom, ktorý hovorí o tom, že za dodržania vopred stanovených podmienok bude poskytovať takúto službu
- musí byť veľmi dobre zdokumentovaný
- kontrakt sa vlastne skladá z podmienok, dokumentácie jednotlivých operácií a parametrov

### Objektovo orientované kontrakty
- udávajú presnú štruktúru špecifikácie daného interfacu
- popisuje služby ktoré sú poskytované za konkrétnych podmienok

### Typy kontraktov
Invariatny:
- je to podmienka ktorá musí vždy platiť pre všetky inštancie danej triedy/komponenty
- podmienka ktorá sa počas behu programu nikdy nemení

Precondition
- je to podmienka ktorá musí byť splnená na začiatku volania určite operácie

Postcondition
- je to podmienka ktorá platí vždy po volaní operácie

### Object Constraint Language
- je to jazyk na formulácie podmienok daného kontraktu
- podmienky vlastne pridávajú informáciu o elementoch daného modelu a vzťahoch medzi nimi
- OCL obsahuje string, boolean, real a integer
- pridávajú sa do UML
- používa sa na presnú špecifikáciu daného kontraktu
- OCL formulujeme vždy v kontexte danej triedy a následne pridávame podmienky
- v prípade dedenia, pre-condition je v sub-class vždy **slabšia**
- V prípade dedenia, post-condition je v sub-class vždy **silnejšia**

#### OCL collections
- OCL obsahuje kolekcie:
- Set - neusporiadana množina v ktorej sa každý prvok vyskytuje práve jeden krát
- Bag - neusporiadana množina v ktorej sa každý prvok môže vyskytovať viackrát
- Sekvencia - usporiadana množina v ktorej sa každý prvok môže vykystovať viackrát

#### OCL operations
- OCL obsahuje operácie:
- collect - vracia Bag prvkov splňujúci danú podmienku
- select - vracia subset elementov ktoré splňujú danú podmienku
- reject - doplnok ku select
- forAll - je true pokiaľ podmienka platí pre všetky prvky danej kolekcie
- exists - je true pokial podmienka platí aspoň pre jeden prvok danej kolekcie
- iterate - dokážeme danou kolekciou iterovať

## SW architecture

- Skladá sa zo základných dizajnových rozhodnutí týkajúcich sa daného systému.
- Je to také rozhodnutie, ktoré je v neskorších fázach veľmi ťažké zmeniť

Prvky softvérovej architektúry
- modules
- sú to časti softvéru, ktoré implementujú určitú funkcionalitu
- zapúzdrené časti softvéru ktoré obsahujú logicky zoskupenú funkcionalitu
- pre komunikáciu s vonkajším svetom sú vystavené interfaces
- connector
- interface daného modulu
- slúži na komunikáciu
- deployment
- je to vlastne mapovanie modulov a konektorov na harverové zdroje na ktorých budú bežať
- môže to ovplyvniť správanie celého systému

### Architektonické návrhy

- Generické riešenia dizajnu architektúry
- je to súhrn architektonických riešení ktoré sú aplikovateľné na konkrétny prípad použia
- je prepoužiteľný
- Slúži na vzájomnú komunikáciu medzi zúčastnenými stranami o danom softvere
- Využíva sa aj pri projektovom plánovaní, na základe architektúry si vieme lepšie predstaviť čo vlastne ideme implementovať, vďaka tomu vieme lepšie odhadovať pracnosť
- udržovateľnosť

#### Client-Server architecture pattern
- data sú distribuované naprieč servermi ktoré poskytujú službu
- klient volá takéto služby

**Server**
- reactive entity

**Client**
- active entity

#### Peer-to-Peer Architecture
- distribuovaná architektúra, kde úlohy a zaťaženie sú rozdelené medzi jednotlivé peery
- peer pôsobí ako klient aj ako server

#### Layered Architecture
- pomáha štruktúrovať aplikáciu na viacero vrstiev, ktoré komunikujú prostredníctvom interfacov
- čím vyššia vrstva, tým vyššia miera abstrekcie
- Vrstva N poskytuje službu vrstve N+1 a deleguje úlohy na vrstvu N-1
- Vrstvy sú komplexné entity pozostávajúce z komponent

Komunikácia zhora nadol:
- Klient zadá požiadavku na vrstvu N. Vrstva N volá ďalšiu vrstvu N-1 na podporu čiastkových úloh a tak ďalej, kým sa nedosiahne vrstva 1. Vrstva N často prekladá jednu požiadavku na niekoľko požiadaviek do vrstvy N-1.

Komunikácia zdola nahor:
- Reťazec akcií začína na nižšej vrstve 1, napr. keď ovládač zariadenia detekuje vstup. Horné vrstvy sú upozornené a poskytnuté údaje sú interpretované hornými vrstvami.

Výhody:
- jednotlivé vrsty je možné prepoužiť

Nevýhody:
- nižšia efektivita komunikácie

Príklad: iDesign Method

#### Repository Architecture Pattern
- Interakcia s dátami prostredníctvom centrálneho repoziráta
- Repozitár je stredník v komunikácií medzi dátovou vrstvou a biznisovou vrstvou

#### Model View Controller(MVC)
- pomerne starý pattern

Model:
- poskytuje funkcionalitu a enkapsuluje dáta
- upozorňuje závislé komponenty na zmenu

View:
- prezentuje dáta použivateľovi
- rôzne Views môžu zobražovať model v rôznych podobách

Controller:
- Prijíma vstup používateľa ako udalosti. Udalosti sa prevedú do žiadostí pre Model alebo súvisiace Views.

#### Broker Architecture
- pôsobi ako stredník v komunikácií medzi klientom a serverom

Client:
- Implementujee používateľskú funkcionalitu, posiela požiadavky na servery. Na zavolanie vzdialenej služby klienti preposielajú požiadavky Brokerovi. Klient nemusí poznať lokalitu serverov, ku ktorým pristupuje.

Server:
- implementuje služby

Broker:
- je zodpovedný za prenos dát medzi klientom a serverom

#### Microkernel Architecture
- core systém štruktúry mikcokernel obsahuje iba minimálnu funkcionalitu potrebnú na to, aby bol systém operovateľný.
- Plug-in moduly sú samostatné, nezávislé komponenty ktoré obsahujú funkcionalitu a vlastný kód, ktorý má rozšíriť core systém

#### Pipes and Filters
- poskytuje štruktúru systému cez ktorý prúdia dáta
- dáta prúdia prostredníctvom pipes a menie sa v jednotlivých filtroch
Pipe: zabezpečuje spojenie medzi jednotlivými filtrami
Filter: Procesuje vstupné dáta a vracia upravené výstupné
Active filter: získava dáta z pipes a odosiela ich ďalej
Active pipes: aktívne posieľajú a žiadajú dáta
Data source: input stream
Data sink: výsledok na konci pipe

#### Blackboard
- užitočný na riešenie problémov na ktoré nemáme konkrétny postu
- Centrálne úložisko dát. Termín slovná zásoba používame pre množinu všetkých dátových prvkov, ktoré sa môžu objaviť na tabuli.
- Knowledge sources - separate independent subsystems that resolve specific aspects of overall problem, komunikujú len prostredníctvom tabule
- Control - určuje poradie KS, monitoruje blackboard

## Komponentové systémy

- spustitelný kus kódu
- typicky sa skladá z množstva tried alebo objektov
- nepriamo komunikuje prostredníctom interfacov
- nezobrazujú source code, sú enkapsulované, poskytujú len dobre špecifikovaný interface
- sú prepoužiteľné a jednoducho
- Rozhrania sú užitočné pri deklarovaní celkového správania komponentu, ale nemajú žiadnu individuálnu identitu.
- Port má identitu. Komponent môže komunikovať s iným komponenton cez špecifický port.
- komponent sa delí na časti

#### Komponentový model
- definuje špecifikú reprezentáciu, interakciu, kompozíciu a iné štandardy SW komponent
- komerčný príklad, Corba

## Quality Assurance
- chceme garantovať kvalitu daného softvéru
- vzhľadom na SLA, zákazník požaduje určite štandardy týkajúce sa kvality, za ktoré platí

funkčné požiadavky
- definujú funkcionalitu sw

nefunčkné požiadavky
- môže definovať obmedzenia a použité technológie

Extra-functional requirements
- rýchlosť systému, dostupnosť

Ako navrhnúť vysoko kvalitný softvér?
- snažíme sa použiť vhodné architektonické návrhy
- snažíme sa robiť jednotlivé komponenty alebo prvky čo najkvalitnejšie

Ako garantovať kvalitu?
- musíme ju merať
- meriame prostredníctom
- monitorovania a testovania
- formálnej verifikácie
- predikcie na základe modelu - odhad kvality vyvíjaného systému(je na to potrebný model systému, je to použiteľné počas celej doby návrhu architektúry), kvalita odhadu závisí na modele a pozornosti venovanej detailom

Kvalita komponenty alebo služby závisí na kvalite jej implementácie, služieb ktoré jú volajú a zdrojoch ktoré komponent používa a spôsobe ako je služba používaná