Jedním z poměrně hloupých nedostatků UML je, že aktivita i akce mají stejnou základní notaci. Jednou z naprosto neakceptovatelných chyb Enterprise Architekta je, že uživatelům dovoluje zaměňovat aktivity a akce. A nedostatkem uživatelů UML je, že si myslí, že stejná notace uvedených prvků znamená i jejich stejnou sémantiku. Co je tedy z pohledu UML standardu správně a jak vhodně modelovat aktivity a akce v uvedeném nástroji?

Aktivita popisuje libovolné chování pomocí orientovaného grafu, tj. pomocí uzlů a orientovaných hran, které jsou aktivitě podřízené (aktivita je vlastní). Uzly se dělí do tří velkých skupin: řídící, objektové a ty, které něco vykonávají. Jedním typem takových vykonávacích uzlů jsou právě akce. Akce jako taková je dále nedělitelný krok dané aktivity (tímto krokem ovšem může být volání jiné aktivity, ukážeme si dále). Předávání řízení mezi akcemi se děje pomocí tzv. přechodových hran, přičemž UML definuje řídící a objektové hrany. Důležité je dále vědět, že přechodová hrana může být pouze mezi uzly, které vlastní stejná aktivita, která současně vlastní i danou hranu. Jinými slovy, nesmí se stát, že byste namalovali hranu, která vede z uzlu jedné aktivity do uzlu jiné aktivity.

Ukažme si jednoduchý příklad:

Na diagramu je aktivita pojmenovaná „Udělej čaj“, která vlastní, kromě jiného, pět akcí. Tyto akce jsou dále nedělitelné (myšleno v našem modelu, který, jak jistě víte, poskytuje zjednodušený pohled na reálný svět). Jak jsem říkal, notace obou elementů je v této základní podobě shodná. První častou chybou uživatelů EA je skutečnost, že místo akcí používají aktivity. To je špatně! Proč je to špatně, samozřejmě vysvětlím kousek níž.

Pojďme ale prozatím o krok dál. Co se má stát, pokud má sekretářka udělat šéfovi čaj a přinést jej s návrhem dopisu pro představenstvo společnosti? Nejprve ukážu to, co udělá většina nepoučených analytiků:

Co je na obrázku špatně? Řídící tok směrem k aktivitě a poté od aktivity. Ten totiž z definice může vést pouze mezi uzly diagramu aktivit, nikoliv však mezi aktivitami nebo od aktivity k něčemu jinému (akci, rozhodovacímu uzlu…).

Jak to však má být správně? UML mj. definuje akci typu CallBehavior. Jejím úkolem je zavolat některé jiné chování. Notace přidává do pravého dolního rohu „vidličku“ v případě volání jiné aktivity. Akci určíme, které chování má zavolat:

Pokud vám to připadne divné, tak vězte, že taková akce nedělá nic jiného, než že synchronně zavolá jinou aktivitu. Zavolání jiné aktivity je tedy jeden, dále nedělitelný krok. Teď už by vám to tedy mělo být jasnější.

Proč tomu tak je?

Dosud jsem tu jen povídal, jak to má být správně. Ještě než ukážu, jak se s tím vypořádat v EA, řeknu vám, proč je to tak správně. K tomu mi bude sloužit UML 2.5 (druhá beta), ale tytéž informace najdete na podobných místech i ve starších verzích UML 2.x.

Nejprve nahlédněme na základní diagram metatříd pro aktivity:

Na něm vidíme, že opravdu aktivita (metatřída Activity) vlastní uzly (metatřída ActivityNode) a hrany (metatřída ActivityEdge). Dále shledáme to, že hrany vycházejí z nějakého takového uzlu a vedou do nějakého uzlu (dvě asociace mezi ActivityNode a ActivityEdge).

Abych potvrdil další správnost mého výkladu, musíme zjistit, zda aktivita (metatřída Activity) je specializací – ne nutně přímou – metatřídy ActivityNode. Pokud by byla, pak lze vést hranu do a z aktivity. Pokud nikoliv, pak hrana do aktivity vést nesmí (jestliže znáte principy objektově orientovaného návrhu, tak plně rozumíte právě napsanému textu). Důkaz lze provést procházením standardem nebo v EA načtením metamodelu. Pokud věříte mně, pak vám stačí následující obrázek:

Je aktivita, třeba i nepřímou, specializací metatřídy ActivityNode? Nikoliv. Tedy platí tvrzení, že hranu mezi aktivitou a čímkoliv dalším udělá jen ten, kdo neumí UML, nebo ten, kdo si nepřečetl tento článek. A EA mu takovou čuňárnu umožní.

Konečně pro formu si můžete sami dohledat, zda může být hrana mezi uzly různých aktivit (nápověda: hledejte omezení source_and_target metatřídy ActivityEdge).

Jak správně pracovat s EA?

 

Nové modelování 

Začínáte-li nový model nebo vytváříte nový diagram aktivit, pak máte víceméně cestu umetenou. Pro aktivitu použijte v ToolBoxu prvek Activity, pro akci Action.

Pokud akci přetáhnete na diagram, Enterprise Architect vám dát na výběr, který typ akce chcete. Pokud jej nechcete blíže specifikovat, použijte volbu Atomic. Jestliže chcete zavolat jiné chování, vyberte položku Call Behavior.

EA vám zobrazí dialog, ze kterého dané chování vyberete.

Již existující elementy

V případě, že již máte špatně namodelovaný diagram aktivit, kde jste místo akcí používali opět aktivity, ani zde není moc co ztraceno. Označte špatně použitou aktivitu a v menu Element -> Advanced -> Change Type… lze změnit typ prvku.

Bohužel to nefunguje pro více než jeden element najednou.

Závěrem

Je třeba si zapamatovat tři zásadní pravidla:

• Aktivita není totéž, co akce.
• Řídící i objektové toky lze modelovat pouze mezi uzly téže aktivity, nikoliv však mezi aktivitami.
• Chceme-li použít „kód“ jiné aktivity, použijeme k tomu akci CallBehavior.

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.

Dlouho jsem se odhodlával k tomu, abych sepsal nejen to, jaké změny UML 2.5 přináší, ale také to, zda tyto změny mají smysl. Konečně jsem se k tomu dostal, takže se na to nyní pojďme společně podívat.

Trocha historie

Konečná podoba standardu UML 2.0 byla vydána sdružením OMG v roce 2005, tedy dva roky poté, co se s ní seznámilo. Od té doby docházelo pouze k dílčím změnám a opravám, které se ve standardu postupně nacházely (ostatně sám na některé poukazuji v přípravném textu pro certifikaci OCUP). UML standard se skládal ze dvou částí: infrastruktury a superstruktury. První jmenovaná byla především pro vývojáře UML nástrojů a blázny, druhá pak pro uživatele UML jako takového.

Dlouhou dobu se mluvilo o tom, zda připravit UML verze 3.0 nebo zda udělat jen dílčí změny. Bohužel OMG je složeno mj. z několika mezinárodních společností, a kdo v nějaké takové korporaci pracuje, tak ví, že dosáhnout seriosního výsledku je téměř nemožné. A teď si představte, že se takových firem sejde více a každá vnitřně přemýšlí, co do UML zavést a pak ještě musí komentovat návrhy dalších zainteresovaných stran. Je tedy jasné, že výsledek nemůže být ani v rozumné době, a často ani přínosný. Jen opravy drobných chyb trvají roky! Možná právě proto se začalo hovořit pouze o zjednodušení standardu jako takového, ovšem tak, aby koncový uživatel nic nepoznal. Původní termín byl několikrát posunut, jeden z posledních takových byl květen loňského roku. Ačkoliv se OMG probudilo, bohužel zjistilo, že letos, tj. v roce 2014, bude slavit 25 let své byrokratické existence, a tak vše šlo stranou a začaly se připravovat zákusky, šampaňské a dortíky na oslavu. Kvůli tomu tedy máme první beta verzi UML 2.5 vydanou v říjnu 2012, druhou beta verzi v září 2013 a od té doby je ticho po pěšině (zřejmě lemované výsledky bujarých oslav).

Ale abych jim úplně nekřivdil, alespoň v certifikační zkoušce se něco událo (viz dále). Kdy ovšem bude konečná verze UML 2.5, tak o tom se můžeme zatím jen dohadovat. Můj osobní názor je takový, že brzy někomu bouchnou saze a dle úsloví z nouze cnost se druhá beta prohlásí za onu kýženou finální (s opravdu minoritními úpravami).

Změny v UML

Nyní ale již k vlastním změnám. Tou první zásadní a viditelnou je sloučení superstruktury a infrastruktury do jediného dokumentu (což je úspora cca 150 stran) nazvaného čistě a prostě OMG Unified Modeling Language. Druhou, už ne tolik viditelnou, ale zcela nejzásadnější změnou je, že se pro definici UML nepoužívá spojování balíků (třída PackageMerge), ale každá metatřída je definovaná na jednom místě jako jeden celek.

Tuto druhou změnu považuji za poměrně velkou podpásovku a nesmysl. Hned na začátek musím na rovinu uznat, že operace spojení balíků je hodně náročná a k pochopení si musíte pár věcí načíst. To je jediný argument, který pro vypuštění akceptuji. Na druhou stranu UML nepoužívalo všechna pravidla této operace, jen ty nejjednodušší. A teď to hlavní: dříve stačilo nastudovat balík Classes::Kernel (případně přidat velmi jednoduché Classes::Dependencies, Classes::Interfaces a Classes:: AssociationClasses) a uměli jste základ, jádro UML. Mohli jste modelovat třídy, vazby mezi nimi, a jakmile bylo třeba naučit se něco dalšího, stačilo stavět na již naučených dovednostech. Ne však tak již dnes. Např. hned po první kapitole, kde se dozvíte o třídách Element, Relationship, DirectedRelationship a Comment, na vás čekají šablony. Tj. téma, které jednak je např. obsaženo až v poslední úrovni testu znalosti UML a jednak téměř nikdo nepoužívá. U hodnot se pak již standard zmiňuje např. o TimeExpression či Duration (opět, zřídkakdy používaná část UML) či o chování. A mohl bych pokračovat. Nelze tedy jednoduše studovat UML po logicky ucelených blocích postupně a na znalostech stavět. Jestli tím chtělo OMG podpořit prodej knih o UML, těžko říct. Ale dle standardu se již UML těžko naučíte. Hodně těžko.

Pojďme ale dál. Snahou tvůrců nové verze bylo maximálně omezit nutnost mít tzv. dopředné znalosti, tedy ve výkladu použít něco, co se teprve bude probírat v pozdější kapitole. Musím uznat, že tohle se vcelku povedlo. Jako důsledek toho je nejen jiné členění kapitol, ale i jiné rozdělení UML do jednotlivých balíků (viz následující obrázek, kde je náhled na část UML 2.4.1 a 2.5 načteného do Enterprise Architekta).

Ve standardu již nenajdete úrovně shody s UML dle úrovní L0 až L3 čistě proto, že to nikdo nepotřeboval a nepoužíval. Jestliže totiž některý současný nástroj chce podporovat UML, tak ho podporuje celý. Tedy… snaží se. Ne však vždy zcela správně.

Změn doznala i struktura základního vysvětlování dané oblasti, tedy notace, sémantika, pravidla a další potřebné věci. V UML od 2.0 až do 2.4.1 včetně byla za začátku každého celku (např. balík Classes) kapitola nazvaná Abstract syntax, kde byly diagramy vztažených elementů. Poté následoval popis každého elementu (tj. elementy, ze kterých je odvozen, popis, atributy, asociace, omezení, sémantika a notace), který byl touto částí definován. Na závěr pak byla souhrnně zobrazena notace. Výhoda byla, že když jste potřebovali něco vědět o konkrétním elementu, měli jste to na jednom místě. Pokud jste potřebovali znát, jak tyto elementy fungují dohromady (např. kompozitní struktury), museli jste hodně listovat.

UML 2.5 se k tomu staví jinak. Každý balík má krátké shrnutí na začátku a poté je rozdělen do podoblastí (např. balík Simple Classifiers popisuje v jedné části datové typy, v jedné signály a v jedné rozhraní). Každá takováto podoblast ukazuje diagram relevantních prvků, popisuje sémantiku, notaci a uvádí příklady. Velkou výhodou je, že vidíte, jak tyto prvky spolu souvisí a jak se případně doplňují. Poté následuje část nazvaná Classifier Descriptions, ve které jsou již formálně uvedeny diagramy, kde se prvek nachází (paráda!), prvky, od který je ten popisovaný nejen odvozený, ale i další, které z něj vycházejí (paráda!), asociační konce a omezení. Jestliže však chcete mít popis elementu na jednom místě, máte smůlu, což je neskutečný průser. UML standard má fungovat jako reference a tento způsob to neumožňuje! Sám tedy používám pro hledání informací jak UML 2.4.1, tak i 2.5, a to na základě toho, co potřebuji zjistit.

Dosud jsme se bavili jen o změnách ve struktuře dokumentu, ale verze 2.5 přináší i pár drobných změn, které postřehne málokdo (a pro málokterého z uživatelů má nějaký sebemenší význam). Takže jen ve zkratce:

• Autoři se snažili opravit všechny chyby v omezeních (constraints) definovaných pomocí OCL. Konečně!
• Několik násobností s dolní hranicí 1 bylo posunuto na 0.
• Informace {ordered} byla někam přidána a někde naopak odebrána, aby to jako celek dávalo smysl.
• Vlastnost LoopNode::loopVariable je nyní kompozitní.
• NamedElement::clientDependency je nově odvozená vlastnost (derived).

Změny v certifikačních zkouškách OCUP

O změnách v certifikační zkoušce jsem toho už napsal poměrně dost, stačí se podívat na mé první informace o změnách a o průběhu testu. Zde tedy jen pár základních bodů, které jsou důležité či které mě zaujaly z přechodu z OCUP na OCUP 2:

• Zkouška první úrovně se přejmenovala z Fundamental na Foundation.
• Prozatím lze skládat pouze úroveň Foundation a pokud máte úroveň Fundamental, pak i další dvě úrovně (více v článku o certifikační schizofrenii, časem se snad to srovná).
• Konečně je test zaměřen mnohem víc na praktické znalosti uživatele UML nežli na akademické znalosti standardu.
• Platnost certifikátu OCUP2 bude pět let. Certifikáty OCUP platí na doživotí, ale jsou již označovány jako zastaralé (obsolete).

Podrobnější informace pak najdete již v uvedených článcích.

Mělo to tedy smysl?

Co se UML jako takového týče, tak rozhodně ne. Nebýt vypuštění používání třídy PackageMerge ze standardu, změnu bych uvítal. Ale takhle to byla zbytečná práce. Vynaložené úsilí se mělo věnovat na opravu chyb a definování některých požadovaných změn.

U zkoušek OCUP (2) jsem naopak moc rád, že ke změně došlo (a to bez ohledu na to, že já vynaložil mnoho času na text pro zkoušku úrovně Advanced a teď evidentně bude mnohé jinak). Konečně to prověří nejen teoretickou znalost UML, ale prokáže, že nad tím umíte přemýšlet, že UML dokážete použít a koneckonců to něco vypoví i o vašich znalostech objektově orientovaného světa. A to je dobře.

Povedlo se, stále ještě něco umím i z úplných základů UML. Z 90 otázek 80 dobře sice není úplně můj vysněný výsledek, ale 4 chyby z oblasti Why We Model se daly čekat (viz má kritika).

V současné době vládne jakési dvojvládí na trůnu certifikace znalostí UML. Původní OCUP (OMG Certified UML Professional) se skládá ze tří úrovní: Fundamental, Intermediate a Advanced a odpovídá metamodelu do verze 2.4.1. Nová verze zkoušek, tj. OCUP 2 se skládá také ze tří úrovní: Foundation, Intermediate (podmínky zatím nebyly nestanoveny) a Advanced (podmínky zatím nebyly nestanoveny) a odkazuje se na UML 2.5 (ta je ovšem stále v druhé beta verzi, na stránce OMG se však odkazuje na první betu; mají v tom nepořádek).

Co tedy dělat, chcete-li skládat zkoušku? Inu, to záleží na tom, jakou byste rádi měli. OCUP Fundamental již dle prohlášení OMG absolvovat nelze (viz krátká zpráva na webu Pearson VUE). Pokud ji ale máte, můžete ještě po omezenou dobu složit další dvě. Jestliže si zakládáte certifikáty na stěnu, tak máte výhodu, že staré zkoušky platí doživotně. Nemáte-li dosud žádnou zkoušku, musíte již začít již tou novou, tj. OCUP2 Foundation. Ta má platnost pět let od vydání certifikátu. Další dvě zkoušky zatím skládat nelze, neboť nejsou připravené. Údajně se na to pracuje, ale dosud nejsou známy ani požadavky, natož aby proběhlo testování.

A jak je na tom stránka OCUP.cz resp. její podoba v elektronické knize? Ta stále nabízí přípravu pro OCUP Fundamental a OCUP Intermediate. Jestliže se chcete připravit na OCUP2 Foundation, nevěšte hlavu. UML 2.5 sice přináší značné překopání celé struktury metamodelu, ve skutečnosti však v ní pro uživatele vlastně žádné novinky nejsou (jen drobnosti). Takže ze stránek OCUP.cz lze stále studovat a připravit se na zkoušku Foundation. Co si z uvedených stránek načíst, jsem již uvedl v dřívějším článku. Také doporučuji podívat se na to, jak testovací běh zkoušek vypadal.

A na závěr snad pozitivní novinka. Usilovně pracuji na přepracování stránek tak, aby co nejdříve odpovídaly nové verzi zkoušek, tedy prozatím oficiálně vydané OCUP2 Foundation.

Na webu se objevila poměrně samovypovídající prezentace o IFML, kterou nedávno přednesl Marco Brambilla, spoluautor této specifikace. O IFML jsem tu psal již loni, od té doby přišla na svět druhá beta verze a vydání té finální je na spadnutí.

Konečně jsem se téměř před měsícem rozhodl podstoupit poslední certifikační zkoušku z UML, ve schránce jsem v pátek našel obálku s příjemným obsahem.

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.

Dneska jsem měl tu čest absolvovat zkoušku OCUP 2 – Foundation Level (kód OMG-OCUP2-FOUND101) v její beta verzi, o které jsem tu nedávno psal. Ještě za čerstva bych se rád podělil se svou zkušeností.

Především musím říct, že testové otázky jsou postaveny mnohem blíže k uživatelům UML nežli k akademikům, kteří sice znají jednotlivé klky střev UML, ale s každodenním používáním tohoto jazyka to nemělo moc společného. Pokud zkouškou projdete, bude to mnohem více vypovídat o tom, jak UML umíte používat.

Protože jde o otázky ve zkušební verzi, najdou se samozřejmě nějaké ty chybky. Např. jste dotazováni na věci, které v požadavcích na zkoušku nejsou uvedeny (např. jedna otázka byla na třídu Port). V zadání jedné otázky jsem našel chybu (guard v diagramu aktivit nebyl v hranatých uvozovkách). Co mě však vytáčelo, byly otázky směrované do oblasti „Why we model“, protože to byly klasické dotazy na měkké dovednosti. V takových otázkách akorát odhadujete, která odpověď uspokojí tazatele. A 15% podíl takových otázek v testu je přespříliš.

Pokud se na zkoušku chystáte (ať už na betu nebo na finální), uvádím pár věcí, na které byste rozhodně neměli zapomenout (a které si pamatuji, že tam jsou):

• Dávejte dobrý pozor na to, na co se ptají. Někdy záleží na slovíčku (např. když v zadání otázky mají i abstraktní třídy a vás se ptají jen na ty, ze kterých lze vytvořit instance).
• Naučte se dobře viditelnosti a jmenné prostory (může mít balíček v sobě balíček stejného jména? Může balíček obsahující třídu A s atributem private vidět jeho hodnotu?)
• Dost otázek mělo v zadání diagram tříd a vy jste měli vybrat jeden ze čtyř objektových diagramů, které odpovídají zadanému diagramu tříd.
• Podívejte se na násobnosti asociace aktora s use casem (ostatně z případů užití vás proklepnou opravdu důkladně).
• U akcí si zapamatujte, že je tato spuštěna jen v případě, že má tokeny na všech vstupních hranách.
• Zapamatujte si notace parametru a pinu u aktivit/akcí.
• Mrkněte na notaci akce pro volání jiné aktivity a pro volání metody nějaké třídy.
• U sekvenčních diagramů si řádně procvičte ona dvě známá pravidla pro hledání platné sekvence. A pak samozřejmě typy volání (synchronní, asynchronní…)
• Jak se zobrazují pre- a post-contions u akcí? Kdy se vyhodnocují?
• Kdy použít datový typ a kdy třídu?
• Jak se dají zobrazit prvky balíčku?
• U stavových diagramů doporučuji mít hodně zažité výskytu události a princip triggerů, podmínek a efektů.
• A další.

Jestliže jste zkoušku absolvovali, připojte komentář s vašimi postřehy, ostatním to může pomoci.