To, co jsem tu již několikrát sliboval, se dnešním dnem stává realitou. Po několika týdnech strávených nastavováním a tvořením testů mohu směle prohlásit, že je hotovo. Vy všichni, kdo si chcete prověřit své znalosti UML, máte nyní velmi jednoduchou možnost. Jak na to? Vezměme to postupně.

1. Veškerá nabídka testů (a v budoucnu i kurzů) je na nově spuštěném webu http://www.kurzy-uml.cz.
2. Abyste nekupovali zajíce v pytli, můžete si nejprve vše vyzkoušet na ukázkovém testu. Ten má 6 otázek a ukazuje, jak vypadají i ostré testy.
3. Plnohodnotných testů máte k dispozici tři (zatím). Každý z nich umí něčeho více, něčeho méně. Doporučuji srovnávací tabulku.
4. Testy můžete platit kartou (přes PayPal) nebo si objednat a peníze poslat z účtu na účet.
5. A teď možná to nejzajímavější. Pokud absolvujete plnohodnotý test během tohoto měsíce, máte možnost získat tričko uvedené v tomto příspěvku. Podmínky najdete opět na novém webu.

V závěsu testů UML přichází další slibovaná novinka. Celý tento blok jsem přesunul z Bloggeru na WordPress a navíc trochu změnil adresu. Ale to je opravdu jen na okraj.

Užívejte si tedy testů, já si přes Velikonoce odpočinu a poté se vrhnu na tvorbu slíbených kurzů. Zřejmě začnu Enterprise Architectem, neboť již mám většinu textu napsanou.

Předminulý týden jsem měl povídání o často dělaných chybách uživatelů UML. O některých jsem již psal i na těchto stránkách. Prezentaci můžete zhlédnout níže.

Pokud vás některý zaujal více a nevíte si s ním rady, dejte např. v komentářích vědět a já se tu o něm rozepíšu.

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.

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.

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.

Na Internetu jsem narazil na myšlenku psát si (vlastně modelovat) blog v UML. Zaujala mě. O čem bych modeloval? Jaké diagramy bych používal? Osobně nemám moc rád strukturální diagramy, protože se v nich nic neděje, ale na druhou stranu pro zápis vět typu „byl jsem tam a tam“ diagramem aktivit nepřináší UML žádnou přidanou hodnotu. Přepis rozhovoru např. mezi mnou a dětmi v sekvenčním diagramu může vypadat pěkně jednou, dvakrát, ale pak se to ohraje.

Přesto jsem o tom přemýšlel dál a vzpomněl si na objektové diagramy. Pokud si udělám rozumný doménový model a poté vytvořím objektový diagram, možná by se v tom něco jako příběh mohlo najít. UML je hodně intuitivní i pro lidi, kteří jej neznají, takže by z toho mohli něco mít. Pohrál jsem si s tím a tady je můj záznam z úterý. Co z toho vyčtete?

class Workout Domain Model

object Tuesday

Obálka knihy

 Díky recenzi Reného Steina (kterého jsem sice dosud nepotkal osobně, ale dle jeho vystupování a prezentaci na internetu považuji za přirozenou autoritu) jsem se dostal ke knize Masterminds of Programming: Conversations with the Creators of Major Programming Languages. Jedná se o sbírku rozhovorů s tvůrci různých (tedy nejen programovacích) jazyků. A to včetně UML.

UML dostalo v knize tu výsadu, že autor vedl fundovaný rozhovor hned se třemi jeho (hlavními) tvůrci: Ivarem Jacobsonem, Jamesem Rumbaughem a Gradym Boochem.

Protože tématem hovorů není pouze UML, ale mnoho věcí spojené s návrhem, dovolil jsem si pro mě zajímavé myšlenky, nápady či jen zmínky o čemkoliv vypsat a případně mírně okomentovat. Neberte tedy mé povídání jako recenzi knihy, ale jako mé vlastní názory na věci, které uvedení pánové zmiňují.

Poznámka: Citace (jsou psány kursívou) z knihy jsem překládal sám, takže je prosím neberte jako směrodatné.

Ivar Jacobson

• Případ užití (dle definice) popisuje chování systému z pohledu uživatele. Ivarova zkušenost napovídá přistupovat k systému jako k černé skříňce: svým způsobem má pravdu pro případ, že se bavíme o sběru požadavků, kdy od uživatele chceme znát, co požaduje. V praxi se často setkávám s uživateli, kteří do daného systému trochu vidí (ale už ne mimo něj) a snaží se business konzultantům (hlavně nováčkům) radit nebo říkat nikoliv co potřebují, ale jak to potřebují. Konzultanti pak přijdou s řadou nesmyslných požadavků, které se musí v tom lepším případě narovnat, v tom horším nemilosrdně zahodit. Analytik však již s případy užití musí pracovat jinak: systém pro něj musí být zcela jasnou doménou, kterou ovládá.
• Tip na knihu: Kurt Bittner, Ian Spence: Use Case Modeling (ostatně Ivar pro ni napsal předmluvu)
• „Každý případ užití definuje množinu scénářů, které popisují, jak jsou implementovány pomocí spolupráce mezi jednotlivými třídami a komponentami.“ Škoda, že se nerozmluvil trochu o tom, že vývoj řízený případy užití (use-case driven development) mnozí považují již za překonaný. Také by mě zajímal jeho pohled na diagramy složených struktur dodané právě v UML 2. Sám je považuji za poměrně silný nástroj, bohužel již ne tak intuitivní jako jiné typy diagramů.
• Líbí se mi jeho (skrytá) kritika metodiků, kteří přijdou, seřadí si celé IT, tři dny do nich hustí novinky, které se pak musí ihned začít používat: „Namísto šíření znalostí všeho o všem […] je třeba představit v jednom okamžiku pouze jednu věc, a to takovou, kterou v danou chvíli nejvíce potřebujete.“
• „Ty opravdu náročné věci se na universitách nenaučíte.“ Do kamene tesat! Jeho kritika výuky na vysokých školách mě však překvapuje. Chápal bych, kdyby mluvil o systému zavedeném u nás v České republice, ale i v zahraničí?
• „Náš pohled na způsob vývoje se dramaticky mění co dva až tři roky. Je to mnohem častěji než proměny v již tak vrtošivé módě.“ A poté hned dodává, že zaručené nové metodiky jsou často jen jinak pojmenované staré. A vše se veze na vlně dobrého marketinku. Ano, i zde smutně souhlasím a mnohem smutněji zažívám. Celé to vede k té nepříjemnosti, že „pokaždé, když změníme zaměstnání, tak se musíme učit nové přístupy k vývoji, než se do něj můžeme zapojit. To není efektivní, protože namísto používání toho, co již známe, musíme znovu a znovu začínat od píky.“
• Na druhou stranu dále popisuje, jak by to mělo být a to není nepodobné agilnímu přístupu, tedy přístupu, které dnešní čeští „manažeři“ s MBA dávají za každou cenu zelenou. Nechci úplně tvrdit, že si Ivar protiřečí, ale malý rozpor v tom vidím.
• Ivar neskutečně trefně reje do současné podoby podnikových architektů (enterpise architects) jako do partičky projektů se neúčastnících individuí, která si jen kreslí své architektonické obrázky. Mou přibarvenou interpretaci jen doplňuji, že to matlají ve Visiu, ti zkušenější přímo v PowerPointu.
• „Nikdy jsem nevěřil, že by lidé mohli používat RUP tak, jak se pokoušejí ho používat. RUP totiž musíte používat více jako znalostní a myšlenkovou databázi a pak pracovat dle toho, co pro vás dává smysl.“
• Asi každý rozumný člověk zná, ale přeci jenom: „Namísto učení se velkých metodik nebo jazyků jako je UML či Java, zaměřte se na praktickou stránku věci. Zkoušení si je lépe zvladatelné.“
• Celkem jasně vyznívá jeho kritika OMG a stavu UML, ve kterém je. Do UML si každý snaží prosadit tu svou část bez ohledu na to, jaký přínos (a pokud vůbec nějaký) to bude mít.

James Rumbaugh

• „Z mých vlastních zkušeností mohu říct, že pouze necelá polovina programátorů umí pracovat s abstrakcí. Jeden z mých kolegů tvrdí, že je to méně než 10 %.“ Zkuste takovému programátorovi či analytikovi vůbec vysvětlit abstrakci. A myslet abstraktně? Hm, nebudu se raději rozepisovat.
• „Pokud musíte mít neustále při ruce tisícistránkový manuál, pak je něco špatně. Systém není správně rozdělen. Bohužel, mnozí lidé komplexitu zbožňují. IBM z ní udělala náboženství. Jak jinak, pomáhá jí to prodávat konzultanty.“ Pokud máte chuť, zkuste někdy ve větším podniku přijít s tím, že chcete něco zrychlit, zjednodušit, vylepšit. Uvidíte, kolik lidí tohle náboženství vyznává. Z mých zkušeností to je 95 % lidí v IT oddělení.
• Doporučení knihy: Fred Brooks: Mythical Man-Month
• „UML není dobře navržený programovací jazyk.“ Tolik lidí z akademické sféry by si uvedenou větu mělo přečíst, než začnou své studenty nutit v rámci cvičení např. přepisovat kus kódu v C do diagramu aktivit. Nerozumná práce s proměnnými, model akcí stojící za starou bačkoru a vlastně: UML není vůbec programovací jazyk, páni profesoři. Písmenko M v UML značí modelovací.
• „Znovupoužitelnost je přeceňovaná.“ „Znovupoužitelnost je proklatě těžká.“ Jamesův názor na znovupoužitelnost je trochu extrémní, ale opět mu nelze příliš odporovat. Svého času jsem se o ni také snažil, ale vždy přišlo to, co James říká: Buďto to doteď nikdo znovu nepoužil, nebo se to stejně muselo vlivem nových požadavků předělat. Jeho rada zní: „Předně, nedělejte věci příliš vymezené pro jeden účel, ale zkuste je lehce zobecnit. Nestavějte kolem sebe mantinely, pokud nemusíte. Jestliže lze něco zobecnit bez větší námahy, udělejte to. Navrhujte věci s myšlenkou, že je bude třeba někdy změnit.“ Ano, změnit, nikoliv znovupoužít. Co naplat, měl jsem si jeho myšlenku přečíst o pár let dřív, než jsem na to přišel také (na druhou stranu, zkušenost je nepřenositelná, každý se musí spálit).
• „Dobrý název je lepší než roční práce na projektu.“ Pokud máte dobrý název, lépe to celé prodáte a to leckdy bez ohledu na smysl toho, co prodáváte. Zde narážel na SOA.
• „V reálném životě obvykle neexistují jednosměrné vztahy. Málokdy se stane, že pokud A je ve vztahu s B, pak B není ve vztahu s A. Vztahy jsou již z podstaty obousměrné… přičemž obousměrnost nutné neznamená symetričnost. Člověk kousnutý psem je něco jiného než pes kousnutý člověkem.“ Na první pohled se může zdát, že to hodně souvisí s mírou abstrakce, ale při bližším zkoumání musíme tuto tezi zavrhnout.
• „Vše se jednou změní… Pokud píšete nějaké aplikace, vždy je píšete s jistotou, že se v příští verzi změní.“ K tomu snad jediné: a tak to pište tak, abyste druhý den/další měsíc/za rok věděli, proč jste to tak napsali a mohli to efektivně změnit.
• James opět značně kritizuje OMG, proces standardizace a jednotlivé přicmrndávače do UML standardu („když ty mi povolíš moji pitomost, tak já povolím tobě tu tvoji“). Nedivím se mu. Sám jsem dva týdny řeši jen změnu jména v jejich systémech. Ani nechci vědět, jak dlouho by opravovali chyby, které jsem ve standardu našel. O nelogičnostech ani nemluvě.

Grady Booch

• Grady byl oproti svým kolegům trochu žoviálnější a do OMG se neopíral, naopak myšlenku standardizace podporoval. Stejně tak i změnový proces mu připadl rychlý. Nesouhlasím s ním. Je mnoho požadavků na UML, na které se kašle, byť po nich mnozí volají (proč třeba dosud není jen blbá notace pro podmínkový uzel? Skoro deset let se OMG vymlouvá na nedostatek času).
• Grady dost dá na pocit: To, že něco nedokážu rozumově vysvětlit, ještě neznamená, že to dělám špatně.
• „Není těžké najít mizernou práci, kterou nenávidíš. Dělej však raději to, co tě naplňuje uspokojením.“ Netřeba komentáře, klasická klišoidní motivační hláška, ale stále zabírá.
• Líbilo se mi, jak se vyjádřil k Donu Knuthovi (autorovi geniálního TeXu): „… anebo jako to udělal Knuth: ‚sice teď píšu knihu, ale nelíbí se mi, jak je sázena. Takže psaní na pár let přeruším a vytvořím si jazyk, který sazbu udělá dle mých představ.‘“. Zřejmě se mi to líbí proto, že tak funguji také (a TeX mám rád).
• Pěkná je myšlenka, která říká, že nemá smysl pokoušet se pochopit fungování systému, dokud nebudeme mít předložený seznam pravidel a omezení. Proč já tohle nikdy nedělám? Aha, ono to není nikde nikým evidováno. Dokumentace nemá v dnešní době význam.

Pokud vás tento článek zaujal, knihu (či alespoň část věnovanou UML) si přečtěte. Najdete tam jistě mnoho dalších myšlenek, které vás zaujmou více než mě.

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