Blok přesunut






Vážení čtenáři. Tento blok byl přesunut na novou adresu http://blok.kurzy-uml.cz. Zde ještě chvíli budou staré články, nové však již vycházejí pouze na novém místě. Prosím, upravte si své záložky.



čtvrtek 17. října 2013

Kreslete od ruky

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

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


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


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

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

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

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

Nový diagram

neděle 14. dubna 2013

IFML – jazyk pro modelování interakcí aplikace s uživatelem

Co si budeme nalhávat, UML sice je úžasný modelovací jazyk, ale jeho jednou nevýhodou je, že v něm jde namodelovat úplně všechno. Tedy samozřejmě i uživatelské prostředí. Přesto (či možná právě proto) si mnozí návrháři kladou otázky typu: Jak jednoduše zobrazit, že změna v jednom prvku našeho formuláře vyvolá změnu i v tom dalším? Jak efektivně určit, jaká data zobrazit na základě nastavení prvků ve formuláři? A přesně na ně a jim podobné otázky může odpovědět IFML – Interaction Flow Modeling Language neboli jazyk pro modelování toku interakcí.

IFML je doménově specifický jazyk, tedy je určen pouze především pro modelování toků interakcí systému s uživatelem. Vychází, stejně jako UML a další, z MOF, což zajišťuje bezproblémovou spolupráci např. právě s UML. Při definici IFML měli tvůrci hodně na paměti WebML.

V současné době je IFML v beta verzi, ke které se můžete až do 9. prosince tohoto roku vyjadřovat. Poté se relevantní připomínky zapracují a uvedení první oficiální verze je naplánováno na 28. března 2014. Asi nejdůležitější je, že IFML je přijat standardizační skupinou OMG.

Pojďme si teď ukázat, jak jej jeho tvůrci zamýšlejí používat. IFML diagram obsahuje jeden nebo více základních kontejnerů (top-level view container). Tím může být okno ve Windows, webová stránka nebo např. formulář na vašem chytrém telefonu. IFML je totiž na platformě nezávislý jazyk.

Základní kontejner pak může být vnitřně hierarchicky rozdělen do dalších, do sebe vnořených kontejnerů (hierarchy of sub-containers). Můžete si to představit jako např. panely ve formuláři, kdysi používané rámečky (frames) na webových stránkách apod. V následujícím obrázku (dialog pro vlastnost diagramu v Enterprise Architectu) je základním kontejnerem celé okno. Vnořenými kontejnery to pak jsou záložky General, Diagram a další. V kontejneru Diagram to pak jsou např. Appereance nebo Page Setup.


Každý kontejner může obsahovat komponenty, což v tomto významu neznamená nic jiného než prvek, který zobrazuje nějaký obsah nebo slouží k zadávání vstupních dat (vstupní pole, číselníkový seznam, zaškrtávací tlačítko…). Každá taková komponenta může mít vstupní a výstupní parametry. Např. komponenta pro zobrazení názvu knihy může na vstupu požadovat ISBN. Seznam knih autora na vstupu bude logicky požadovat identifikaci konkrétního spisovatele (která může být jinou komponentou poskytována na výstupu).  Tato závislost se zobrazuje pomocí vazby parametrů (parameters binding).

Komponenta i kontejner mohou reagovat na konkrétní události (ať už od uživatele, od vlastnící aplikace nebo od externího systému), čímž vlastně podporují interakci prvků s okolním světem. Tyto události se pak ve skutečnosti i jako interakce opravdu zakreslují. Pozor však na to, že interakce jsou již závislé na platformě (např. gesta na dotykovém displeji) a tedy již nejsou pomocí IFML prezentovány (k tomu se používají jiné nástroje).

Následující příklad ukazuje formulář se seznamem děl autora. Pokud je některé dílo vybráno, jsou jeho vlastnosti zobrazeny na vedlejším panelu. Pod tím je pak tato interakce zakreslena v IFML.





Důsledek události je označován jako interakční tok (interaction flow), který je pomocí konektorů připojen na jednotlivé kontejnery nebo komponenty danou události dotčené. Interakční tok vlastně vyjadřuje změnu stavu uživatelského prostředí.

Událost také může spustit nějakou akci, která je spuštěna před změnou uživatelského prostředí (např. se nejprve načtou nějaká data, než jsou zobrazena na formuláři).

Chcete-li se podívat na podrobnější příklad, doporučuji se podívat do standardu na přílohy A a B.

Má smysl další jazyk?

Pro IFML horují hlavně ti, kteří se snaží o MDD (Model Driven Development známý též jako MDA – Model Driven Architecture). Pro ně je to údajně ta poslední věc, která jim chyběla k plné spokojenosti. Mně se to ale tak úplně nezdá už jenom proto, že součástí standardu IFML je profil pro UML. Ten rozšiřuje především komponenty a signály. Nutno ovšem přiznat, že jsem četl jen část navrhovaného standardu. Konečné stanovisko tedy nechám na později.

Další odkazy

pondělí 25. února 2013

Hraje Enterprise Architect podle pravidel standardu UML?

Pravidelně potkávám uživatele Enterprise Architecta, kteří si myslí, že vše, co jim EA dovolí namodelovat, je podle pravidel definovaných standardem UML. Předvedu zde pár příkladů, které jsou v rozporu s uvedeným přesvědčením.

Generalizace



Jak jistě víte, tak generalizace je vztah mezi dvěma klasifikátory, přičemž jeden je specializací (resp. zobecněním) toho druhého. V omezení definovaném u klasifikátoru je jasně napsané, že generalizační hierarchie musí být acyklická. Jinými slovy např. třída nesmí být (přímo ani nepřímo) svým zobecněním. Následující diagram je tedy proti pravidlům v UML:


Ano, obrázek je vytvořen v Enterprise Architektu. A to bez jeho protestů. Zkusme si model validovat (menu ProjectModel ValidatonValidate Selected). Nástroj sice správně řekne, že nelze udělat generalizaci třídy sebe sama, ale o větší cykly se už nestará. Mylně tak lze dojít k závěru, že je to v pořádku.
 

 Ve výsledku validace je ještě jedna chyba navíc a ta se týká následujícího diagramu (který EA opět dovolí udělat):

Pojďme ale dále. Pro úplnost nutno dodat, že následující chyby již kontrola zabudovaná v EA neodhalí.

Aktivity a akce


Aktivity a akce jsou už průser přímo ve standardu. Koho mohlo napadnout, že základní notace těchto dvou elementů bude stejná? (Nejen) kvůli tomu to uživatelé UML nerozlišují a flákají do modelu aktivity místo akcí poměrně často a značně svižně. A Enterprise Architect je v tom podporuje.

Znovu a znovu je třeba připomínat to, co vy již určitě víte: Aktivita řídí nějakou činnost pomocí množiny uzlů a hran. Uzly jsou (zjednodušeně řečeno) trojího typu: akce, objektové uzly a řídící uzly. Akce je dále nedělitelný krok, atomická operace (kterou může být např. volání jiné aktivity).

To bychom měli aktivity a akce, ale ještě nekončíme. K dispozici standard nabízí hrany, které se dělí na řídící toky a objektové toky. V UML standardu se dozvíme, že hrana slouží pro předávání tokenů (a případně objektů) mezi uzly aktivity (tj. mezi uzly, které aktivita vlastní). Co nám dovolí udělat EA? Mít toky mezi aktivitami. Mít toky mezi uzly různých aktivit. Mít tok mezi aktivitou a akcí. Vše je pochopitelně špatně, ale EA nás na to neupozorní.


Takže ještě jednou:
  • Akce je atomická operace. 
  • Aktivita obsahuje uzly a hrany. 
  • Toky mezi uzly aktivity jsou pouze mezi uzly téže aktivity. 
  • Mezi aktivitami není žádný tok. 

Tohle ale často vede k otázce: jak tedy zobrazit sled aktivit? Nebo volání aktivit? Budu se tím zabývat v některém z příštích článků.


Další


Enterprise Architekt umožňuje hřešit proti standardu i v mnoha dalších případech. Zde krátce vyjmenovávám jen některé hříchy, při bližším studiu UML standardu a používání EA jistě najdete mnohé další:
  1. Vytvoření závislosti se šipkami na obou stranách či na žádné (správně je mít hrot šipky právě na jedné straně). 
  2. Vytvoření informačního toku mimo povolené elementy. 
  3. Špatná notace třídy GeneralOrdering (sekvenční diagramy). 
  4. Špatná notace třídy Extension (profily). 
  5. Umožnění mít nepojmenovaného účastníka (třída Actor, diagram případů užití). 
  6. Neumožnění všech povolených notací (např. hran v diagramech aktivit nebo tagových hodnot). 

Závěr 



Ukázal jsem několik důkazů, že Enterprise Architect NEPODPORUJE SPRÁVNĚ A ZCELA UML Standard. Nevěřte tedy autorům aplikace a naučte se UML používat správně.

Nakonec nabízím malé domácí cvičení. Odpovědi, na které stačí základní znalosti UML, mi můžete poslat e-mailem.

Otázka č. 1: Je následující diagram v pořádku nebo není? Proč?


Otázka č. 2: Je následující diagram v rozporu s UML standardem? Co lze o něm (o diagramu) říct?