Loni těsně před Vánoci v tichosti vyšla nová verze UML označená jako 2.5.1 (přechozí je 2.5). Z toho je jasné, že změny budou jen drobné. Pojďme se na ně podívat.

Číst více

Musím se přiznat, že chování OMG nechápu. V naprosté tichosti na stránkách uml.org vystavila finální verzi UML 2.5. No dobře, tak se tím nechlubí (ostatně byrokratické kolo se točilo bezmála čtyři roky). Co mi ale vadí, je naprostá ignorance změnového dokumentu, tedy vyznačení, co se od druhé beta verze změnilo.

Přitom v předchozích verzích to tak fungovalo. Jen namátkou uvádím odkazy na změnové dokumenty mezi betami 1 a 2 verze 2.5  nebo mezi UML 2.2 a 2.3. Takže, změnilo se vůbec něco mezi druhou betou a finální verzí?

Pokud se podíváme na XMI soubor pro UML, tak ani náhodou (obsah je stejný již od roku 2013). A to tam jsou prokazatelné chyby. Porovnat dvě verze PDF je víceméně nemožné. Zkusil jsem alespoň zkopírovat text z PDF dokumentů a porovnat je, ale odradilo mě to (viz obrázek – v jednom dokumentu jsou diagramy jako obrázky, v druhém pak lze např. kopírovat text rolí). Řádkování je také jiné.

Při procházení zájmových skupin jsem žádnou zmínku o změnách nenašel, kolega Google mlčí. Vložil jsem tedy dotaz do jednoho fóra na LinkedIn, uvidíme, zda se něco objeví.

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.

Před několika málo dny byla vydána dlouho očekávaná první beta verze UML 2.5. Pokud můžeme věřit tomu, co se o ní šíří po Internetu (dobré je sledovat např. Eda Seidewitze), pak by měla obsahovat především zásadní zjednodušení jazyka jako takového. Zřejmě nejdůležitější je zrušení konceptu infrastruktury a superstruktury a nepoužívání operace merge (viz PackageMerge) v metamodelu.

Sám jsem se zatím dokumentem neprokousával, ale jakmile najdu trochu času, budu zde průběžně psát své pocity z nové verze.

UML už tu pár let je a prošlo si vlnami nadšení i kritiky. Kam se může ubírat ukazuje téměř dva roky starý článek od Ivara Jacobsona a Steva Cooka. Doporučuji k přečtení a zhodnocení současné situace.

OMG nedávno provedla test vybraných nástrojů, ve kterém se zaměřila na jejich schopnost pracovat se standardizovaným formátem pro výměnu dat mezi modely (XMI). Celkem se provedlo na 16 testových scénářů v aplikacích firem Atego, IBM, NoMagic, Sodius, SOFTEAM a Sparx Systems (poslední jmenovaný dodává mnou používaný Enterprise Architect).

Předseda skupiny, která se formátem pro výměnu dat zabývá, mj. prohlásil: The ability to interchange models offers the potential to significantly improve productivity, quality, and the long term retention of models. Volně přeloženo s přihlédnutím mezi řádky: test dopadl katastrofálně. Výrobci musí vyvinout ještě mnoho úsilí, než dosáhnou uživateli požadovaného výsledku (totiž aby to fungovalo správně).

Ku dobru všech firem je ale nutné přičíst, že na testu spolupracovaly a všechny chyby, které se v průběhu testu našly, byly opraveny. Současně dodávané verze by tedy všemi scénáři nyní prošly bezchybně.

Důležitější je ale zřejmě ohlášení normativního XMI (Canonical XMI). XMI tak, jak je dnes definováno, nabízí poměrně dost volitelných možností, jak např. element či atribut zapsat. Proto vzniklo normativní XMI, které utahuje popuštěnou uzdu volnosti. Teď už jen, aby to všechny významné nástroje začaly plně podporovat.

Odkazy:

• Všechny testové scénáře
• Původní tisková zpráva OMG

V UML 2.4.1 ze srpna 2011 (betu 2.4 můžeme ignorovat) došlo k poměrně dosti změnám v diagramech. V mnoha se do diagramu přidaly (existující) třídy, takže je to obecně hůře čitelné a je třeba trávit více času nad jednotlivými diagramy. Obzvláště nečitelný je např. diagram strukturovaného uzlu (Activities::StructuredActivities). Připadne mi to značně kontraproduktivní. Opět uvádím změny především z Classes::Kernel.

• Kapitola 7: Drobné změny v úvodní kapitole Reusing packages from UML 2 Infrastructure.
• Kapitola 7: Změna v diagramu Expressions diagram of the Kernel package. Přibyla třída LiteralReal.
• Kapitola 7: Změna v diagramu Classifiers diagram of the Kernel package. Jde především o pojmenování rolí tříd v asociacích.
• Kapitola 7: Jinak zakreslen diagram Features diagram of the Kernel package. Jinak a mnohem hůř. Zobrazení několika tříd vícekrát „pro lepší čitelnost“ tu čitelnost naopak zhoršili. Navíc z obrázku vyhodili výčet ParameterDirectionKind a nedali nikam jinam. V textu knihy jsem jej v obrázku záměrně nechal. Dále zde není zakreslena třída ValueSpecification, která byla přesunuta do diagramu Operations diagram of the Kernel package.
• Kapitola 7: Překreslen diagram Operations diagram of the Kernel package. Zásadní změna je v tom, že jsou zde více formalizované výchozí hodnoty všech atributů třídy Operation. Oproti předchozímu mi tento naopak připadne obsažnější než v předchozí verzi a to bez zhoršení čitelnosti.
• Kapitola 7: Překreslen diagram Classes diagram of the Kernel package, přidání výchozích hodnot atributů tříd Property a Association.
• Kapitola 7: V diagramu DataTypes diagram of the Kernel package přibyla vazba mezi třídami EnumerationLiteral a Enumeration. 
• Kapitola 7: V diagramu The Packages diagram of the Kernel package došlo k pár drobným, nevýrazným změnám.
• Kapitola 7: Překreslen diagram Contents of Dependency package. Jde ale o čuňárnu. V původních verzích bylo (zcela správně) používáno kvalifikovaných jmen u relevantních tříd. Dnes je tam pouze v závorce uvedeno, ze kterého balíku třída pochází. Není to dobrý příklad, jak kreslit diagramy podle UML. V textu používám lepší zápis. Jinak ale jde o zpřehlednění a při čtení se lépe hledají souvislosti. Vypadla (jen ze zápisu, nikoliv ze standardu) asociace mezi třídami NamedElement a Namespace.
• Kapitola 7: Překreslen diagram Contents of Interfaces package.
• Kapitola 7.3.38: Třída Package má nový atribut URI.
• Kapitola 7.3.45: Třída Property má nový atribut isID.
• Kapitola 7.3.55: Třída ValueSpecification má novou metoda realValue(). Ta souvisí s novou třídou LiteralReal.
• Kapitola 7.3.39: Třída PackageableElement má opravenou výchozí hodnotu atributu visibility z false na public (původní hodnota byla chybou standardu).
• Kapitola 7.3.29: Přibyla nová třída LiteralReal.
• Až do UML 2.3 byla kapitola PrimitiveTypes součástí superstruktury. UML 2.4.1 ji však přesunulo do infrastruktury. Pro znalost primitivních datových typů je tedy třeba sáhnout do 13 kapitoly infrastruktury. Další novinkou v této oblasti je nový typ Real. V superstruktuře (balík Classes::Kernel) pak najdeme odpovídající třídu LiteralReal a dále novou motody třídy ValueSpecification nazvanou realValue().

Jak jsem před pár dny slíbil, napsal jsem postup, jak si importovat UML standard 2.4.1 do Enterprise Architecta. Zde překládám všechny jeho kroky.

1. Je nutné mít Enterprise Architect verze 9.2.
2. Stáhněte si XMI podobu specifikace, konkrétně tyto soubory:
   1. PrimitiveTypes.xmi
   2. Infrastructure.xmi
   3. Superstructure.xmi
3. V EA si zvolte balík, do kterého chcete standard importovat.
4. V kontextovém menu balíku zvolte možnost Import Model from XMI…
5. Zadejte soubor PrimitiveTypes.xmi (věcí v Options si všímat nemusíte, pokud si s tím chcete pohrát, můžete).
   

   Dialog Import Package from XMI

6. Stiskněte tlačítko Import.
7. Čekejte. Aplikace bude chvíli chroupat, během čehož vytvoří požadované elementy.
8. Zopakujte kroky 5. až 7. pro soubory Infrastructure.xmi a Superstructure.xmi.
9. Stiskněte tlačítko Close.

A je hotovo. Ve vybraném balíku máte tři další: PrimitiveTypes, InfrastructureLibrary a UML (což je superstruktura).

Importovaný UML standard

Co importem získáte? Budete mít v modelu všechny třídy včetně vazeb, jejich atributy a metody a umístění v balících. U atributů a metod dostanete krátký popis jejich významu.

Co naopak mít nebudete? Nedostanete hlavně diagramy. Pokud chcete i je, musí bohužel nastoupit ruční práce (ta vaše). Dále nebudete mít základní popis významu tříd, nebudou tam omezení a další.

Podle stránek produktu by „éáčko“ verze 9.2 mělo umět načíst specifikaci UML 2.4.1 dodávanou mimo jiné v XMI (připomínám, že XMI je součástí standardu). EA tento formát již nějakou tu dobu podporuje, ale standard se mi do něj dosud nepodařilo načíst. Jakmile budu mít prodlouženou licenci nástroje, vyzkouším to.

Při pročítání UML verze 2.3 a psaní nových textů pro OCUP.CZ jsem narazil na pár změn v UML 2.3 proti předchozí verzi. Nejsou tu samozřejmě vypsány všechny, ale jen takové, které mě (jakkoliv) zaujaly. Nejvíce se starám o balík Classes::Kernel.

• Kapitola 5: Byla odstraněna původní relativně bezvýznamná věta a nyní se zabývá významem slov typu „musí“, „nesmí“, „měl by“, apod. Jde o odkaz na RFC 2119. Dále se zabývá anotacemi v některých příkladech uvedených ve standardu.
• Kapitola 7, Diagram 7.9
• Role u Property již neobsahuje subsets feature.
• Třída Classifier má nový atribut isFinalSpecialization: Boolean
• Třída Generalization má nový atribut isSubstitutable: Boolean [0..1] = true
• Kapitola 7.3.3: V třídě Asociation přibyla věta v úvodním popisu: A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.
• Kapitola 7.3.4: Změněn popis asociační třídy a sémantika.
• Kapitola 7.3.8: Třída Classifier má nový atribut isFinalSpecialization (viz popis klasifikátoru).
• Kapitola 7.3.11: V popisu sémantiky třídy DataType je místo slovíčka „equal“ používáno „same“. Jde tedy o drobné zmírnění podmínek, v mém českém překladu bez dopadu na význam.
• Kapitola 7.3.35: Rozšíření definice atributů třídy OpaqueExpression.
• Kapitola 7.3.40: Změny v pravidlech třídy PackageMerge. Je vhodné si pročíst, ale stále platí to, co je uvedeno v textu.
• Kapitola 7.3.46: Popsán vliv atributu isLeaf třídy RedefinableElement na operaci spojení balíků (třída PackageMerge).