UML

O protokolárním stavovém automatu dosud nepadlo ani slovo. A protože tohle je poslední šance, tak ji využijeme.

V prvním bonusovém pravidle jsme se bavili o informačním toku. Jenže k čemu by nám byl, pokud bychom nebyli schopni určit, co v rámci tohoto informačního toku teče za data.

Informační toky milují především integrační analytici a architekti řešení. Jedná se o velmi efektivní znázornění, že z nějakého zdroje tečou data k nějakému cíli. Těmito zdroji a cíli bývá nejčastěji komponenta, ale nemusí tomu tak být.

Podobně jako aktér (odkaz na předchozí článek), i případ užití má svá omezení, co se asociace týče. A nejenom asociace, další pravidlo se věnuje (často špatně používaného) vztahu include.

Asociace je v praxi zřejmě jediný používaný vztah mezi aktérem a případem užití. Ovšem aktéra můžeme asociovat i s dalšími prvky v modelu. Ne však se všemi. Které jsou povolené?

V předchozím příspěvku jsme hovořili o kombinovaných fragmentech, operandech a podmínkách. Přiznám se, že jsem jednu vlastnost zmíněné podmínky záměrně vynechal. Uschoval jsem si ji pro případ, kdy budeme hovořit o kombinovaném fragmentu typu loop.

V rámci sekvenčních diagramů můžeme používat kombinované fragmenty, jichž UML nabízí poměrně velké množství. Ovšem i s fragmenty musíme zacházet opatrně, i ony mají svá pravidla.

Jestliže předchozí povídání o počtu příchozích a odchozích hran v aktivitě nám trošku zkomplikoval rozhodovací uzel, zde bude situace mnohem klidnější. Na řadě jsou rozdělující (fork), slučovací (join) a spojovací (merge) uzly.

Diagramy aktivit jsou pro začátečníky poměrně náročné, jestliže chtějí modelovat správně, tedy podle pravidel UML. Každý uzel v takovém diagramu má různá pravidla pro příjem a přeposílání tokenů a také omezení na počet vstupních a výstupních […]

Pravidlo, o kterém bude právě řeč, bych doporučil si více než jen zapamatovat. Moc lidí ho nezná a vznikají kvůli tomu diagramy, které s UML nemají skoro nic společného (ač autoři tvrdí opak).