---
# System prepended metadata

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

---

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

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


## Návrhové vzory

Návrhový vzor je obecné a znovupoužiteľné riešenie problému 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čujú znovupoužiteľnosť architektúr a návrhov SW
- zachytávajú statickú, dynamickú štruktúru a spoluprácu medzi účastníkmi SW
- nie sú finálny návrh, slúžia ako model, ktorý je treba inštanciovať pre konkrétne použitie

#### Problémy návrhových vzorov
- nie je pravda, že čím viac vzorov, tým lepšie
- použitie nesprávneho vzoru pre riešenie problému
- vysoké náklady na redizajn SW pre použitie návrhových vzorov
- používanie posledného naučeného vzoru na každý problém
- vzory majú často vizuálne podobnú štruktúru, preto je treba im plne 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 použitia vzoru)

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

1. **Creational patterns**
    - problematika vytvárania objektu
    - inicializácia a konfigurácia
3. **Structural patterns** 
    - oddeľujú rozhrania od implementácie
    - kompozície tried do hierarchií
    - dedičnosť
5. **Behavioral patterns**
    - dynamická interakcia medzi triedami
    - distribuovanie zodpovedností

![](https://i.imgur.com/UNs9OXl.png)

### Creational patterns

#### Abstract Factory
- vytváří kompatibilní objekty
- když potřebujeme v paměti instanciovat objekty
- objekty jsou z rodin objektů a potřebujeme, aby byly kompatibilní
- (vyrábíme auta (kola, blatníky) a zároveň když vyrábíme škodovku, tak potřebujeme zajistit, že ty části vyrábíme pro ni a ne pro Citroen)
- v Jave napr. `DocumentBuilderFactory.newInstance()`

Aplikovatelnost:
- pokud chceme, aby systém byl nezávislý na tom, jak se vytváří instance (jak jsou spojovány a reprezentovány)
- pokud systém by měl být konfigurovatelný s různými rodinami produktů
- produkty z jedné rodiny musí pracovat společně

Důsledky: 
- izolovat klienty od implementace podtříd
- snadno se mění produktové rodiny
- nutná konzistence mezi produkty
- nevýhoda: obtížné přidat nový druh produktu

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/abstract-factory

![](https://i.imgur.com/OQmjRbi.png)

#### Builder

- builder (stavitel) je návrhový vzor popisující způsob jak přistupovat k tvorbě různých instancí s podobným konstrukčním procesem
- ve skutečném světě by se to dalo přirovnat například k přípravě pizzy - všechny druhy mají stejný základ, liší se jen na povrchu

Aplikovatelnost:
- ak má byť algoritmus pre konštrukciu komplexných objektov nezávislý na častiach, z ktorých sa objekt skladá
- ak má proces konštrukcie objektu umožňovať rôzne reprezentácie objektu

Důsledky: 
- umožňuje meniť internú reprezentáciu objektu
- izoluje kód pre konštrukciu a reprezentáciu objektu

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/builder

![](https://i.imgur.com/X8Okqu8.png)

#### Prototype

- způsob vytváření (naklonování) na základě prototypů, které mám v paměti
- obdobnou funkčnost může také poskytovat tovární metoda (Factory Method), která je jednodušší na implementaci

Aplikovatelnost:
- Používá se, když je vytváření instance třídy velmi časově náročné nebo nějak výrazně složité. Potom je výhodnější než náročně vytvářet mnoho instancí, vytvořit jednu a ostatní objekty z ní naklonovat.
- může být také použit když jsou potřeba třídy, které se liší pouze v tom, jaké zpracování nabízejí

Důsledky: 
- môže zjednodušiť vytváranie zložitých inštancií

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/prototype

![](https://i.imgur.com/sGVukwb.png)


#### Singleton

- když chci volat nějaký objekt, singleton zajistí, že vždy sahám na jediný objekt v systému (nikdy tam nemám více instancí)
- máme jedinou instanci, ke které se vždycky dostaneme
- pokud někdo bude chtít volat instanci, nebude to dělat pomocí konstruktoru
- použije se mechanismus volání statických metod (statická metoda instance)
- pokud někdo bude chtít volat metodu objektu a objekt v paměti ještě neexistuje, tak se instancuje (vytvoří), uloží a pokud pak někdo bude chtít volat tuto metodu, tak se bude neustále odkazovat na ten jediný objekt v systému
- v Jave napr. `Runtime.getRuntime()`

Aplikovatelnost:
- ak potrebujeme v celom systéme presne jednu inštanciu danej triedy, dostupnú cez definovaný prístupový bod

Důsledky: 
- kontrolovaný přístup k instanci
- menej premenných v kóde (odkazujúcich sa na jednotlivé inštancie)

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/singleton

![](https://i.imgur.com/CT6oZVU.png =60%x)
![](https://i.imgur.com/Gr0taCD.png)

#### Factory method
> Nebolo v prednáškách, ale pre istotu:
> https://refactoring.guru/design-patterns/factory-method

### Structural patterns

#### Adapter

- mám rozhraní, které má něco splňovat a mám existující knihovnu nebo objekt, který splňuje požadavky jen částečně
- 2 typy
    - class adapter
        - udělám podtřídu, která implementuje obě rozhraní
        - využíva subclassing
    - object adapter
        - delegácia cez objekt - privátny atribút 
        - využíva kompozíciu

Aplikovatelnost:
- pokud potřebujeme využít existující kód, ale interfacy nám úplně přesně nesedí
- chceme vytvořit znovupoužitelnou třídu, která bude spolupracovat s objekty, o kterých ještě nic nevíme
- pokud potřebujeme použít existující podtřídy, ale není praktické adaptovat jejich rozhraní subclassingem (object adapter)

Důsledky: 
- nebude fungovat, pokud chceme adaptovat i podtřídy (class adapter)
- umožňuje změnit chování adaptovaného (class adapter)
- těžší pozměnit chování (object adapter)

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/adapter

*class adapter*
![](https://i.imgur.com/bTqHpfG.png)

*object adapter*
![](https://i.imgur.com/teaOijk.png)

#### Bridge

- když vytváříme hierarchie objektů, abychom je nedělali zbytečně složité

Aplikovatelnost:
- pokud nechceme permanentně spojovat abstrakci a implementaci (implementaci tam mohu podstrčit za běhu)
- abstrakce a implementace budou rozšiřovány podtřídami (bridge pomůže zkombinovat 2 rozšíření)
- změny v implementaci by neměly ovlivňovat klienta
- proliferace tříd – potřeba přidání jedné třídy znamená přidání několika variant pro již existující třídy 

Důsledky: 
- oddělení rozhraní a implementace
- schování implementačních detailů klientovi

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/bridge

![](https://i.imgur.com/MNNZR3j.png)

#### Composite

- pro práci se stromy
- třída Component je uzel stromu, má metody add, remove, get, specializuje se na 2 podtypy – Composite a Leaf
- Composite – větvící se uzel, implementuje operace a agreguje libovolné instance komponenty
- Leaf neimplementuje add, remove, get, pouze obecnou operaci

Aplikovatelnost:
- Pokud chceme reprezentovat celek-část hierarchii nebo pokud chceme, aby klientský kód nerozlišoval mezi uzly
- operace se aplikuje na celý strom (přepošle se na potomky), nezáleží, jaký uzel klientovi poskytneme

Důsledky: 
- zjednodušuje klienty (nemusí rozlišovat, co je to za uzel, jen aplikují operaci)
- je snadné přidávat nové typy komponent
- nevýhoda: neomezuje, jaký potomek může být v jakém rodiči

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/composite

![](https://i.imgur.com/pTbPQ4B.png)

#### Decorator
- snažíme se pozměnit chování objektu za běhu
- pokud chceme pozměnit chování - buď uděláme podtřídu, a nebo to uděláme na úrovni objektů za běhu
- mám nějaký objekt (text) v paměti, mohu rozšířit jeho chování tak, že ho umožním třeba scrollovat a dále například obalit ho okrajem
- flexibilní alternativa k podtřídám
- podobné vzoru Composite (degenerovaný composite s jednou komponentou), Adapter (mění objekty a ne rozhraní jako Adaptor) a Strategy

Aplikovatelnost:
- pokud potřebujeme přidat zodpovědnost k individuálnímu objektu a dědením je to nepraktické

Důsledky: 
- více flexibilní než dědičnost
- nevýhoda: větší množství malých objektů

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/decorator

![](https://i.imgur.com/CsgmwSQ.png)

#### Facade
- poskytuje jednotný prístupový bod (rozhranie) komplexného systému
- namiesto priamej interakcie klientov s komplexnými komponentami subsystému, používa jednotné (často zjednodušené) API

Aplikovatelnost:
- ak chceme poskytnúť jednoduché rozhranie komplexného systému
- ak chceme používať subsystémy vo vrstvách, facade môže definovať prístupový bod každej vrstvy

Důsledky: 
- oddeľuje klientov od komponent subsystému
- zjednodušuje väzby medzi subsystémom a klientmi (weak coupling)

![](https://i.imgur.com/2LXMlfD.png)

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/facade

#### Flyweight
- minimalizácia pamäťovej náročnosti zdieľaním čo najviac dát medzi viacerými podobnými objektmi
- pokud máme spoustu malých podobných objektů
- vytvoříme zásobník (pool)
- objekty v paměti nejsou tolikrát, kolikrát se vyskytují, ale pouze jednou a každý výskyt znamená, že se odkazují do pool
- intrinsic stav - sdílený stav medzi podobnými objektmi, bez ohledu na kontext
    - napr. word processor, objekt zobrazujúci znak "A" má uložený vzhľad znaku (ikonu) v zdieľanom flyweighte, pre všetky znaky "A"
- extrinsic stav – stav špecifický pre daný kontext 
    - napr. word processor, pozícia znaku "A" v texte je uložená v každom objekte zvlášť, nemôže byť zdieľaná pre všetky "A"

Aplikovatelnost:
- pokud jsou splněny všechny podmínky:
    - aplikace používá velké množství malých objektů
    - cena za ukládání je vysoká
    - vyplatí se nám vytáhnout z objektů extrinsic state a zbytek sdílet (u každého objektu si musím uvědomit, kterou informaci jsme schopni sdílet a kterou si musím pamatovat)
    - aplikace nezávisí na identitě objektu

Důsledky: 
- menšia časová náročnost výpočtu
- děláme to pro ušetření paměti
- velikost intrinsic stavů (čím víc toho sdílíme, tím více ušetříme)
- nesdílenou znalost lze počítat
- často kombinovaný s Composite

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/flyweight

![](https://i.imgur.com/Xtj1Bxn.png)

#### Proxy
- neplést s Adapterem
- abychom nahradili reálný objekt jiným objektem
- klient komunikuje s reálným subjektem a my tam podstrčíme proxy, přes který celá komunikace jde

Aplikovatelnost:
- pokud reálný subjekt leží na jiném pc na jiné síti – proxy zprostředkovává komunikaci
- vytváření paměťově drahých objektů na požádání (práce s obrázky, aplikace může a nemusí potřebovat konkrétní pixely)
- kontrola přístupu – zda máme právo přistupovat k objektu

Důsledky: 
- nekomunikujeme přímo s objektem, ale přes prostředníka
- vytvoření objektu na požádání

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/proxy

![](https://i.imgur.com/FePR2WU.png)

### Behavioral patterns

#### Iterator

- mám agregovaný objekt (kontejner), který má za úkol mít v sobě nějaké podobjekty
- místo toho, aby nám agregovaný objekt vracel přímo podobjekty, vytváří speciální objekt (iterátor), který umí kontejner procházet
- ke konkrétnímu prvku se dostaneme přes iterátor

Aplikovatelnost:
- pokud chceme mít přístup k agregovanému objektu bez toho, abychom klientům zpřístupňovali interní strukturu
- pokud chceme podporovat paralelní procházení, lze instanciovat více iterátorů

Důsledky: 
- podporuje různé variace procházení (více typů integrátorů, více variant procházení)
- iterátory zjednoduší rozhraní agregovaného objektu

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/iterator

![](https://i.imgur.com/HGDYgim.png)

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

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/memento

![](https://i.imgur.com/TfOS7ic.png)

#### Observer
- princip publish subscribe
- mám subjekt, který pozoruji a já se na něj mohu dívat z různých pohledů
- zároveň chci, aby to bylo interaktivní

Aplikovatelnost:
- pokud abstrakce má dva aspekty, které na sobě závisí
- keď zmena objektu má vyvolať zmenu v iných objektoch, ale nevieme v koľkých

Důsledky: 
- abstraktná väzba medzi subjectom a observerom
- podpora broadcastingu
- nečekané updaty (pretože observeri o sebe navzájom nevedia)

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/observer

![](https://i.imgur.com/gpnoO83.png)


#### State
- zabezpečuje rozdielne chovanie objektu v závislosti na stave objektu
- objekt s ktorým klienti interagujú (Context) si drží svoj stav v objekte stavu (State)
- State je rozhranie, ktoré implementujú viaceré konkrétne stavy (ConcreteState)
- State alebo ConcreteState objeky sú zodpovedné za prechody do nasledujúcich stavov
- Context objekt deleguje požiadavky klientov aktuálnemu ConcreteState objektu

Aplikovatelnost:
- ak má správanie objektu závisieť na jeho stave, ktorý sa môže meniť za behu
- ak majú operácie zložité podmienky, ktoré závisia na stave objektu

Důsledky: 
- oddeľuje od seba správanie pre jednotlivé stavy
- explicitné prechody medzi stavmi

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/state

![](https://i.imgur.com/VlSLvUQ.png)


#### Strategy

- mám kontext algoritmu (klient volá kontext) a ten si asociuje konkrétní strategii výpočtu
- třída strategie definuje jednu nebo více metod a podtřídy definují různé varianty výpočtu
- za běhu lze podstrčit konkrétní strategii

Aplikovatelnost:
- pokud máme podtřídy, které se liší implementací jediné metody
- pokud potřebujeme různé varianty algoritmu
- pokud algoritmus používá data, o kterých by klient neměl vědět
- když máme switch, if then else a v každé větvi je trošku jiná varianta výpočtu (každou variantu jako separátní třídu)

Důsledky: 
- hierarchie strategií definují rodiny
- alternativa k subclassing
- eliminuje switch cases
- různé implementace stejného chování
- na začátku musím určit, která strategie se bude používat
- může to být pomalejší – overhead
- větší počet objektů

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/strategy

![](https://i.imgur.com/e59VOA2.png)

#### Visitor

- oddeľuje algoritmus od objektovej štruktúry, na ktorej ho vykonáva
- namiesto pridávania operácií do jednotlivých tried, vytvoríme Visitor triedu, ktorá implementuje jednotlivé operácie v závislosti na triede objektu
- príklad operácie (viz. diagram)
    - na objekte ConcreteElementA sa zavolá metóda Accept() s ConcreteVisitor1 (predstavuje danú operáciu)
    - v rámci metódy Accept() element zavolá metódu VisitConcreteElementA(this)
    - vykoná sa operácia implementovaná vo visitore špecifická pre triedu ConcreteElementA
     

Aplikovatelnost:
- ak máme viaceré objekty rôznych tried, na ktorých chceme vykonať operáciu, ktorá závisí na triede daného objektu
- ak potrebujeme na objektoch rôznych tried vykonávať viaceré nesúvisiace operácie, ktoré nechceme mať zakomponované priamo do jednotlivých tried

Důsledky: 
- jednoduché pridávanie nových operácií
- visitor môže byť použitý na spájanie súvisiacích operácií, a rozdeľovanie nesúvisiacích
- nevýhoda: porušuje zapuzdrenie

> podrobnejšie vysvetlenie: https://refactoring.guru/design-patterns/visitor

![](https://i.imgur.com/uFOAWKJ.png)

#### Chain of Responsibility
> Nebolo v prednáškách, ale pre istotu:
> https://refactoring.guru/design-patterns/chain-of-responsibility

#### Command
> Nebolo v prednáškách, ale pre istotu:
> https://refactoring.guru/design-patterns/command

#### Mediator
> Nebolo v prednáškách, ale pre istotu:
> https://refactoring.guru/design-patterns/mediator

#### Template Method
> Nebolo v prednáškách, ale pre istotu:
> https://refactoring.guru/design-patterns/template-method

## Analytické vzory
> Nie sú explicitne v otázke, neviem, či je to potrebné

### Accountability vzory
- modelování organizačních struktur, osob...

#### Party
- nerozlišujeme mezi konkrétní osobou a organizační jednotkou (oddělení)
- například využijeme pro eshop – zákazníci, společnosti, potřebujeme znát kontakty

![](https://i.imgur.com/sni4Jeo.png)


#### Organizační hierarchie
- univerzita se skládá z fakult, kateder
- jeden strom řízení
- použití rekurzivních vztahů
- umožňuje na úrovní objektů/ instancí vytvářet různé hierarchie organizačních struktur, což je mnohem flexibilnější
- v návrhové části je přirozené tento vzor rozpracovat pomocí Composite

![](https://i.imgur.com/OtwWYJT.png)


#### Organizační struktura
- složitější strom
- například MU
- 2 asociace, 2 paralelní hierarchie
- problém je, pokud je organizačních struktur více – použít Organization Structure
- pokud chceme propojit 2 instance (fakultu a katedru) je nutné to udělat přes pomocný objekt Organization Structure
- větší flexibilita
- vhodné pro násobné organizační hierarchie
- přidání nové hierarchie = přidání instance
- lze přidat pravidla (kdo s kým může být ve vztahu)

![](https://i.imgur.com/j8x3Zhi.png)


#### Accountability
- řeší zodpovědnost
- zobecnění vztahů nadřízený-podřízený
- snažíme se oddělovat Knowledge a Operation Level
- přímo vzor Accountability Knowledge Level
- na Knowledge Level definuji, kdo s kým může být
- na Operation Level definuji konkrétní instance

![](https://i.imgur.com/F3qhXcu.png)

#### Další vzory
- Party Type Generalization
- Hierarchic Accountability
- Operating Scopes
- Post

### Vzory na pozorování a měření
- chceme měřit výšku, váhu, krevní skupinu
- sofistikované alternativy k numerickým atributům

#### Quantity
- v systému lze mít různé hodnoty v různých jednotkách
- chceme, aby systém podporoval ukládání různých hodnot v různých jednotkách
- systém pacientů

![](https://i.imgur.com/ZLmsswE.png)

#### Conversion Ratio
- převodní tabulka v paměti
- v tabulce je napsáno, jakým číslem (nebo celým algoritmem) číslo vynásobit, abychom dostali stejné jednotky
- v návrhovém vzoru je to Strategy

![](https://i.imgur.com/1GxHG2p.png)

#### Compound Units
- složené jednotky – zrychlení, km/h..
- vyjádření jednotek pomocí exponentů - km * h-1

![](https://i.imgur.com/ePoyodv.png)

#### Measurement
- chceme zaznamenat do systému, že hodnota byla naměřena

![](https://i.imgur.com/TvKaFcH.png)

#### Observation
- měření nemusí být jen číslo, ale i vyjmenované možnosti
- nečíselné měření, nějaká kategorie
- male/female

![](https://i.imgur.com/tRVYGRF.png)

#### Protocol
- potřebujeme zaznamenat způsob měření
- 3 možnosti měření teploty pacientů

![](https://i.imgur.com/TvnImbT.png)


### Odkazy na objekty

#### Name
- identifikace objektu
- problém, že jméno nebude identifikovat instanci jednoznačně - př. Masarykovo náměstí, není jen jedno, je jich v ČR více

![](https://i.imgur.com/331H3d8.png)


#### Identification Scheme
- víme, že se používá několik výrazů pro danou věc

![](https://i.imgur.com/5AV4BA1.png)


#### Object Merge
- pokud budeme mít duplicitní objekty
- přijdu s bolavým zubem x dovezou mě na ARO, kdy budou řešit, zda tam mám kartu nebo ne až později
- jako Adapter

![](https://i.imgur.com/Rz0LJyS.png)


#### Object Equivalence
- užitečné definovat, že objekty jsou více méně stejné

![](https://i.imgur.com/5hTFP7I.png)


## Softwarové architektury
- nutné zacelit mezeru mezi požadavky a kódem
- sada principiálních návrhových rozhodnutí o systému
- volba architektury je složité rozhodnutí, pozdější změna je náročná
- má 3 složky
    - moduly – komponenty, které tvoří funkcionalitu systému (balíky, procesy, vlákna), UML: component/class diagram
    - konektory – komunikační spoje a kanály, UML: sequence/communication/activity diagram
    - nasazení – nasazení systému na konkrétní hw a sw, UML: deployment diagram
- výhody definované architektury systému
    - vzájemná komunikace – sjednocení pohledu na systém mezi různými rolemi
    - systémová analýza – mám namodelovanou architekturu, tak na ní mohu dělat další operace - výpočty, predikce
    - znovupoužitelnost – stejná architektura může být použitelná i pro jiné zákazníky
    - projektové plánování – odhady cen
- role sw architekta (měl by mít všechny tyto znalosti):
    - sw návrhář – aby našel efektivní návrhová řešení
    - doménový expert – znalost aplikační domény
    - technolog – přehled o technologických řešeních
    - znalec sw/hw standardů – orientace v relevantních standardech
    - ekonom sw inženýrství – rozdělování práce ve vývojovém týmu

### Návrh SW architektury
**Časti SW architektúry:**
- Moduly
    - systémové komponenty
    - model statické struktury (knihovna, balík)
    - buď složené z jiných podmodulů (používá se diagram komponent) nebo dále nedělitelné moduly (diagram tříd)
- Konektory
    - komunikační styly
    - procesní (dynamický) model
    - používají se sekvenční diagramy, ale i diagram aktivit nebo komunikační
- Nasazení
    - mapování na hw/sw zdroje
    - definuje strukturu zdrojů systému
    - diagram nasazení


#### Architektonické návrhy
- Vrstvená architektura
    - napr. datová, aplikační a prezentační vrstva
    - ![](https://i.imgur.com/OVBoocC.png)


- Model-View-Controller MVC
    - celý systém je dekomponován na 3 moduly
    - Model = funkcionalita
    - View = prezentácia (GUI)
    - Controller = preberá vstupy od používateľa
    - ![image](https://hackmd.io/_uploads/SJjH9SOO6.png)


- Model-View-Presenter MVP
    - variace MVC pro widgetové systémy
    - používateľ nepracuje s Controllerom, iba s View
    - presenter má za úlohu manipulovať Model aj updatovať View
    - ![](https://i.imgur.com/3M8Ymw6.png)

- Model-View-ViewModel MVVM
    - View nepristupuje k Modelu priamo
    - PresentationModel (ViewModel) je zodpovedný za poskytovanie funkcií pre View, a manipulovanie Modelu
    - ![](https://i.imgur.com/8fYLX3E.png)


- Ďalšie
    - **mikrokernel (Linux)** - 
        - kde jadro (kernel) je redukované na minimálnu funkcionalitu - hlavnou úlohou je poskytovať základné operačné služby, ako sú správa pamäte, plánovač procesov a komunikačné mechanizmy. 
        - funkcionalita je potom rozsirovatelna pluginmi
    - **peer to peer (Skype)**
        - v ktorej každý počítač alebo uzol (peer) má rovnakú úroveň zodpovednosti a môže fungovať ako poskytovateľ aj príjemca zdrojov. 
        - umožňuje priamy výmenu informácií a služieb medzi jednotlivými uzlami bez centrálnej autority, čo zvyšuje odolnosť systému a umožňuje lepšie škálovanie.
    - **broker (CORBA)**
        - existuje centrálny prostredník (broker), ktorý zabezpečuje komunikáciu medzi  komponentami systému. 
        - Tieto komponenty môžu byť izolované a nezávislé, pričom 
    - **pipes and filters (streamy dát, UNIX)**
        - systém je rozdelený na sériu nezávislých komponentov, nazývaných filtre, ktoré sú spojené pomocou kanálov, nazývaných rúr (pipes). 
        - každý filter vykonáva špecifickú úlohu na vstupných dátach a prenáša výsledky na ďalší filter cez rúry. Táto architektúra podporuje modulárny a znovupoužiteľný dizajn systému.
    - **Mikroslužby (Microservices)** 
        - rozdeluje aplikáciu na malé, nezávislé a samostatne nasaditeľné služby. 
        - Každá mikroslužba má jasnú funkciu a môže byť vyvíjaná, nasadzovaná a škálovaná nezávisle.


#### Architektonické styly
Sumarizujú architektonické princípy, ktoré sú aplikovateľné pre konkrétny systém a kontext, a zabezpečujú istú úroveň kvality SW 
- objektovo orientovaný štýl - Tento štýl sa zameriava na reprezentáciu systému ako kolekcie objektov, ktoré majú svoje vlastnosti a metódy na manipuláciu s nimi. Každý objekt má svoj stav a môže komunikovať s inými objektami.
- message delivery - Tento štýl sa často využíva v systémoch, kde komunikácia medzi komponentami alebo službami je základným prvkom. Princípom je posielanie správ medzi komponentami, ktoré môžu obsahovať informácie alebo inštrukcie.
- publish/subscribe - Ide o štýl, v ktorom vydavateľ (publisher) posiela správy, ktoré sú prijímané odberateľmi (subscribers). Vydavateľ nevie, kto všetko konkrétne správu prijme, ale odberatelia môžu byť informovaní o udalostiach, na ktoré sa chcú prihlásiť.

**Postavení architektonických stylů/vzorů**
- návrhové vzory - obecná řešení problémů při návrhu kódu
- architektonické vzory - obecná řešení problémů při návrhu architektury
- architektonické styly - průřezové architektonické principy s vlivem na kód
- doménově specifické softwarové architektury - předpisy kompletních struktur aplikací dle zvolené domény


## Rozhraní komponent

### Rozhraní
- poskytuje kontrakt (omezení na použití služeb) s okolním světem
- skládá se z operací (funkcionalta) a vstupních/výstupních parametrů (signatura)
- musí být velmi dobře dokumentovaná
- musí byť ľahko dostupné (zvyčajne public)
    - "Need to know princíp" - public informácie sú iba tie, ktoré sú potrebné, ostatné private

### Stereotyp \<\<interface>>
- dva pohledy na věc – někdo to implementuje a někdo to používá
    - jedno rozhraní může být implementováno více třídami
    - jedna třída může implementovat více rozhraní
- ![](https://i.imgur.com/dYGldvS.png)  –  poskytované rozhranie (realization)
- ![](https://i.imgur.com/rHW4D3l.png) – vyžadované rozhranie (dependency)
- 2 notace zobrazování, viz. obrázek:

![](https://i.imgur.com/zo1QbIW.png)

Viditelnost operací a atributů v UML:
- public (+) – jsou veřejné, metody předepsané rozhraním
- private (-) – dostupné pouze dané třídě (podtřída nemá přístup)
- protected (#) – dědí se, ale cizímu kódu není přístupné
- package (~) – atribut nebo metoda je viditelná pro kód ve stejném balíku

#### OO(object-oriented) kontrakt
- Kontrakt - Právní dohoda mezi dvěma stranami, ve které obě strany přijímají povinnosti a na základě které mohou obě strany uplatňovat svá práva.
- zabezpečuje aby mali poskytovateľ a volajúci rovnaké informácie o triede/komponente/subsystéme
- Při formulaci služeb pro nový (pod)systém se zaměřte na explicitní specifikaci:
    - podmínek / omezení, za kterých bude služba poskytována
    - výsledku poskytované služby
- 3 typy podmínek
    - invariant
        - musí byť pravdivý pre všetky inštancie triedy/komponenty
    - preconditions
        - musí byť pravdivý pred zahájením operácie
    - postconditions
        - musí byť pravdivý po skončení operácie
- OO kontrakty sa modelujú za pomoci OCL (Object Constraint Language), popísané nižšie v samostatnej kapitole



#### Distribuované počítání
- chci, aby komponenty/služby, běžely na různých pc, ale aby komunikovaly mezi s sebou
- zvyčajne komunikácia cez middleware

##### CORBA (Common Object Request Broker Architecture)
- ORB (Object Request Broker)
    - definuje middleware pro komunikaci aplikacemi 
        - lokalizovat vzdálené objekty
        - aktivovat vzdálené objekty
        - komunikovat request objektu
        - komunikovat response volajícimu
- CORBA IDL
    - deklaruje data members, metódy a parametre
    - má vlastné typy
    - dá sa namapovať na programovacie jazyky (C, C++, Java) pomocou interface compilers
    - Lze definovat vlastní typy, datové položky (attribute), readonly atributy, konstanty


## Signatury a omezující podmínky služeb - OCL

### OCL (Object Constraint Language)
- deklaratívny striktně typovaný jazyk (nelze porovnat Integer a String)
- UML samotné nestačí, potreba jazyka pre pomoc so špecifikáciou a sémantikou UML
- může být napojen na jakýkoli model v UML
- má explicitne definovanou sémantiku a viac precíznu
- přináší lepší dokumentaci (používa sa na dokumentovanie UML modelov)
- má preddefinované základné typy a kolekcie
- používá se na:
    - specifikaci invariantů pro třídy a typy (nadřízený musí být ve stejné firmě jako jeho zaměstnanec)
    - na specifikaci kontraktů u rozhraní (post a preconditions)
    - jako navigační jazyk (navigation through object links)
    - pro specifikace testů – definuju si, jak se ta třída má chovat a test to ověří
- každý klasifikátor (třídy, atributy) z UML se stává typem v OCL
- **constraints** sú obmezdenia na jednom alebo viacerých hodnotách OOP systému
    - invariant
    - precondition
    - postcondition
- **context** prepája OCL constraint so špecifickým elementom (trieda, interface...) UML modelu

#### Podmínky (invarianty)
- invariant je constraint - boolean výraz, ktorý musí byť true počas celého životného cyklu objektu
- kontext – ke kterému prvku kterého modelu se ten invariant vztahuje, většinou bývá v závorce: context (Třída)
- self – odkazujeme se na sebe sama
- mohou mít nějaké jméno, za slovíčkem invariant nebo inv.
- v invariantu můžeme volat operace definované na dané třídě
- vždy se odkazujeme na tu druhou třídu přes její roli v dané asociaci
- asociační třída – nemá žádnou roli, pak použijeme malé písmena v odkazu
- napr. `context Flight inv flightDuration: duration < 4`

#### Preconditions
- musí byť true pred spustením operácie
    - `context Flight::shiftDeparture (t:Integer) pre: t>0`
    - shiftDeparture je metóda triedy Flight
    - departureTime je atribút


#### Postconditions
- musí byť true po dokončení operácie
    - `context Flight::shiftDeparture (t:Integer):Time post: result = departureTime + t`
- @pre označuje hodnotu daného atribútu pred spustením operácie
    - `context Flight::shiftDeparture (t:Integer):Time post:result = departureTime@pre + t + duration`

#### Dedičnosť constraintov
Invariant
- invariant je vždy zdedený z parenttriedy
- podtriedy môžu invariant iba posilniť, nie oslabiť
    - `context Flight inv: duration < 4`
    - `context JetFlight inv: duration < 2`

Precondition
- podtriedy môžu precondition iba oslabiť (**contravariance**)
    - `context SuperClass::foo(i : Integer) pre: i > 1000`
    - `context SubClass::foo(i : Integer) pre: i > 0`
    - OK, pretože podtrieda vie stále spracovať všetky vstupy, ktoré vie spracovať parent trieda

Postcondition
- podtriedy môžu invariant iba posilniť (**covariance**)
    - `context SuperClass::foo() : Integer post: result > 0`
    - `context SubClass::foo() : Integer post: result > 1000`
    - OK, pretože volajúci dostane vždy výsledok > 0


### elementy OCL vyrazov
Basic types:
- Boolean (true, false),
    - ops: and, or, xor, not, implies, if … then … else … endif
- Integer (1, -5, 2, 34, 26524, …),
    - ops: *, +, -, /, abs
- Real (1.5, 3.14, …),
    - ops: *, +, -, /, floor
- String ('To be or not to be...’),
    - ops: toUpper, concat, …
- Asociace z UML modelov

### Kolekce (Collections)
- na druhé straně asociace nemusí být jen jedna instance, ale celá kolekce (aerolinky provozují více letů, dotaz na flights vyhodí množinu destinací)
- 3 typy kolekcí
    - Set – neuspořádaná množina, bez duplicit (příchozí lety)
    - Bag – neuspořádaná množina, s duplicitami (jména všech pasažérů všech letů)
    - Sequence – uspořádaná množina, s duplicitami (všichni pasažéři v daném letu)



#### Operace s kolekcemi
![](https://i.imgur.com/SW9f9Ss.png)
*k tomuto modelu sa vzťahujú príklady*

- Collect
    - vybere z kolekce ty typy informací, které odpovídají danému výrazu
    - projekce v relační algebře
    - `contextAirport inv: self.arrivingFlights -> collect(airline) -> notEmpty`
- Select
    - výběr takových prvků kolekce, které splňují danou podmínku
    - `contextAirport inv: self.departingFlights -> select(duration < 4) -> notEmpty`
    - reject – opak selectu, ty, které nesplňují podmínku
- For All
    - něco prohlašuje o všech prvcích kolekce
    - lze porovnávat i více prvků v množině mezi sebou
    - `contextAirport inv: self.departingFlights -> forAll(departTime.hour > 6)`
- Exist
    - musí existovat alespoň jeden prvek v kolekci, který splňuje daný výraz
    - `contextAirport inv: self.departingFlights -> exists(departTime.hour < 6)`
- Iterate
    - umožňuje iterovat přes prvky kolekce
    - ![](https://i.imgur.com/Er3Cfu0.png)

- Další operace
    - isEmpty, size, sum, asSet(převod na množinu-bez duplicit),intersection, union, first

#### Pokročilé OCL výrazy
- oclInState()
    - vráti true, ak je objekt v danom stave
    - ![](https://i.imgur.com/IFHlloI.png)
- Lokální proměnné
    - hodnoty si lze ukládat do lokál ních proměnných, pomocí výrazu let
    - ![](https://i.imgur.com/ZcsT2X9.png)

## Komponentové systémy a modely

### Komponenty
- „Spustitelná“ jednotka běžící v middleware.
- Typicky složená z mnoha objektů/tříd (hierarchicky).
- Nepřímá komunikace pomocí rozhraní (konektory).
- Dobře definovaná složitá rozhraní/smlouvy (IDL)
- Bez viditelného zdrojového kódu (černá skříňka/šedá skříňka).
    - Pohled černé skříňky = pouze dobře zdokumentovaná rozhraní.
    - Pohled šedé skříňky = dobře zdokumentovaná rozhraní + přehled vnitřní architektury.
- Vyvíjeny nezávisle na ostatních komponentách.
- Složitý životní cyklus: specifikace komponent a rozhraní, implementace, sestavení komponent, nasazení, instancování,
- sú znovupoužiteľné (reusability), ľahko vymeniteľné (replaceability)

### Komponentové systémy
- rychlé sestavení celku bez znalosti vnitřního fungování jednotlivých komponent
- softwarová komponenta - znovupoužitelný druh sw, zapouzdřený, s co nejméně závislostmi, s jasným cílem

#### Odlišnost komponenty od třídy

|komponenta|trieda|
|----------|--------| 
|spustitelná běhová jednotka (jako prográmek)|třída má seznam metod, které poskytuje
|vstupní a výstupní parametry|poskytuje jednu ci více rozhraní
|složena z mnoha podkomponent (tříd, objektů)|třída už je ta malá část komponenty
|nemá viditelný zdrojový kód|viditelný zdrojový kód
|vyvinuta odděleně od ostatních|navržena pro konkrétní systém
|zasazení do kontextu a až poté kompilace|kompilace a až pak zasazení do kontextu
 
#### Příklady zajímavých problémů řešených v komponentových systémech
- **Instanciovatelnost a replikace komponent** - kam zasadit novou komponentu
- **Interoperabilita** - vzájemná kompatibilita komunikujících komponent (málokdy se stane, že komponenty sedí 1:1)
- **Nahraditelnost komponenty** - otázka korektnosti nahrazení stávající komponenty novou (rekonfigurace systému)
- **Middleware pro komponentové systém** - komponenta běží v middlewaru (J2EE, .NET)

### Komponentový model
- definuje špecifikú reprezentáciu, interakciu, kompozíciu a iné **štandardy** SW komponent
- komerční
    - vznikly proto, aby mohly vznikat komerční aplikace tím, že skládám komponenty do sebe a mohu dále prodávat zákazníkům
    - CORBA, EJB/J2EE, COM/.NET
    - jednoduché, ale nic moc neumí
- akademické
    - Fractal, KobrA, PCM, Koala
    - slouží akademické sféře
    - spíše experimentální, než přímo využitelné pro zákazníka

#### Komponentové frameworky
- SW entity, ktoré prepájajú komponenty (splňujúce určené štandardy)
- konkrétny middleware, runtime environment
- napr. J2EE Glassfish

### Component diagram
![](https://i.imgur.com/ud4pgiq.png)

- 6 prvků
    - Interface
        - rozhraní komponenty, kolekce operací, které specifikují služby
    - Component 
        - za běhu systému vyměnitelná část
    - Port 
        - identifikují místa, na která se můžeme připojovat
        - pokud chci, aby komponenta rozlišovala mezi dvěma různými službami (lístky pro VIP a normální zákazníky) je potřeba využít porty
        - seskupuji do nich poskytovaná/požadovaná rozhraní
        - měly by mít unikátní jméno
        - mohou mít násobnost – kolik klientů naráz se může připojit
        - lze mít více portů na jedno rozhraní
        - interaguje se jen přes ně
    - Internal structure 
        - lze se dívat na vnitřní strukturu
        - uvnitř jedné komponenty lze modelovat další
    - Part 
        - části vnitřní struktury
        - části komponenty
        - mají jméno a typ
        - mohou mít kardinalitu
        - mohou být stejného typu
    - Connector 
        - komunikace mezi 2 parts nebo ports
        - konektory slouží k propojení rozhraní
        - několik typů
            - přes rozhraní
            - přímý konektor
            - delegation connector – co z vnitřního světa propaguji ven

### Delenie komponent (v modeloch)
- rozdíl, zda model vnímá komponentu jako run-time jednotku nebo design-time
    - **run-time**: většinou komerční, zkompilovatelná část, která vytváří instance, nabízí rozhraní, skládá to dohromady, COM/.NET
    - **design-time**: formální model, zkoumá model bez kódu, PCM, KobrA
- dynamický x statický prvek
    - **dynamický**: možnost vytváření instancí za běhu
    - **statický**: komponenty pevně dané
- stavový x bezstavový
    - **stavový**: mění své chování podle historie
    - **bezstavový**: stále se chová stejně, nelze uložit data mezi transakcemi

#### Skládání komponent
- synchronně x asynchronně
    - **synchronně**: zavolám službu a čekám na výsledek
    - **asynchronně**: vyvolám službu, dělám další věci a až dostanu odpověď, tak dál zpracuju
- jednoúrovňové x víceúrovňové
    - **jednoúrovňové**: síť bez hierarchie
    - **víceúrovňové**: hierarchie
- jednoduché x násobné propojení mezi komponentami

### Lifecycle komponent
![](https://i.imgur.com/AO0wnfu.png)

- Component specification
    - popisuje správanie component 
- Component interface
    - definícia množiny správaní, ktoré sú ponúkané komponentou
    - podporujú zameniteľnosť (replaceability)
    - redukujú dopady zmien (vďaka oddelenej špecifikácie od implementácie)
- Component implementation
    - realizácia Component specification
    - samostatne nasaditeľná na runtime environment
- Installed component
    - komponenta nainštalovaná na runtime environment
- Component object
    - inštancia Installed Componentu
    - runtime concept (objekt so svojími dátami a identitou)


### Komponentový vývoj
- 4 fáze 
    - vývoj komponent
    - sestavování systému
    - nasazování
    - ohodnocení
- fáze probíhají nezávisle

![](https://i.imgur.com/T1DDlhq.png)

#### Komponentový vývojář 
- implementace a dokumentace jednotlivých komponent (zejména jejich rozhraní a omezení na komunikaci skrz ně)
- aktivity, state, class diagrams


#### Softwarový architekt
- sestavení komponent do celkového systému na základě popisu jejich rozhraní
- specifikace vnějších rozhraní systému (pro komunikaci s uživateli i externími systémy) delegací vnitřních rozhraní
- component diagram

#### Expert pro nasazení systému (Deployer)
- návrh fyzické architektury systému
- mapování softwarových komponent na fyzicke zdroje
- deployment diagram

#### Doménový expert (Domain Expert)
- vyjasnění očekávaných scénářů používání systému
- specifikace sekvencí volání systému, očekávaných argumentů těchto volání


## Kvalitativní aspekty služeb (QoS)
- Cieľom je garantovať SW a service kvalitu.
- Kvôli SLA
    - formální smlouva mezi zákazníkem a poskytovatelem služby
    - popisuje poskytované služby, priority, zodpovednosti, garancie a záruky
    - špecifikuje miery dostupnosti, výkonnosti, účtovania...
    - zákazník platí za službu, preto dožaduje isté záruky
    - často obsahuje tresty/sankcie v prípade porušenia stanovenej zmluby
- závisí na:
    - implementaci služby (kód)
    - kvalitě externích služeb
    - zdrojích, na kterých je komponenta nasazena
    - způsobu použití služby
- typy z pohledu klienta služby:
    - pokud je celý kontext známý (máme uzavřený systém) – garantovaná doba odezvy, spolehlivost
    - část kontextu neznámá – Assume Guarantee, Parametrizovaná specifikace


##### Specifikace požadavků
- funkční
    - omezení kladené na funcionalitu systému
        - k provedení serviceA() by nemělo být třeba více než 10 dalších komponent.
        - každá otevřená transakce (služba poskytovaná jinou komponentou) by měla být zavřena před tím, než daná komponenta zahájí novou
- nefunkční
    - Definice omezení použitých technologií
        - Kompatibilita HW/SW,
        - Middlewarové systémy komponent,
    - garantovaná doba odezvy v X% případů
- extra-funkční požadavky
    - kvalitativní omezení kladená na implementaci
        - dostupnost X% v rámci každého měsíce

##### Kvalitativní atributy:
- týkají se extra-funkčních požadavků (co systém má splňovat)
    - **výkonnost**
        - veľká priepustnosť (throughput), rýchla odozva (response time), nízke náklady
    - **spolehlivost**
        - dostupnosť, robustnosť, beh bez chýb/výpadkov, schopnosť obnovenia zotavenia sa (recovery)
    - **bezpečnos**t
        - integrita, dôvernosť, dostupnosť
    - **škálovatelnost**
        - zaťaženie, súbežná komunikácia, data scaling
    - **udržovatelnost**
        - modifikovateľnosť, adaptabilita


##### Metody hodnocení kvality
- **monitorování a testování**
    - ověření kvality existujícího systému
    - levná a často používaná metoda
    - použitelné až po implementaci systému
    - výsledky nutno brát s rezervou, závisí na počtu testovacích běhů
- **predikce z modelu**
    - nutno mít k dispozici (zjednodušený) model systému (vytvářený a upřesňovaný v průběhu návrhu)
    - použitelné v průběhu celého procesu návrhu architektury
    - přesnost výsledků závisí na detailnosti modelu
- **formální verifikace**
    - nejdražší a nejpřesnější metoda
    - ověřováno na modelu vytvořeném speciálně za účelem verifikace (částečně možno generovat automaticky z kódu nebo návrhových modelů)
    - pro zaručení přesnosti nutno investovat nemalé úsilí vyladění modelu (a úrovně jeho detailu)

##### Taktiky ladění SA
- optimalizácia zvoleného kvalitatívneho atribútu tým, že upravíme architektúru
- metódy optimalizácie
    - **výkonnost**
        - minimalizovat počet adaptorů a wraperů
        - zjednodušit komunikaci skrz rozhraní
        - oddělit data od výpočtů
        - přehodnotit použití broadcast konektorů
        - nahradit synchronní komunikaci asynchronní kdekoli je to možné
        - alokovat často komunikující komponenty blízko sebe
    - **spolehlivost**
        - zkontrolovat externí závislosti komponent
        - vhodné chybové reportovací mechanismy
        - vyhnout se existenci kritických míst
        - integrovat do systému automatické zálohování kritické funkčnosti dat a mechanismy zotavení
    - **škálovatelnost**
        - zajistit každé komponentě dostatečnou integritu, jasně definovaný účel a srozumitelná rozhraní
        - distribuovat zdroje dat
        - eliminovat úzká místa systému (komponenty a konektory používané více klienty současně)
        - nasadit na vhodných místech paralelní zpracování
    - **udržovatelnost**
        - oddělit různé zodpovědnosti do různých komponent/sjednotit stejné zodpovědnosti do stejných komponent
        - vyčistit komponenty od operací souvisejících s interakcí, ne funkcionalitou
        - udržet komponenty malé a kompaktní
        - izolovat data od výpočtu

#### Typy špecifikácie kvality
- ak je celý kontext známy (uzavretý systém, známy profil použitia)
    - napr. garantovaný čas odozvy je 10ms v 99.9%
    - napr. spoľahlivosť (funkčnosť bez chyby) je 99.9% pre každé spustenie
- ak nie je celý kontext známy (rozhrania nezávislých komponent)
    - assume-guarantee špecifikácia (ak *context*, tak niečo garantujeme)
    - parametrická špecifikácia (neznáme sú v špecifikácii nahradené voľnými parametrami)


## Objektové metody vývoje softwaru

### Vodopád
- iterativní vývoj s jedinou operací
- inkrementální vývoj s jediným přírůstkem představujícím celý systém

### Iterativní vývoj
- iterativně = předělávat (udělám jednu věc a pak ji stále překopávám a vylepšuju)
- každá iterace obsahuje to, co obsahuje vodopád
- rychlejší dílčí výsledky
- rychlejší odhalení chyb

### Inkrementální vývoj
- inkrementálně = přidávat k
- u větších projektů
- pro každý přírůstek lze vybrat jinou metodiku
- nejdříve postavíme celý dům, v dalším inkrementu postavíme bazén a integrujeme
- výstupem je vždy hotový funkční systém
- jednotlivé inkrementy jen přidávají něco navíc, často jsou to další verze systému

#### Vlastnosti iterativního/inkrementálního vývoje
- automatické testování nového inkrementu
- refactoring
- průběžná integrace – automatický překlad kódu při uložení změn + automatické testování

### Agilní metody vývoje
- pravidla jsou zaměřena na spolupráci lidí v týmu
- metodika říká, kdo co dělá, jaké jsou návaznosti
- malé, ale výkonné týmy
- UML se používá jen jako doplněk, není tam podstatou modelování
- Implementace: Extreme Programming, Scrum, Feature Driven Development
- fixní čas a zdroje a proměnná funkcionalita

### Vývoj řízený modely (Model-driven)
- více seriózní
- metodiky založené na modelech, které určují, kdo má co dělat
- základem je UML
- fixní funkcionalita a proměnný čas a zdroje

## RUP (Rational Unified Process)
UP (Unified process)
- otvorený, generický koncept

RUP
- komerčná implementácia UP, rozširuje UP, rozdiely sú iba v detailoch
- proces RUP považujte za kostru, do které přidáváte a ze které odvozujete projektově specifickou, přizpůsobenou a podrobnou definici procesu

### Základné prvky RUP

Role, pracovník (worker)
- modeluje „kdo“ v procesu vývoje SW
- jednotlivec nebo tým
- worker v UP, role v RUP

Aktivita (activity)
- modeluje „co“ v procesu vývoje sw
- úkol v projektu vykonávaný jednotlivci nebo týmy
- mohou být dokomponovány na podrobnější úrovně

Artefakt (artifact)
- „co“ je výsledkem aktivit
- vstupy a výstupy projektu
- různé ikonky podle toho, co představují

Tok práce (workflow)
- „kdy“ v procesu vývoje
- sekvence aktivit vykonávaných pracovníky
- mohou být dekomponovány

### RUP cykly a fázy
RUP je známý svou strukturou zahrnující několik cyklů, které se skládají z iterací.

#### Cyklus 
- v každom cykle vznikne nová verzia systému (release)
- každý cyklus pozostáva zo 4 fáz
    - **Zahájenie (Inception)**
    - **Rozpracovanie (Elaboration)**
    - **Konštrukcia (Costruction)**
    - **Predanie (Transition)**
- každá fáza môže byť rozdelená do viacerých **iterácií**

#### Iterácia
- Během každého cyklu (Inception, Elaboration, Construction, Transition) se provádějí iterace.
- 3 aktivít
    - analýza (analysis)
    - návrh (design)
    - implementácia (implmenetation)

![](https://i.imgur.com/JHsXcn4.png)

### Fáze RUP cyklu
#### Zahájenie (inception)
- vytýčenie "business case" systému
    - kritériá úspechu systému
    - prvotné hodnotenie hrozieb (risk assesment)
    - odhady nákladov (cena, čas)
- odhad rozsahu systému

Výstupy
- prvotný use-case model a problem-domain model (10-20% hotový)
- popis účastníkov systému (actors)

Milestone
- definícia cieľov životného cyklu projektu

--- 
#### Rozpracovanie (Elaboration)
- analýza domény problému
- vytvorenie architetúry
- identifikácia problémových častí projektu
- vytvorenie celého projektového plánu

Výstupy
- use-case model a problem-domain model (80% hotový)
- vytvorená architektúra a jej dokumentácia
- dokončenie "business case", aj s hodnotením hrozieb (risk assesment)

Milestone
- architektúra celého životného cyklu

---
#### Konštrukcia (Costruction)
- inkrementálne vyvíja SW produkt (alebo jeho časť), tak aby ho bolo možné dodať zákazníkovi

Výstupy
- hotový use-case model a design model tried
- spustiteľná verzia produktu
- dokumentácia nasadzovania (deployment)
- update plánu vývoja

Milestone
- prvotný funkčný systém

---
#### Predanie (Transition)
- dodanie SW zákazníkovi

Výstupy
- otestovaná spustiteľná verzia
- update modelu systému
- vyhodnotenie kritérií pre každú iteráciu
- update dokumentácie

Milestone
- nová verzia (product release)

![](https://i.imgur.com/qwcUYX8.png)

### Workflows

**Requirements**
- nájsť aktorov a use cases
- detailne modelovať use case

![](https://i.imgur.com/FTO2L8n.png)

**Analysis**
- modely tříd
- používají se analytické vzory
- sekvenční diagramy

![](https://i.imgur.com/RzY6uPa.png)

**Design**
- detailní model
- návrhové vzory
- upřesnění analytických vztahů

![](https://i.imgur.com/qSMe6nf.png)

**Implementation**
- implementace, testování a rozmístění komponent
- integrace částí systému

![](https://i.imgur.com/e9AxWed.png)

#### Modely k jednotlivým workflowom

![](https://i.imgur.com/mD0PlqT.png)
![](https://i.imgur.com/3U01qQl.png)
![](https://i.imgur.com/kdclWJa.png)
![](https://i.imgur.com/NKs7aXo.png)



