Pravidelně potkávám uživatele Enterprise Architecta, kteří si myslí, že vše, co jim EA dovolí namodelovat, je podle pravidel definovaných standardem UML. Předvedu zde pár příkladů, které jsou v rozporu s uvedeným přesvědčením.

Generalizace

Jak jistě víte, tak generalizace je vztah mezi dvěma klasifikátory, přičemž jeden je specializací (resp. zobecněním) toho druhého. V omezení definovaném u klasifikátoru je jasně napsané, že generalizační hierarchie musí být acyklická. Jinými slovy např. třída nesmí být (přímo ani nepřímo) svým zobecněním. Následující diagram je tedy proti pravidlům v UML:

Ano, obrázek je vytvořen v Enterprise Architektu. A to bez jeho protestů. Zkusme si model validovat (menu Project ► Model Validaton ► Validate Selected). Nástroj sice správně řekne, že nelze udělat generalizaci třídy sebe sama, ale o větší cykly se už nestará. Mylně tak lze dojít k závěru, že je to v pořádku.
 

 Ve výsledku validace je ještě jedna chyba navíc a ta se týká následujícího diagramu (který EA opět dovolí udělat):

Pojďme ale dále. Pro úplnost nutno dodat, že následující chyby již kontrola zabudovaná v EA neodhalí.

Aktivity a akce

Aktivity a akce jsou už průser přímo ve standardu. Koho mohlo napadnout, že základní notace těchto dvou elementů bude stejná? (Nejen) kvůli tomu to uživatelé UML nerozlišují a flákají do modelu aktivity místo akcí poměrně často a značně svižně. A Enterprise Architect je v tom podporuje.

Znovu a znovu je třeba připomínat to, co vy již určitě víte: Aktivita řídí nějakou činnost pomocí množiny uzlů a hran. Uzly jsou (zjednodušeně řečeno) trojího typu: akce, objektové uzly a řídící uzly. Akce je dále nedělitelný krok, atomická operace (kterou může být např. volání jiné aktivity).

To bychom měli aktivity a akce, ale ještě nekončíme. K dispozici standard nabízí hrany, které se dělí na řídící toky a objektové toky. V UML standardu se dozvíme, že hrana slouží pro předávání tokenů (a případně objektů) mezi uzly aktivity (tj. mezi uzly, které aktivita vlastní). Co nám dovolí udělat EA? Mít toky mezi aktivitami. Mít toky mezi uzly různých aktivit. Mít tok mezi aktivitou a akcí. Vše je pochopitelně špatně, ale EA nás na to neupozorní.

Takže ještě jednou:

• Akce je atomická operace. 
• Aktivita obsahuje uzly a hrany. 
• Toky mezi uzly aktivity jsou pouze mezi uzly téže aktivity. 
• Mezi aktivitami není žádný tok. 

Tohle ale často vede k otázce: jak tedy zobrazit sled aktivit? Nebo volání aktivit? Budu se tím zabývat v některém z příštích článků.

Další

Enterprise Architekt umožňuje hřešit proti standardu i v mnoha dalších případech. Zde krátce vyjmenovávám jen některé hříchy, při bližším studiu UML standardu a používání EA jistě najdete mnohé další:

1. Vytvoření závislosti se šipkami na obou stranách či na žádné (správně je mít hrot šipky právě na jedné straně). 
2. Vytvoření informačního toku mimo povolené elementy. 
3. Špatná notace třídy GeneralOrdering (sekvenční diagramy). 
4. Špatná notace třídy Extension (profily). 
5. Umožnění mít nepojmenovaného účastníka (třída Actor, diagram případů užití). 
6. Neumožnění všech povolených notací (např. hran v diagramech aktivit nebo tagových hodnot). 

Závěr 

Ukázal jsem několik důkazů, že Enterprise Architect NEPODPORUJE SPRÁVNĚ A ZCELA UML Standard. Nevěřte tedy autorům aplikace a naučte se UML používat správně.

Nakonec nabízím malé domácí cvičení. Odpovědi, na které stačí základní znalosti UML, mi můžete poslat e-mailem.

Otázka č. 1: Je následující diagram v pořádku nebo není? Proč?

Otázka č. 2: Je následující diagram v rozporu s UML standardem? Co lze o něm (o diagramu) říct?