Kompozice a agregace se v praxi používají, když chceme v případě binárních asociací zdůraznit princip celku a jeho částí: motor je součástí auta, procesor je součástí počítače, firma je složena z jednotlivých oddělení apod.

Poznámka: Text tohoto článku můžete považovat za ukázku z knihy UML pro analytiky, která vyšla v únoru 2019.

Číst více

Loni jsem tu popisoval mé strasti k cestě stát se oficiálním konzultantem a školitelem nástroje Sparx EA. Učinit se oficiálním konzultantem/školitelem je však podmíněno prodáváním licencí. Tehdy jsem to nechtěl dělat, ale připouštěl jsem možnost, že časem změním názor. A stalo se. Jak? Číst více

Často dostávám na kurzech dotazy na doporučenou literaturu k UML. Jednoduchá otázka, složitější odpověď. K UML existuje pouze jedna jediná doporučená literatura a tou je UML standard. Je to kniha, kde je nejméně chyb. No a pak jsou ty ostatní. Které byste letos neměli minout? Číst více

Minulý týden jsem měl možnost absolvovat beta verzi zkoušky OCUP 2 Advanced. Jak jsem byl rád za nové verze úrovní Foundation a Intermediate, kde se kromě znalostí jazyka v otázkách obracejí i na zkušenosti s UML a OOP, tak Advanced je průšvih. OMG opět zabředlo do testu znalosti standardu, navíc otázky jsou šité horkou jehlou (po dvou letech asi dostal někdo kartáč, že dosud žádné nepřipravil). Z 268 otázek, na které jsem odpovídal, opět nakonec vyberou 90, které pak budou ve standardním testu. To dělají v tuto dobu, odhadem do měsíce budou známy výsledky. Do té doby máte možnost naposledy absolvovat starou OCUP Advanced, která se sice stane zastaralá, ale na druhou stranu platnost nikdy nevyprší.

Pokud se na novou verzi úrovně Advanced budete někdy chystat, měli byste mít mj. zažité následující:

• MOF, rozšiřitelnost UML přes profily a přes MOF, profily vůbec byly hodně zkoušené (včetně povolených a zakázaných vazeb apod.) – pokud půjdete na zkoušku, rozhodně si pár profilů např. v EA procvičte (ovšem pozor na to, že EA není UML compliant), úrovně abstrakce (M0 až M3). Kde je UML? Kde je MOF?
• fUML a Alf
• Šablony, StringExpression, aliasy
• Aktivity a akce, is(Localy)Reentrant a to i v kombinaci se stramovanými parametry
• V aktivitách se ptali i na takové akce, které nejsou v propozicích (variables actions)
• Vyšlehávání výjimek a jejich obslužnost, a to včetně toho, kdy jsou výjimky zaměnitelné (generalizace – v UML bohužel není definované pořadí)
• Interakce s consider/ignore, critical, general ordering, assert, reference.
• Redefinice aktivit a stavových diagramů
• Stavové diagramy: pozor na to, na co se ptají: pořadí triggerů či pořadí spouštěného chování. A dvojitý pozor na entry/do/exit chování.
• Subsets a (derived) union.
• Pokud neznáte, naučte se anglické výrazy pro kráva, být a tele. Dále může pomoct znalost genetiky (xx a xy).

Časem samozřejmě připravím školení i na tuto úroveň, bude k dispozici zřejmě v první polovině příštího roku. Přesto, pokud jste byli také na beta testu této úrovně, jaké jsou vaše zážitky a pocity?

Uložit

V praxi se velmi často stává, že některá ze tříd má asociaci sama na sebe, přičemž z podstaty věci neumožňuje cyklus. U zaměstnance evidujeme nadřízeného, produkt může být součástí jiného produktu a ten dalšího, na matrice zaznamenáváme u dětí rodiče apod. Mnohé diagramy pak, bohužel, vypadají následovně:

Proč bohužel? Ještě jednou se na diagram podívejte a zamyslete se nad násobností. Opravdu každý zaměstnanec musí mít svého nadřízeného? Jak by vypadala instance zaměstnance? Třeba takto?

Jenže diagram není úplný, chybí nám tam nadřízený Helimadoe Havlíčkové. Abychom vyhověli předpisu v diagramu tříd, museli bychom vytvářet instance donekonečna. A to není naším záměrem. Z tohoto důvodu je nutné, abychom násobnost 1 resp. 2 nahradili násobností 0..1, resp. 0..2. Poté dostaneme logicky správný výsledek:

Věřím, že se s touto chybou začnu potkávat již jen zřídkakdy.

Uložit

V pátek mi přišel prapodivný mail od OMG, že od daného data do 11. srpna tohoto roku se lze přihlásit na beta zkoušku OCUP 2 Advanced. Poněkud narychlo, chtělo by se říci. Dlouhou dobu nic a teď tohle. No budiž.

Ovšem podívejte se i na zkoušené okruhy (viz odkazy níže), budete se divit: téměř čtvrtinu zabírá metamodeling. MOF bych ještě chápal, ale proč do toho cpou fUML a Alf? Sakra, proč? To jako kdyby u státnic z češtiny musel student ještě prokázat znalost hantecu. Bohužel je zde vidět, kdo má nyní otěže UML v ruce.

Jakmile test „vyzkouším“, podělím se se zkušenostmi.

A pro úplnost:

• fUML je Foundation UML, což je OMG standard silně ovlivněn spustitelným UML (Executable UML).
• Alf je Action Language for Foundation UML, opět propagovaný OMG.
• Všechny oblasti pro testy OCUP 2 Advanced Beta – Pozor, neschopnost OMG dělat něco pořádně tam zavedla odkaz na UML 2.5 Beta 1 namísto finální podobu UML 2.5.

Uložit

Z pohledu UML je případ užití a aktor natolik primitivní záležitostí, že ji ovládá téměř každý po pětiminutovém vysvětlení. Ovšem zápas začíná ve chvíli, kdy se začnou používat. Jednou takovou dílčí bitvou je nalezení odpovědi na otázku: ke kterým všem případům užití má vést asociace od aktora?

Ukažme si to na příkladu. Předem však musím upozornit, že níže popisovaná technika NENÍ dána standardem UML, ale popisuje jeden ze způsobů, jak pracovat s případy užití.

Mějme jednoduchý e-shop, který bude nabízet knihy. Zákazník přijde, prohlíží si nabídku, a pokud se rozhodne něco koupit, vloží zboží do košíku, zadá doručovací adresu, způsob platby a nakonec potvrdí celou objednávku.

Primárním případem užití zde budeme myslet takový případ užití, který slouží k základnímu cíli uživatele (aktora) našeho systému. V našem příkladu je takovým cílem zakoupit si knihu. Diagram pak může vypadat takto:

Dosud je vše v pořádku. Postupnou analýzou problematiky však určíme, že je potřeba zavést další případy užití: Zobraz knihu, Vyhledej knihu, Zpracuj košík apod. Jde o sekundární (či pomocné) případy užití, které sice nejsou důvodem, proč uživatel náš systém používá, ale primární případy užití se bez nich neobejdou. Náš primární případ užití je pak bude využívat pro svou potřebu. To zobrazíme pomocí vztahu include:

Opět, dosud tu nebude nic, co bychom mohli nějak rozporovat.

Ke kterým případům užití však udělat asociace od Zákazníka? Tady nám už UML nepomůže, neboť to říká, že asociaci lze od aktora vést k libovolnému případu užití. Jenže pokud to uděláte, diagram bude nečitelná změť čar. Již asi tušíte, že vhodná odpověď je asociace pouze s primárními případy užití. Výsledek tedy bude vypadat takto:

Toto pravidlo se docela osvědčuje, ale někdy může vést ke zmatení. Do našeho modelu totiž přidáme nového aktora a to Prodavače. Nyní si představte situaci, kdy naši eShopovou aplikaci používá i tento prodavač. Ten stojí např. mezi regály, když v tom jej osloví zákazník a zeptá se: Máte knihu XY? Pokud prodavač neví, přistoupí k počítači a knihu vyhledá. Pokud se povede, zákazník má radost, pokud ne, děje se něco jiného. Náš diagram bychom tedy mohli upravit takto:

Je to však v pořádku? Vždyť máme asociaci k sekundárnímu případu užití a my jsme si řekli, že to dělat nebudeme! Ovšem v pořádku to je. Případ užití je totiž sekundárním pro Zákazníka, ale primárním pro Prodavače. A proto je naše asociace dle našeho pravidla.

A to je vlastně vše, co jsem k tomu chtěl povědět. Zapamatujte si prosím jedno zásadní pravidlo modelování: vždy mějte na paměti, z jakého pohledu se na vaše prvky díváte. Každý pohled totiž může být jiný. A doporučení, které jsem zde záměrně porušil: Každý digram by měl být pouze a jen z jednoho úhlu pohledu. Porušení tohoto pravidla vede k nepochopením a nedorozuměním.

Pozn.: V uvedeném příkladu se samozřejmě můžete šťourat a hledat pro i proti. Já osobně se používání aktorů bráním. Je to zbytečný prvek, který se hodí maximálně pro diagram na prezentaci pro zadavatele. Raději používám popis nějakého procesu, přičemž případ užití realizuje některý krok takového procesu. Ale o tom třeba někdy příště.

Mnozí uživatelé UML chápou velmi dobře a víceméně intuitivně, že jejich diagramy (modely) jsou ve skutečnosti jen abstrakcí reálného světa a že nelze zachytit vše. A ani to nezkoušejí. Ovšem leckdy to celé vezme za své, jakmile se pustí do diagramu nasazení.

Mají totiž pocit, že to je přesně ten bod, kdy se abstrakce setkává s realitou, a tedy je třeba zaznamenat vše. Jenže to opravdu nemá smysl. Proč modelují počítač na úroveň hardisku a paměti, když chtějí pouze ukázat, že aplikace má běžet na počítači s nějakými minimálními požadavky? Proč modelují USB konektor a ovladač tiskárny, aby ukázali propojení s tiskárnou ve chvíli, kdy chtějí jen říct, že jejich aplikace tiskne daňové doklady?

Ukažme si jednoduchý příklad, který zkusí abstrakci zachovat.

Na následujícím obrázku je Raspberry Pi 3 v malinově-bílé krabičce. Pomocí kabelů je propojena nepájivá deska s GPIO piny. Má diody, A/D převodník, rezistory, čidlo teploty a vlhkosti a mnohé další. Na základní desku je dále připojena kamera. To celé je pak pomocí WiFi připojeno do lokální sítě a poté do Internetu.

Na „malině“ běží skript, který sbírá aktuální teplotu a vlhkost a výsledky posílá do světa, kde to ukládá, nebo to zobrazí na obrazovce terminálu.

Jak to zaznamenat v UML, abychom se nezbláznili? Inu, těch prvků není třeba mít příliš mnoho:

Všimněte si, že v diagramu není kamera, A/D převodník, dioda a mnohé další. Ono to totiž pro tento případ není důležité, a tak to nezobrazuji. Stejně tak není uvedeno přesné zapojení na konkrétní pin GPIO. Opět, není to pro uvedenou situaci důležité.

Máte jiný názor? Sem s ním.

Ve středu jsem si prošel všech 247 otázek, co byly připraveny pro beta verzi zkoušky OCUP 2 Intermediate. Vyhodnocení má být na přelomu září a října, uvidíme, jak to dopadne. Snad dobře, mám z toho ovšem horší pocit, než z bety OCUP 2 Foundation.

Protože vím ještě o několika lidech, kteří se na betu teprve chystají (poslední zkoušky jsou kolem poloviny července), uvádím několik postřehů, co si ze zkoušky pamatuji. Nejprve obecné věci:

1. Čtěte každé zadání pozorně. Ačkoliv na první pohled vypadá stejně jako to předchozí, často se liší v detailu.
2. Pokud je zadání otázky dlouhé či diagram velký, přečtěte si nejprve text. Zjistíte, že pak nemusíte diagram studovat celý, ale veskrze pouze dva, tři elementy, až snad na jednu výjimku.
3. Pokud se připravujete podle (zadání), děláte dobře. A až na pár drobností se vás optají na vše. Buďto přímo, nebo nepřímo.
4. Pozor na to, kam klikáte. Ačkoliv máte pocit, že klikáte na prázdnou oblast, může to změnit již vybranou odpověď, aniž byste si toho všimli.
5. Pokud neznáte odpověď nebo je zadání dlouhé, kašlete na to, označte si to vlaječkou a pokračujte dál. K otázce se vrátíte pohodlně na konci.

A nyní k UML:

1. Musíte vědět, co to je jmenný prostor (namespace). Př.: Kolik vidíte na diagramu jmenných prostorů?
   
2. Na diagramech je použita notace typu „circle-plus“. Musíte vědět, co znamená.
3. Dobře si natrénujte, co znamenají atributy násobnosti isOrdered a isUnique. Dobré je znát bag a výchozí hodnoty. Příklad: Máte klasických 52 hracích karet (2..10, J, Q, K, A, každou takovou ve dvou barvách a každou barvu ve dvou znacích – srdce, kára, piky, kříže). Hráč dostane náhodně do ruky sedm karet. Jaké hodnoty nabudou atributy isOrdered a isUnique?
4. Usage a Abstraction – naučte se význam a jednotlivé stereotypy. Rozhodně se ptali na create, instantiate (ano, je zbytečné mít dva stereotypy víceméně pro totéž).
5. ElementImport – kromě významu musíte znát i alias a viditelnost (access versus import). Příklad: Co je třeba udělat, abyste v třídě Circle mohli používat typ P2::Real, ale nazývat ho double?
   
6. Instance – Příklad: Až kolik různých instancí třídy Z může být přímo či nepřímo dostupných instanci třídy X2?
   
7. Packages: Mohou mít dva balíky na stejné úrovni stejné URI?
   
8. Dobře nastudujte syntaxi času a intervalu. Budete ji potřebovat u sekvenčních diagramů.
9. Informační toky – vše. Drobný úvod do informačních toků najdete v mém článku. Příklad: dostanete diagram a máte jej zjednodušit nebo spočíst informační toky.
10. Měli byste znát pojem compartment.
11. Signály a receptory: test znalosti notace a názvu compartmentu, kam se receptory vkládají.
12. Odvozené atributy (derived) – zápis plus to, zda musí či nemusí být readOnly a dále, zda musí mít zapsáno, jak je odvozeno.
13. BNF notace – testují znalost – uvedou příklad a máte určit, který zápis tomu neodpovídá.
14. OCL – měli byste pasivně znát.
15. K čemu jsou dobré pre- a post-conditions? Kdo je vyhodnocuje a kdy? Co když jsou porušeny?
16. Vlastnost jako memberEnd. Pozor na to, co znamená šipka a co malá černá tečka na konci asociace.
17. Generalizační množiny – velmi dobře si zapamatujte klíčová slova a výchozí hodnoty atributů isDisjoint a isCovered. Samozřejmě včetně použití, na obojí je tam několik otázek.
18. Diagramy vnitřních struktur (port je property, tedy nemůže implementovat rozhraní, leč ho poskytuje, co je part a co je property, jak vznikají instance), atribut isService a další.
19. Diagramy nasazení: znalost a to včetně notací a deployment specification. Příklad: Kterým směrem vedou šipky a jakého jsou typu?
    
20. Základy chování:
    1. Typy událostí a jejich notace (at, when, after), event pooly, rozdíly mezi stavovým diagramem a ostatními chováními.
21. Diagram aktivit:
    1. Dobře si prosvištěte pravidla strukturovaného uzlu a expansion region a různé notace téhož.
    2. Pozor na to, že inout parametr má dva aktivity parametry.
    3. Notace výjimky lezoucí z akce.
    4. Vstupní a výstupní piny bez příchozích resp. odchozích hran.
    5. Dobře se naučte streamování, AcceptCallAction a ReplyAction, rozdíl mezi CentralBufferNode a DataStoreNode.
    6. Přerušitelná oblast.
    7. Jeden znak pro Desicion a Merge plus jeden znak pro Fork a Join.
    8. Pravidla pro spuštění akce. Příklad: kdy začne akce?
       
22. Stavové diagramy – hodně dobře si zopakujte pravidla pro entry a exit chování. Dále pseudostavy entry a exit point. Měli byste vědět, že dva regiony téhož stavu běží nezávisle na sobě.
23. Protokolární stavové diagramy – k čemu to je, notace přechodu. Vlastnictví s rozhraním.
24. Sekvence:
    1. Pravidla pro fragmenty par, loop (pozor na podmínku s loopem), opt, alt, strict a to včetně toho, kolik může mít operandů.
    2. Interaction use.
    3. Brány.
    4. Ztracené a nalezené zprávy.
25. Komunikační diagramy – oproti předpisu i znalost souběžného vykonávání.

Tolik ke zkoušce. Já byl po třech a půl hodinách vyflusaný a to jsem měl, tuším že, ještě hodinu k dobru. U dvou otázek jsem byl přesvědčený, že všechny odpovědi jsou špatně, u některých se hodně slovíčkařilo.

Pokud jste zkoušku již absolvovali, jaké z ní máte pocity vy? Co vám nesedlo nebo naopak vyhovovalo? Použijte komentáře.

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í.