Arlow Jim, Neustadt Ila: UML 2 a unifikovaný proces vývoje aplikací

Požadavky

• Dva způsoby zachycení požadavků: 1) funkční + nefunkční požadavky, 2) jako případy užití a aktéři (tzn. model případů užití už při sběru požadavků, ne až v pozdějších fázích upřesňování a vizualizací).
• Specifikace systémových požadavků zahrnuje jak funkční požadavky (požadovaná služba), tak nefunkční požadavky (vlastnosti a omezení).
• Techniky hledání požadavků: pohovory, dotazníky, dílny.
• Klíčové aktivity metodiky UP: 1) nalezení aktérů a případů užití, 2) detail případu užití.
• Případy užití jsou funkce, které systém vykonává jménem jednotlivých aktérů (tj. iniciátorů těchto funkcí) nebo v jejich prospěch.
• Požadavky v modelu požadavků mohou být k případům užití sledovány pomocí matice sledovatelnosti požadavků, tedy propojením dvou databází funkčních požadavků – SRS s množinou případů užití.
• Doporučení pro psaní případů užití: 1) stručně a jednoduše; 2) důležité je CO, nikoliv JAK; 3) vyhýbat se funkční dekompozici.

Analýza

• Analýza spočívá v tvorbě modelů, které zachycují podstatné požadavky a charakteristické rysy požadovaného systému.
• Charakteristiky dobrého analytického modelu: 1) je vždy vytvořen v jazyku dané problémové domény; 2) zachycuje problém z určité perspektivy; 3) obsahuje artefakty, jež modelují problémovou doménu; 4) vypráví příběh o požadovaném systému; 5) je užitečný pro maximální počet uživatelů a zúčastněných osob.
• Artefakty analýzy – metamodel: 1) analytické třídy s klíčovými pojmy business domény; 2) realizace případů užití (= vzájemná komunikace analytických tříd realizujících chování systému specifikované případem užití).

Třídy a objekty

• Analytický model středně velkého systému obvykle obsahuje přibližně 50-100 tříd.
• Objekty jsou soudržné jednotky, v nichž se snoubí data s funkčností. Každý objekt je instancí přesně jedné třídy.
• Třída definuje společné vlastnosti (atributy, operace, metody, relace, chování) sdílené všemi objekty dané třídy, je vysoce soudržná (= vše podporuje jeden určený účel).
• Operace jsou abstraktní specifikace pro funkce objektu vytvořené během analýzy, zatímco metody jsou konkrétní specifikace funkcí objektu vytvořených v etapě návrhu. (Během analýzy jsou služby modelovány jako množina operací, v etapě návrhu jako množina metod.)
• Konstruktory představují speciální metody ve většině OOP, které vytvářejí nové objekty, mají platnost třídy (patří třídě). Stejně tak se mohou pro vymazání objektů z operační paměti volat speciální metody nazývané destruktory.
• Výstupem analýzy případů užití jsou analytické třídy a realizace případů užití.

Analytické třídy

• Analytické třídy obsahují množinu hlavních kandidátních atributů a množinu hlavních operací.
• Podle čeho poznáme dobrou analytickou třídu? – V názvu se zrcadlí její účel, je výlučným zobecněním (jedním specifickým prvkem domény), je mapována na jasně danou vlastnost problémové domény, má svou vlastní množinu odpovědností.
• Podle čeho poznáme špatnou analytickou třídu? – Je to funktoid (třída s jedinou operací), je “všemohoucí” (tzv. děvečka pro všechno, obvykle s hodně obecným a nic neříkajícím názvem), obsahuje široce rozvětvený strom dědičnosti, je málo soudržná, má úzké vazby na mnoho dalších tříd.
• Analýza podstatných jmen a sloves (technika hledání analytických tříd): podstatná jména a spojení podstatných jmen na třídy a atributy, slovesa a slovesné fráze na odpovědnosti a operace.
• Metoda štítků CRC (technika hledání analytických tříd): důležité předměty problémové domény zapisují členové týmu na lístečky, které jsou rozděleny na tři oddíly – C (classes, obsahuje název třídy), R (responsibilities, obsahuje seznam odpovědností), C (collaborators, obsahuje seznam dalších spolupracujících tříd).

Relace

• Objekty uskutečňují chování modelovaného systému díky vzájemné spolupráci, která spočívá v předávání zpráv prostřednictvím spojení. Tato spojení, asociace, jsou sémantickými vazbami mezi třídami.
• Násobnost vazeb označuje interval objektů, které lze zahrnout do relace v určitém okamžiku.
• Závislosti jsou relacemi, v nichž se změna v dodavateli automaticky projeví i v klientovi, klient je určitým způsobem na dodavateli závislý.

Dědičnost a polymorfismus

• Zobecnění je relace mezi obecnějším a přesněji specifikovaným, přičemž zákon o nahraditelnosti říká, že obecnější předmět lze vždy nahradit konkrétnějším typem.
• Abstraktní operace nemá implementaci (je příliš abstraktní na to, aby byla uchopitelná v jakékoli konkrétní implementaci). Abstraktní třída obsahuje alespoň jednu abstraktní operaci (?) a neumožňuje tvorbu svých instancí. Abstraktní nadtřída musí být implementována všemi svými potomky.
• Dědění od více předků (multiple inheritance) = v UML třída může mít více přímých předků. (Ze všech objektově orientovaných jazyků je však dědění od více předků možné pouze v C++.)
• Polymorfismus (mnohotvárnost) umožňuje návrh systému využívající abstraktní třídu, kterou pak za běhu programu nahradí jejími konkrétními potomky – takové systémy jsou flexibilní a snadno rozšiřitelné.
• Polymorfní operace mají více implementací – různé třídy mohou implementovat stejnou polymorfní operaci odlišným způsobem. Polymorfismus umožňuje instancím různých tříd reagovat na stejnou zprávu odlišným způsobem.
• Zobecňující množiny umožňují dělit potomky nadtřídy podle určitého pravidla.

Analytické balíčky

• Balíček je mechanismem UML pro seskupování významově příbuzných prvků, vytváří tak “sémantické hranice” uvnitř modelu.
• Balíček definuje zapouzdřený jmenný prostor, k použití prvku z jiného balíčku je třeba použít úplný název prvku (tj. celou jeho cestu).
• Jak hledat analytické balíčky? – Hledají se soudržné skupiny úzce souvisejících tříd a hierarchie dědičnosti.

Realizace případů užití

• Z hlediska analytického procesu je realizace případů užití zásadní součástí – ověřuje teorii v praxi. Explicitně znázorňuje spolupráci skupin objektů pro dosažení požadovaného chování systému (specifikované v případech užití). Tímto způsobem se převádí případ užití (tj. specifikace funkčního požadavku) na diagram tříd a interakcí (tj. vyšší stupeň specifikace systému). Realizace případů užití = popis spolupráce tříd pro dosažení požadovaného chování systému.
• Jedna realizace případu užití odpovídá přesně jednomu případu užití.
• Realizace případů užití je v podstatě proces upřesňování, může odhalit nové požadavky vztahující se k případu užití, které je třeba zachytit.
• Diagramy interakce: sekvenční diagramy (časová posloupnost odeslaných zpráv), komunikační diagramy (strukturální vztahy mezi objekty), zjednodušený diagram interakcí (vztahy mezi interakcemi), diagramy časování (časové aspekty interakcí).
• Realizace případů užití v etapě návrhu znamená seskupení návrhových tříd, rozhraní a komponent, navzájem spolu komunikujících za účelem zpřístupnění chování specifikovaného případem užití. Návrhové realizace případů užití se skládají z návrhových diagramů interakce a návrhových diagramů tříd, které jsou upřesněním analytických diagramů.

Diagramy aktivit

• Diagramy aktivit lze použít k modelování všech typů procesů (popř. je připojit k libovolnému modelovanému prvku), přičemž dobrý diagram aktivit popisuje jeden konkrétní aspekt chování systému.
• V UML 2 používají diagramy aktivit sémantiku Petriho sítí – aktivity jsou sítěmi uzlů spojených hranami.

Návrhové třídy

• Návrhové třídy = třídy, jejichž specifikace je již na takové úrovni, že je lze implementovat. Lze je získat z problémové domény (postupným upřesňováním analytických tříd) nebo z domény řešení (knihovny užitkových tříd, střední vrstvy, knihovny GUI, znovupoužitelné komponenty, implementační detaily).
• Návrhové třídy obsahují kompletní specifikaci: veškeré atributy (včetně názvu, typu, nepovinně implicitní hodnoty, typu viditelnosti), metody (název, názvy a typy všech argumentů, příp. hodnoty nepovinných argumentů, návratové typy, typ viditelnosti).
• Správně formulované návrhové třídy mají veřejné (exportované) metody, jsou úplné (poskytují vše, co se od nich čeká), dostatečné a soudržné (všechny metody realizují zamýšlený účel třídy), jednoduché (nedělitelnost a jedinečnost služeb třídy) a s minimem vazeb (při plnění toho, za co je třída zodpovědná, by měla být co nejvíc nezávislá na dalších třídách).

Upřesňování analytických relací

• Agregace a kompozice = relace typu celek/součást, kde objekty celku využívají služeb objektů součástí.
• Dva typy agregačních relací: agregace a kompoziční agregace (kompozice).
• Agregace je jako PC a jeho periférie – existuje zde jen velmi volná vazba, periférie lze připojovat/odpojovat a může je sdílet více PC, v podstatě nejsou “vlastněny” žádným konkrétním PC.
• Kompozice (skládání) je silnější vazbou agregace, lze ji přirovnat ke stromu a jeho listům – existuje zde silnější vazba, listy (součásti) patří pouze jednomu stromu (celku), který má výhradní odpovědnost za použití všech svých součástí, strom nemůže své listy zapůjčit jinému stromu, jakmile strom zemře, jeho listy umírají s ním. (Součást v kompozici je v podstatě ekvivalentem atributu, čili jsou-li součásti nedůležité/nezajímavé, je lepší ponechat je jako atributy.)
• Různé typy asociací: 1:1 (téměř vždy upřesnit do kompozice, nebo se může dát jako atribut či sloučit dvě třídy), M:1 (používat agregaci, kompozice je vyloučena), 1:N (kolekce).
• Kolekce = třídy, které se specializují na správu kolekcí jiných objektů.
• Některé čistě analytické relace je třeba uzpůsobit možné implementaci: asociace typu M:N (relaci nahradit třídou, čímž se redukuje na dvě asociace typu 1:N), obousměrné asociace (nahradit jednosměrnými asociacemi nebo kompozicemi, popř. závislostmi), třídy asociací (konkretizovat do normální třídy, její sémantiku vyjádřit asociací, agregací, kompozicí, případně závislostí, lze vložit i poznámku o omezení).
• Strukturovaná třída = třída s vnitřní strukturou, má dodatečné omezení (je kontejnerem všech svých součástí, konektorů a portů).

Rozhraní a komponenty

• Rozhraní předepisuje pojmenovanou množinu veřejných funkcí, jedná se o specifikaci funkčnosti. Tedy odděluje specifikaci od fyzické implementace prostřednictvím klasifikátoru (třída nebo podsystém), může se připojit k třídám, k podsystémům, ke komponentám, příp. k jakýmkoliv klasifikátorům, a definovat tak služby poskytované zmiňovanými entitami.
• Rozhraní definuje kontrakt – tj. signaturu a sémantiku operací, jejich stereotypy, omezení a označené hodnoty. Nic víc!
• Rozhraní se hodí používat k určení společných protokolů pro třídy, mezi nimiž by za normálních okolností neměly být dědičné vazby.
• Návrh zaměřený na implementaci: specifické třídy jsou propojeny (pro tvorbu jednoduchého, byť neohebného modelu).
• Návrh zaměřený na dohodu: třídy připojeny k rozhraní, které může mít různé realizace (pro tvorbu flexibilního, byť složitějšího modelu).
• Rozhraní jsou klíčem k vývoji komponentového SW, který spočívá v tvorbě samostatných a připojitelných částí – zásuvných modulů (plug-ins).
• Komponenta = modulární část systému (může mít atributy, operace, relace, vnitřní strukturu), která ukrývá/zapouzdřuje svůj obsah, své externí chování definuje pouze přes zpřístupněné/požadované rozhraní a projevuje se prostřednictvím svých artefaktů.
• Artefakty = specifikace čehokoliv skutečného, kupř. souboru (zdrojové soubory, spustitelné soubory, skripty, databázové tabulky, dokumenty, popř. UML modely).
• Podsystém = komponenta, která se chová jako jednotka dekompozice rozsáhlejšího systému. Rozhraní pak slouží k ukrytí implementačních detailů těchto podsystémů.
• Hledání rozhraní: 1) napadením každé asociace; 2) napadením každého odesílání zpráv; 3) vyčleněním operací, které lze použít i jinde (opakují se ve více třídách); 4) hledáním možností pro budoucí rozšíření; 5) hledáním závislostí mezi komponentami.

Stavové diagramy

• Stavový diagram modeluje stavový automat pro reaktivní objekt, stavový automat modeluje dynamické chování reaktivního objektu.
• Reaktivní objekty reagují na externí události, mohou generovat vnitřní události, mají určitý životní cyklus (modeluje se jako posloupnost stavů, přechodů a událostí), mají aktuální chování vyplývající z předchozího chování. Nejčastěji se jedná o třídy, případy užití, podsystémy či celé systémy.
• Dva typy stavových automatů: stavové automaty chování a stavové automaty protokolů.
• Akce = proces, který proběhne rychle a nepřerušovaně.
• Aktivita = proces, který trvá určitou dobu a lze jej přerušit.
• Stav je sémanticky významná podmínka objektu, určená hodnotami atributů daného objektu, jeho relacemi s jinými objekty a aktuálně vykonávanou aktivitou.
• Složené stavy mohou obsahovat jeden nebo více vložených stavových automatů (podstavy), které dědí od svých předků (nadstavů) všechny přechody. Zatímco sekvenční složený stav obsahuje jen jeden stavový automat, souběžný složený stav obsahuje alespoň dva stavové automaty, které jsou spuštěny současně.

Nasazení

• Diagramy nasazení umožňují modelovat distribuci SW systému na fyzickém HW (mapují architekturu SW na architekturu HW). Popisují celou množinu možných nasazení. Jsou z nich patrné uzly (typy HW, na nichž bude systém spouštěn), relace (typy spojení mezi uzly) a komponenty (typy komponent nasazených na určité uzly).