Na středeční snídani spojené s Enterprise Architectem jsme řešili mj. vyhledávání požadavků, které nejsou realizované, tedy takové, které nejsou cílem realizačního vztahu.

EA takovou možnost v základu nenabízí, ale není problém si ji poměrně jednoduše doplnit. Poslouží nám k tomu uživatelsky definované vyhledávání, základní znalost SQL a tabulky, které EA používá. Zde uvádím krok za krokem.

1. Zvolte vyhledávání v modelu (Ctrl+F, menu Edit, položka Search in model).
2. V prvním rozbalovacím seznamu vyberte My Searches.
3. Z tlačítek více vpravo zvolte New Search.
4. V nabídnutém okně zadejte název vašeho hledání (např. Nerealizované požadavky) a typ editoru vyberte SQL Editor.
5. Po stisku tlačítka OK dostanete možnost zadat SQL dotaz, jednoduše tam vložte ten následující:
   select o.ea_guid AS CLASSGUID, Object_ID, Name, Alias, Stereotype, CreatedDate, ModifiedDate, Status
from t_object o
where object_type = "Requirement"
and not exists (select 1
from t_connector
where end_object_id = o.object_id
and connector_type = "Realisation")
6. Dotaz uložte (ikona diskety) a hned můžete spusit (F5). Jestliže bude váš model vypadat např. takto (je to opravdu jen příklad, nic jiného za tím nehledejte): výsledkem dotazu budou dva požadavky Requirement2 a Requirement4:

A to je vlastně vše. Snad jen douškou upozorňuji na první sloupeček v SQL dotazu. Ve výsledné tabulce se sice nezobrazuje, ale způsobuje, že když v ní dvojitě kliknete na element, tak se automaticky zobrazí jeho vlastnosti.

Při programování rozšíření pro EA jsem narazil na další chybu. Funkce Repository.GetContextItemType() nevrací správnou hodnotu, pokud máte vybraný model v Project Browseru. Namísto hodnoty otModel dostanete otNone, což není úplně zdravé. Chybu jsem poslal do Sparxu, ale údajně o ní již dlouho vědí, ovšem do opravy se jim zřejmě nechce. Než se tak stane, můžete použít následující funkci, které problém řeší:

protected EA.ObjectType temporaryGetContextItemType(EA.Repository Repository) {
    EA.ObjectType vOT = Repository.GetContextItemType();
    if (vOT == EA.ObjectType.otNone)
        //try it to retype to Package and check if it is a model... 
        //if anything gets wrong, forget it
        try {
            if (((EA.Package)(Repository.GetContextObject())).ParentID == 0)
                return EA.ObjectType.otModel;
        } catch { }
    return vOT;
}

Funkce v případě, že GetContextItemType vrátí otNone, tak zkusí vybraný objekt přetypovat na balík a zjistit jeho ParentID. Pokud se to povede a hodnota je rovna nule, jde o model, jinak je to cokoliv jiného, chybné přetypování odchytím v sítu výjimek a navrátím původní hodnotu.

Pokud budete dále pracovat s balíkem, který je vlastně modelem, tak také dejte pozor na to, že jeho vlastnost Element je null (což se v dokumentaci nedozvíte). Není to od autorů hezké.

A drobnost na závěr: funkce očekává, že máte otevřený nějaký projekt. Že tomu tak opravdu je, byste si měli zajistit sami např. vhodným povolením či zakázáním jejího volání v EA_GetMenuState.

Vytvořit vlastní rozšíření (plug-in) pro Enterprise Architect je velmi snadné, rychlé a dokonce bez dalších nákladů na programovací nástroje. Jak tedy na to?

Předpokládám, že máte nainstalovaného Enterprise Architecta (pro uvedené pokusy stačí i dosud funkční trial verze). Dále budete potřebovat nějaký programovací nástroj. Jestliže nechcete do něj vkládat jakékoliv peníze, použijte Express edici Visual Studia od Microsoftu. Já sám používám VS Express 2013 for Desktop s jazykem C#. Pokud tedy i to máte, můžeme přikročit k vlastní tvorbě (ukázky budou právě v C#).

Visual Studio

1. Spusťte si Visual Studio a vytvořte nový projekt podle šablony Class Library.
   
2. Nyní musíte svůj projekt ve VS seznámit s Enterprise Architektem, tedy jinými slovy přidat na něj referenci. Díky tomu budete moci využívat třídy a jejich vlastnosti definované přímo dodavatelem EA. To uděláte tak, že:
1. V Solution Exploreru zvolíte položku References a přes kontextové menu vyberete položku Add Reference… 
   
2. V dialogu Reference Manager, který se otevře, zvolte tlačítko Browse… a z adresáře, kde máte nainstalovaný Enterprise Architect, vyberte soubor nazvaný Interop.EA.dll.
   

    

3. Zvolte tlačítko OK.
3. Jelikož budeme zobrazovat nějaké informace i uživateli, pak přidáme ještě System.Windows.Forms (podobně jako v předchozím kroku vyvoláme dialog Reference Manager, vlevo zvolíme Assemblies –> Framework a v seznamu zaškrtneme System.Windows.Forms).
   
4. V tomto kroku řekneme překladači, aby s naší knihovnou zacházel tak, aby ji šlo použít jako COM objekt. Toho docílíme tak, že:
1. dvojitým kliknutím (dablklikem) na položku Properties v Solution Exploreru zobrazíme vlastnosti našeho projektu.
2. Zvolíme tlačítko Assembly Information…
3. Zaškrtneme Make assembly COM-visible.
4. Volitelně můžete upravit i další pole.
5. Stiskněte OK.
   
5. Abychom si ulehčili ještě trochu život, požádáme Visual Studio, aby po každém sestavení nové verze na našem počítači zaregistrovalo knihovnu do registrů.
1. Z předchozího kroku máme zobrazené Project Extensions. Po pravé straně zvolíme záložku Build.
2. V sekci output zaškrtněte políčko Register for COM interop.
   
6. Visual Studio pro nás připravilo třídu Class1. Pro lepší pohodlí si ji můžete přejmenovat např. na MyFirstEAPlugin, podobně i soubor na MyFirstEAPlugin.cs.
7. Zkopírujte si nyní následující zdrojový kód do VS. V textu je pár komentářů, které vysvětlují jednotlivé metody. Obecně lze říct, že EA volá v případě potřeby metody začínající na EA_. Pro další studium je tu pro vás nápověda k Enterprise Architektovi a oblast nazvaná Automation and Scripting.

   using System;
   using System.Windows.Forms;
   
   namespace OCUPBlokPlugin
   {
       public class MyFirstEAPlugin
       {
   
           /// 
   
           /// Tuto metodu volá EA aby zjistil, jakého typu je náš plugin.
           /// Můžeme buďto zvolit MDG, pokud tvoříme plugin tohoto typu, jinak 
           /// vrátíme prázdný řetězec, čímž říkáme, že jde o obecný plugin.
           /// 
   
           /// Budeme ignorovat.
           /// Vrátíme prázdný řetězec.
           public String EA_Connect(EA.Repository Repository)
           {
               return "";
           }
   
           /// 
   
           /// Metoda je volána při ukončování EA. Takže po sobě zkusíme trošku uklidit.
           /// 
   
           public void EA_Disconnect()
           {
               GC.Collect();
               GC.WaitForPendingFinalizers();
           }
   
           /// 
   
           /// Definujeme si někteté položku v Menu
           /// 
   
           const string menuHeader = "-&OCUP blok plug-in";
           const string menuItemAbout = "&About...";
   
           /// 
   
           /// Pokud EA potřebuje znát seznam položek menu, pak se zavolá tato metoda
           /// 
   
           /// Repository jako taková
           /// Umístění menu
           /// Název menu
           /// 
           public object EA_GetMenuItems(EA.Repository Repository, string Location, string MenuName)
           {
   
               switch (MenuName)
               {
                   // Jde o hlavní položku, vrátíme náš název
                   case "":
                       return menuHeader;
                   // a zde vrátíme všechny naše položky mmenu
                   case menuHeader:
                       string[] subMenus = { menuItemAbout };
                       return subMenus;
               }
   
               return "";
           }
   
           /// 
   
           /// Tady se nás EA ptá, zda má položku v menu povolit nebo zakázat. 
           /// Můžeme tak reagovat na různé stavy (např. zdali je otevřen nějaký projekt).
           /// 
   
           /// 
           /// 
           /// 
           /// 
           /// 
           /// 
           public void EA_GetMenuState(EA.Repository Repository, string Location, string MenuName, string ItemName, ref bool IsEnabled, ref bool IsChecked)
           {
               switch (ItemName)
               {
                   case menuItemAbout:
                       IsEnabled = true;
                       break;
                   default:
                       IsEnabled = false;
                       break;
               }
           }
   
           /// 
   
           /// Konečně! Někdo zvolil některé z našeho menu, takže směle do toho.
           /// 
   
           /// 
           /// 
           /// 
           /// 
           public void EA_MenuClick(EA.Repository Repository, string Location, string MenuName, string ItemName)
           {
               switch (ItemName)
               {
                   case menuItemAbout:
                       MessageBox.Show("OCUP blok plug-in. Hello, EA user!");
                       break;
                   default:
                       MessageBox.Show("Neobsloužená položka menu!");
                       break;
               }
           }
   
   
   
   
       }
   }

8. Teď vaše řešení přeložte, aby se vytvořila DLL knihovna. Poznámka: Na některých operačních systémech je třeba mít pro následnou registraci dostatečné oprávnění, Visual Studio je pak nutné spouštět jako správce. 

Záznam do registrů

Nyní máte sestavenou a zaregistrovanou knihovnu. Posledním krokem je říct EA, aby ji používal. K tomu stačí drobný zásah do registrů:

1. Spusťte editor registrů regedit.
2. Najděte větev HKEY_CURRENT_USERSoftwareSparx SystemsEAAddins.
3. Přidejte do této větve nový klíč s názvem projektu ve Visual Studiu (v našem příkladu je to OCUPBlokPlugin).
4. V registrech vznikne i výchozí hodnota pro tento klíč. Změňte ji dle formátu [název projektu].[název třídy], tedy opět v našem případě na OCUPBlokPlugin.MyFirstEAPlugin.
   

A je hotovo! Teď můžete svůj výtvor otestovat.

Enterprise Architect

1. Otevřete si EA (pro náš pokus není nutné mít otevřený žádný projekt).
2. V menu Extensions zvolte položku OCUP blok plug-in, která rozbalí a ukáže jednu položku About…:
   
3. Pokud ji zvolíte, dostanete jednoduché hlášení: 
   

Jak vaše rozšíření distribuovat?

Pokud máte nějaký software na tvorbu instalačních souborů, tak máte vyhráno, zachovejte se podle jeho instrukcí. V opačném případě je třeba postupovat následovně:

1. Zkopírujte si knihovnu (s případnými dalšími potřebnými soubory) na nové místo (na jiný počítač).
2. Na novém místě je třeba zaregistrovat soubor do registrů. To se dělá pomocí aplikace regasm, kterou máte v adresáři %WINDIR%Microsoft.NETFrameworkv4.0.30319. Celá registrace pak probíhá tímto příkazem:

   %WINDIR%Microsoft.NETFrameworkv4.0.30319regasm OCUPBlokPlugin.dll /codebase

3. Je třeba se zmínit Enterprise Architectovi o vašem pluginu. To, jak již víte, se dělá vytvořením klíče v registrech. Zde stačí export vašeho stávajícího klíče a pak distribuovat přímo .reg soubor.

Jak dál?

Teď už je to na vás. Podívejte se na uvedené metody začínající na EA_ a prostudujte si nápovědu, co vše lze tvořit. Možností je mnoho. Pro vaši potřebu si můžete stáhnout celé zdrojové kódy uvedeného příkladu zde.

Po delší době jsem opět sedl k mému připravovanému projektu a testoval nově napsaný kód. Zjistil jsem, že v některých případech nedělá to, co má. Po delší době přicházím na to, že chyba je samozřejmě mezi klávesnicí a židlí, ovšem na straně Sparxu.

Sám mám verzi EA 11, build 1107 (na 64bitových Windows 8.1), ale věřím, že to bude reprodukovatelné i jinde. Co je vlastně tak špatně? Zkuste si to sami:

1. Nejprve si uložte rozpracovanou práci, abyste o nic nepřišli! 
2. Vytvořte si diagram a vložte do něj omezení (prvek Constraint). 
3. Nyní vložte do diagramu jiný prvek, třeba třídu.
4. Od omezení k třídě udělejte link.
5. Nyní chytněte konec linku u třídy a přetáhněte jej na omezení (je to sice proti UML pravidlu not_apply_to_self definovaného u metatřídy Constraint, ale EA to přesto umožní).
6. Teď označte omezení a stiskněte Ctrl+C.
7. Enterprise Architekt spadne. 

Když jsem si s tím hrál, tak v některých případech (nenašel jsem, v jakých přesně) jsem v tabulce t_object (soubor .eap není nic jiného než accessovská databáze a tak k ní lze přistupovat) objevil nepříjemnou věc a to, že hodnota ve sloupci object_id byla shodná s hodnotou ve sloupci parentid (což je hodně podivné – EA to používá pro vnořování elementů, např. akce do aktivit). To má mimo jiné ten důsledek, že pokud přes OLE Automation přistupujete k datům v Enterprise Architektu, tak v kolekci Package.Elements takový objekt nemáte k dispozici.

Reportoval jsem chybu přímo Sparxu, tak uvidíme, jak se pochlapí. Průběžně budu informovat.

Že jsou okna v Enterprise Architectu typu Project Browser dokovatelná nebo je lze mít samostatně, to asi každý uživatel ví (a pravidelně ho to může rozčilovat kvůli nevyzpytatelnosti). Ale když vidím, jak někteří kolegové neustále přepínají mezi dvěma diagramy pomocí záložek a nadávají, protože by rádi měli informace vedle sebe pro větší pohodlí, tak mi nedá než jim ukázat, jak na to.

Ono to totiž jde úplně stejně jako s každým jiným oknem – myší chytnete záložku (její název) a pomoci Drag n‘ Drop ji přemístíte někam jinam – do zvláštního okna nebo ji ukotvíte vedle jiného diagramu. Překvapuje mne, jak často jsem svědkem němého úžasu.

Chytíme záložku…

…zobrazí se okno s možností ihned pustit nebo přetáhnutím na odpovídající místo určit, kam se má zadokovat.

Zde dva diagramy vedle sebe.

S devátou verzí Enterprise Architecta přišla jedna drobnost, která se mi osvědčila při vyjednávání požadavků se zadavateli. Ti totiž nemají rádi technické výkresy, a co si budeme povídat, např. diagram tříd jím víceméně je. Celý dojem z obrázku se však rázem změní, když je nakreslen od ruky. Zadavatelé tleskají, zadavatelky jihnou a vy máte jejich podporu. Jak tedy kreslit od ruky? Odpověď je jednoduchá: nijak! Stačí totiž jen zaškrtávat.

Jako ukázku vezmu diagram, který jsem již použil v článku o stereotypech a barvách:

Ono tomu není z pohledu rozvržení moc co vytknout, ale co kdybychom si tentýž diagram zobrazili stejně, jako jsme jej kreslili např. na bílou tabuli (whiteboard) při některém sezení se zadavateli?

Případně použili i nějakou barvu?

Celý fígl spočívá v použití voleb Hand Drawn a Whiteboard Mode na záložce Diagram dialogu pro nastavení vlastností diagramu:

Vlastnosti diagramu

Vyzkoušejte si sami nejen v Enterprise Architectu, ale i na vašich zákaznících, pro které mají tyto obrázky nějaký význam. Z vlastní zkušenosti však doporučuji tento test provést na nějakém opravdu jednoduchém diagramu, neboť prvotní nadšení může přispět k přehlédnutí nedostatku v předkládaném návrhu.

Pro úplnost ještě dodám, že diagram může nabýt podobných vlastností hned na začátku, stačí zvolit ten správný typ při jeho vytváření:

Nový diagram

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?

Po několika týdnech čekání, dvou beta verzích a jednoho kandidáta na ostrou verzi tu máme konečnou podobu Enterprise Architecta 10 (sestavení 1004). Přehled zásadních novinek je na úvodní stránce produktu, podrobné změny pak najdete v historii jednotlivých vydání. Stahujte tedy novou verzi a studujte změny, je jich tam dost.

Informační tok definuje obecné předávání informací v systému a to na té nejvyšší úrovni abstrakce. Nespecifikuje se ani povaha informace (typ, počáteční hodnota…), ani mechanismus, kterým výměna informací probíhá. Dokonce se neurčuje ani pořadí či podmínky pro možnost výměny. K tomu je určena až některá z následných – detailnějších – fází návrhu, ve které lze určit, které prvky přenášenou informaci reprezentují a které vztahy daný tok realizují.

Informační tok

Pro zavedení informačního toku do modelu se používá vztah InformationFlow, který říká, že jedna či více informací putuje ze svého zdroje do svého cíle. Zobrazuje se přerušovanou čarou zakončenou šipkou směrem k příjemci informace. U čáry je uvedeno klíčové slovo «flow». Pozor na to, že byť je čára přerušovaná, nejde o závislost (tj. přímou či nepřímou specializaci třídy Dependency metamodelu).

Poblíž čáry jsou pak dále textově zobrazeny i jednotlivé informace, které jsou tokem přenášeny (viz dále).

Příklad notace informačního toku

Postup v EA: V Enteprise Architektu je vytvoření informačního toku hodně jednoduchou záležitostí.  Najdeme jej v ToolBoxu v části Common. Hned po vytvoření vztahu mezi objekty se zobrazí dialog pro zadání informací (Information Items Conveyed), které tok přenáší. Záhy se k němu dostaneme.

Toolbox Classes

Informační tok může být podle UML standardu zaznamenán pouze mezi těmito prvky: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition a InstanceSpecification (navíc pokud zdroj či cíl je InstanceSpecification, nemůže jeho typ představovat třídu Relationship či libovolnou její specializaci). Zde je nutné uvést, že Sparx „zapomněl“ toto pravidlo v Enterprise Architectu implementovat a tak lze mít celkem jednoduše (tak, jak v mnoha ostatních případech) nevalidní model.

Informace

Informační tok může přenášet informaci v podobě nějakého klasifikátoru (např. třída) nebo informaci v nedefinované struktuře – třída InformationItem (což je nakonec také klasifikátor). Informace (již zmíněná třída InformationItem) je abstrakcí libovolného typu informace, kterou si mohou objekty mezi sebou vyměňovat. Jde o blíže neurčený klasifikátor pro reprezentaci informace na hodně abstraktní úrovni, tj. na takové, na které z ní nelze vytvořit instanci (prostě proto, že nelze přesně říct, o jaký typ, resp. klasifikátor jde). Informace nemá ani vlastnosti, ani asociace a ani na ni nelze použít generalizaci. Také z ní nelze vytvořit instanci.

Notace: Protože InformationItem je klasifikátor, lze informaci zobrazit jako obdélník s názvem informace a klíčovým slovem «information» nad názvem. Alternativní notace je opět obdélník s názvem a v pravém horním rohu je plný rovnoramenný trojúhelník „ukazující“ doprava (aniž by však měl jakoukoliv spojitost se směrem případného toku!).

Příklad notace třídy InformationItem

Postup v EA: V Enterprise Architectu najdeme Information Item v Toolboxu s objektovými prvky (Object). Pokud to někoho překvapuje, pak si uvědomte, ve kterých situacích to používáte: např. na naprostém začátku projektu při vyjednávání požadavků a prvních rozhovorech o analytických třídách. A zde se bavíte především v instancích.

Toolbox Object

Informace se většinou zobrazuje jako součást informačního toku nebo jako součást vztahu (informačního kanálu), který informační tok realizuje. V prvním případě se zobrazuje název informace poblíž čáry realizačního toku (viz příklad výše). V druhém případě se zobrazí černý trojúhelník směřující k příjemci informace přímo na čáře vztahu. Název informace se pak zobrazí poblíž tohoto trojúhelníku. Pokud vztah realizuje více přenosů informací stejným směrem, pak se zobrazí jen jeden trojúhelník a jednotlivé názvy informací se oddělí čárkou.

Příklad realizace informačního toku

Postup v EA: Abychom určili, které informace jsou informačním tokem přenášeny, potřebujeme již výše zmíněný dialog Information Items Conveyed. Ten se zobrazuje po vytvoření vztahu mezi prvky modelu nebo jej můžeme vyvolat přes kontextové menu informačního toku z položky Advanced ► Information Items Conveyed…  V něm pomocí tlačítek Add a Remove můžeme upravovat seznam informací, které jsou tokem přenášeny.

Dialog Information Items Conveyed

Pro přenesení dat je nutné mít nějaký „informační kanál“, který pak bude daný přenos realizovat. V UML se reprezentuje různými způsoby s ohledem na povahu zdroje a cíle. Těmito způsoby jsou asociacemi, linky, konektory a závislosti.

Postup v EA: Aby se uvedený vztah stal realizátorem informačního toku, stačí málo. Pomocí kontextového menu vztahu Advanced ►Information Flows Realized… vyvoláme stejnojmenný dialog. V něm se zobrazí seznam informačních toků mezi stejnými elementy, jako máme náš vztah. Zde pak stačí zaškrtnout požadované položky.

Dialog Information Flows Realized

Reprezentace informace

Konečně poslední věc, kterou v souvislosti s informačními toky zde zmíním, je reprezentace informace. Jde o vztah mezi informací (InformationItem) a klasifikátory, které budou (na nižší úrovni abstrakce) určovat strukturu dané informace. Těmito klasifikátory mohou být pouze třídy Class, Interface, InformationItem, Signal a Component.

Příklad notace reprezentace informace

Postup v EA: Enteprise Architect zde pro zobrazení používá svou oblíbenou prasárnu, tj. klasickou závislost se stereotypem «representation». Pozor však na to, že ve skutečnost opravdu o žádnou závislost ve smyslu třídy Dependency v UML nejde. V EA tedy můžeme vytvořit závislost a přidat uvedený stereotyp nebo použít ikonu reprezentace v Toolboxu Composite, která dělá totéž.

Toolbox Composite

Odkaz do standardu

• V aktuální verzi UML, tj. v době vydání článku to je 2.4.1, je to kapitola 17.2.
• V beta verzi UML 2.5 je to kapitola 20.

V jedné z nejlepších českých pohádek je scéna, kde podřízený chce navést svého nejvyššího na konkrétní místo v dokumentu. Ten ho však odbude slovy: Mrknu a vidím. Dneska vám představím možnost Enterprise Architecta, která dokáže čtenáře dostat do stejné situace: mrknout a vidět.

Nejprve si nastiňme problematiku. Řekněme, že máme model, ve kterém chceme zvýraznit elementy, které se v rámci projektu změnily, které se přidaly či ubraly a samozřejmě takové, které zůstaly na produkčním prostředí nedotčeny. Informaci budeme uchovávat pomocí následujících stereotypů:

• deployed – říká, že v našem projektu v daném elementu ke změně nedošlo,
• new – oznamuje zavedení nového elementu,
• modified – odkazuje na změnu a
• decommissioned – sděluje publiku, že element byl v rámci projektu odstraněn.

Jeden z takových příkladů může vypadat takto (ke stažení zde):

Stále však nejsme v cílovém stavu. Zde musí čtenář diagramu dost číst, aby „viděl“. Enterprise Architect si tedy nastavíme tak, aby se automaticky každý element přebarvil barvou odpovídající aktuálnímu stereotypu. K tomu potřebujeme nejprve vlézt přes menu Settings ► UML Types… do dialogového okna nazvaného UML Types.

Na záložce Stereotypes si v seznamu najdeme postupně každý z námi zavedených stereotypů a provedeme pro ně následující nastavení: 

Base Class změníme na <all>. Tím bude nastavení platit pro každý element s tímto stereotypem. Pole Notes můžeme změnit, chceme-li. A teď to nejdůležitější: dle libosti si vyberte výchozí barvy pro výplň, okraje a/nebo font. Jakmile budete mít hotovo, je nutné stisknout tlačítko Save.

Máte-li hotovo, pak výsledek může vypadat přibližně takto (za zvolené barvy se omlouvám, na tohle nemám cit):

Jakmile se s barvami sžijete, můžete potlačit zobrazování stereotypů (přes kontextové menu digramu vyberte dialog Properties… a na záložce Elements odškrtněte Show Element Stereotypes) a obrázek bude zase o něco přehlednější, přesně ve stylu Mrknu a vidím.

Pár tipů:

• Pokud nejprve zavedete stereotypy a až pak je nastavíte, pak v seznamu budete mít zavedený pro každý element jeden stereotyp (např. pro třídu a komponentu zvlášť). Buďto tedy nejprve nastavte stereotypy a až pak je u elementů používejte (další změna barvy je pak bez uvedeného efektu) nebo stereotyp dle uvedeného postupu a ostatní stejného jména smažte.
• Stereotyp lze nastavit každému prvku, tedy i např. atributům tříd či vztahům. Má-li to význam, používejte je.
• V případě atributů však nedochází k jejich obarvení (viz uvedený obrázek a v něm výčet).
• V případě vztahů můžete měnit barvu čáry a fontu.
• Každému elementu lze nastavit libovolné množství stereotypů. Enterprise Architect bere barvu podle prvního stereotypu v pořadí.
• Pokročilejší uživatelé mohou využít možnosti měnit nejenom barvu, ale napsat si kompletní skript pro vlastní vizualizaci prvku.
• Nastavení lze přenášet mezi jednotlivými projektovými soubory (*.EAP) pomocí exportu a importu referenčních dat (menu Tools ►Export Reference Data… resp. Import Reference Data…).

A na závěr snad už jen ona scéna, o které jsem mluvil v úvodu. Důležitý okamžik je na druhé minutě a dvaadvacáté sekundě.