I přes vánoční svátky se mi podařilo občas spustit Visual Studio, a tak mohu představit další novinku v Aktivních diagramech, kterou uživatelé chtěli.

Nečastějším požadavkem byla potřeba znát, zda diagram v dokumentu je či není vložen pomocí rozšíření Active Diagrams. Nyní není nic jednoduššího, než si zobrazit panel s informacemi o diagramu:

Pokud je obrázek (diagram) v dokumentu označen a je vložen pomocí Active Diagrams, uvidíte základní data nejen o diagramu jako takovém, ale zvíte i datum vložení do dokumentu a poslední aktualizaci.

Okno s těmito informacemi se vyvolává na již známém místě – na záložce s doplňky. Ty jsou rozšířeny kromě jiného o zaškrtávací pole, které zobrazí nebo schová požadované informace.

Další dvě nová tlačítka pak slouží k:

1. Spuštění Sparx Enterprise Architecta s repository připřazenou k dokumentu.
2. Spuštění výchozího prohlížeče se stránkou produktu.

Rozšíření si jako obvykle můžete stáhnout, případně si o něm přečíst jako o celku.

 

Tři týdne stačily k tomu, abych udělal novou verzi rozšíření Active Diagram. Dnes není sice novinek tolik, vlastně je jen jedna, ale o to zásadnější.

Pokud chcete vložit nový diagram, již nemusíte kopírovat GUID diagramu ze spuštěného Enterprise Architectu, ale Active Diagram zobrazí stromovou strukturu odpovídající Project Browseru.

V ní jsou pak vidět jednotlivé balíky (packages) a diagramy. Jakmile diagram vyberete, vloží se do dokumentu. Stará možnost zůstala zachována, najdete ji na třetí záložce daného dialogu (viz obrázek).

S tím souvisí i to, že bylo třeba aktualizovat i návodné video, takže pokud chcete vše vidět, pusťte si jej.

Rozšíření si jako obvykle můžete stáhnout, případně si o něm přečíst jako o celku.

Sparx ke konci listopadu vydal novou verzi svého nástroje. Vyzkoušel jsem čtyři novinky, kterými se chlubí, a musím se přiznat, že pro mě jsou zklamáním. Proč?

Automatické obarvování prvků na diagramu

To, že můžete automaticky měnit barvu obrysů a výplní prvků na diagramu, jsem tu již psal. Tehdy to bylo možné pomocí stereotypů. Nyní však Sparx (konečně) přišel na to, že by tak mohl činit i na základě legendy diagramu. Dosud jste totiž legendu mohli jen zobrazit, ale dobarvovat jste museli ručně.

Definice legendy není nijak strašná, ostatně mrkněte na obrázek. Vyberte filtr, zadejte podmínku a barvy a vše funguje.

Legend lze na jednom diagramu mít víc a zapínat je dle potřeby. Pokud byste chtěli použít dvě legendy na tutéž vlastnost (např. výplň), pak se bere v potaz Z-pořadí legend.

Potud to je víceméně fajn. Problém však nastává, když chcete diagram přenést např. do dokumentu či mailu a přitom nechcete přenášet i legendu (typicky v případě, kdy máte třeba deset diagramů, nemá smysl mít zobrazenou legendu na každém z nich). To však bohužel nejde – tedy, lze potlačit výběr a tisk, ale do dokumentace či do souboru nemáte šanci s tím něco udělat.

Info View

EA dokáže zobrazit další pohled na element a to jako tzv. informační náhled (Info View). Na obrázku vidíte, jak to může vypadat.

Co mně na tom vadí?

• Musím to nastavit pro každý prvek zvlášť. Čekal bych, že to bude možné nastavit i pro celý diagram.
• Proč to není zobrazované jako další oblast (compartment)? Rád bych viděl jak atributy, tak i další informace.
• Nefunguje na to výše zmíněné obarvování dle legendy.

Virtualizované zakončení konektorů

Tohle budete znát např. z UML standardu, kde se na některých diagramech objevuje vícekrát tatáž třída. Virtualizace spočívá v tom, že ona třída je v modelu pouze jednou, avšak na diagramu je použita vícekrát. Od verze 12.1 to umí u EA.

Na příkladu níže existují v modelu dvě třídy: Osoba a Adresa. Osoba díky asociacím pak má jednak trvalou adresu a jednak fakturační adresu. Díky virtualizaci zobrazím Adresu pomocí dvou prvků na diagramu.

Netuším, jak moc tato funkčnost bude využívána, osobně si myslím, že spíše čtenáře diagramů mate.

Současné řešení v EA má však mnohá úskalí:

• Špatně na to fungují poziční operace.
• Nefunguje synchronizace tagových hodnot.
• Nefunguje na to dobře změna barev dle legendy.
• Když chci smazat virtuální element, zruší to celou vazbu. Čekal bych alespoň dotaz, zda zrušit pouze virtuální zakončení.
• Atributy apod. si zobrazím pouze na jednom prvku.

Nápověda

Do předchozí verze byla nápověda v CHM formátu a dalo se v ní pěkně vyhledávat a číst. Dnes? Humus. Při stisku F1 se otevře okno internetového prohlížeče a máte k dispozici nějakou stránku. Vyhledávání je čaroprostá hrůza. Na webu a potažmo i v EA (viz obrázek). Jako kluci sorry, ale tohle mě opravdu vytočilo.

Závěr

Podle mého jde o jakési vlastnosti dodané vývojáři. Uživatel, který by rád nástroj používal, má tak smůlu. Snad se to co nejrychleji změní.

Po čtrnácti dnech přichází první aktualizace rozšíření Active Diagrams. Co přináší?

• Nové: V dialogu pro zadání repository EA je v rozbalovacím seznamu možno vybrat až z deseti naposledy použitých repository, které jste za poslední dobu otevřeli v EA.
• Nové: V dialogu pro zadání repository EA je tlačítko na procházení disků s možností vybrat souborovou repository (přípona .EAP).
• Nové: Pokud uživatel již má v dokumentu nějaký diagram a snaží se změnit repository, je dotázán, zda to myslí vážně (typicky může přijít o možnost aktualizace již vložených diagramů).
• Opraveno: Návodný text je u všech tlačítek na záložce s rozšířeními (stačí na ně najet myší).
• Opraveno: Pokud uživatel vložil nějaký diagram a poté změnil repository, rozšíření se snažilo načítat diagramy z původního místa.

Jestliže jsou tyto změny přímo pro vás, můžete začít stahovat instalační soubor.

Občas chvíli trvá, než se z myšlenky stane hmatatelný výsledek. Mně se po mnoha letech podařilo dát dohromady vcelku jednoduchou věc: diagramy, které kopíruji z Enterprise Architecta do wordového dokumentu, tak se na stisk jednoho tlačítka v daném dokumentu samy aktualizují.

Toto přání jsem měl několik let, ovšem teprve minulý a tento měsíc jsem jej dokázal realizovat do podoby rozšíření pro Microsoft Word nazvané Active Diagrams.

To, jak to uživatelsky funguje, můžete vidět na videu níže. A pokud vás to zaujalo, tak můžete rovnou přejít na stránku, které je tomuto produktu věnována a to včetně možnosti stažení.

Budu rád, pokud vás zaujme a přijdete s dalšími možnostmi na vylepšení.

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.

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.

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.