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
2. Structural patterns
   • oddeľujú rozhrania od implementácie
   • kompozície tried do hierarchií
   • dedičnosť
3. 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

OOP konkrakt

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