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

> Zdroje:
> - https://drive.google.com/file/d/0B1LjyXWQHazOWm5XaEFWeUhjX1U/view?usp=sharing
> - https://is.muni.cz/auth/el/fi/podzim2019/PA103/um/

## 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
- kniha - *Gang of Four (**GoF**)*: Design Patterns: Elements of Reusable Object Oriented Software

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


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


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


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


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


#### 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*

*object adapter*

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


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


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


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


> 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


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


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


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


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


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


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


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


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


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


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


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


#### 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ů


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


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


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


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


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


### Vzory na měření ve finančnictví

#### Enterprise Segment
- společnost si uspořádáme do několika hierarchií (dimenzí) z různých pohledů


#### Další vzory
- Measurement Protocol
- Range
- Phenomenon with Range

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


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


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


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


## 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é vzory:**
Generické znovupoužiteľné riešenia návrhu architektúry, parametrizované podľa kontextu SW

- Vrstvená architektura
- napr. datová, aplikační a prezentační vrstva
- 

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

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

- Model-View-ViewModel MVVM
- View nepristupuje k Modelu priamo
- PresentationModel (ViewModel) je zodpovedný za poskytovanie funkcií pre View, a manipulovanie Modelu
- 

- Ďalšie
- mikrokernel (Linux)
- peer to peer (Skype)
- broker (CORBA)
- pipes and filters (streamy dát, UNIX)
- blackboard (ukladá dáta centrálne, do ktorých zapisujú a čítajú viaceré zdroje)

**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
- message delivery
- publish/subscribe

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

#### Ohodnocení SW architektury
##### Specifikace požadavků
- funkční a nefunkční (extrafunkční) požadavky
- 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
- komponenta nesmí být zablokována při provádění žádné ze svých služeb (z důvodu čekání na výsledek volání jiné komponenty)
- nefunkční (extra-funkční) požadavky
- omezení na způsob, jakým je systém implementován a realizuje svou funkcionalitu
- garantovaná doba odezvy v X% případů
- dostupnost X% v rámci každého měsíce
- kompatibilita softwaru/hardwaru

##### Kvalitativní atributy SA:
- 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čnost
- 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
- promítnutí stavu komponent ven a definovat invarianty stavu
- vhodné chybové reportovací mechanismy
- integrovat kontrolu spolehlivosti komponent do konektorů
- 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
- identifikovat data, která bude vhodné replikovat
- zajistit každému konektoru dostatečnou integritu a jasně definovaný účel
- zvážit nahrazení přímých závislostí nepřímými
- 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

## Rozhraní komponent

### Rozhraní
- kontrakt (omezení na použití služeb) s okolním světem
- skládá se z operací 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
- špecifikuje kontrakt (obmedzenia na použitie)

### Kontrakt
- smlouva, kde někdo slibuje, že bude poskytovat služby, za dodržania stanovených podmienok
- pro každou službu nutné definovat podmínky, za kterých služba bude poskytována
- a také výsledky, které to bude dávat, za předpokladu, že se zákazník chová podle podmínek

#### OO(object-oriented) kontrakt
- zabezpečuje aby mali poskytovateľ a volajúci rovnaké informácie o triede/komponente/subsystéme
- přesná specifikace rozhraní (conditions, result)
- 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

### Stereotyp \<\<interface>>
- stereotyp je obecný princip jak předat nebo upřesnit sémantiku nějakým předdefinovaným prvkům v UML jazyce
- seznam služeb (vývěsní štít)
- 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í
-  – poskytované rozhranie (realization)
-  – vyžadované rozhranie (dependency)
- 2 notace zobrazování, viz. obrázek:


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

### IDL Interface Description Language
- jazyk špecifikácie, k popisu služeb softwaru
- umožňuje definovat kontrakt
- není to programovací jazyk, ale popisovací
- není součástí UML

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

#### Webové služby
SW zabezpečujúci machine-to-machine komunikáciu cez sieť. Poskytuje interface popísané v machine-readable formáte (**WSDL**). Iné systémy komunikujú s WS podľa predpísaného WSDL, použitím **SOAP** správ, zväčša cez HTTP protokol a za pomoci **XML** serializácie.

- **XML** - formát správ
- **SOAP** (Simple Object Acces Protocol) – komunikační protokol pre prenos správ
- **WSDL** (Web Services Description Language) – jazyk pro popis služeb, založen na XML, generován automaticky, interface description, dá sa prekonvertovať z IDL
- **UDDI** (Universal Description, Discovery and Integration) – umožňuje hledat a publikovat služby

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

### OCL (Object Constraint Language)
- deklaratívny jazyk
- UML samotné nestačí, potreba jazyka pre pomoc so špecifikáciou a sémantikou UML
- přináší lepší dokumentaci (používa sa na dokumentovanie UML modelov)
- má jasně definovanou sémantiku
- nemá side-effects (ukládání hodnot atd)
- 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ěří
- může být napojen na jakýkoli model v UML
- striktně typovaný jazyk (nelze porovnat Integer a String)
- každý klasifikátor (třídy, atributy) z UML se stává typem v OCL
- má preddefinované základné typy a kolekcie
- **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 jakoby 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 spustení 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

### 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
*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
- 

- 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
- 
- Lokální proměnné
- hodnoty si lze ukládat do lokál ních proměnných, pomocí výrazu let
- 
- oclType: typ objektu self
- oclTypeOf(t): true ak self a t sú rovnakého typu
- oclIsKindOf(t): true ak self a t sú rovnakého typu, alebo t je super-type self

## Komponentové systémy a modely

### Komponenty
- zapouzdřují části systému
- redukují závislosti
- vytváří explicitní závislosti
- může poskytovat více rozhraní, ale i jedno ve více variantách
- 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
- jsou konkrétní realizací sw architektur
- společné s HW komponentami
- zapouzdření
- rozhraní a služby na nich
- anonymita klienta i serveru – komponenta se musí dát použít i jinde
- připravenost k okamžitému použití – komponenty jsou předkompilované
- black-box znovupoužitelnost
- snadná vyměnitelnost – za běhu programu ji lze vyměnit
- jazyková nezávislost – jedno kde to vyrobili a v jakém jazyce
- odlišné vlastnosti s HW komponentami
- hierarchická struktura
- instanciovatelnost – možnost klonovat
- dynamičnost – přidávat odebírat za běhu
- vysoká míra složitosti a variability –
- vliv fyzických zdrojů
- silná závislost na vnitřním stavu – komponenty jsou stavové, odlišné chování v závislosti na historii
- závislost na běhovém prostředí – middlewaru

#### Odlišnost komponenty od třídy
- komponenta
- spustitelná běhová jednotka (jako prográmek)
- může mít více rozhraní
- složena z mnoha podkomponent (tříd, objektů)
- nemá viditelný zdrojový kód
- vyvinuta odděleně od ostatních
- zasazení do kontextu a až poté kompilace
- třída
- třída má seznam metod, které poskytuje
- vstupní a výstupní parametry
- třída už je ta malá část komponenty
- viditelný zdrojový kód
- navržena pro konkrétní systém
- 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)
- kompatibilita typů v signatuře volajícího (např. int) a volaného (např. real)
- generování a použití adaptorů a wrapperů
- Nahraditelnost komponenty
- otázka korektnosti nahrazení stávající komponenty novou (rekonfigurace systému)
- nová komponenta by neměla
- požadovat více
- nabízet méně
- Middleware pro komponentové systémy
- komponenta běží v middlewaru (J2EE, .NET)
- middleware poskytuje běhové prostředí

### Component diagram

- 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
- když vznikne instance komponenty, vzniknou i porty
- 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

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

#### Co se rozumí komponentou
- 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
- zda komponenta umožňuje signatury, protokoly, vstupní/výstupní podmínky, popis chování

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

#### Specifikace komponent

- Component specification
- popisuje správanie množiny komponent ako inštancií
- 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
- business pohled – mám několik fází vývoje
- knihovna komponent – urychlení vývoje a snížení rizika
- znovupoužitelnost komponent – nižší náklady, vyšší kvalita
- udržovatelnost – srozumitelnost, konfigurovatelnost, jazyková nezávislost, flexibilita, snadná výměna
- 4 fáze
- vývoj komponent
- sestavování systému
- nasazování
- ohodnocení
- fáze probíhají nezávisle


#### Komponentový vývojář
- implementace a dokumentace jednotlivých komponent (zejména jejich rozhraní a omezení na komunikaci skrz ně)
- model: specifikace komponenty
- UML: diagram tříd/objektů, komponentový diagram
- v obou případech: interakční diagramy, diagram aktivit, stavové diagramy

#### 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í
- dokumentace použitých konektorů
- model: model sestavení systému
- UML: komponentový diagram, sekvenční diagramy

#### Expert pro nasazení systému (Deployer)
- volba fyzických zdrojů (včetně jejich parametrů)
- návrh fyzické architektury systému
- mapování softwarových komponent na zvolené zdroje
- model: model nasazení systému
- UML: diagram nasazení

#### 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í
- odhadnutí očekávaného počtu souběžných uživatelů
- model: Model používání systému
- UML: sekvenční diagram

#### QoS analytik (QoS Analyst)
- otestovat systém, jak je kvalitní, rychlý
- volba kvalitativních atributů k ohodnocení
- provedení analýzy – ohodnocení jednotlivých kvalitativních kritérií celkové architektury na základě modelů dodaných všemi rolemi
- interpretace výsledků – impuls k modifikaci architektury
- model: model ohodnocení kvality služeb

## Kvalitativní aspekty služeb (QoS)
- říkám něco o kvalitě služby
- garantovaná kvalita služby
- vyjádřeno pro každý sledovaný kvalitativní atribut
- 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
- kvality z pohledu architekta - neváží se na konkrétní službu, ale na zdroje systému, komponenty nebo systém jako celek

### Service Level Agreement 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

### QoS špecifikácia
Perspektíva **klienta**
- 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)

Perspektíva **architekta**
- špecifikácie nie sú asociované s konkrétnymi službami, ale so systémovými zdrojmi, komponentami celým systémom
- napr. zataženie CPU nepresiahne 90%
- konkrétne CPU bude dostupné 99.9% času

## 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
- rodina se nastěhuje a provizorně bydlí, za provozu užívá systém a zároveň se na něm pracuje a vylepšuje
- rychlejší dílčí výsledky
- rychlejší odhalení chyb

### Inkrementální vývoj
- inkrementálně = přidávat k
- vyvíjíme funkcionalitu nezávisle na předchozím a pak se ji snažím integrovat do stávajícího systému
- 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, většinou dvojice (jeden sedí u pc a kóduje, druhý čte dokumentaci, pak se vymění atd)
- spíše menší projekty na zakázku
- 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
**Cyklus**
- inkrement
- 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**
- každá pochádza z 3 aktivít
- analýza (analysis)
- návrh (design)
- implementácia (implmenetation)
- v každej iterácii vzniká nová verzia systému (release), môže byť externá alebo interná


#### 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
- vyhodnotenie kritérií pre každú iteráciu

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)


### Workflows

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


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


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


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


#### Modely k jednotlivým workflowom