Co si přečíst ještě letos

Č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?

Zcela bez uzardění nejprve doporučím své dvě knihy, které mají čtenáře připravit ke zkoušce OCUP 2 Foundation a OCUP 2 Intermediate. Jedná se o elektronické knihy, které navíc dávám zdarma během svého certifikačního školení. 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. Více se dozvíte přímo na stránce věnované oběma knihám.

Slávek Rydval: UML a OCUP 2 aneb jak si certifikovat znalosti UML 2, úroveň Foundation, 2017, ISBN: 978-80-906968-1-5, počet stran: 126

Slávek Rydval: UML a OCUP 2 aneb jak si certifikovat znalosti UML 2, úroveň Intermediate, 2017, ISBN: 978-80-906968-2-2, počet stran: 142

Pokud nechcete nic číst v češtině, pak tu jsou další dvě knihy, na které jsem narazil. Tou první je UML @ Classroom. Jedná se o publikaci postavenou na základě školení UML. Ještě jsem neměl možnost začíst se důkladně, ale již jsem ji několikrát prolistoval a vypadá rozumně. Objednat lze na The Book Depository (poštovné je zdarma).

Martina Seidl, Marion Scholz, Christian Huemer, Gerti KappelUML @ Classroom: An Introduction to Object-Oriented Modeling, 2015, ISBN 978-3-319-12741-5

Tou druhou je kniha vyšlá minulý měsíc a má připravit k certifikační zkoušce OCUP 2 Foundation. Jmenuje se OCUP 2 Certification Guide: Preparing for the OMG Certified UML 2.5 Professional 2 Foundation Exam a opět je dostupná např. na The Book Depository s poštovným zdarma. Knihu jsem ještě v ruce nedržel, ale již ji mám objednanou a je na cestě. Jsem zvědav, jak píše o certifikační zkoušce konkurence.

Michael Jesse Chonoles: OCUP 2 Certification Guide: Preparing for the OMG Certified UML 2.5 Professional 2 Foundation Exam, 2017, 384 stran, ISBN 978-0-12-809640-6

A jak si od UML odpočinout? I zde nabízím možnost. Letos mi jakožto spoluautorovi vyšly tři knihy o dubáncích. Tou první jsou Dubánci – příběhy jednoho roku. Jde o 120stránkovou knihu, kterou byste, hlavně teď, když je všude žaludů dost, měli přečíst svým dětem ve věku 4-12 let.

Jestliže máte mladší děti, můžete jim pořídit dubánčí leporela. Jedno se nazývá Dubánčí den, druhé Dubánčí rok. Kromě obrázků v sobě mají básničky. Tato dvě leporela vycházení příští týden.

Všechny tři knihy jsem dával dohromady se skvělou Leonou Šťastnou a kamarádem Petrem Václavkem. Vše lze zakoupit např. na internetovém knihkupectví Kosmas.

Leona Šťastná, Slávek Rydval: Dubánci, příběhy jednoho roku, 2017, 120 stran, ISBN 978-80-264-1439-1

Leona Šťastná, Slávek Rydval, Petr Václavek: Dubánčí rok: Veršovánky s dubánky, 2017, ISBN 978-80-264-1633-3

Leona Šťastná, Slávek Rydval, Petr Václavek: Dubánčí den: Veršovánky s dubánky, 2017, ISBN 978-80-264-1632-6

Rubriky: Nezařazené | Štítky: , , , | Napsat komentář

Podzimní veřejný kurz Sparx Enterprise Architect

Vypisuji veřejný termín pro školení Enterprise Architect pro (nejen) mírně pokročilé a to na 27.-28.11. 2017 v Praze. Pokud máte zájem, neváhejte s objednávkou.

Během školení vás provedu nejprve základy nástroje a poté budeme nabalovat další a další schopnosti éáčka do té míry, abyste byli schopni pracovat samostatně. Vše si ukážeme na příkladech.

Prohlédněte si podrobný přehled školení včetně dalších informací, objednejte se a připravte si na svém počítačí éáčko. A já se těším na viděnou.

Uložit

Rubriky: Nezařazené | Štítky: , | Napsat komentář

Jak jsem se NESTAL oficiálním konzultantem SPARXu

S nástrojem Sparx Enterprise Architect pracuji už hodně dlouho a myslím si, že o něm toho vím poměrně dost. Protože jej i učím, rozhodl jsem se požádat Sparx o oficiální partnerství v oblasti poskytování školení a konzultací.

Na jejich stránkách jsem tedy v lednu tohoto roku vyplnil poměrně obsáhlý dotazník, zaškrtl partnerství Consulting a Training a pak již jen čekal, co oni na to. Zkraje února přišla první odpověď, že vše je paráda a jak si představuji, že budu podporovat prodej a vlastně i prodávat EA tu v ČR. Kromě toho bych měl psát články na stránku komunity EA.

Na to jsem odepsal, že články určitě nejsou problém (s ohledem na požadovanou frekvenci cca jednou za dva tři měsíce), ale že nástroj prodávat v současné době určitě nechci. To celé s douškou, že doufám, že to není nutná podmínka.

Odpověď přišla záhy s jasným stanoviskem: Jedním z hlavních důvodů, proč Sparx poskytuje partnerství, je podpora prodeje nástroje. Současně ale bylo uvedeno, že nejsou žádné podmínky na počet prodaných licencí. Tedy klidně nula.

To mi však přišlo jako podivné řešení, kterému jsem nechtěl propadnout. Alespoň ne v současné době. Je možné, že třeba někdy v budoucnu licence prodávat budu, ovšem to bude třeba řešit na jiné bázi, než funguji dnes.  Závěrem jsem jim ve vší slušnosti poděkoval a současně akceptoval to, že zůstávám NEOFICIÁLNÍM konzultantem a školitelem Sparx EA. A vy této možnosti můžete využívat.

Uložit

Rubriky: Nezařazené | Štítky: | Napsat komentář

Nová služba: Aplikační podpora Sparx Enterprise Architect

Za poslední rok jsem víceméně pravidelně dostával postesky, že lidem především ze středních a velkých firem chybí nějaká podpora a konzultace v řádech destítek minut až malých hodin se zaměřením na Sparx Enterprise Architect. Dosud jsem to řešil ad-hoc, ale na základě pozitivních zkušeností zavádím novou službu nazvanou Aplikační podpora Sparx Enterprise Architect.

V čem to spočívá? Představte si, že máte náhlý problém s nástrojem, nevíte si rady s konfigurací nebo chcete poradit s výběrem licenčního schématu či edice. Se službou Aplikační podpora máte problém z 90 % vyřešený. Zavoláte mi nebo mi napíšete a já se Vám budu věnovat. K dispozici z mé strany bude i vzdálená podpora, takže se mohu připojit k Vám na počítač a vyřešit to „na místě“. Jestliže zjistíme, že problém je přímo v nástroji, budu kontaktovat výrobce.

K dispozici jsou celkem tři modely možné podpory: Téměř expresní, Běžná a Ad-hoc. Bližší informace a ceny najdete přímo na stránce služby.

 

 

Uložit

Uložit

Uložit

Rubriky: Nezařazené | Štítky: | Napsat komentář

Tahák: Oblíbené klávesové zkratky v EA

Školní rok sice začíná až v pondělí, ale to neznamená, že bychom se neměli připravit již nyní. K dispozici dávám přehled mých oblíbených klávesových zkratek, které v éáčku používám nejčastěji. Kromě toho tam ještě máte prostor pro své vlastní zkratky.

Vše je ke stažení v pdf podobě. Dokument lze v nezměněné podobě šířit.

Rubriky: Nezařazené | Štítky: | 1 komentář

Učebnice pro přípravu k certifikaci OCUP 2 Intermediate

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.

A konečně poslední zpráva: ve dnech 20. 9. – 21. 9. 2017 ve spolupráci se školicím střediskem Anywhere pořádám školení Příprava k certifikační zkoušce OCUP 2 Foundation. Účastníci získávají licenci na odpovídající text knihy v ceně školení.

V případě, že Vám termín nevyhovuje, můžeme si domluvit vlastní, a to nejen na OCUP 2 Foundation, ale na mnohé další.

Rubriky: Nezařazené | Štítky: , , , , | Napsat komentář

Kam si Sparx Enterprise Architect ukládá data

Soubor s příponou .EAP zná, doufám, každý uživatel nástroje Sparx Enterprise Architect. Ovšem často vídám udivení, když řeknu, že to není nic jiného, než databáze formátu Microsoft Access. Každopádně to není jediný způsob, kam můžete vaše modely ukládat. Jaké jsou tedy všechny možnosti?

Obecně lze hovořit o souborových a serverových úložištích (repositories):

  • Souborové úložiště
    • EAP soubor
      • MS JET 3.5
        • JE již zastaralé, známe od MS Access 97
        • Neumí UNICODE (MS Access ’97 format .mdb)
        • Data se zamykají na úrovni stránky, což dělá problém při přístupu více uživatelů k datům
      • MS JET 4.0
        • Bylo (je) součástí MDAC (Microsoft Database Access Components)
        • Je pouze 32bitové
        • Je součástí Windows 2000 až Windows 7
        • Zamykání je na úrovni záznamu
      • Access 2007
        • „Office-specific“ verze MS Jet původně nazývaná Office Access Connectivity Engine (ACE), nyní Access Database Engine
    • FEAP (Firebird Backend Database, od EA 11)
      • Více robustní, ale umožňuje pouze jednouživatelský přístup
  • Serverové úložiště
    • Pouze pro licence Corporate a vyšší
    • Databázové
      • Podporované následující SQL servery: Oracle, MS SQL, MySQL, PostgreSQL, Sybase a MariaDB.
      • Nutno každé úložiště zvlášť nakonfigurovat
  • Cloudové úložiště
    • http(s) připojení na interní síti nebo „do světa“
    • Nejsou nutné databázové drivery na lokálním počítači
    • Podpora protokolů TLS/SSL

Výhody a nevýhody jednotlivých typů

EAP soubory

  • Pro použití na lokálním PC jednoho uživatele
    • Rychlé, efektivní, bez dalších nákladů a nutnosti být neustále připojen do sítě (s drobnou výjimkou sdíleného klíče)
    • Hůře se sdílí dílčí výsledek práce, lépe se předává zákazníkovi jako celek
  • Pro hodně malé týmy
    • Do cca 5 uživatelů, kteří si nelezou do zelí
    • Vhodné pro menší úložiště
    • Nutnost sdíleného místa na síti
  • Ve spolupráci s verzováním:
    • Na síti „master“, na lokále práce uživatele
    • Neustálý opruz s importem a exportem

Databázové

  • Většinou je automaticky zálohováno
  • Lepší řízení přístupových oprávnění (ačkoliv…)
  • Nutnost být neustále online
  • Problematické s docking stations (spojení padá a s tím i spuštěná instance EA)
  • Musí někdo spravovat (nejen server, ale i klientské stanice)
  • Pouze pro licence Corporate a vyšší

Cloud

  • To samé co předchozí kromě nutnosti spravovat databázové klienty na uživatelských stanicích

Přesun dat mezi různými repository

Jestliže chcete změnit typ úložiště, EA vám k tomu nabízí podporu. Na pásu karet (ribbonu) zvolte Configure a na ní možnost Transfer. Ve vyvolaném dialogu Project Transfer zadejte požadované hodnoty.

Pozor: v cílovém místě musí být připravené podkladové tabulky a veškerá data, které v nich jsou, budou smazána. V některých případech je nutné před přesunem ještě udělat nějaké úpravy.

Blíže doporučuji dokumentaci nebo poptejte některé mé školení či konzultaci.

Rubriky: Nezařazené | Štítky: | Napsat komentář

Beta verze zkoušky OCUP 2 Advanced absolvována

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

Rubriky: Nezařazené | Štítky: , , , , | Napsat komentář

Asociace třídy sama na sebe

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

Rubriky: Nezařazené | Štítky: , | Napsat komentář

OCUP 2 Advanced Beta – Metamodeling

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

Rubriky: Nezařazené | Štítky: , , , | Napsat komentář