Sdružení OMG (vykonavatel autorských práv nad UML) dne 22. ledna konečně oficiálně oznámilo, že dává do ostrého běhu třetí úroveň certifikační zkoušku, tj. OCUP 2 Advanced. Tímto krokem stará verze zkoušky definitivně končí, a to pro všechny úrovně. Čí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

Konečně nastala vhodná doba k tomu, abych mohl představit učebnici UML a OCUP 2 aneb Jak si certifikovat znalosti UML 2 pro přípravu k aktualizované úrovni OCUP 2 Intermediate. Po dlouhých týdnech psaní a revidování máte možnost mít 142 stran textu a diagramů, které budete určitě ke zkoušce potřebovat.

Celá kniha samozřejmě pokrývá kompletní požadavky ke zkoušce, ve stručnosti jde o tyto oblasti:

• Základní struktury
• Klasifikace
• Strukturované klasifikátory
• Komponenty
• Pokročilé chování
• Aktivity a akce
• Interakce
• Pokročilé stavové automaty
• OCL (Object Constraint Language)

Cena je podobně jako pro úroveň Foundation stanovena na 499 Kč. Pokud si vezmete knihy pro obě úrovně, zaplatíte dohromady 799 Kč, objednáte-li si do 30. září 2017. Poté bude cena 899 Kč. Jestliže máte v současné době platnou licenci na text pro úroveň Foundation a chcete si učebnici pro Intermediate přikoupit, do 30. září 2017 ji můžete mít za 299 Kč, poté za 399 Kč. Více informací najdete na stránce učebnic.

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

Do požadavků na znalosti potřebné pro úspěšné složení zkoušky OCUP 2 Advanced (Beta) byla přidána oblast metamodelování rozdělená do tří částí: MOF, fUML a Alf. Níže bez jakékoliv záruky na správnost, úplnost či srozumitelnost poskytuji své poznámky, které si ke zkoušce připravuji. Tato syrová podoba je čistě z toho důvodu, že zkoušky již probíhají a poslední možný termín je 11. srpna. Tak ať u vy z toho něco málo máte.

Poznámky jsem postupně rozšiřoval, viz verze níže. Dále se k němu již zřejmě nebudu vracet.

• 20. 7. 2017 – Verze 1
• 21. 7. 2017 – Verze 2 (přidán popis na základě kapitol 6.2 a 6.3.1 z UML standardu, níže v první části v podkapitolách UML a Model).
• 27. 7. 2017 – Verze 3 (doplněny poznámky ke kapitolám fUML 6.2 a 6.3, obecné povídání o spustitelném UML a jazyku akcí, kapitoly fUML Overview, definice pojmů, abstraktní syntaxi a overview of execution model)
• 28. 7. 2017 – Verze 4 (doplěna kapitola Behavioral Semantics v části fUML a dále Alf – vše). Tímto je vše, co jsem chtěl, doplněno.

The MOF and Metamodeling (12 %)

Zkoušené oblasti:

• Architectural alignment
• Models and what they model
• The semantics of languages, models, and metamodels
• The MOF

Zdroje:

1. [UML] UML 2.5:
   • 6.2 Architectural alignment: All
   • 6.3.1 Models and What They Model: All except Execution Scope, which was covered in the main exam
2. [fUML] fUML:
   • 6.2 On the Semantics of Languages and Models: All
   • 6.3 On the Semantics of Metamodels: All
3. [WPMOF] OMG White Paper
   • Meta-Modeling and the OMG Meta Object Facility (MOF): All
4. [MOF] MOF 2.5.1
   • 9.1, 9.2 Reflection: All
   • 10.1, 10.2 Identifiers: All
   • 11.1, 11.2 Extension: All

Moje poznámky:

• Celá tahle taškařice je pro potřeby OMG podporovat jejich MDA (Model Driven Architecture) koncept. Ten je založen na OOP (objektově orientovaném přístupu). [MOF, 1]
• MOF = Meta Object Facility, původně založené kvůli CORBA.
• MOF je dělen na EMOF (Essential MOF) a CMOF (Complete MOF). Jsou to vlastně dva balíčky, přičemž mj. CMOF includuje EMOF.
  • EMOF je pro základní schopnost navrhovat objektově orientovaný programovací jazyk a mapování na XMI nebo JMI (Java Metadata Interface) s možností jednoduché rozšiřitelnosti (pomocí tagů, viz dále).
  • CMOF pak poskytuje komplet schopnost tvorby meta[*]modelů. [MOF, 6.2] Je založen na EMOF a vybraných elementech z UML. [WPMOF] Daný balík pak nedefinuje žádný nový element. [WPMOF]
• MOF je založen na zjednodušeném UML [MOF 1]. MOF sdílí svůj metamodel s UML [MOF, 6.2]. Uf, tak jak si to vysvětlit tak nějak lidsky?
• Specifikace od OMG sice pracují se 4 měrami abstrakce, ale MOF na to není omezen, těch měr může být libovolné množství.
• MOF slouží pro metametamodelování (model UML je metamodel, uživatelský model je model)
• Reflexe (MOF 9):
  • obdoba toho, co znám z .NETu (C#).
  • Metaobjekty umožňují používat objekty bez jejich předchozích znalostí (resp. jejich struktury).
  • Každý element má přiřazenou třídu, která popisuje jeho vlastnosti a operace. Element je pak instance této třídy. Některé vlastnosti Elementu:
    • metaclass: UML::Class
    • isInstanceOfType (type: Class, includes Subtypes: Boolean): Boolean
• Identifiers (MOF, 10):
  • Element má identifikaci v rámci kontextu, která jej nezaměnitelně určuje/rozlišuje od jiného elementu.
  • Používá se např. pro (de)serializaci.
  • Identity lze porovnávat (např. pro potřeby rekonciliace apod.)
  • Extent (česky asi prostor, rozsah platnosti) je kontext ve kterém se elementy od sebe dají identifikací rozlišit.
    • Element může být v libovolném množství extentů (0..*)
    • Extent není element, jde o součást MOF schopností.
• Extension (rozšiřitelnost) (MOF 11):
  • Možnost přidávat metatřídám tagy (známé z Profilů)
  • Tag je třída s atributy name a value (obojí string)
  • Tag nemusí být přiřazen žádnému prvku, ale také libovolnému množství (0..*).
  • Element nemůže mít přiřazen více než jeden tag téhož jména.
  • Tag může být vlastněn jiným elementem.
• Další Z3P (Zkratka ze 3 Písmen), které je vhodné znát [WPMOF]:
  • XMI – XML Metadata Interchange – formát dat pro výměnu modelů založených na MOF
  • OCL – Object Constraint Language – objektový jazyk pro definici omezení
  • CWM – Common Warehouse Metamodel – sourozenec UML, jazyk pro definici dat v datovém skladu
  • PIM – Platform Independent Model
  • PSM – Platform Specific Model
  • MDA – Model Driven Architecture – cílem je z modelu generovat zdrojové kódy na základě transformací. Dle mého naprostý nesmysl a pouze hračka pro akademiky. Ovšem přináší důležité věci i pro lidi z praxe a to je právě různý náhled na totéž, viz PIM či PSM.
• MOF je popsán jak textově, tak graficky (využití prvků UML). [WPMOF]
• Primárním cílem MOF je poskytovat „next-generation platform independent metadata framework for OMG“ postavené na předchozí verzi MOF, XMI 2.1, XMI production of XML Schemas a JMI 1.0. (uf, marketingovej žvást).
• Hlavní výhody:
  • Jednodušší pravidla pro modelování metadat (stačí znát omezenou podmnožinu UML).
  • Různé technologie mapování (XMI, JMI apod.)
  • Širší podpora nástrojů pro metamodelování (čistě proto, že nástroje umí UML, takže můžete i metamodelovat, aniž by o tom ten nástroj věděl) – hezké, jak z ničeho vytřískat hodně.
• MOF stále hojně využívá operaci MERGE (která byla při zjednodušení UML z 2.4.1 na 2.5 z popisu jazyka vynecháno, pozor, metatřída v UML PackageMerge samozřejmě zůstala).

UML

• Definice UML je napsaná/specifikovaná pomocí UML modelu nazvaného metamodel UML. Tento metamodel používá konstrukty z vybrané podmnožiny UML – což je vlastně onen MOF. [UML, 6.2]
• Třídy v metamodelu se nazývají metatřídami. [UML, 6.2]
• Pokud tedy vezmeme UML metatřídu Element, pak víme, že jde o abstraktní metatřídu. Z pohledu MOF jde tedy o instanci metatřídy Class, jejíž atribut isAbstract má hodnotu true. Nebo metatřída Comment má atribut body, což z pohledu MOF je je instance metatřídy Property, jejíž název je body. [UML, 6.2]
• Souhrnem je tedy UML definováno samo sebou (podobně jako např. překladač jazyka c může být napsán v týmž jazyce) nebo funkce může být definována sama sebou (rekurzivně, např. faktoriál).  [UML, 6.2]
• Výhodou uvedeného je to, že s UML lze manipulovat tak, jak je definováno v MOF a model lze mít v XMI formátu.  [UML, 6.2]

Model

• Model je vždy model něčeho. [UML, 6.3.1]
• Modelem říkáme o skutečnosti to, co nás v dané chvíli zajímá, přičemž abstrahujeme od detailů, které sice popsat/modelovat lze, ale není to potřebné. [UML, 6.3.1]
• UML model se skládá ze tří základních částí (ang. individual things, zkráceně i individuals): klasifikátory, události a chování. [UML, 6.3.1]
• Klasifikátory (classifiers): [UML, 6.3.1]
  • popisují množinu objektů.
  • Objekt je ve vztahu s jinými objekty, je v nějakém stavu a nabývá nějakých hodnot.
• Události (events): [UML, 6.3.1]
  • události popisují množinu možných výskytů takových událostí.
  • Výskyt (occurence) je něco, co se stane a má nějakou konsekvenci v modelovaném systému.
• Chování: [UML, 6.3.1]
  • popisuje množinu možných vykonávání činností (execution).
  • vykonávání činnosti je provedení množiny akcí, které mohou generovat odpovědi na výskyty událostí nebo přistupovat k a měnit stav objektů.
• UML model jako takový NEOBSAHUJE objekty, výskyty události, ani provádění chování (pozor na to, že i použití metatřídy InstanceSpecification je jen modelování).[UML, 6.3.1]
• Provádění chování v modelovaném systému může vyústit ve vytváření a rušení objektů.[UML, 6.3.1]

fUML, kapitola 6.2 – obecné povídání o tom, co je to model a formalizace reálného světa. Nic zásadního pro ty, kteří chápou princip modelování a abstrakce.

fUML, kapitola 6.3 – opět, pokračování teorie o metamodelování (proč to sakra není v MOFu?):

• UML je reflexivní jazyk, neboť je definován sám sebou.
• Minimální reflexivnost: metamodel, který se mapuje sám na sebe. Z pohledu UML (2.4.1 a staršího) se jednalo o Infrastrukturu.

Spustitelné UML a jazyk akcí obecně

Executable UML (xUML, xtUML) je jednak způsob vývoje software a jednak vysoce abstraktní programovací jazyk. Poprvé přišel na svět v roce 2002. V té době šlo o UML profil, který kombinoval grafickou notaci podmnožiny UML se sémantikou pro vykonávání kódu.

Model spustitelného UML může být spuštěno, testováno, laděno a lze měřit výkonnost takového běhu. Dále jej lze zkompilovat do méně abstraktního programovacího jazyka (čímž se stává závislý na platformě daného jazyka).

Spustitelné UML je vyšší abstrakce programovacích jazyků třetí generace (např. C#, Java, C++, Pascal).

Jednotlivé akce, které se mají provádět, jsou určeny tzv. jazykem akcí (action language).

Systém je ve spustitelném UML rozdělen do několika oblastí zájmu, tzv. domén. Tyto domény jsou pak reprezentovány následujícími prvky:

• Doménový diagram (poskytuje pohled na modelované domény).
• Diagram tříd
• Stavový diagram
• Akce a operace modelované jazykem akcí

Aby OMG mělo něco svého a standardizovaného, přišla (světe, div se) se svými standardy. Foundation UML (fUML) je v podstatě jedna z možností spustitelného UML. Pro jazyk akcí OMG vymyslelo Alf (Action Language for Foundation UML). V následujících částech si tedy o fUML a Alfu povíme více s ohledem na požadavky zkoušky.

fUML (6 %)

Zkoušené oblasti:

• Scope
• Terms and Definitions
• Overviews of Abstract Syntax and Execution Model
• Behavioral Semantics

Zdroje

1. [fUML] fUML
   • 1 Scope: All
   • 4 Terms and Definitions: All
   • 7.1 Abstract Syntax: Overview
   • 8.1 Execution Model: Overview, Behavioral Semantics

Scope

Víceméně obecné kecy s odkazem ještě do superstruktury UML 2.2 (sakra, proč? Slyšel někdo v OMG o aktuální verzi UML?). Stručně řečeno se odkazují na to, že aktivity, stavové stroje a interakce mají „pod sebou“ akce. A tyto akce mají pod sebou dvě funkcionality: inter-object behavior base a intra-object behavior base. Inter-object behavior base říká, jak objekty mezi sebou komunikují, intra-object behavior base říká, k jakému chování dochází uvnitř objektu. Akce, které jsou nad nimi, pak slouží k tomuto popisu. Toto povídání je ještě v UML 2.4.1, ale v UML 2.5 již není. Každopádně fUML popisuje právě ony dva prvky: inter-object a intra-object behavior base.

Obecně lze říct, že fUML definuje pro UML virtuální stroj, na kterém může UML běžet.

Osobně se domnívám, že v OMG někomu opravdu řádně hráblo. UML je modelovací jazyk. MODELOVACÍ. Není pro to třeba dělat virtuální mašinu jen proto, že si na tom někdo postavil doktorát. No nic, pojďme dál.

Terms and Definitions

Upozornění: z nedostatku času doporučuji si tuto kapitolu (je čtvrtá) přečíst v fUML standardu v originále. Z nedostatku času nebudu nyní trávit čas nad lepším než podprůměrným překladem. Očekávám, že v testu na to dotazy budou.

Base Semantics – definice sémantiky vykonávání konstruktů UML použitých ve vykonávajícím modelu za použití formalismů jiných, než dává vykonávající model sám o sobě. Jelikož je vykonávající model UML model, základní sémantika je nutná z důvodu dosažení acyklického základu pro vykonávající sémantiku definovanou vykonávajícím modelem. Základní sémantika poskytuje význam pro běh pouze těch konstruktů UML, které jsou obsaženy ve vykonávajícím modelu. Vykonávající model pak definuje význam běhu libovolného UML modelu založeného na základní podmnožině (viz foundational subset). Libovolný nástroj, který vykonává vykonávající model by měl reprodukovat vykonávání chování určené pro něj (pro co?) by the base semantics. Uááágggrhhh.

Behavioral Semantics – mapování odpovídajícího jazykového elementu pro specifikaci dynamického chování vyúsťujícího do změn v čase na instance v sémantice domény, ve které je jazyk použit.

Compact Subset – pro potřeby standardu fUML se jedná o malou podmnožinu konceptu UML pro dosažení výpočetní úplnosti (no ty kráso).

Computationally Complete – výpočetně úplná podmnožina UML, která dokáže uspokojivě vyjádřit definici modelů, které mohou být automaticky spuštěné na počítači nebo ve vykonávajícím nástroji (execution tool, viz dále).

Execution Model – model, který poskytuje kompletní, abstraktní specifikaci, kterou musí splňovat vykonávající nástroj.

Execution Semantics – chovací sémantika konstruktů UML, které specifikují provozuschopné akce v čase, popisující či omezující schopnosti chování v modelované doméně.

Execution Tool – libovolný nástroj, který je schopen spouštěn validní UML model založený na fUML.

Foundation Subset – podmnožina UML, které je přiřazena sémantika spustitelnosti.

Static Semantics – potenciální, kontextově závislé omezení, které příkaz jazyka musí splňovat, aby byl well-formed.

Structural Semantics – mapování odpovídajícího jazykového elementu na instance v sémantice modelu, ve kterém je v daném jazyce zaznamenán nějaký příkaz.

Syntax – pravidla, jak tvořit správně formulované příkazy v jazyce (jakém?) nebo pro validaci toho, že navržený příkaz je opravdu správně.

Overview of abstract syntax

fUML je mezičlánek mezi „surface subset“ of UML (co to sakra je?) používané pro modelování a cílovým jazykem používaným pro běh modelu.

To tedy vyžaduje schopnost překladu ze surface subset UML (sakra, pořád nevím, co to je) do fUML a z fUML do cílové platformy.

V tomto kontextu (sakra, co to je surface subset UML? Povrchní podmnožina UML? Povrchové množení UML?) je fUML určeno třemi kritérii:

• Kompaktnost – podmnožina by měla být malá kvůli ulehčení definice jasné sémantiky a implementace běhových nástrojů.
• Jednoduchost překladu – podmnožina by měla umožnit přímý překlad z common surface subsets of UML (grrrrrrrrrrrrrr) do fUML a z fUML do jazyka cílové platformy.
• Funkčnost akcí – fUML pouze specifikuje, jak vykonávat UML akce. fUML tedy neobsahuje funkcionalitu vyžadující sjednocenou množinu UML akcí.

Mám to sakra chápat tak, že fUML je ve skutečnosti jen předpis pro to, jak si udělat vlastní executable UML? Něco mezi úrovní M3 a M2?

Předchozí tři body přinášení komplikace. Pokud např. máme surface vlastnost UML VlastnostX, tak bychom měli mít stejnou vlastnost i v jazyce platformy (např. v Javě). Jenže ji nemusíme mít v fUML. V takovém případě překlad do fUML musí použít jiné možnosti fUML. A překlad do jazyka platformy takovou „jinou“ možnost musí rozeznat a správně ji použít. Kompaktnost je pak v kolizi s jednoduchostí překladu.

Na druhou stranu, pokud by fUML VlastnostX uměla, narůstá komplexita. To nemusí být v jednom případě na škodu, ovšem postupem času může docházet k nabalování. A to není žádoucí.

fUML se snaží vyřešit vhodnou vyváženost mezi kompaktností a jednoduchostí překladu. Nemá např. výchozí hodnoty atributů, má ale třídy a operace. Stejně tak má komentáře či možnost dělení modelu do balíků.

Overview of Execution Model

Execution model je sám o sobě modelem napsaným v fUML, který určuje, jak jsou fUML modely vykonávány. Tato cykličnost je narušena oddělením specifikace základní sémantiky od podmnožiny fUML používané ve vykonávajícím modelu.

Behavioral Semantics

Vykonávaný model je formální a provozuschopná specifikace vykonávající sémantiky fUML. Tedy, že definuje procedury pro požadované změny, které se dějí při vykonávání modelu. Je to opak k deklarativnímu přístupu.

Vykonávaný model je sám o sobě spustitelný, objektově orientovaný model fUML of a fUML execution engine (uff). Aby bylo možné plně specifikovat chovací sémantiku fUML, vykonávaný model musí plně definovat své vlastní chování, tedy musí plně specifikovat každou metodu operace a chování klasifikátoru. Jelikož jediný typ chování, který fUML podporuje, je aktivita, každé chování musí být modelované pomocí aktivit.

Alf (6 %)

Zkoušené oblasti:

• Scope
• Semantic Conformance
• Integration with UML Models
• Lexical Structure

Zdroje:

1. [ALF] Action Language for Foundational UML (Alf)
   • 1 Scope: All
   • 2.3 Semantic Conformance: All
   • 6.1 Overview – General: All
   • 6.2 Integration with UML Models: All
   • 6.4 Lexical Structure: All

Scope

Alf (Action Language for Foundational UML) je textová, do hloubky nejdoucí reprezentace (textual surface representation, opět ono surface…) pro elementy modelované v UML. Sémantika vykonávání Alfu je dána mapováním syntaxe Alfu na abstraktní syntaxi fUML. Výsledek běhu Alfu je tedy dán sémantikou fUML modelu, na který je Alf mapován.

Primárním cílem jazyka akcí je možnost používat textový zápis, je-li třeba jej upřednostnit před grafickou notací. Přesto Alf poskytuje i rozšířenou notaci, která může být použita pro reprezentování strukturálních elementů. To znamená, že UML model může být celý reprezentován v Alfu.

Klíčové vlastnosti Alfu:

• Podobný jazyku C (C-legacy).
• Ačkoliv používáte Alf, není třeba kvůli tomu měnit model (např. názvy elementů z češtiny do cestinybezmezer).
• Podporuje jmenné prostory.
• Používá implicitní typový systém (není třeba tedy nic explicitně deklarovat).
• Alf má schopnost OCL pro manipulaci se sekvencemi hodnot.

Semantic Conformance

Sémantika vykonávání Alfu je popsána ve standardu jednak neformálně a jednak je specifikována formálně mapováním na fUML. Odpovídající nástroj poté musí implementovat sémantiku danou vybranou podmnožinou Alfu (jsou tři – minimum conformance, full conformance a extended conformance).

Takový nástroj má tři cesty k implementaci:

• Interpretace – text je interpretován podobně jako skript
• Kompilace – Alf je překompilován do fUML a běh je poté veden nad fUML modelem.
• Překladový běh – modelovací nástroj překládá Alf a UML model tak, jak je mu bližší do nějaké běhové podoby NEZALOŽENÉ na UML (např. exe file).

Bez ohledu na způsob implementace je nutné, aby všechny tři způsoby měly stejný výsledek z pohledu uživatele.

Integration wih UML Models

Zdrojový text zapsaný v Alfu může být jak v modelu, pro který je vytvořen, tak v jiném takovém modelu.

UML jako takové je definováno grafickou a textovou notací. Alf může být použit jako alternativa k uvedenému. Alf může být použit v těchto třech situacích:

• Kdekoliv je třeba vyjádřit hodnotu (value specification) – toho je možné dosáhnout jako body OpaqueExpression nebo může být Alf zápis přeložen do odpovídající UML aktivity
• Kdekoliv jsou použity příkazy:
  • Definování chování UML akcí v aktivitě nebo interakcích. Opět, Alf lze použít v body OpaqueAction nebo přeložen do odpovídajícího strukturovaného uzlu (structured aktivity node).
  • Definování celého chování – opět, jako body v OpaqueBehavior nebo jako překompilát do odpovídající aktivity.
• Reprezentování klasifikátorů a balíků, které jsou zamýšleny pro individuální referencování pomocí názvu.

Bez ohledu na překlady je fajn, když je zachován původní Alf text. Ten může být v původním modelu, ve speciálním modelu nebo jako textová poznámka napojená na nejvyšší prvek, který z překladu vzešel. Tato poznámka pak má stereotyp TextualRepresentation a tagovou hodnotu language s hodnotou Alf.

Lexical Structure

Lexikální struktura Alfu definuje rozdělení řetězců zdrojové podoby do tří typů vstupních prvků: bílé znaky (whitespace), komentáře a tokeny.

Lexikální analýza je proces konverze textu zapsaného v Alfu do odpovídajícího streamu vstupních elementů. Během této analýzy jsou komentáře a bílé znaky zahozeny.

Lexikální struktura je určena lexikální gramatikou, ve které jsou znaky terminálem a vstupní elementy vzniklé při lexikální analýze jdou neterminální (nebudu to více vysvětlovat, je třeba si vzpomenout na přednášku Základy překladačů na MFF UK). Lexikální gramatika je definována rozšířenou Backus-Naur formou (EBNF), jejíž konvenci lze vidět zde:

• Terminal element: „terminal“
• Non-terminal element: NonterminalElement
• Sequential element: Element1 Element2
• Alternative elements: Element1 | Element2
• Optional element (zero or one): [ Element ]
• Repeated element (zero or more): { Element }
• Production definition: NonterminalElement = …

 

Uložit

Uložit

Uložit

Uložit

Uložit

Uložit

Uložit

Uložit

Uložit

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!

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:

	OCUP 2 Foundation	OCUP 2 Intermediate	OCUP 2 Advanced Pouze spekulace!
Číslo zkoušky	OMG-OCUP2-FOUND100	OMG-OCUP2-INT200	OMG-OCUP2-ADV300
Délka zkoušky*	120/150	105/135	90/120
Počet otázek	90	90	90
Minimum pro úspěch	60 (tj. 67 %)	51 (tj. 57 %)	45 (tj. 50 %)

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

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.

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.

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.

Dlouho jsem se odhodlával k tomu, abych sepsal nejen to, jaké změny UML 2.5 přináší, ale také to, zda tyto změny mají smysl. Konečně jsem se k tomu dostal, takže se na to nyní pojďme společně podívat.

Trocha historie

Konečná podoba standardu UML 2.0 byla vydána sdružením OMG v roce 2005, tedy dva roky poté, co se s ní seznámilo. Od té doby docházelo pouze k dílčím změnám a opravám, které se ve standardu postupně nacházely (ostatně sám na některé poukazuji v přípravném textu pro certifikaci OCUP). UML standard se skládal ze dvou částí: infrastruktury a superstruktury. První jmenovaná byla především pro vývojáře UML nástrojů a blázny, druhá pak pro uživatele UML jako takového.

Dlouhou dobu se mluvilo o tom, zda připravit UML verze 3.0 nebo zda udělat jen dílčí změny. Bohužel OMG je složeno mj. z několika mezinárodních společností, a kdo v nějaké takové korporaci pracuje, tak ví, že dosáhnout seriosního výsledku je téměř nemožné. A teď si představte, že se takových firem sejde více a každá vnitřně přemýšlí, co do UML zavést a pak ještě musí komentovat návrhy dalších zainteresovaných stran. Je tedy jasné, že výsledek nemůže být ani v rozumné době, a často ani přínosný. Jen opravy drobných chyb trvají roky! Možná právě proto se začalo hovořit pouze o zjednodušení standardu jako takového, ovšem tak, aby koncový uživatel nic nepoznal. Původní termín byl několikrát posunut, jeden z posledních takových byl květen loňského roku. Ačkoliv se OMG probudilo, bohužel zjistilo, že letos, tj. v roce 2014, bude slavit 25 let své byrokratické existence, a tak vše šlo stranou a začaly se připravovat zákusky, šampaňské a dortíky na oslavu. Kvůli tomu tedy máme první beta verzi UML 2.5 vydanou v říjnu 2012, druhou beta verzi v září 2013 a od té doby je ticho po pěšině (zřejmě lemované výsledky bujarých oslav).

Ale abych jim úplně nekřivdil, alespoň v certifikační zkoušce se něco událo (viz dále). Kdy ovšem bude konečná verze UML 2.5, tak o tom se můžeme zatím jen dohadovat. Můj osobní názor je takový, že brzy někomu bouchnou saze a dle úsloví z nouze cnost se druhá beta prohlásí za onu kýženou finální (s opravdu minoritními úpravami).

Změny v UML

Nyní ale již k vlastním změnám. Tou první zásadní a viditelnou je sloučení superstruktury a infrastruktury do jediného dokumentu (což je úspora cca 150 stran) nazvaného čistě a prostě OMG Unified Modeling Language. Druhou, už ne tolik viditelnou, ale zcela nejzásadnější změnou je, že se pro definici UML nepoužívá spojování balíků (třída PackageMerge), ale každá metatřída je definovaná na jednom místě jako jeden celek.

Tuto druhou změnu považuji za poměrně velkou podpásovku a nesmysl. Hned na začátek musím na rovinu uznat, že operace spojení balíků je hodně náročná a k pochopení si musíte pár věcí načíst. To je jediný argument, který pro vypuštění akceptuji. Na druhou stranu UML nepoužívalo všechna pravidla této operace, jen ty nejjednodušší. A teď to hlavní: dříve stačilo nastudovat balík Classes::Kernel (případně přidat velmi jednoduché Classes::Dependencies, Classes::Interfaces a Classes:: AssociationClasses) a uměli jste základ, jádro UML. Mohli jste modelovat třídy, vazby mezi nimi, a jakmile bylo třeba naučit se něco dalšího, stačilo stavět na již naučených dovednostech. Ne však tak již dnes. Např. hned po první kapitole, kde se dozvíte o třídách Element, Relationship, DirectedRelationship a Comment, na vás čekají šablony. Tj. téma, které jednak je např. obsaženo až v poslední úrovni testu znalosti UML a jednak téměř nikdo nepoužívá. U hodnot se pak již standard zmiňuje např. o TimeExpression či Duration (opět, zřídkakdy používaná část UML) či o chování. A mohl bych pokračovat. Nelze tedy jednoduše studovat UML po logicky ucelených blocích postupně a na znalostech stavět. Jestli tím chtělo OMG podpořit prodej knih o UML, těžko říct. Ale dle standardu se již UML těžko naučíte. Hodně těžko.

Pojďme ale dál. Snahou tvůrců nové verze bylo maximálně omezit nutnost mít tzv. dopředné znalosti, tedy ve výkladu použít něco, co se teprve bude probírat v pozdější kapitole. Musím uznat, že tohle se vcelku povedlo. Jako důsledek toho je nejen jiné členění kapitol, ale i jiné rozdělení UML do jednotlivých balíků (viz následující obrázek, kde je náhled na část UML 2.4.1 a 2.5 načteného do Enterprise Architekta).

Ve standardu již nenajdete úrovně shody s UML dle úrovní L0 až L3 čistě proto, že to nikdo nepotřeboval a nepoužíval. Jestliže totiž některý současný nástroj chce podporovat UML, tak ho podporuje celý. Tedy… snaží se. Ne však vždy zcela správně.

Změn doznala i struktura základního vysvětlování dané oblasti, tedy notace, sémantika, pravidla a další potřebné věci. V UML od 2.0 až do 2.4.1 včetně byla za začátku každého celku (např. balík Classes) kapitola nazvaná Abstract syntax, kde byly diagramy vztažených elementů. Poté následoval popis každého elementu (tj. elementy, ze kterých je odvozen, popis, atributy, asociace, omezení, sémantika a notace), který byl touto částí definován. Na závěr pak byla souhrnně zobrazena notace. Výhoda byla, že když jste potřebovali něco vědět o konkrétním elementu, měli jste to na jednom místě. Pokud jste potřebovali znát, jak tyto elementy fungují dohromady (např. kompozitní struktury), museli jste hodně listovat.

UML 2.5 se k tomu staví jinak. Každý balík má krátké shrnutí na začátku a poté je rozdělen do podoblastí (např. balík Simple Classifiers popisuje v jedné části datové typy, v jedné signály a v jedné rozhraní). Každá takováto podoblast ukazuje diagram relevantních prvků, popisuje sémantiku, notaci a uvádí příklady. Velkou výhodou je, že vidíte, jak tyto prvky spolu souvisí a jak se případně doplňují. Poté následuje část nazvaná Classifier Descriptions, ve které jsou již formálně uvedeny diagramy, kde se prvek nachází (paráda!), prvky, od který je ten popisovaný nejen odvozený, ale i další, které z něj vycházejí (paráda!), asociační konce a omezení. Jestliže však chcete mít popis elementu na jednom místě, máte smůlu, což je neskutečný průser. UML standard má fungovat jako reference a tento způsob to neumožňuje! Sám tedy používám pro hledání informací jak UML 2.4.1, tak i 2.5, a to na základě toho, co potřebuji zjistit.

Dosud jsme se bavili jen o změnách ve struktuře dokumentu, ale verze 2.5 přináší i pár drobných změn, které postřehne málokdo (a pro málokterého z uživatelů má nějaký sebemenší význam). Takže jen ve zkratce:

• Autoři se snažili opravit všechny chyby v omezeních (constraints) definovaných pomocí OCL. Konečně!
• Několik násobností s dolní hranicí 1 bylo posunuto na 0.
• Informace {ordered} byla někam přidána a někde naopak odebrána, aby to jako celek dávalo smysl.
• Vlastnost LoopNode::loopVariable je nyní kompozitní.
• NamedElement::clientDependency je nově odvozená vlastnost (derived).

Změny v certifikačních zkouškách OCUP

O změnách v certifikační zkoušce jsem toho už napsal poměrně dost, stačí se podívat na mé první informace o změnách a o průběhu testu. Zde tedy jen pár základních bodů, které jsou důležité či které mě zaujaly z přechodu z OCUP na OCUP 2:

• Zkouška první úrovně se přejmenovala z Fundamental na Foundation.
• Prozatím lze skládat pouze úroveň Foundation a pokud máte úroveň Fundamental, pak i další dvě úrovně (více v článku o certifikační schizofrenii, časem se snad to srovná).
• Konečně je test zaměřen mnohem víc na praktické znalosti uživatele UML nežli na akademické znalosti standardu.
• Platnost certifikátu OCUP2 bude pět let. Certifikáty OCUP platí na doživotí, ale jsou již označovány jako zastaralé (obsolete).

Podrobnější informace pak najdete již v uvedených článcích.

Mělo to tedy smysl?

Co se UML jako takového týče, tak rozhodně ne. Nebýt vypuštění používání třídy PackageMerge ze standardu, změnu bych uvítal. Ale takhle to byla zbytečná práce. Vynaložené úsilí se mělo věnovat na opravu chyb a definování některých požadovaných změn.

U zkoušek OCUP (2) jsem naopak moc rád, že ke změně došlo (a to bez ohledu na to, že já vynaložil mnoho času na text pro zkoušku úrovně Advanced a teď evidentně bude mnohé jinak). Konečně to prověří nejen teoretickou znalost UML, ale prokáže, že nad tím umíte přemýšlet, že UML dokážete použít a koneckonců to něco vypoví i o vašich znalostech objektově orientovaného světa. A to je dobře.