 |
| Nodes |
Uvedený diagram je poměrně chudý na některé třídy, které se zkouší na úrovni Fundamental. Proto si vypomůžeme ještě jedním z balíku IntermediateActivities:
 |
| Control nodes |
Na úrovni Fundamental se zkouší pouze níže popsané řídící uzly. Rozdělení (třída ForkNode) a synchronizace (třída JoinNode) je až pro zkoušku úrovně Itermediate. Stejně tak FlowFinalNode.
Řídící uzel (Třída ControlNode)
ControlNode je abstraktní třída, která řídí tok tokenů v aktivitě. UML standard v této třídě i definuje notaci, ale já ji zde uvedu u každé třídy zvlášť (ne, nebudete o nic ochuzeni a nebude to mít vliv na případný výsledek testu).
Počáteční uzel (Třída InitialNode)
InitialNode je řídící uzel ve kterém začíná tok tokenů, jakmile je událost spuštěna.
Má pouze odchozí hrany.
Token je umístěn na všechny hrany (které splňují podmínku definovanou atributem guard; na ostatní se nedostane, ale tento uzel ostatní tokeny nezadržuje).
Aktivita může mít více počátečních uzlů.
Aktivita však nemusí mít žádný počáteční uzel. Lze jej nahradit vstupními parametry. Aktivita pak začíná, jakmile jsou všechny vstupní parametry dostupné.
Notace
Počáteční uzel je zobrazován jako černé kolečko.
 |
| Příklad: Počáteční uzel |
Koncový uzel (Třída ActivityFinalNode)
Třída ActivityFinalNode při doputování prvního tokenu zastavuje všechny ostatní toky (tokeny) v aktivitě.
Nemá žádnou výstupní hranu.
Jakmile dorazí první token, CELÁ aktivita je ukončena bez ohledu na to, co dělají případné další tokeny. Pokud se v nějaké akci čeká na běh jiné aktivity (zavolaná synchronně), jsou ukončeny i tyto volané aktivity. Pokud došlo k asynchronnímu volání, pak akce spuštěné tímto voláním nejsou ukončením aktivity zasaženy.
Na výstupní parametry jsou vloženy tokeny. Pokud některý nebyl vytvořen, vloží se nulový token (null token).
Pokud má aktivita více koncových uzlů, aktivita končí při doputování tokenu do libovolného z nich.
Tento uzel není v aktivitě povinný, namísto něj lze použít výstupní parametr.
Notace
Koncový uzel se zobrazuje prázdným kolečkem s černým uprostřed. V anglických textech občas nazýváno jako býčí oko (bull eye) nebo terč (target).
 |
| Příklad: Koncový uzel |
Rozhodovací uzel (Třída DecisionNode)
Rozhodovací uzel slouží k tomu, aby předal řízení (token) do jedné z výstupních hran, která splňuje podmínku. Token je předán do první hrany, která podmínku splní, přičemž nikde není určeno pořadí, ve kterém se podmínky vyhodnocují. Pokud do rozhodovacího uzlu připutuje více tokenů, jsou výstupním hranám nabídnuty všechny tyto tokeny.
Rozhodování může definovat chování (viz relace decisionInput v metamodelu). Každý token je pak vložen do chování a až pak dojde k vyhodnocování podmínek. V knize [ocup-cg] je řečeno, že výsledek chování je dostupný všem výstupním hranám, vyhodnocení chování tedy není opakované. Naopak ve standardu je napsáno, že chování je spuštěno tolikrát, než se najde vhodná hrana, do které je token přenesen. Každopádně v obou zdrojích je napsáno, že chování nesmí mít vedlejší účinek (side effect), takže je to víceméně jedno.
DecisionNode má dvě asociace:
- decisionInput: Behavior [0..1] – jak již bylo zmíněno, jedná se o vstup do vyhodnocovacích podmínek (guard) odchozích hran z rozhodovacího uzlu.
- decisionInputFlow: ObjectFlow [0..1] – další vstupní hrana do rozhodovacího uzlu poskytující vstupní hodnotu pro rozhodnování.
- Rozhodovací uzel má jednu nebo dvě příchozí hrany a alespoň jednu odchozí.
- Hrany přicházející nebo odcházející do/z rozhodovacího uzlu a jsoucí jiné než vstupní tok, musí být všechny objektové toky nebo řídící toky.
- decisionInputFlow musí být příchozí hrana.
- Pokud rozhodující uzel nemá příchozí decisionInputFlow ani příchozí řídící tok, pak cho-vání přiřazené k rozhodovacímu uzlu nemá žádný vyplněný vstupní parametr.
- Ostatní pravidla viz definice standardu, třída DecisionNode. V rámci zkoušky by nemělo být zkoušeno.
Rozhodovací uzel se zakresluje jako kosočtverec.
 |
| Příklad: Rozhodovací uzel |
 |
| Příklad: decisionInput |
Pokud použijeme decisionInputFlow, pak je nutné tuto hranu uvodit klíčovým slovem «decisionInputFlow».
 |
| Příklad: decisionInputFlow |
Spojovací uzel (Třída MergeNode)
Spojovací uzel čeká na token z libovolné vstupní hrany. Jakmile jej dostane, pošle jej dál (což znamená, že jej nelze použít pro synchronisaci).
MergeNode má pouze jednu výstupní hranu.
Vstupní i výstupní hrany musí být všechny řídící nebo všechny objektové.
Notace
Používá se kosočtverec.
Rozhodovací a spojovací uzel lze spojit v jeden. Pak se provede nejprve sémantika spojovacího uzlu a až poté rozhodovacího.
Objektové uzly (Třída ObjectNode)
Abstraktní třída ObjectNode říká, že v rámci aktivity v daném okamžiku existuje objekt nebo množina objektů. Objektové uzly mohou být v aktivitách použity jako příchozí či odchozí parametry (parametry aktivity) nebo jako parametry akce (piny). Objekt je přenášen společně s tokenem na objektové hraně.
Objekty se používají pro znázornění, že během aktivity dochází k vytvoření, zrušení či modifikaci nějakého objektu. Akce, která takto objekt vyžaduje, nebude spuštěna, dokud se jí kýženého objektu nedostane.
Všechny příchozí i odchozí hrany z objektového uzlu musí být objektové (ObjectFlow).
Notace
Objektový uzel se zobrazuje jako obdélník s názvem uvnitř. Název indikuje typ objektového uzlu. Případně lze napsat název a za dvojtečku typ. Stejnou notací se zobrazuje množina objektů (viz také příklad u pinů).
 |
| Příklad: Objektový uzel |
V UML standardu se ještě zmiňuje objektový uzel určující signál (s notací podobnou šipce), ale signály se ve zkoušce úrovně Fundamental nezkouší.
Žádné komentáře:
Okomentovat