 |
| Metamodel: Object Nodes |
S objektovými uzly jsme se již setkali v části pro úroveň Fundamental (např. Pin či ActivityParameterNode). Zde se podíváme na třídu CentralBufferNode. Ta nám slouží pro řízení toků z vícera zdrojů do vícera konzumentů. Tento uzel přijímá na vstupu objekty a shromažďuje je. Ve chvíli, kdy si o ně někdo řekne, tak mu je posílá. Objekty jsou přijímány po jednom, nečeká se, až přijdou ve všech vstupních hran. Jakmile jeden objekt přijde (z libovolné vstupní hrany), je uložen a připraven pro libovolného konzumenta. Stejně tak je uzel připraven přijmout další objekt. Podobně se pracuje s konzumenty objektů. Jakmile je libovolný z nich připraven objekt přijmout, CentralBufferNode mu jej pošle. Pokud je připraveno více konzumentu, není dáno, který má přednost (chování je tedy nedeterministické).
Notace: obdélník s klíčovým slovem «centralBuffer». Pod klíčovým slovem je název objektového tokenu, který uzel je schopen přijmout.
Představme si to na příkladu ČSÚ a nesmyslné akci Velkého Bratra nazvané Sčítání lidu. Při ní ČSÚ či dostatečně „spřátelená“ firma z různých částí republiky dostávají vyplněné sčítací archy, které je potřeba převést do elektronické podoby (a následně prodat na černém trhu). Archy chodí v předem nedefinovaném pořadí a stejně tak je skenery různě rychle zpracovávají. Mezi okrskem a skenerem tedy bude vhodné nasadit v nějaké podobě CentralBufferNode.
 |
| Příklad notace třídy CentralBufferNode |
Řídící uzly
 |
| Metamodel: Control Nodes |
S řídícími uzly jsme se už také setkali a to s většinou. V této úrovni znalosti UML standardu se podíváme na zbývající tři: FlowFinalNode, ForkNode a JoinNode.
Řídící uzel FlowFinalNode je hodně podobný ActivityFinalNode: vezme příchozí token, ale nikam ho neposílá, pouze ho zahodí. Aktivitu jako takovou však nekončí, ale ukončí se pouze daný tok, všechny ostatní tokeny a akce v aktivitě pokračují ve své činnosti. FlowFinalNode nemá odchozí hranu. Pokud do něj vede více hran, pak vždy vezme token z některé příchozí hrany, na ostatní nečeká. Notace: vnitřně škrtnuté kolečko.
 |
| Příklad notace třídy FlowFinalNode |
S řídícím uzlem ForkNode je větší zábava. Ten vezme příchozí token (je jen jeden!) a rozdělí je mezi všechny výstupní hrany. Hrany, které do/z uzlu vstupují, jsou buď všechny objektové, nebo všechny řídící. Notace: silná černá vodorovná nebo svislá čára.
 |
| Příklad třídy ForkNode |
Se znalostí nabytou z předchozí zkoušky vám nedá moc práce si potvrdit, že předchozí obrázek má naprosto stejný význam jako ten následující:
 |
| Příklad: Implicitní rozdělení |
Výstupní hrany z ForkNode mohou obsahovat i podmínku (guard) známou z kapitoly o rozhodovacích uzlech. Zde však platí trochu jiné pravidlo. Token je poslán jen na ty hrany, které podmínku splňují.
Posledním řídícím uzlem je JoinNode. Ten má několik vstupních hran a jednu výstupní. Opět platí, že všechny jsou buďto objektové nebo jsou všechny řídící. Vždy se čeká na doputování všech tokenů ze vstupních hran. Pokud se jedná o řídící tokeny, pak je tento poslán dál. V případě objektových to funguje trochu jinak. Tam se nejprve objekty stejných typů spojí v jeden token a pak jsou všechny tokeny, v pořadí, v jakém dorazily, posílány výstupní hranou dál (v knize [ocup-cg] je tedy obr. 3.114 špatně, neboť pokud nebudu chtít zamluvit auto, nikdy se k potvrzení výletu nedostanu).
Notace je shodná s ForkNode, přičemž je možné je zakreslit v diagramu jako jeden prvek. Rozhodně ale stále jde o dva řídící uzly.
 |
| Příklad notace třídy JoinNode |
 |
| Příklad předávání objektových tokenů |
K uvedenému obrázku je ještě nutné doplnit, že nikde není řečeno, že seřizování a mytí auta probíhá současně nebo že trvají stejně dlouho. Pouze tím říkáme, že obě aktivity jsou na sobě nezávislé.
Rozdělení aktivity
 |
| Metamodel: Partitions |
ActivityGroup je abstraktní třída, která umožňuje seskupovat uzly a hrany. Tyto skupiny mohou být rozdělovány do dalších podskupin. Uzly i hrany musí náležet pouze jedné aktivitě, ale mohou být členy více (pod)skupin. Tato třída nemá definovanou žádnou notaci.
Konkrétní třídou je pak ActivityPartition. (Pozor na knihu [ocup-cg], kde se píše, že tato třída je přímou specializací pojmenovaného elementu. Není to pravda, to je třída ActivityGroup.) Ta již notaci definuje. Část (partition) je zobrazena jako dvě vodorovné linky s názvem v obdélníku mezi jejich začátky (viz obrázek).
 |
| Příklad notace třídy ActivityPartition |
Umístění linek nemusí být nutně horizontální, ale klidně vertikální. Uzly a hrany, které do části patří, se pak umisťují mezi dvě hlavní linky. Části lze do sebe zanořovat, čímž vzniká jakási hierarchická struktura.
 |
| Příklad vnořených částí |
Části můžeme dávat i přes sebe, typicky se tak děje, když chceme rozdělit např. firmu ještě podle toho, kde sídlí.
 |
| Příklad rozdělení |
Na uvedeném příkladě je ještě několik dalších prvků, které je vhodné znát. Tím prvním je uvedení názvu elementu (zde class). To odpovídá vazbě represents v metamodelu, která odkazuje na element, jehož chování je daným uzlem vyvoláno. Slovo «external» je totéž, jen naznačuje, že se daná věc vyskytuje mimo náš model, tedy mimo naší kontrolu. Může to být třeba aktor, který k našemu systému přistupuje.
Části, které nejsou podčástmi, mohou mít i tzv. dimenze. Ty jsou umístěny nad názvy částí (na příkladě je to Umístění, podobně bychom mohli udělat dimenzi i pro Oddělení).
Rozdělení do částí způsobem uvedeným na obrázku může často diagram zpřehlednit, ale také znepřehlednit. Proto UML umožňuje ještě jeden typ notace a tím je zápis názvů částí přímo do akce:
 |
| Příklad: Zápis částí do akcí |
Díky tomu pak lze akci vizuálně umístit libovolně po aktivitě.
Žádné komentáře:
Okomentovat