 |
| Závislosti mezi balíky metamodelu |
Třída Component
 |
| Metamodel komponent |
Komponenta je jedním z proklínaných slov. Na Internetu lze najít desítky zaručeně správných definic, každá však, jak už to bývá, říká něco jiného. Pro nás je však důležité, co o komponentě říká UML. Tam je definice poměrně přímá a snadno pochopitelná: komponenta je část modulárního systému, která zapouzdřuje svůj obsah a jejíž chování či projev navenek lze nahradit.
Znamená to tedy, že pokud z fungujícího systému komponentu vyjmeme a nahradíme ji takovou, která poskytuje a požaduje stejné chování od systému, pak je vše v naprostém pořádku. Je to jako např. nahradit v autě motor jednoho typu. To lze, ale není možné jednoduše místo zážehového dát vznětový, byť by díry na šrouby byly shodné.
Komponenta (třída Component) jakožto specializace třídy Class může mít operace a atributy a účastnit se asociací či generalizací. Podobně díky tomu, že třída Class je specializací třídy EncapsulatedClassifier, může mít komponenta vnitřní strukturu a vlastnit porty.
Komponenta také může poskytovat či požadovat rozhraní. Ta mohou být zprostředkována napřímo nebo přes již zmíněné porty. Právě díky rozhraní tak komponenta jasně říká, jak komunikuje s okolním světem a tedy jaké minimální požadavky musí splňovat případná jiná komponenta, kterou by tu stávající měla být nahrazena. Tímto nahrazením je myšleno jak nahrazení při návrhu, tak i při běhu systému.
Pokud je atribut komponenty isIndirectlyInstantiated roven True (výchozí hodnota), pak je komponenta používaná pouze v době návrhu, ale nikoliv v době běhu aplikace (typicky může mít např. zmíněný stereotyp «specification»). Pokud je False, pak se lze na komponentu odvolávat přímo v kódu.
Komponenta rovněž může vlastnit sadu stavů a chování klasifikátorů.
Na komponentu lze pohlížet jako na černou skříňku (black-box), tedy pouze na něco, co poskytuje svému okolí rozhraní a veřejné vlastnosti. Stejně tak lze komponentu vidět jako otevřený systém (white-box), kdy vidíme, jak komponenta uvnitř funguje a jakou má strukturu.
UML taktéž poskytuje pro komponenty řadu stereotypů. Jmenujme např. «subsystem» používaný pro modelování rozsáhlých systémů či «specification» a «realization», kde jeden slouží k definici nějaké části systému a druhý zmíněný pak říká, jak je tato specifikace realizována. Typicky máme jednu specifikaci a více možných realizací (např. pro různé operační systémy, pro různé databáze apod.).
Notace
Komponenta je zobrazována podobně jako klasifikátor v obdélníku s klíčovým slovem «component». Volitelně je pak v pravém horním rohu zobrazen piktogram komponenty.
 |
| Příklad notace komponenty |
Rozhraní, která komponenta poskytuje nebo vyžaduje, jsou zobrazována klasickou lízátkovou notací.
 |
| Notace komponenty a rozhraní |
Rozhraní lze samozřejmě zakreslit i přes závislosti.
 |
| Komponenty a rozhraní přes závislosti |
V komponentě lze zobrazit také jednotlivé oddíly (zápisu se anglicky říká table notation).
 |
| Oddíly komponenty |
Třída ComponentRealization
Vlastnosti, které komponenta poskytuje, mohou být realizovány (či implementovány) různými klasifikátory. To napomáhá udržovat jistou míru abstrakce komponent. Notace je stejná jako u třídy Realization, tedy přerušovaná linka s otevřenou šipkou u komponenty a použitím klíčového slova «realize» nebo přerušovaná linka s trojúhelníkovou šipkou.
 |
| Realizace komponenty |
Další způsob, jak zobrazit informaci, že nějaký klasifikátor realizuje komponentu, je umístit jej právě do komponenty. Pozor ale na to, že nejde o kompozitní strukturu!
 |
| Realizace komponenty |
Uvedený zápis sice standard uvádí, bohužel už však neuvádí rozhraní u uvedených klasifikátorů. Nebál bych se je přesto použít ve vašich diagramech.
Pro zdůraznění, která komponenta realizuje kterou, můžeme použít stereotypy uvedené v úvodu:
Třída Connector
 |
| Metamodel konektorů |
Třída Connector rozšiřuje konektor definovaný v kompozitních strukturách mj. o atribut ConnectorKind, kterým říkáme, zda propojení mezi prvky je delegací nebo spojením. V případě, že jde o delegaci (ConnectorKind = delegation), pak konektor pojí externí požadavky na činnost komponenty přes port na vlastnost, která tento požadavek umí splnit. Stejně tak požadavky od této vlastnosti dokáže delegovat (opět přes port) do okolí komponenty.
Pokud je konektor spojením (ConnectorKind = assembly), pak spojuje vnitřní části nebo porty vnitřních částí, které splňují požadovanou funkcionalitu.
Notace
Notace delagovaného konektoru je poměrně oříšek. UML striktně říká, že je zobrazován stejně, jak je definováno v třídě InternalStructures::Connector (tedy jako asociace). V knize [ocup-cg] se však hovoří o šipce s klíčovým slovem delegate. Některé nástroje tento zápis podporují dokonce i jako výchozí. Uvádím zde teda raději oba. V druhém případě je směr šipky důležitý. Říká nám, kterým směrem je požadavek předáván (delegován) dál.
 |
| Notace konektoru dle UML |
 |
| Notace konektoru nezmíněná ve standardu |
Notace pro spojovací konektor je už však opět všude uváděna stejně. Vypadá jako dvě rozhraní spojená k sobě.
 |
| Spojení |
Žádné komentáře:
Okomentovat