Dneska jsem měl tu čest absolvovat zkoušku OCUP 2 – Foundation Level (kód OMG-OCUP2-FOUND101) v její beta verzi, o které jsem tu nedávno psal. Ještě za čerstva bych se rád podělil se svou zkušeností.

Především musím říct, že testové otázky jsou postaveny mnohem blíže k uživatelům UML nežli k akademikům, kteří sice znají jednotlivé klky střev UML, ale s každodenním používáním tohoto jazyka to nemělo moc společného. Pokud zkouškou projdete, bude to mnohem více vypovídat o tom, jak UML umíte používat.

Protože jde o otázky ve zkušební verzi, najdou se samozřejmě nějaké ty chybky. Např. jste dotazováni na věci, které v požadavcích na zkoušku nejsou uvedeny (např. jedna otázka byla na třídu Port). V zadání jedné otázky jsem našel chybu (guard v diagramu aktivit nebyl v hranatých uvozovkách). Co mě však vytáčelo, byly otázky směrované do oblasti „Why we model“, protože to byly klasické dotazy na měkké dovednosti. V takových otázkách akorát odhadujete, která odpověď uspokojí tazatele. A 15% podíl takových otázek v testu je přespříliš.

Pokud se na zkoušku chystáte (ať už na betu nebo na finální), uvádím pár věcí, na které byste rozhodně neměli zapomenout (a které si pamatuji, že tam jsou):

• Dávejte dobrý pozor na to, na co se ptají. Někdy záleží na slovíčku (např. když v zadání otázky mají i abstraktní třídy a vás se ptají jen na ty, ze kterých lze vytvořit instance).
• Naučte se dobře viditelnosti a jmenné prostory (může mít balíček v sobě balíček stejného jména? Může balíček obsahující třídu A s atributem private vidět jeho hodnotu?)
• Dost otázek mělo v zadání diagram tříd a vy jste měli vybrat jeden ze čtyř objektových diagramů, které odpovídají zadanému diagramu tříd.
• Podívejte se na násobnosti asociace aktora s use casem (ostatně z případů užití vás proklepnou opravdu důkladně).
• U akcí si zapamatujte, že je tato spuštěna jen v případě, že má tokeny na všech vstupních hranách.
• Zapamatujte si notace parametru a pinu u aktivit/akcí.
• Mrkněte na notaci akce pro volání jiné aktivity a pro volání metody nějaké třídy.
• U sekvenčních diagramů si řádně procvičte ona dvě známá pravidla pro hledání platné sekvence. A pak samozřejmě typy volání (synchronní, asynchronní…)
• Jak se zobrazují pre- a post-contions u akcí? Kdy se vyhodnocují?
• Kdy použít datový typ a kdy třídu?
• Jak se dají zobrazit prvky balíčku?
• U stavových diagramů doporučuji mít hodně zažité výskytu události a princip triggerů, podmínek a efektů.
• A další.

Jestliže jste zkoušku absolvovali, připojte komentář s vašimi postřehy, ostatním to může pomoci.

S novou verzí UML, která je v druhé beta verzi, se na svět dere i změna v certifikaci znalostí tohoto jazyka. S tím přichází ruku v ruce i poměrně výhodná nabídka přímo od OMG (Object Management Group), která má UML pod standardizačním patronátem.

Než se však k tomu dostanu, pojďme si povědět, co se vlastně s UML děje a v nejbližší době dít bude. Upozorňuji, že informace, které zde uvedu, se mohou měnit dle toho, jak se bude vše postupně dokončovat.

Aktuální verze UML nese číselné označení 2.4.1 a je tu s námi od srpna 2011. Je složena ze dvou zásadních dokumentů: infrastruktury a superstruktury. Superstruktura definuje to, co znají především uživatelé UML, tedy např. případ užití, aktivitu, komponentu, třídu a to včetně sémantiky. Infrastruktura je pak jakési podhoubí UML, se kterým pracují víceméně pouze vývojáři UML nástrojů. Připravovaná verze 2.5 má přinést výrazné zjednodušení celého UML jazyka, vyhodit nepotřebné věci a hlavně mít jen jeden jediný dokument (zda je opravdu o zjednodušení, rozeberu v některé v dalších z článků). Zmizí však zásadní věc a to rozšiřování definic UML prvků pomocí importů a spojování balíků, které – přiznejme si – bylo pro začátečníky zajímající se o text standardu poměrně náročné na chápání.

Díky tomu však začnou být některé otázky v testu OCUP (OMG Certified UML Professional) značně mimo mísu (především pro úroveň Advanced). Z tohoto důvodu se společně s novou verzí spustí i nová verze těchto zkoušek pod označením OCUP2. Co přinese nového? Vybírám pár nejzajímavějších bodů.

1. Původní zkoušky již nebude možné skládat. Dosud získané certifikáty však budou platit nadále, byť budou označovány jako zastaralé.
2. Budou stále tři úrovně znalostí; první se namísto Fundamental bude jmenovat Foundation.
3. Platnost certifikátu bude pět let. Osobně si myslím, že tohle by mělo platit u každé zkoušky, včetně těch státních, za které se dávají tituly typu Ing. či Mgr. Na druhou stranu je tady zřejmá potřeba generovat příjmy do pokladny OMG.
4. Složení požadavků zkoušek bude mírně odlišné. Např. již v té první (Foundation) se vás budou ptát na stavové diagramy (původně bylo až v druhé a třetí úrovni). Totéž platí třeba o některých třídách z oblasti diagramů aktivit (např. SendSignalObject).
5. V době vydání tohoto článku byly známy jen požadavky pro první úroveň. Prozatím není určeno, kolik otázek již znamená, že jste zkouškou prošli. V původní verzi zkoušky to bylo 57,5 %, což je strašně málo (jistou prestiž by zkoušce dodalo zvýšení tohoto čísla alespoň na 80 %).
6. První úroveň zahrnuje 15 % otázek z oblasti „proč modelujeme“. Z toho mám trošku obavy, protože může jít o otázky, na které nebude jednoznačně správná odpověď. Ale to je prozatím pouze má domněnka.

A nyní pojďme konečně k nabídce, o které jsem se v úvodu zmínil. Po omezenou dobu (zřejmě jen pouze do konce dubna, možná ještě méně) OMG hledá beta testery, kteří chtějí absolvovat zkoušku úrovně Foundation a to zcela zdarma (no dobře, tramvajenku do certifikačního střediska vám nezaplatí). Pokud zkoušku absolvujete, tak dostanete zdarma možnost podívat se na zkoušku na druhou úroveň. A totéž pak platí pro tu třetí. Pokud navíc jednotlivými zkouškami projdete, dostanete navíc platný certifikát (pozor, musíte je složit od té první; pokud projdete druhou, ale první pokazíte, nebudete mít žádný certifikát). Testování by mělo probíhat od půlky dubna do půlky května. Moc brzy? A co to brát tak, že si zkoušku prostě jen zkusíte? Můžete získat cenné zkušenosti z toho, jak to celé probíhá.

Jistě jste zvědaví, jak se takovým beta testerem stát. Informace získáte na stránce věnované beta verzi zkoušek OCUP 2. Nebudu je tady přepisovat, bez angličtiny stejně zkouškou neprojdete, tak si počtěte. Najdete tam odkaz i na formulář, kterým se do testovacího programu zapojíte. Pokud vás vyberou, dostanete o tom v řádu několika dnů zprávu e-mailem (sledujte případně i složku se spamem). Doporučuji si pospíšit, dokud tu ta možnost je.

Než se pak vrhnete na vlastní zkoušku, jistě se budete shánět po nějakém přípravném materiálu. Kromě vlastního změní druhé bety UML 2.5 dosud nic není. Jelikož je tato informace poměrně nová (cca měsíc), ještě nic nevyšlo. Sám stránky ocup.cz budu postupně upravovat tak, aby odpovídaly OCUP 2, ovšem nebude to hned. Teď ale holt bude nutné vystačit s tím, co je. Mrkněte se na vlastní požadavky zkoušky a pak na seznam níže. Odkazuji se na kapitoly příprav k původní verzi zkoušek, které by vám měly pomoci:

• Why We Model (15 % otázek): jak jsem již uvedl, zatím lze jen usuzovat, jaký typ otázek dostanete. Řídil bych se zdravým rozumem a zkušenostmi jednak z vlastní tvorby modelů a jednak ze zažitých středních a velkých projektů.
• The Class Diagram (25 % otázek): zde bude muset studovat trochu více:
• Základní koncept
• Jmenné prostory
• Typové prvky
• Násobnost
• Určování hodnot
• Omezení
• Klasifikátory
• Vlastnosti
• Operace
• Asociace
• Třída
• Generalizace
• Závislosti
• The Object Diagram (5 % otázek): Specifikace instance
• The Package Diagram (5 % otázek): Balíky
• The Use Case Diagram (5 % otázek): Případy užití
• The Activity Diagram (20 % otázek): Diagram aktivit a Struktura akcí
• The Sequence Diagram (15 % otázek):
• Základy chování
• Způsob volání chování
• Diagramy interakcí
• Sekvenční diagramy
• Výměna zpráv
• The State Machine Diagram (10 % otázek): Stavové diagramy

Mno, když na to tak koukám, tak to vlastně vůbec nebude zlé. Budu rád, pokud se podělíte o vlastní zkušenosti.

Dnes především nevážně. Připravuji nějaký projekt a potřeboval jsem k tomu seznam všech omezení definovaných v aktuální beta verzi UML 2.5. Vzal jsem tedy standardní profil a vytvořil si jednoduchý styl, kterým jsem tato omezení vyzobal. Výsledkem je 666 omezení. Náhoda, nebo je UML dílo ďáblovo?

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

Během závěrečných hodin posledního červnového dne se mi podařilo dát na http://www.ocup.cz veškerou mou přípravu ke zkoušce OCUP Intermediate. Nyní tam tedy můžete nasávat znalosti hned pro dvě úrovně.

Připomínám, že byť je to postavené na Bloggeru, tak se to celé chová jako kniha a jednotlivé kapitoly tudíž naleznete v druhé části. Doporučuji se na ně dostavit pomocí obsahu.

Tištěná podoba webu bude také. V průběhu příštího týdne ji zašlu k tisku a k dispozici bude v druhé půli července.

Pokud se ptáte, zda bude někdy i třetí, poslední část, tak si stále myslím, že ano. Je možné, že se na ni začnu připravovat ještě letos o prázdninách (ano, záměrně nepíši o kterých).

Po dnešku mám úspěšně za sebou zkoušku OMG-OCUP-200, tj. úroveň Intermediate. Musím říct, že ačkoliv jsem měl ze 70 možných otázek 67 správně, jsem z toho trošku rozladěný. V testu se objevovaly otázky např. na stavový automat protokolu (má se zkoušet až na úrovni Advanced) nebo se používaly termíny, které sice byly v návrhu UML verze 2.0, ale pak byly přejmenovány či vynechány (pamatuji si otázku na jakousi akci ApplyFunctionAction, která v současné verzi UML vůbec není).

Většinu z toho šlo odvodit logicky, ale přesto pachuť odfláknutí ze strany OMG zůstává. Skoro 7000 Kč za zkoušku není žádná láce, tak by se ta skupinka akademiků měla sakra starat o to, aby tato investice měla řádnou hodnotu.

Pomalu se chýlí ke konci můj text k přípravě na zkoušku OCUP úrovně Intermediate. Již jsem aktualizoval obsah a jako ochutnávku dal na web notační plachty. Ke zveřejnění chybí již jen pár kroků:

1. Ještě jednou si to celé přečíst a opravit nedostatky.
2. Udělat zkoušku.
3. Připsat pár otázek pro představu, co vás čeká.
4. Překlopit text z Wordu sem na stránky.

 Minimálně první dva body budou provedeny teď v červnu, další dva buďto také nebo v první půli července.

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.