Text učebnice konečně dospěl do stádia, kdy jej lze nabídnout vám všem. Jedná se o výrazně přepracované znění přípravy k předchozí verzi zkoušek dostupné na http://ocup.ocup.cz.

Na více než 120 stranách se dostane na všechny okruhy, jejichž znalost je potřeba pro úspěšné složení zkoušky OCUP 2 Foundation:

• Základy UML
• Diagramy tříd, objektů, balíků
• Případy užití
• Diagramy aktivit
• Sekvenční diagramy
• Stavové automaty

Součástí ceny za licenci ke knize dostáváte doživotní aktualizaci textu. Jakmile se tedy objeví nová verze textu, dostanete o tom informaci a budete si moci novou verzi stáhnout.

Pokud vás to zaujalo, podívejte se na stránku věnované knize.

Upozornění: Do konce února můžete za knihu platit i pomocí platební karty nebo PayPal. Poté začne pro tento typ plateb platit Babišův paskvil a šunt nazvaný EET, na který není ani jedna uvedená platební metoda připravena. Jediná možnost poté bude převodem na bankovní účet (což lze i dnes).

Učebnici můžete získat zdarma např. jako podklady pro mé distanční školení Příprava k certifikaci OCUP 2 Foundation!

Konečně dorazily výsledky a certifikát z beta testů OCUP 2 Intermediate.  Ovšem také se dá objevit, co bude v OCUP 2 Advanced. Je to zatím jen námět k zamyšlení, stránka není oficiálně odkazovaná a je vidět, že je v rozpracovaném stavu.

Je to venku. OCUP Intermediate je mrtvé, na světě je OCUP 2 Intermediate. OMG však opět degradovalo tuto certifikaci tím, že pro její úspěch stačí necelých 57 %. Chápu, jsou v tom prachy, o nic jiného stejně nejde. V každém případě je to neúcta k lidem, kteří se poctivě na zkoušku připravují.

Porovnejme si tedy to, co již víme o zkouškách OCUP 2 Foundation a OCUP 2 Intermediate, a zašpekulujme si o OCUP 2 Advanced:

*První číslo je pro ty, kteří mají angličtinu jako rodný jazyk, druhé pak pro ostatní.

Dívejme se však kupředu. Doufám, že se brzy (za rok) objeví požadavky pro OCUP 2 Advanced a za další rok a půl začnou beta testy. Prozatím by ale většině z nás stačilo znát výsledek beta testů OCUP 2 Intermedite.

Pokud se i přes mou kritiku chcete se mnou na libovolnou z aktuálně platných zkoušek připravit, můžete.

Pokud můžeme věřit tomu, co píše OMG, tak dnem 11. září tohoto roku se přestanou zkoušet znalosti UML na úrovni OCUP Intermediate a od 12. září nastupuje nová verze, tedy OCUP 2 Intermediate. Jinými slovy tedy máte poslední možnost složit tuto zkoušku postaru.

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

Je to již rok, co bylo možné absolvovat beta verzi zkoušku OCUP 2 – Foundation Level (kód OMG-OCUP2-FOUND101). OMG se konečně rozhoupalo a připravilo beta verzi testu úrovně Intermediate. Podle jejich slov ji bude možno absolvovat koncem léta (takže tipuju někdy v druhé půlce srpna).

K tomu dostávám opakující se otázky, zkusím na ně odpovědět.

Má příprava k testu OCUP2 – zeleně úroveň Foundation, modře Intermediate a červená se třese na Advanced.

Co je potřeba umět? Vše, co je nutné znát pro úroveň předchozí a k tomu něco navíc. Pěkně je to rozepsané na stránce beta testu.

Co se vlastně zkouší (zkoušelo) v úrovni Foundation? Základní předpoklady jsou na stránce zkoušky, v poslední době ale přibyl velmi užitečný dokument odkazující do konkrétních kapitol standardu. Pozor, mají tam chybu, v případě kapitoly 8 se jedná o podkapitoly Literals a Expressions.

Musím něco dělat, když jsem byl zapojen do testování úrovně Foundation? Ne. Přibližně před měsícem jste měli mít v e-mailové schránce dopis, ve kterém se mj. píše, že včas dostanete slevový kupón a další informace.

Mohu se do beta programu zapojit? Ano, vše podstatné najdete na příslušné stránce.

Existuje nějaká přípravná literatura ke zkoušce? Zatím ne. Máte v podstatě pouze UML standard a z něj se můžete učit. Já sám sice postupně píšu věci, které je třeba znát, ale rozhodně to do zkoušky nebude hotové. Navíc typ otázek lze pouze předvídat.

A co když se to nechci učit sám? Pokud se najdou zájemci, mohu v červenci uspořádat nějaký seminář, kde si přípravu probereme. Jestliže byste se chtěli účastnit, napište mi. Stejně tak mohu poskytovat soukromé hodiny. Opět, stačí napsat a domluvíme se.

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.