UPOZORNĚNÍ

Zkoušky OCUP Fundamental a OCUP Intermediate již není možné absolvovat. Nově jsou k dispozici OCUP 2 Foundation a OCUP 2 Intermediate. Texty uvedené na těchto neodpovídají plně novým zkouškám. Aktuální text najdete na nových stránkách.

Testy znalostí UML

Chcete si kdykoliv před, při nebo po čtení těchto stránek udělat test znalostí UML? Máte možnost absolvovat takový, který připravil autor těchto stránek. Vše podstatné najdete na http://www.kurzy-uml.cz.

Komponentové diagramy (Component Diagrams)

Tato část je obsažena v 15 % testových otázek.
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

Líbila se vám právě přečtená kapitola?

Líbil se vám článek? Přinesl vám užitek? Pokud ano, můžete mi zaslat pár drobných, čímž jednak dáte najevo, že se vám tu opravdu líbilo, a jednak mi ukážete, že má práce není zbytečná. Informace o darovací platbě zde.