Zkouška OCUP 2 Intermediate proměněna v certifikát

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

ocup2inter

 

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

OCUP 2 Intermediate konečně v plné palbě

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.

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

Poslední šance na složení OCUP Intermediate

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

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

Jak se ze Sparx EA připojit k JIRA?

Na základě několika dotazů, které jsem dostal na připravované rozšíření pro Sparx Enterprise Architect, které se napojí do nástroje JIRA (psal jsem o něm v souhrnu minulý týden), tu trochu rozepisuji, co bude umět. Předem upozorňuji, že jde o rozpracovanou verzi a pár věcí se může ještě změnit.

K JIRA se připojuje balík na základě Jql dotazu (tedy něčeho, co by měl uživatel JIRA dobře znát). Tento dotaz může být obecný nebo jít o konkrétní epiky a k němu navázané storky (issues obecně). To se zadavá pomocí jednoduchého dialogu s možností definovat Jql dotaz:

JuraJqlDefinition

Výsledek první možnosti je na obrázku v balíku Blok testy::Jql (dotaz zněl type = task or type = story). Epiky a jeho storky jsou pak v balíku Blok testy::Epics and issues.

JuraProjectBrowser

Obsah balíků lze samozřejmě obnovit. Pokud ve výsledku nějaké issues přibudou, jsou přidány i do balíku, pokud se v dotazu již neobjeví, jsou z EA přesunuty do speciálního balíku. Ostatní jsou případně aktualizovány. Je to z toho důvodu, že je možné mít k libovolnému issue různé vztahy, a já chci, aby zůstaly zachovány. Komponenty uvedené v issues mám totiž fyzicky i v EA a pomocí vztahů pak budu jednoduše podporovat dohledatelnost (tracebility).

JIRA Test - Jura

To, kam se připojit, je dáno jednoduchým dialogem:

JuraLogin

Každé issue lze zobrazit (obsah okna se ještě výrazně změní):

JuraIssueProperties

Je-li třeba, pak si můžete issue zobrazit i v prohlížeči přímo v okně EA. Více viz další obrázek:

JuraWholeViewBod 1: Balík, který obsahuje zvolené issues.

Bod 2: Definice dotazu do JIRA je uložena v tagových hodnotách.

Bod 3: Průběh načítání issues.

Bod 4: Zobrazení issue v prohlížeči na záložce v EA.

Dodělat už toho nezbývá moc, většinou už jen testuji. Pokud chcete zkusit předběžnou verzi, napište mi. Hotovo by mělo být do konce září.

Uložit

Uložit

Uložit

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

Další ohlédnutí s vyhlédnutím vpřed

Slunce brzy dorazí do roviny rovníku a je tedy na čase, abych opět nechal nahlédnout do mé dílny. Kdo chcete, mrkněte, co se událo, na čem pracuji a co lze očekávat.

  1. Hned zkraje musím připustit, že jsem trošku zanedbával psaní článků. Řešil jsem spousty povinností, a když přišel čas na zábavu, věnoval jsem se spíše Malině a programování nežli UML. Na druhou stranu i tu Malinu jsem v jednom článku využil.
  2. Rozšiřoval jsem Aktivní diagramy. Ostatně, o tom jsem psal.
  3. Rok průběžně pracuji na rozšíření Sparx Enterprise Architectu pro firmu, kde jsem zaměstnán. Díky tomu člověk nabere spousty zkušeností s EA. Bohužel naráží i na to, že mnohdy programátoři ze Sparxu neodvedli dobrou práci. Pokud chcete vy sami vědět, jak se rozšíření pro EA dělá, využijte mé školení.
  4. Připravoval jsem se na betu OCUP 2 Intermediate. Vzal jsem to důkladně a hned si vše psal. Co s tím, dozvíte se níže. Následně jsem si beta verzí OCUP 2 Intermediate prošel. Náročné na pozornost a na čas. Více jsem se o tom rozepsal hned po zkoušce. Jak jsem dopadl, bych měl vědět na přelomu září a října.
  5. AnywhereV červnu jsem připravil osm lidí na OCUP Intermediate, šest jich šlo ke zkoušce a úspěšně prošli. Gratuluji všem. V září učím OCUP 2 Foundation a poté Sparx Enterpise Architect. Na druhé zmíněné školení, které je ve spolupráci se školicím střediskem Anywhere, se můžete ještě přihlásit. Pouze pozor na to, že termín bude o den posunut na 14.-15. 9. Dále upozorňuji na přípravu ke zkoušce UML Advanced.
  6. logo-lightDalší školení jsem připravil ve spolupráci se školicím střediskem Goodea Consulting. Mrkněte na moje UML školení, jen říjnové termíny se budou posouvat.
  7. Samozřejmě stále platí, že můžete poptat přímo mě. Více na http://www.kurzy-uml.cz.
  8. S mou úžasnou ženou a kamarádem jsme téměř dokončili přípravy dětského leporela s tématem dubánků a měsíců v roce. Více o tom píše Petr.Dubanci
  9. V práci jsem nucen používat nástroj Atlassian JIRA. Protože jeho použití mi nepřijde intuitivní a navíc na jednotlivé issues potřebuji ve Sparx Enterprise Architectu navazovat elementy (typicky komponenty), rozhodl jsem se tedy připravit plugin pro EA, který bude EA a JIRU integrovat. Na obrázcích je první ukázka. Pokud máte podobný problém, ozvěte se, rád bych, aby to bylo použitelné ve větším měřítku.
    JuraProjectBrowser
    JuraIssueProperties
  10. Plním si jeden ze svých snů a dávám si dohromady víkendové sídlo na místě, které je mi velmi blízké. Již brzy snad bude hotové.Jilove
  11. A perlička na závěr. Nevím, zda je více směšná, trapná nebo absurdní, ale to není důležité. Tento blok se řešil během jednoho soudního stání stran úpravy styku s dětmi. Naštěstí soudkyně měla rozum zdravý. Ostatně, je tu snad něco špatně?

A co je přede mnou?

  1. Inu, stále slibovaný on-line kurz přípravy k certifikaci UML. Pro úroveň OCUP 2 Foundation je text již napsaný, probíhá jeho revize a připravují se otázky ke každé kapitole. Na úroveň OCUP 2 Intermediate mám text také víceméně hotový, takže až bude zkouška ve finální verzi, školení bude připravené výrazně rychleji, než tomu je u první znalostní úrovni. A časování? Snad již v říjnu. Dosud můžete využívat mé školení, kdy se uvidíme osobně.
  2. Aktivní diagramy – mám rozpracovanou aktualizaci diagramů tak, aby bylo možné ji kdykoliv přerušit. To ocení ti z nás, co mají v dokumentu desítky či stovky diagramů.
  3. Připravuje se Enterprise Architect 13, v současné době je k dispozici beta verze. Určitě se se svými zkušenostmi podělím. Podle předběžných informací to vypadá na větší změny.

Pěkný zbytek prázdnin.

Uložit

Uložit

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

Primární a sekundární (pomocné) případy užití

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

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

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

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

Knižní eShop var. 1

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

Knižní eShop var. 2

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

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

Knižní eShop var. 3

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

Knižní eShop var. 4

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

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

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

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

I diagramy nasazení jsou abstrakcí reality

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

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

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

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

MalinaRealita

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

MalinaTeplotaTerminal

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

PříkladRaspberryPi

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

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

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

OCUP 2 Intermediate beta – 247 otázek, 3,5 hodiny pekla

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ů?
    JmenneProstory
  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?
    ElementImport
  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?
    Instance
  7. Packages: Mohou mít dva balíky na stejné úrovni stejné URI?
    PackagesAndURIs
  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?
    DiagramNasazeni
  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?
      KdyZacneAkce
  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.

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

Vyhledávání diagramů v Aktivních diagramech

Našel jsem si v sobotu chvilku pro sebe a do Aktivních diagramů dodělal možnost vyhledávat diagram při vkládání nového diagramu. Záložka „Find a Diagram“ tedy konečně něco dělá:

VyhledavaniDiagramuZadat můžete přesný název nebo jeho část, rozlišovat nebo potlačit rozlišování velkých a malých písmen, a pokud i to je vám málo, jsou k dispozici regulární výrazy.

A to je vlastně vše. Drobnost, ale snad potěší.

Rozšíření si jako obvykle můžete stáhnout, případně si o něm přečíst jako o celku.

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

Vývoj Aktivních diagramů není pasivní

I přes vánoční svátky se mi podařilo občas spustit Visual Studio, a tak mohu představit další novinku v Aktivních diagramech, kterou uživatelé chtěli.

Nečastějším požadavkem byla potřeba znát, zda diagram v dokumentu je či není vložen pomocí rozšíření Active Diagrams. Nyní není nic jednoduššího, než si zobrazit panel s informacemi o diagramu:

ActiveDiagramsTaskPanePokud je obrázek (diagram) v dokumentu označen a je vložen pomocí Active Diagrams, uvidíte základní data nejen o diagramu jako takovém, ale zvíte i datum vložení do dokumentu a poslední aktualizaci.

Okno s těmito informacemi se vyvolává na již známém místě – na záložce s doplňky. Ty jsou rozšířeny kromě jiného o zaškrtávací pole, které zobrazí nebo schová požadované informace.

AddonRibbonVer1_6Další dvě nová tlačítka pak slouží k:

  1. Spuštění Sparx Enterprise Architecta s repository připřazenou k dokumentu.
  2. Spuštění výchozího prohlížeče se stránkou produktu.

Rozšíření si jako obvykle můžete stáhnout, případně si o něm přečíst jako o celku.

 

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