Opět bych vás chtěl pozvat na kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1.

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1

Datum konání kurzu:  4. 6. – 6. 6. 2012

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé i studené nápoje. V ceně kurzu jsou obědy v restauraci.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu
Výběr z ohlasů na kurz

Zde jsou ještě některé ohlasy z twitteru na  kurzy, které proběhly na podzim roku 2011:
https://twitter.com/#!/AugiCZ/status/129271721512538112

https://twitter.com/#!/topascz/status/129228333991989248

https://twitter.com/#!/petrkucera/statuses/129474672575250432

FAQ - často kladené dotazy ke kurzům

Tento rok se na jaře uskuteční pouze výše popsaný kurz. Dva další kurzy, Školení Základy objektově orientovaného návrhu a vývoje (UML 0) a Pokročilé návrhové vzory a objektové principy 2, proběhnou na podzim a můžete se na ně také  předběžně hlásit. Důvodem, proč tyto kurzy neproběhnou na jaře, je moje vytížení dalšími projekty.

Pro jistotu připomenu, že všechny kurzy lze také objednávat v “inhouse” variantě, kdy kurz proběhne ve vaší firmě v termínech, na kterých se spolu domluvíme, a za podmínek, které s vámi ráda dohodne Petra Steinová. V inhouse variantě je také samozřejmě možné zcela upravit program kurzu  a věnovat se jen “specialitkám” a “špekům”, které v aplikaci řešíte.

Budu se těšit na záludné dotazy na kurzu.

Pozvánka na mé kurzy na blogu trochu zapadla, a protože tento týden dvě firmy zvolily raději inhouse variantu kurzu, a tím se uvolnila místa na veřejných kurzech, i když předtím jsme museli na začátku srpna některé zájemce o veřejné kurzy OOP 0 a OOP 1 odmítat, dávám i pro další zájemce znovu odkaz na pozvánku.

Dnes na twitteru David Grudl odkázal na debatu, která se týká vlastností v PHP. O vlastnostech v PHP mluvit nechci, ale v tomto  příspěvku se chci dotknout některých “dogmat”, které se ozývají stále častěji a které byly použity jako univerzální kladivo na oponenty  i v odkazované diskuzi.

Jedno zvláštní dogma se týká principu jedné odpovědnosti třídy (Single responsibility principle). Tento princip říká, že třída by měla mít jednu přesně vymezenou odpovědnost, která je v souladu s jejím názvem. I když na první přečtění se tento princip zdá neproblematický, dá se zneužít jako univerzální kladivo. Dogmatici mi říkali, že jedna odpovědnost si vynucuje, aby třída vždy měla právě jednu metodu, která tuto odpovědnost realizuje. Není nad přehledný svět objektových dogmatiků, kde objekt je jen stupidní kontajner na jednu (de facto globální?) funkci.

Dogmatiky tohoto zvláštního ražení  zanedbejme jako ztracené případy a SRP obohaťme o další vysvětlení, které říká, že třída by měla mít jen jeden důvod ke změně. Tento princip je užitečný v tom, se snaží z aplikací odstranit všemocné božské (God) objekty, které mnohdy už svým názvem signalizují, že řeší spoustu věcí. UniversalOrderAndInvoiceProcessor oznamuje, že se bude měnit nejen, když se změní zpracování objednávek, ale také když se změní zpracování faktur. Jednoduché, což? Proč o tomhle jednoduchém principu vůbec dále mluvit?

V diskuzi se o SRP mluví (viz i příspěvky níže), ale diskutující tam ve  své argumentaci používají něco, čemu na kurzech u SRP říkám falešné alternativy.

Mějme stejně jako v diskusi svou třídu Image, která nese informace o obrázku. Obrázek chceme uložit.

Varianta 1, kdy obrázek nese informace a současně nabízí metodu Save, ve které uloží data do souboru.

Co je v diskuzi vyčítáno této třídě? Porušuje princip jedné odpovědnosti, protože podle některých (Jiří Knesl, Ondřej Mirteš)  řeší dvě věci najednou – nese data o obrázku a současně data ukládá. Souhlasím, že jde o porušení SRP, ale hlavním důvodem je to, že metoda Save je napsána tak,  že třídu Image ukládáme vždy do souboru. Co když budeme chtít třídu Image uložit do nějakého “response” streamu na webovém serveru, nebo uložit přímo do databáze? Tuto třídu skutečně budeme měnit ze dvou důvodů – jednou, když přidáme nebo odebereme informace o obrázku a také, když budeme chtít ukládat obrázek do databáze, musíme rozšířit stávající metodu Save, což povede k tomu, že metoda bude mít v sobě nějaký podivný switch a  bude trpět smíšenou odpovědností, protože bude dělat několik věcí najednou,  nebo můžeme přidat novou samostatnou metodu SaveToDb.

Jedinou (!?) alternativou v diskuzi k tomuto postupu je vyvedení odpovědnosti za ukládání do různých úložišť do samostatných objektů, které mohou být  skryty za jednotným rozhraním.

Toto řešení důsledně separuje odpovědnosti, navíc je velmi snadné přidat další implementaci rozhraní IImagePersistor, např. DbPersistor, který data uloží do databáze. Už v diskuzi Jakub Vrána ale upozorňuje na to, že se mu nelíbí, jak se řešení komplikuje pro uživatele-vývojáře, který s třídami bude pracovat, protože tento vývojář musí vědět, že existuje nějaký IImagePersistor/FilePersistor odpovědný za uložení dat. Třída Image nestačí k tomu, abyste dokázali vygenerovat data obrázku a uložit je, což může být ve vaší knihovně častý scénář. Také bych rád poprvé v tomto článku připomněl princip OOP, ke kterému se za chvíli vrátím, že objekt představuje jednotu svého stavu a chování, které je pro tento stav definováno.

Psal jsem o falešných alternativách, můžeme najít i jiná řešení. Co ponechat metodu Save ve třídě Image, ale z třídy Image udělat tzv kompozitor - objekt, který skládá své chování tak, že využívá další pomocné objekty, na kterých závisí, a nabízí intuitivní rozhraní pro klienty.

Odpovědnosti jsou stále separovány a dokonce třída Image, náš kompozitor, dodržuje pravidlo, které říká, že kompozitor by měl být jednodušší než suma funkcí jeho pomocných objektů.  Klient třídy Image nemusí pracovat přímo s třídou FilePersistor, a přitom nemáme kód pro ukládání do souboru přímo ve třídě Image. Problém je, že metoda Save třídy Image vždy vytváří FilePersistor. Klient třídy Image si nemůže vyžádat to námi dříve zmiňované ukládání obrázku do databáze, a navíc třída Image závisí na jedné konkrétní třídě FilePersistor, u níž přímo volá konstruktor. V třídě Image mixujeme vytváření grafu spolupracujících objektů se samotným použitím pomocných objektů. Opět jde o dvě odpovědnosti, které bychom měli oddělit – SRP, nezapomeňme.

Nejprve ale zkusme vyřešit problém s tím, že klient nemůže ukládat data do databáze, protože třída Image ukládá data vždy do souboru.

Jednoduše přidáme další variantu metody, která přijímá odkaz na IImagePersistor, v našem případě třeba na DbPersistor. Původní metoda Save bez argumentů řeší ukládání do souboru. Ukládání do souboru je nejčastější scénář, který je zvolen jako výchozí. Stále ale tady máme problém s tím, že v metodě Save konstruujeme "natvrdo" FilePersistor. A navíc naše API klientům trochu lže. V podtextu klientovi sděluje, že výchozí metoda Save nemá žádné další závislosti, i když z implementace, !a jen z implementace!,  je zřejmé, že jsme závislí na přítomnosti třídy FilePersistor. Poznámka: V C# 4 můžeme použít volitelné argumenty u jedné metody, ale na principu této varianty řešení se moc nemění.

Zkusme naše prozatím ulhané API vylepšit a dodržet SRP.  Oddělme nyní konstrukci pomocných objektů, na kterých závisíme, od jejich použití v metodě Save.

Objekt Image si nyní v konstruktoru vynucuje předání IIMagePersitoru. Když klient IImagePersistor nepředá, objekt nezvznikne – sám konstruktor garantuje, že buď objekt Image má vyplněny všechny závislosti, nebo vůbec nevznikne. Vytvořili jsme konstruktor, který může použít a automaticky naplnit DI kontajner, nebo různé abstraktní továrny registrované v DI kontajneru  apod. DI kontajner je přesně tím objektem, který by měl být v aplikaci odpovědný za konstrukci grafu objektů, v metodě Save objektu Image injektovaný IImagePersistor jen používáme. SRP v praxi.

Možný že ale v tomto případě je injektování závislostí přes konstruktor moc striktní. Co když nám skutečně vyhovuje, že můžeme bez DI kontajneru vytvořit objekt Image, který bude data ukládat do souboru. Pak můžeme využít injektování přes vlastnosti, kdy příslušnou vlastnost po vzniku objektu vyplníme rozumnou výchozí hodnotou – v našem případě instancí FilePersistoru. Poté ale platí, že třídu Image stále částečně zatěžujete konstrukcí objektů…
U většiny DI kontajnerů je preferováno injektování závislostí přes konstruktory, všechny, které znám,  si ale poradí ale i s injektováním závislostí přes vlastností a u MEFu bych řekl, že injektování závislostí pomocí vlastností hrají prim.

Všechny tyto varianty mají své výhody a nevýhody a asi nemusím zdůrazňovat, že ani jedna není univerzálním kladivem. Varianty s injektováním závislostí (konstruktor, metoda, vlastnost) jsou samozřejmě mnohem lépe testovatelné.

Dokážu přidat i další příklady, ale chtěl jsem,  abyste viděli, že SRP není ani nesmysl, ale ani princip, který by, podobně jako to zaznělo v diskuzi, sděloval – existují jen dvě alternativy, jak rozdělovat odpovědnosti, a ZROVNA TA TVOJE JE ŠPATNĚ.

A poslední  poznámka:

Jiřé Knesl také v diskuzi uvedl: “ objekt buďto data reprezentuje (pak má settery/gettery), nebo vykonává činnost (pak dostane data parametry)”. Tohle je podle mě  postoj blízký hlavně některým Javistům, o čemž svědčí i podle mého soudu schematický a nevěrohodný článek, který se zabývá vlastnostmi v Javě a na který se J. Knesl odkazuje. Znovu připomínám, že objekt představuje jednotu svého stavu a chování, které je pro tento stav definováno.  Objekt, který má jen gettery a settery, je ”krabičkou na data”, pouhou strukturou známou i z neobjektových jazyků, a když má objekt jen metody, tak jde o (v mnoha případech skutečně globální) funkce/procedury, které prefixujeme názvem proměnné/třídy. V diskuzi to myslím nezaznělo, ale když někdo razí tuto drastickou separaci chování od samotných dat, často dodává, že takto je to přece definováno Evansem, tedy autoritou,  v kanonické knize o Domain Driven Designu. Když se ptám, kde o tom Evans mluví, dozvím se, že Evans má objekty, které mají svůj stav (vlastnosti)  a s objekty pracují speciální business-doménové služby (chování). I když mám vůči DDD spoustu výhrad, zde Evanse špatně interpretují – Evans by model, kde objekty mají jen stav a nemají žádné chování, nazval anemickým modelem – izolovaná data podepřená berličkami nesouvisejících globálních funkcí. Business služby jsou, zjednodušeně řečeno, určeny pro zapsání složitější business logiky, na které spolupracuje více objektů a žádný participující objekt není sám o sobě přirozeným kandidátem, do kterého by bylo vhodné logiku situovat.

Zde bych mohl pokračovat dále k rozdělení objektů v DDD, ke skutečnému významu vlastností u objektu, co říká princip “tell, don't ask”, ale už teď mi původně krátký komentář k SRP a DDD až moc nabobtnal. Když budete mít zájem o další naznačená témata, napište prosím komentář k článku.

Dostal jsme dotaz, jak si poradit s odstraňováním chyb u starší a rozsáhlé aplikace. Když jsem odepisoval, uvědomil jsem si, že sepisuju jakési “triviální  desatero vývoje”", které se snažím už dlouhou dobu svému okolí vtloukat dohlavy. I když jde o triviální zásady, budu příště odkazovat raději na tento příspěvek, než abych vše opakoval pokaždé znovu. Jméno firmy je v textu nahrazenou souslovím “anonymní firma”.

“Zdravím,
to je na hodně dlouhý příspěvek.
Alespoň tedy:

1) Je nutné zrušit umělou hranici mezi vývojáři a testery. Žádná výměna informací přes šéfy oddělení nebo pověřené osoby.

2) Na každou objevenou chybu musí být napsán automatický test, který zajistí, že chyba neprobublá do dalších releasů. Bez toho žádné organizační opatření nefunguje. Bez napsaného testu se chyba nepovažuje za odstraněnou, ale jen za náhodou se nyní neprojevující.

3) Vytvořit malé sebeorganizující týmy odpovědné za určitou část projektu (nastálo, nebo do dalšího releasu). V čele team leader, který garantuje kvalitu. Team leader je k dispozici i testerům a řeší nesrovnalosti v analýze a systémovém designu. S dalšími team leadery řeší problémy integrace různých částí projektu. Team leader ale stále většinu času kóduje, není to embryo vychovávané pro střední management.

4) Je potřeba postupně napsat velké množství automatických testů (unit, integrační, akceptační) tak, aby se testeři věnovali hlavně novým záležitostem v releasu a aby vývojáři ani testeři nebyli obětí "ručně prováděných" regresních testů, které mají formu nikdy nekončícího debugování. Tím se i zkrátí doba, kterou "anonymní firma" nutně musí trávit opakovaným debugováním a "ručním" nalézáním příčin chyb. Automatizované testy představují práci, která se na projektech vyplatí, a navíc jde i o mnohem levnější řešení problému, než nabírání dalších a dalších testerů.

5) Nedávat žádné fixní odhady na odstranění chyb ani nikoho exkluzivně nealokovat jen na odstraňování chyb. Vývojář není a přes různé manažerské poučky ani nebude anonymní zdroj, který sebereme z jiného projektu, posadíme k aplikaci, kterou nezná, ale u které dostane befelem, že za jednu normohodinu musí odstranit 20 bugů. Tato kouzla fungují jenom v Excelu. V reálném světě vývojář těch 20 bugů neodstraní, ani když ho posadíte do open space, který  je oblepen motivačním majstrštykem vytisknutým z PowerPointu nejlepším absolventem MBA.

Pokud se objeví chyba, chopí se jí člověk, který za danou oblast odpovídá (konflikty přinejhorším vyřeší team leadeři). Vývojář neustále čte a refaktorizuje kód, pokud možno ihned také odstraňuje chyby . A jsme opět u testů - dokud ty automatizované testy mít nebudete, vývojáři do kódu raději nezasahují, protože nevědí, kde všude se změna projeví a raději neriskují další možnou příčinu pádu aplikace po nasazení u zákazníka. A psát použitelné, ne jen formální-švejkovské testy, kdy se hodnotí "jen code coverage", se musí všichni vývojáři naučit a nějakou dobu to zabere.

Mám zkušenost s 12 let starou aplikací psanou původně pro VB, poté čátečně přepsanou na .Net Framework,  která byla po 9 letech postupně obalena testy, a ani dnes sice nejde o žádnou vývojářskou lahůdku, ale pracuje se na ní beze strachu, co při každé změně v aplikaci zničíme. Nic jiného než to, co píšu výše, se mi neosvědčilo.

A pak další záležitosti jako (nutné) bonbonky:

• Neztrácet čas “mergováním” změn v něčem tak zastaralém a nepohodlném jako je Subversion. V Mercurialu (GITu) je propagace změn z vývojové větve do hlavní (a zpět) otázka chvíle. V Subversion ani TFS jsem po pár zkušenostech raději moc "branchů" nedělal.
  
• Automatické buildy spojené s již napsanými testy.
  
• Automatické nasazení nové verze aplikace, aby testeři nemuseli pátrat, kde seženou novou verzi a také, aby nasazení do produkčního prostředí neznamenalo 3denní práci party lidí, kteří se metodou pokus-omyl snaží dostat aplikaci do použitelného stavu u zákazníka.
  
• Alespoň u nováčků code review, abyste rychle odstranili jejich špatné návyky.
  
• Statická analýza kódu.

A dovolím si jednu soukromou poznámku k "anonymní firmě" - pokud možno zredukovat/vyhodit všechny těžkotonážní, neskutečně drahé a pro vývojáře zabijácké nápady se zavedením nejhorší možné formy vodopádu  - analýza->samostatný systémový design->vývoj->testy, v jehož bludném pádu se bude produkovat množství dokumentů, navíc rychlokvašenými analytiky/designery, v mizerné kvalitě a bez vazby na skutečné potřeby projektu. Analýza a systémový design jsou fáze projektu, které pomáhají jen do doby, než se jich chytí nějaký exot, který nikdy žádnou aplikaci nevyvíjel a který si myslí, že analytická práce spočívá ve štosování nahodilých myšlenek zákazníka do příslušné šablony pro use case. Což je dle mých zkušeností většina “čistých”, míněno vývojem nedotčených, analytiků na pracovním trhu.

Opět vás všechny zvu na pravidelný podzimní běh kurzů Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2.

Novinkou v tomto roce je kurz pro začátečníky nazvaný Základy objektově orientovaného návrhu a vývoje. Někteří z vás ho mohli během posledních dvou let absolvovat ve formě inhouse kurzu pod interním názvem UML 0.  Kurz UML 0 vznikl velmi spontánně jako reakce na požadavky některých firem, které nechtěly rovnou absolvovat stávající kurzy. Nyní je vycizelované UML 0 dostupné i jako veřejný kurz, protože v emailech se opakovaly žádosti o jeho veřejnou formu od lidí, kteří kurz absolvovali a nyní na něj chtěli poslat své kolegy.

O tomto novém kurzu naleznete podrobné informace níže v této pozvánce. Znovu opakuji, že se jedná o kurz pro začátečníky, který dříve v nabídce nebyl, protože kurzy Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2 byly a stále jsou určeny pro lidi, kteří základy znají. Nenechte se ale zmást “kódovým” názvem nového kurzu (UML 0), účastníci bývají překvapeni, že s UML na kurzu zacházíme zcela pragmaticky a bez  posvátné úcty, ale i bez módních předsudků a rychlých odsudků. UML bereme jako nástroj, a ne jako samoúčelný cíl našeho snažení na kurzu.

Veřejný kurz Základy objektově orientovaného návrhu a vývoje (UML 0) 

Datum konání kurzu: 19. 9. – 21. 9. 2011

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

FAQ  - často kladené dotazy ke kurzům

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1

Datum konání kurzu:  10. 10. – 12. 10. 2011

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

Výběr z ohlasů na kurz

FAQ - často kladené dotazy ke kurzům

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 2

Datum konání kurzu:  24. 10. – 26. 10. 2011

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

Výběr z ohlasů na kurzy

FAQ - často kladené dotazy ke kurzům

Program nového kurzu Základy objektově orientovaného návrhu a vývoje (UML 0)

Předpokládané znalosti účastníků

1. Základní přehled o etapách vývoje projektu.
   
2. Vhodné je mít nějaké vlastní zkušenosti z analýzy a vývoje projektů, abychom mohli porovnat různé postupy a doporučení a jejich použitelnost v praxi.
   
3. Chuť se učit.;) Schopnost pohlédnout na některá domněle známá témata bez předsudků.
   
4. Částečná znalost UML je vhodná, ale u tohoto kurzu není vyžadována. Vhodná je hlavně pro konfrontaci vlastních zkušeností s tím, co zazní o použitelnosti různých částí UML na kurzu.
   
5. Nenávist ke kariéře zručného "bušiče", nikým nerespektovaného projektového vedoucího (tzv. sekretářky 2.0) a neschopného analytika / vývojáře.
   

Obecné informace ke kurzu

Pro vývojáře se u konstrukcí a prvků jazyka UML, které jsou považovány za analytické, dělají časté odbočky do kódu, aby vývojáři pochopili, že UML ani principy OOP nejsou nějaké nesmyslné abstrakce, ale užitečné konstrukce, které sami v programovacích jazycích používají denně. U role analytika stále zdůrazňuji, jaké znalosti z oblasti vývoje aplikací musí analytik mít, aby byl pro projekt užitečný a nevytvářel jen dokumentaci pro dokumentaci, kterou vývojáři nevyužijí a (až příliš často oprávněně) ji považují  za nesmyslnou, drahou a hlavně  vyvíjenému projektu nic nepřinášející. Kurz je určen pro vývojáře, systémové designery, analytiky a projektové manažery, kteří se chtějí seznámit se základními principy objektového programování a s modelováním v jazyce UML.

Program školení

• Proč má dnes UML v některých kruzích špatnou pověst? Musíte být těžkotonážní rytíři cválající na drahých CASE nástrojích a neživotných formálních projektových metodikách, nebo si vystačíte s nástroji a postupy, které zachytí vaše myšlenky, ale nenutí vás přizpůsobovat se "Jen Tomu Jedinému Pravému Stylu Návrhu A Vývoje"?
  
  
• Dostali jste poptávku, máte za pár dní dodat nabídku a v seznamu svých dovedností nenalézáte jasnovidectví ani nemáte po ruce čarovnou skleněnou kouli, abyste zákazníkovi do nabídky vyvěštili konečnou cenu i datum dokončení projektu? Co dělat v počáteční fázi projektu, kdy ještě ani nevíte, jestli budete projekt vyvíjet?
  
  
• Požadavky na systém. Jak je to s případy užití? Má vlastní zrychlená funkční specifikace bez zbytečných formalit.
  
  
• Rozsáhlé ukázky fukčních specifikací z projektů.
  
  
• Diagram tříd v UML.
  
  
• Rozdíl mezi analytickým diagramem tříd a diagramem tříd vytvářeným ve fázi systémového designu - existuje takový rozdíl, nebo jde jen o další hloupý mýtus?
  
  
• Třída - základní principy OOP, operace, atributy, viditelnost členů třídy.
  
  
• Vztahy mezi elementy diagramu (asociace, agregace, generalizace, závislost, realizace) – vše vykládáno na konkrétních příkladech z praxe + ukázky nejčastějších chyb, se kterými jsem se setkal.
  
  
• Dobře zapamatovatelné principy návrhu známé pod zkratkou SOLID v příkladech. Unit testy, integrační testy, akceptační testy - skutečně si stále myslíte, že se bez nich na projektech obejdete?
  
  
• Nejen SOLIDní principy stojí v pozadí návrhu aplikací...
  
  
• Nenásilný přechod k jednoduchým návrhovým vzorům.
  
  
• Příklady složitých diagramů tříd. Jak je udržovat v souladu s napsaným kódem? A musíme je udržovat? Co se na projektech vyplatí dělat a co projekt spolehlivě zabije?
  
  
• Objektový diagram + příklady.
  
  
• Diagramy a diagramy interakce. Příklady. Typy projektů, pro které se tyto diagramy hodí.
  
  
• Vysvětlení stavových diagramů + výhody aplikací řízených přesně definovanými stavovými automaty.
  
  
• Diagram aktivit - modelování složitých business procesů v organizaci. Hrajete si s diagramem aktivit rádi, ale ocení to Váš zákazník?
  
  
• Vrstvy a moduly v aplikaci – architektura aplikace.
  
  
• Relační a objektový svět? Stále jediné možné partnerství z rozumu?
  
  
• Nasazení aplikace – výklad Component & Deployment diagramů.
  
  
• OOP a jeho vztah UML. Vztah UML a OOP k projektové praxi a realitě.
  
  
• Výhody a nevýhody UML – vyzdvižení nejvíce používaných postupů, odhození nepotřebné veteše z jazyka UML.
  
  
• Odpovědi na dotazy frekventantů kurzu.

Těším se s Vámi na setkání na kurzu!

René Stein

Opět bych Vás všechny rád  pozval na pravidelný podzimní běh kurzů Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2. Níže také naleznete odpovědi na pravidelně se opakující dotazy v emailech.

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1

Datum konání kurzu:  22. 11. – 24. 11. 2010

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu
Výběr z ohlasů na kurz

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 2

Datum konání kurzu:  29. 11. – 1. 12. 2010

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu
Výběr z ohlasů na kurzy

Zde jsou některé nové ohlasy na kurzy. Raději podotýkám, že tato hodnocení jsou mi zaslána účastníky z vlastní vůle a já určitě účastníky nenutím, aby mi psali nějaká hodnocení, natož lichotivá,  hned na kurzu ani po něm, jak se prý děje u konkurence.

pan Martin Pospíšil, společnost Team Trackers s. r. o.

Děkuji za materiály a za výborné školení. Líbilo se mi ještě víc než jednička, díky těm praktickým příkladům, které jsme řešili společně.

Ing. Rudolf Plíva, společnost NOWIRE

Děkuji za velmi zajímavé a přínosné školení!

pan Jiří Filous, společnost Česká pojišťovna a. s.

Ano, mám zájem o zasílání informací o nových kurzech a děkuji za skvělé (i když náročné) školení.

Odpovědi na některé dotazy, které jsme obdrželi od dříve přihlášených zákazníků emailem.

Otázka: Na kurz půjdu, ale raději počkám s přihláškou na týden před školením, protože stejně jako konkurence mi dáte “last minute” slevu ne?

Odpověď: Hry s nějakou uměle nadsazenou cenou, která je potom těsně před kurzem snižována a nabízena v rámci “Last minute” nabídky, nehrajeme. Přijde mi nespravedlivé a nesmyslné, aby každý účastník platil jinou částku v závislosti na dni přihlášení. Všichni dosavadní účastníci mohou potvrdit, že zaplatili cenu, která je uvedena u školení a je jedno, zda se přihlásili 3 měsíce nebo 3 dny před kurzem.

Otázka: Na kurzu bychom rádi diskutovali záležitosti, které se týkají našeho projektu, je to možné? Je možné s vámi probrat podrobně i vývojářské specialitky, které se týkají C#, C++,Windows Forms, Silverlightu, Windows Mobile….

Odpověď: Na veřejném kurzu můžeme diskutovat o věcech, které zajímají všechny účastníky.  Specifické dotazy, které se týkají vašich projektů, je nejlepší probrat se mnou po 16. hodině, kdy skončí oficiální část kurzu, ale já jsem vám samozřejmě k dispozici od 16:00 do umdlení mého či vašeho. Jestliže chcete 3 dny věnovat jen svému projektu, zvažte inhouse variantu kurzu, kde si můžete témata definovat sami. Pro podrobné informace o podmínkách inhouse kurzů napište prosím Petře Steinové (petra@renestein.net), která Vám velmi ráda obratem pošle nabídku.

Těším se s Vámi na setkání na kurzu!

René Stein

Update: Kurz je zcela obsazen včetně náhradníků.

Rád bych Vás pozval na další běh kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1. Pokud se někdo z Vás (oprávněně) diví, proč tak pozdě a proč Vás nezvu i na kurz OOP 2, níže v tomto spotu nalezne odpovědi.

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1

Datum konání kurzu:  14. 6. – 16. 6. 2010

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu
Výběr z ohlasů na kurz

Odpovědi na některé dotazy, které jsme obdrželi od dříve přihlášených zákazníků emailem.

Otázka: Proč se kurz nekoná na předchozím místě (v hotelu Villa), kde byli naši kolegové?

Odpověď: Po vyhodnocení ohlasů na kurz jsme zjistili, že účastníci nebyli  (stejně jako já ) příliš spokojeni s jídlem. Také jsme při domlouvání hotelu byli ujišťováni, kolik účastníků se může na kurz přihlásit  a jak lze pro ně uspořádat pohodlně prostory, a tyto informace se v průběhu kurzu jevily jako marketingové fráze až blafy velmi optimistickými nebo nepočítaly s průměrným Evropanem, ale standardním liliputem. Stručně řečeno – poměr cena/výkon nebyl u čtyřhvězdičkového hotelu příliš dobrý. Jedinou výhodou hotelu Villa bylo parkování, nyní bude lepší na ”poslední míli” použít  MHD.

Otázka: Proč se koná kurz tak pozdě (oproti přechozím rokům) a proč se nekoná kurz OOP2.

Odpověď: Byl a jsem vytížen tento rok dalšími projekty a nalézt vhodné termíny bylo problematické.  Také jsme sháněli nové prostory, kde se bude kurz konat (viz předchozí odpověď). Termín kurzu OOP2 vycházel již na červenec a v době dovolených nemá smysl kurz pořádat. Při větším zájmu vyhlásím (co nejdříve) více termínů kurzu OOP2 na podzim.

Těším se na setkání na kurzu!

Emailem jsem dostal zajímavou otázku, jaký je můj názor na softwarové továrny a kde vidím výhody a nevýhody softwarových továren. Odpověď nakonec publikuji i zde – už jen proto, že jsem si při jejím psaní uvědomil, že na továrnu kladu stejné nároky jako na kteroukoli další knihovnu v systému a že výběr softwarové továrny se u mě moc neliší od výběru třeba ORM Frameworku. Nejde o taxativní výčet výhod a nevýhod, ale spíš o volně nahozená témata, která mě za 20 minut psaní příspěvku napadla.

SW továrny jsou jen pokračováním trendu, že nemá smysl vynalézat znovu kolo ani v případě, že by bylo o dvě setiny procenta krásnější než to staré, které je již navržené a hotové. SW továrna říká – namísto opakování chyb svých předchůdců použijte ověřené zkušenosti, osvědčené praktiky, doporučené postupy a již otestovaný kód. Namísto obecného návrhového vzoru nebo vágně popsaného doporučovaného postupu máte k dispozici osvědčenou knihovnu, základní průvodce a odborný polštář, který by měl zabránit, že napácháte v dané oblasti velké množství hrubých bezpečnostních nebo jen s duchem technologie neslučitelných chyb.

Takže výhody:

1) Osvědčená řešení ihned po ruce. Tím se cíl SW faktory moc neliší od obecných frameworků a návrhových vzorů.

2) Není nutné psát infrastrukturní kód přímo v SW firmě (ISV). Je možné se soustředit na problémovou doménu zákazníka a ne na to, jak centrálně publikovat události nebo jak propojit různé pohledy v aplikaci tak, aby spolu dokázaly komunikovat .

3) Pokud stejnou továrnu používáte napříč všemi projekty, je zaučení nového vývojáře na dalším projektu jednodušší a rychlejší.

4) SW továrna používá praktiky osvědčené v dané technologii. Takže odlišně jsou zakódovány původně platformně nezávislá doporučení a všeobecně zaměřené vzory v SW továrně pro ASP.Net a jinak pro Silverlight. Místo popisu obecných návrhových vzorů je již vzor adaptován na konkrétní cílové prostředí.

Nevýhody:

1) Kód nemáte pod kontrolou a musíte se spolehnout, že továrna sama neobsahuje příliš kritických chyb ani otravných chyb s nižší prioritou. To platí o jakékoli abstrakci (frameworku, knihovně), kterou na projektu používáte, ale myslím, že ani v Microsoftu stále nemají SW továrny stejnou podporu jako samotný .Net Framework. A také by měla být známa alespoň orientační roadmapa SW továrny, abyste věděli, kam autoři směřují a jestli jsou si vědomi nevýhod a omezení stávající verze SW továrny. Od továrny, která se ihned po svém uvedení honosí přídomky „experimentální, testovací, zkušební“, bych dal ruce pryč. Jen ti nejodvážnější z nás si dovolí svým zákazníkům za půl roku po zatracení SW továrny jako slepé uličky tvrdit, že musí trochu poštelovat kardiostimulátor výkonného srdce aplikace a že místo plánovaných dvou hodin za přidání dvou vlastností do objednávky zákazník zaplatí dva měsíce migrace na jinou SW továrnu. Nenechal bych se zmýlit tím, že některé firmy pro odvážlivce používající jejich experimentální SW továrny a frameworky razí lichotivý titul „early adopter“ – méně korektní a pravdě bližší překlad z marketingového slovníku totiž zní „natěšený všehoschopný blbec“.

2) Univerzální řešení jako je SW továrna může být pro jednoduché aplikace zabijákem. Více času strávíte integrací aplikace do rámce vynucovaného SW továrnou než psaním obchodní logiky specifické pro aplikaci a důležité pro zákazníka.

3) U některých složitějších aplikací zjistíte, že rámec SW továrny je příliš těsný a vy potřebujete SW továrnu pro svůj projekt upravit nebo rozšířit. Náklady na rozšíření služeb , „hackování“ a ohýbaní SW továrny pro danou problematiku mohou převážit nad výhodami SW továrny. Z velké radosti nad úsporou času v raných fázích projektu, kde byla továrna použita, můžete ještě před dodáním první verze projektu a po pořádném časovém skluzu, vynuceném třeba přepisem částí továrny, které pro výkonnostních testech  nestačí stávajícím požadavkům na projekt, přejít k jadrným kletbám nad šílenou SW továrnou, v níž si úprava jednoho modulu kaskádově vynutí úpravy všech dalších modulů. Místo používání původně slibované elegantní černé skříňky s jednoduchými službami se prohrabujete nevábnými vyhřezlými vnitřnostmi mizerně navržené SW továrny.

Z výhod a nevýhod snad vyplývá můj postoj k SW továrnám. SW továrny jsou dalším evolučním stádiem na cestě, jejímž cílem je využít pro danou problematiku osvědčená řešení a postupy, nepsat stále se opakující kód nebo v každém řešení už jen změnou typu klienta (Web, Windows Forms, Silverlight, mobilní aplikace) neprocházet znovu a znovu všechny slepé vývojářské uličky specifické pro použitou technologii. Objevování objeveného ponechme těm, kterým stačí zařvat vítězoslavně heuréka, i když jsou v pořadí stí nebo tisící, kteří stejnou infrastrukturní nebo funkční trivialitu konečně zakódovali rozumným a v životním cyklu projektu dále udržovatelným způsobem.

A samozřejmě si nemyslím, že tohle evoluční stádium je konečné. :)

Rád bych Vás pozval na další běh kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a hlavně Vás chci seznámit se zcela novým kurzem Pokročilé návrhové vzory a objektové principy 2.

Kurz Pokročilé návrhové vzory a objektové principy 2 je volným pokračováním kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1. Pojetím kurzu Pokročilé návrhové vzory a objektové principy 2 jsem se snažil vyhovět účastníkům předchozího kurzu, kteří mi, volně parafrázováno, říkali: "Nejlepší jsou ty části, kde probíráme jeden příklad za druhým a kde říkáte  - takto to dělám já." Můj zákazník, můj pán (zvláště, jestliže se v záměrech zcela shodneme ) - nový kurz je prošpikován příklady, tipy, kódem, vzorovými aplikacemi. Budu se těšit na oponeturu mých postupů.

Datum konání kurzu:  9. 3. - 11. 3. 2009

Místo konání: Hotel VILLA Praha  Okrajní 1, 100 00, Praha 10

U hotelu VILLA je  možné parkovat, po celý den máme k dispozici wifi připojení.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Výběr z ohlasů na předchozí kurz

Předpoklady pro absolvování kurzu:

1. Znalost alespoň jednoho z rodiny "C" jazyků (C#, Java) - příklady na školení jsou v jazyce C#.
2. Částečná znalost UML = neutečete zděšeni z kurzu, když zobrazím diagram tříd.
3. Nenávist ke kariéře zručného klikače a zaškrtávače ve vizuálních návrhářích a "wizardech", co s velkou vášní vytváří jedno strhující uživatelské rozhraní pro číselníky za druhým.
4. Vhodné, nikoliv však nutné, je i absolvovat nejdříve školení Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1.

Program kurzu

• Layer Supertype pro další vrstvy aplikace – vrstva pro řízení procesů a business transakcí.
• Deklarativní změny v logice procesů v nasazené aplikaci prováděné samotným uživatelem.
• Evidence historie objektů - různé přístupy.
• Vlastní správce historie pro .Net Framework a Javu.
• Řešení konkurenčního přístupu k datům.
• Optimistická konkurence - různé implementace.
• Pesimistická konkurence - různé implementace.
• Pesimistická konkurence - různé implementace.
• Konkurence napříč objektovými modelem - "Coarse grained lock" - různé implementace.
• Thread Specific Storage – vlastní řešení.
• Modelovani uživatelem zadávaných výběrových podminek (např. uživatelem definované sestavy nad objednávkami) – můj „Conditions“ vzor.
• Návrh a implementace netriviálního právového frameworku.
• Různé způsoby vyhodnocování práv - změna logiky za běhu aplikace.
• Kde všude se nám hodí myšlenky návrhového vzor Accounting - modelování business aplikací jako množiny souvisejících transakcí.
• Návrhové vzory Query a Repository a jejich vazba na „Conditions“ vzor.
• Různé přístupy k vytváření uživatelského rozhraní - Model-View-Controller, Model-View-Presenter, Passive View - můj vlastní Form Controller.
• Aplikace založené na pluginech – vzorové přístupy a doporučení.
• Správa "cizích" pluginů/služeb ve vlastních aplikacích.
• Vzor Component Configurator - správa pluginů.
• Vzor Interceptor - ukázky business aplikací, které jsou rozšiřovány za běhu aplikace s minimálním úsilím a bez strastí opakovaného nasazení aplikace.
• Kdy použít vzor Special Case?
• Remote Facade a Data Transfer Object - různé přístupy k distribuované aplikaci.
• Vzory pro zpracování požadavků na aplikaci-službu.
• Kódování vzoru Acceptor-Connector.
• Asynchronous Completion Token - vlastní pomocné objekty pro zjednodušení asynchronních úloh.
• Kódování vzoru Proactor.
• Kódování vzoru Reactor.
• Thread Safe Interface - co pro nás znamená v moderních prostředích (Java a .Net Framework)
• Co jsou takzvané “Enterprise segmenty” v business aplikacích?
• V průběhu celého kurzu - kompletní případová studie existující business aplikace, v níž jsou zakódovány postupy zmiňované na kurzu - dlouhá procházka kódem. :)

Kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1

Datum konání kurzu:  20. 4. - 22. 4. 2009

Místo konání: Hotel VILLA Praha  Okrajní 1, 100 00, Praha 10

U hotelu VILLA je  možné parkovat, po celý den máme k dispozici wifi připojení.

Pro jistotu dodám, že na kurzu jsou samozřejmě po celý den teplé a studené nápoje a v ceně kurzu jsou obědy v hotelu.

Organizační informace ke kurzu

Program kurzu

Výběr z ohlasů na kurz

Pro CZJUG jsem přednášel o "netradičních" vzorech - myšleno méně známých  vzorech a možná málo známých aspektech provařených vzorů. Tímto ještě jednou děkuji Dagimu a lidem ze SUNu za pozvání  na příjemnou akci i za jejich tolerantní přístup k mému, s nadsázkou,  mluvení o provaze (=C#, Visual Studio) v domě oběšencově (respektive z pohledu konkurence určitě vhodného kandidáta na business oběšence).

Prezentaci si můžete stáhnout v ppt formátu nebo v pdf přímo na stránkách CZJUG.

Dovolte mi, abych Vás všechny pozval na podzimní termín kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací.  Po vyhodnocení některých připomínek jsme se rozhodli změnit místo, kde se školení uskuteční.

Hotel VILLA Praha
Okrajní 1
100 00 Praha 10

Změna místa přinese účastníkům hlavně možnost zaparkovat auto přímo u hotelu a také to, že oběd (v ceně školení) dostaneme přímo v hotelu (oběd může prý obsluha donést až do učebny) a nebudeme tak nuceni trávit dlouhý čas čekáním na nějakého unuděného a pomalého pingla v poloprázdné pizzerii nebo podobném podniku s mizernou kuchyní.

Termín:

20. 10. - 22. 10. 2008

Organizační informace ke kurzu

Program kurzu

Zaregistrované ohlasy na školení :

http://blog.renestein.net/ct.ashx?id=10d7acf8-1026-43fe-b1f1-54fccb69105b&url=http%3a%2f%2fwww.jirifabian.net%2fwordpress%2f%3fp%3d157

http://blog.renestein.net/ct.ashx?id=10d7acf8-1026-43fe-b1f1-54fccb69105b&url=http%3a%2f%2fwww.rarous.net%2fclanek%2f143-skoleni-oop-uml-a-navrhovych-vzoru.aspx

Update: Nový ohlas

"Rene Stein pořádá opět svůj kurz o OOP - více na jeho blogu. Měl jsem možnost účastnit se školení od pana Kravala i školení pana Steina a doporučil bych spíše ten posledně jmenovaný. Je tak nějak více o praxi a z praxe. Oproti tomu kurz pana Kravala je spíše teoretický, Ale každému může vyhovovat něco jiného." Zdroj  - Martin's world

Nadpis vyjadřuje v kostce vše. Hraji si právě teď s překladem a nastavením YetAnotherForum a napadlo mě, že bych na doméně forum.renestein.net spustil fórum, kde bychom společně diskutovali o návrhu aplikací, systémovém designu, OOP, UML, Model Driven Architecture, DSL, zuřivě bychom se hádali nad best practices, vášnivě "flamovali" nad podporou OOP v různých programovacích jazycích :) nebo bychom si vyměňovali linky na zajímavé články. Pro každé větší téma by existovalo samostatné fórum.

Vím. že některá česká fóra se OOP a analýzou zabývají, ale kvůli svému neodvolatelně  finálním stavu  "mrtvé" fórum s občasnými "self" přechody, spuštěnými přijetím jedné OT zprávy s nabídkou domácích zásob viagry nějakého momentálně insolventního a celoživotně impotentního spammera, se v nich nic zajímavého neděje.

Takže - máte zájem? :) 

Update 1.9. 2006  - Kurz je obsazen

Kvůli velkému zájmu o zářijový termín kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací se bude stejný kurz konat také v termínu 25-27.10. 2006. Přihlásit se je opět možné zasláním emailu na adresu petra@renestein.net

Přejít na podrobné informace o kurzu včetně přihlášky na kurz

Protože kolegové v diskuzi pod původním spotem podrobně rozebrali všechny aspekty vztahu Include a Extend v případech užití,  je tento můj spot z větší části sumarizující. V čem tedy byl "chyták"? Cílem hádanky bylo upozornit na to, že vztahy Include a Extend nemusejí být tak jednoduše rozpoznatelné, jak se dočtete v různých rychlopříručkách,  a také jsem chtěl, abyste si všimli, že vztah Extend bylo bylo příjemné zpřesnit tím, co sám pro sebe nazývám "anonymní datové sloty".

Tak toto byl začátek dvoustránkového spotu, který se mi podařilo omylem smazat. :-( Protože už se mi nechce teď psát celý spot znovu, tak jen v krátkosti zrekapituluji, čeho se hádanka týkala.

Specifikace UML popisuje vztahy Include a Extend takto:

"Include is a directed relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case."

"This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use case under specific conditions. Note that the same extending use case can extend more than one use case. Furthermore, an extending use case may itself be extended."

V hádance nemohl být vztah mezi případem užití 'Založení objednávky' a 'Platba kartou' Include ani Extend. Include nelze použít, protože máme i jiné typy plateb, a případ užití Platbu kartou tedy nelze vložit povinně (dalším typem platby bude třeba dobírka - žádné záludnosti ohledně plateb jsem přichystány neměl, jen jsem chtěl, abyste se jako správní analytici pídili po podrobném zadání ). Nejedná se ale ani o vztah Extend, protože rozšířený případ užití nijak nezávisí na rozšiřujícím případu užití a nemůže číst žádné jeho "návratové hodnoty"  - pro nás to znamená, že nezjistíme, jestli platba prošla.

Řešením je vytvoření nového abstraktního případu užití nazvaného třeba 'Kontrola platby', který přes vazbu Include provážeme s případem užití 'Založení objednávky' . Konkrétními potomky budou "Kontrola platby kartou", "Kontrola ostatních typů plateb". Vazba Include nám dovoluje číst návratovou hodnotu vloženého případu užití. V alternativním toku událostí případu užití  'Založení objednávky' podle vybraného typu platby vložíme konkrétní případ užití a dle výsledku vkládaného případu užití dokončíme hlavní tok událostí. Když neprojde platba kartou, můžeme zákazníkovi nabídnout výběr jiného typu platby.

Hlavně ale platí - celá hádanka i její řešení je jen hříčka bez užitku pro zákazníka, která demostruje, jak lze i méně časté vztahy řešit běžnými výrazovými prostředky jazyka UML. Stále platí, že vazby Include, Extend ani gen-spec zákazníkovi raději moc neukazujte, jestliže  nechcete zbytečně trávit čas vysvětlováním vztahů, které jsou pro projekt málo podstatné a pro zákazníka samotného většinou jen iritující.

Po základní analýze jste zjistili, jak zákazníci vašeho klienta vytvářejí objednávky:

"Zákazník v našem obchodě vybírá zboží a poté si může vybrat, jak jej uhradí. Jedním z možných typů platby je platba kartou. K založení objednávky dojde pouze tehdy, pokud zadané údaje o platební kartě jsou platné, zákazník má dostatečnou hotovost na účtu a platba tedy projde."

Řekněme, že z těchto údajů vytvoříme (kromě dalších, zde nezmiňovaných) dva případy užití:

1. UC001 - Založení objednávky zákazníkem
2. UC002 - Platba kartou

Jaký vztah je podle UML mezi těmito případy užití ? Odpověď není tak jednoduchá, jak se může na první (a dokonce i druhý a ležérní třetí) pohled zdát...

Na svých přednáškách při vysvětlování asociace a kompozice mám slide, na kterém jsou zmíněny základní rozdíly mezi oběma typy vztahů v UML. Ihned k tomu ale dodávám, že zmíněné rozdíly jsou akademické a že v praxi si vystačíme většinou s jedním typem vztahu (s agregací), u kterého při kódování intuitivně víme, zda složený (kompozitní) objekt rozhoduje, a pokud ano, tak v jaké míře, o životním cyklu svých konstituentů (objektů, z nichž je složen).

Informace o rozdílu mezi agregací a kompozicí vycházejí z UML specifikace, kde se říká:

"[Agregace je] speciální forma asociace, která specifikuje vztah mezi agregujícím(celkem) a jeho konstituentem (částí)."

"Kompozitní agregace je silnější forma agregace, která vyžaduje, že jakákoli instance konstituenta (části) bude součástí nejvýše jednoho kompozitního objektu. Jestliže je kompozitní objekt smazán, jsou většinou všechny jeho části vymazány s ním".

Čte někdo vůbec UML specifikaci namísto čtení takzvaně přístupných  a "lidsky psaných" knih, které dogmaticky vyžadují rozlišování mezi kompozici a agregací? Jak si můžete všimnout, v definicích agregace i kompozice je zřetelně vidět pozvolný přechod mezi asociací, agregací a kompozicí a ne žádné ostré hranice, jak se nám mnohdy snaží vsugerovat sekundární literatura k UML nebo žabomyší akademické války o přesný význam termínů. Převedu-li definice a jejich důsledky do normální řeči - agregace ani kompozice není z hlediska UML nic jiného než asociace. Protože se ale asociace s rysy kompozice a agregace vyskytují často,  zavedeme pro ně speciální jazykový konstrukty. Tyto jazykové konstrukty jsou implicitními nositeli omezení, jež jsou na agregaci a kompozici kladeny. Spory o to, co je v diagramu ještě agregace a co už musí být kompozice jsou směšné a nikam nevedoucí  - je to jen zvlášní druh moderního pseudovědeckého sektářství, kde se na hranici místo kacířů zástupně smaží nedogmatický duch UML.

Dále moje rozlišení agregace a kompozice vycházejí z praxe, kde indukcí dojdete k tomu, že kompozice bývá heterometrická  - konstituenti jsou objekty z různých tříd. Typicky například u faktury rozlišujete mezi řádky faktury, záhlavím faktury a zápatím faktury - faktura je tedy složena minimálně z objektů tří různých tříd. Když faktura nemá záhlaví, zápatí nebo alespoň jeden řádek, nemůže jít o fakturu. 

U agregace si častěji všimneme toho, že agregované objekty mohou být sdílené a že nezanikají se zánikem celku. Typicky o agregaci hovoříme třeba, když budeme modelovat kalendář pro obchodní zástupce a v kalendáři budou zadávány  jejich schůzky. Kalendář jako takový (seznam dní) může existovat i bez jakékoli evidované události. Některé události v kalendáři jsou privátní - typicky pravidelná návštěva přiděleného zákazníka. Jiné události jsou sdílené - společná schůzka všech obchodních zástupců je (přesněji řečeno - v tomto případě může být výhodně modelována jako) sdílená událost ve více kalendářích. I ty takzvaně privátní schůzky mohou "putovat" po kalendářích různých obchodních zástupců, když se dohodnou, že jeden po dobu dovolené zastoupí druhého a že převezme i jeho schůzky.

Důležité je si uvědomit, že v jazycích jako je C# nebo Java je rozdíl mezi kompozicí a agregaci opravdu zanedbatelný. Důvod je jednoduchý - nemáme v nich operátor delete([]) a odpovědnost za likvidaci objektů za nás převzal Garbage Collector. V C# a Javě si musíme pouze hlídat řízení životního cyklu objektů ukládaných do databáze - pokud něco (exkluzivně i sdíleně) vlastním (kompozice i agregace) , měl bych si uvědomit, že:

1. Při zániku vazby musí dojít k odstranění objektu z databáze. Tedy odebere-li někdo řádek faktury z kolekce, je objekt faktura odpovědný za smazání vazby.
   
2. Jestliže nemažu vazby fyzicky v databázi, ale pouze u objektů ze zrušených vazeb nastavuji stav 'neaktivní', musí moje business vrstva centrálně podporovat princip "co je neaktivní, je tabu a nikdo s tím nesmí pracovat  - a jak to v SW bývá, vždy máme výjimky. Jedinou výjimkou z tohoto pravidla jsou objekty, u nichž eviduji historii."

Poslední poznámka z praxe:

Na jedné přednášce (myslím před rokem na DNG) jsem se setkal s názorem, že typickým zástupcem agregace je "typování" objektů. Pod typováním objektu se můžeme představit objekt Uchazeč o práci, který má na sobě navázáno 0..n dalších objektů z třídy (z hlediska databáze z číselníku) Schopnost (řidičák, anglický jazyk, německý jazyk, práce s Excelem, lámání ženských srdcí atd.). Schopnost je zde termín, pod který jsou subsumovány všechny sledované typy evidovaných znalostí a dovedností. "Typování" není nic jiného, než klasifikace objektů dle různých kritérií, což nám umožňuje objekty rychle seskupovat do (z hlediska projektu) zajímavých množin - například budu-li obsazovat pozici lamačem srdcí se znalostí německého jazyka, snadno zjistím množinu uchazečů splňujících zadaná omezení.

Každý uchazeč může tedy "agregovat" o..n znalostí. Ale jde opravdu o agregaci? Já myslím, že je to prostá asociace - uchazeč nemá žádnou zvláštní vazbu na znalosti, ty jsou k němu jen "volně přidruženy".

A za jakých podmínek by bylo vhodné překvalifikovat vazbu mezi Uchazečem a Schopností opravdu na agregaci ? V momentě, kdy budete chtít evidovat nějakou dodatečnou a unikátní informaci k vazbě mezi uchazečem a jeho schopnostmi. Když tedy budeme chtít zjistit, od kdy uchazeč vlastní řidičský průkaz, nebo kolik dobytí ženských srdcí posloužilo jako předmostí k dobytí klínů , zavedeme novou třídu DetailSchopnostíUchazeče - tato třída bude v asociaci s původní třídou Schopnost a bude agregována třídou Uchazeč (anebo dokonce v tomto případě bude jejím komponentním objektem)  .

Proč? Informace, které nesou objekty z třídy DetailSchopnostíUchazeče nemají význam "an sich", ale jen ve spojení s uchazečem. Jsou nedílnou částí právě jednoho obrazu, který nám dává objekt Uchazeč. Třída Schopnost nedílnou součástí obrazu právě jednoho Uchazeče nebyla - nenesla žádné specifické informace o uchazeči, jen s ním byla svázána náhodným poutem - asociací.

Na konec aktualitka na asociaci a kompozici ze života. :)

Asociace je pouhé registrované partnerství, ve kterém jsou dva konstituenti nahodilými objekty, kteří mají vůči sobě jeden kontingentní a zparchantělým parlamentem posvěcený link. Oba nijak závazně neřídí životní cyklus toho druhého.

Uzavřením manželství vzniká sakrální kompozitní objekt, jehož nedílnými součástmi jsou oba manželé s vzájemně protknutými životními cykly. A jak víme, při zániku kompozitního objektu, dříve či později nevratně odumírají i komponentní objekty.

I když nemusíme rozlišovat mezi asociací, agregací a kompozicí v UML, v životě může být dobře patrný rozdíl mezi asociací a kompozicí diferencujícím znakem mezi frivolní hrou a závazným svazkem. A pak že nelze do odborného blogu jednoduše a nenásilně propašovat názor na politická nebo společenská témata

UPDATE:

Podrobné a aktuální informace o dalších termínech školení a nabídce dalších služeb naleznete nyní zde.

Jak jsem již naznačil v předchozím spotu, uzavřel jsem "strategické partnerství" s novým školícím střediskem - se společností EIITE. Mé kurzy budou pořádány pod hlavičkou Skilldrive.

Všechny kurzy se budou konat v Praze.

Přesná adresa:

EIITE Praha
Karlovo nám. 17
120 00 Praha 2

Termíny kurzů:

• Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací - 3-5.5 2006 (každý den od 9:00 do 16:00). Program a další informace o kurzu naleznete v předchozím spotu. Přihlášky na kurz je možné stále posílat na adresu petra@renestein.net.
  Kurz je obsazen: Pokud máte stále  zájem o kurz, napište nám prosím opět na adresu petra@renestein.net a my Vás budeme informovat ihned po vyhlášení  dalšího termínu školení. Je také možné stále objednávat InHouse školení (viz níže).
  
• Kurz UML pořádaný a administrativně zajišťovaný společností EIITE - 28-29.8. 2006. Přihlášení na kurz.

InHouse školení

Pokud máte zájem o inhouse školení zaměřené na OOP, návrhové vzory, UML, .NET Framework, Compact .Net Framework nebo chcete vytvořit kompletní systémový design aplikace včetně naprogramování klíčových částí, napiště prosím svůj požadavek také na adresu petra@renestein.net nebo nás kontaktujte na telefonním čísle +420 603 266 732. Omezení pro inhouse školení, o kterých jsem zde psal dříve, již neplatí!

Takže předběžně ke kurzům UML a OOP, protože se mi nechce psát stále stejné věci každému zvlášť do mailu. V souvislosti se změnou zaměstnání se mění i některé věci ke kurzům.

1. Kurzy OOP a UML již nebudou pořádány ve školícím středisku DIGI TRADE, ale ve velmi pěkných prostorách jiné společnosti, s níž jsem uzavřel "strategické partnerství" a jejíž jméno oznámím příští týden.
   
2. První termín (pravděpodobně konec dubna/začátek května) patří kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací., na kterém již mnozí z vás byli. Pro připomenutí níže vkládám program kurzu. Pokud máte již nyní zájem předběžně si zarezervovat místo na kurzu, pošlete prosím email na adresu petra@renestein.net. Cena kurzu je 13 000 Kč.
   
3. Dále cca za měsíc zveřejním podrobný program a termín dalšího mého školení s pracovním podtitulem "Design aplikací a návrhové vzory prakticky  - od chaosu k řádu".
   
4. S novým školícím střediskem budeme také pořádat "jednodušší" (přesněji řečeno jinak zaměřený a více na základní znalosti orientovaný) kurz, uvádějící posluchače prakticky do světa UML (2.0). Podrobnosti a termín zveřejním do 14 dnů.
   
5. Fungovat to bude takto - první dva kurzy je po administrativní stránce zcela na mě, kurz o UML bude po admistrativní stránce plně zajišťovat nové školící středisko. I program kurzu o UML jsem samozřejmě připravil i já, nikdy bych nemohl školit nějaké "předžvýkané" řečičky někoho jiného. Uvádím to zde jen proto, aby vás nemátlo, když se u některých kurzů objeví informace, že máte přihlášky posílat mně (respektive mé ženě) a u jiných budete přihlášky směřovat rovnou na nové školící středisko. Kurzy se ale budou vždy konat na stejném místě.
   
6. Omlouvám se těm, kdo absolvovali první kurz a čekají na již poměrně dlouho slibované uvolnění studijních materiálů. Prozatím jsem nenašel čas (respektive vždy jsem našel zajímavější práci ;) , než je "vyčištění" materiálů k veřejnému použití) a také se mi nechce kvůli špatným zkušenostem uvolňovat materiály před konáním dalších kurzů, protože jsem se už v reálu setkal s tím, jak materiály neurčené široké veřejnosti začnou po internetu rychle kolovat, po čemž opravdu nijak netoužím. :(

1. den

1. Přivítání účastníků kurzu.
2. Úvodní informace o zaměření a organizaci kurzu.
3. Základní pojmy OOP a UML..
4. Mýty o OOP a UML.
5. Vysvětlení rozdílů mezi business analýzou, systémovým designem a implementací aplikace na konkrétní platformě.
   1. Světlo v temnotách – Model Driven Architecture (MDA)
6. Základní architektura a rozvrstvení aplikace.
7. Statický pohled na systém – vytváříme základní diagram tříd a ověřujeme, že jsou v něm zaneseny všechny informace, jež jsou nám známy z případů užití.
   1. Zvolení složitosti diagramu tříd. Potřebujeme vždy flexibilní doménový model?
   2. Zapouzdření objektů, polymorfismus, návrh metod.

                                                               i.      Důležitost principů kovariance a kontravariance.

                                                             ii.      Různé typy soudržnosti metod.

                                                            iii.      Rozhodnutí o typu viditelnosti u každého člena třídy.

                                                           iv.      Jaké konstruktory by měl nabízet každý objekt z problémové domény? Jak určit vlastnosti pouze pro čtení.

                                                             v.      Ověření bezpečného chování třídy vůči potenciálním klientům.

3. Precizní definice vztahů mezi třídami. Asociace, kompozice, agregace, závislost, realizace, generalizace.
4. Vysvětlení rozdílů mezi abstraktní třídou a rozhraním (interface).

                                                               i.      Vztah mezi typem a podtypem.

                                                             ii.      Rozpoznání primárního účelu (hlavního smyslu) třídy i jejich sekundárních odpovědností vynucených vztahy s objekty z různých vrstev.

8. Praktický příklad - ukázka implementace vzorových vztahů mezi objekty, perzistence objektů z problémové domény a zobrazování dat.  (jazyk C#)
   1. Separace kódu pro ukládání a obnovení objektů z perzistentního úložiště v samostatné vrstvě.
   2. Jak zajistíme, že v paměti počítače existuje nanejvýš jedna instance objektu se stejnou identitou.
   3. Ukázky různých způsobů mapování agregace, kompozice, generalizace a asociace do databáze.
   4. Zajištění existence maximálně jedné instance objektu v systému.
   5. Efektivní ukládání a nahrávání kolekcí.
   6. Jak se slučuje objektový přístup a přímé použití DataSetu (recordsetu) v uživatelském rozhraní?
9. Odpovědi na dotazy frekventantů kurzu.

2. den

1. Vysvětlení pojmu návrhový vzor.
2. Kdy byste měli používat návrhové vzory?
3. Základní vzory (GoF vzory)
   1. Vzory pro řízení vzniku objektů.
   2. Strukturální vzory.
   3. Vzory pro chování objektů.
4. Začlenění návrhového vzoru do designu aplikace. Kreativní aplikace vzorů.
5. Kompozice vzorů do vyšších sémantických celků.
6. Příklady odvozených návrhových vzorů často používaných při designu informačního systému.
7. Kdy byste neměli používat návrhové vzory?
8. Příklad - ukázky implementace složitějších vzorů. (jazyk C#).
9. Odpovědi na dotazy frekventantů kurzu.

3. den

1. Typické problémy při modelování informačního systému a jejich řešení.
2. Modelování  složitých organizačních struktur.
3. Výhody vytváření fasád (Facade) pro aplikace s více než jedním typem uživatelského rozhraní (lehký klient, těžký klient).
4. Evidence kompletní historie objektu.
5. Aplikační role a práva uživatelů.
6. Vytvoření flexibilního systému, jehož chování je změněno bez rekompilace aplikace.
7. Příklad – ukázky řešení problémů při modelování informačního systému. (jazyk C#).
8. Odpovědi na dotazy frekventantů kurzu.
9. Ukončení kurzu.

"Po delší prodlevě vychází další článek o návrhu aplikací s využitím jazyka UML. Místo zbytečných omluv za dlouhou a neplánovanou odmlku snad čtenáře potěší informace, že se napříště budu věnovat i konstrukcím jazyka UML nově přidaným ve verzi 2.0. Tématem tohoto článku je vysvětlení elementárních pojmů, jejichž znalost je nezbytná při návrhu diagramu tříd. " Pokračování na Interval.cz.

Jak mě upozornil jeden kolega, tak jsem nedal ke stažení prezentaci z přednášky o návrhových vzorech a .Net Frameworku z listopadového programátorského večera.

Takže pro zájemce napravuji:

V archivu ČVUT je i videozáznam přednášky, i když já sám jsem nenašel odvahu se na sebe narcisticko-kriticky podívat ;)

Prezentace, velikost 675 KB

Na čtvrteční přednášce o UML jsem do svého rezervoáru životních paradoxů přidal pár dalších :)

1) I když sebekriticky zredukuju prezentaci o 150 slidech na 70, poté se intenzivní a zostřenou psychoanalytickou rychloseancí, na které by i těžkotonážní barokně rozsochatá lady Halina Pawlowská prodělala akutní záchvat mentální anorexie, jenž by byl excelentně konvertibilní na finační částku za nějakou další a zatraceně rychle natočenou reklamu na hubnutí s bonusem ve formě nezbytných JoJo baculatých efektů pro frustrované paničky, které jako ona chytře snídají dietní Colu s čokoládovými tyčinkami. :), vypořádám s pocity viny, jejichž zdrojem je obsedantní představa, že svatokrádežně zjednodušuju svá milovaná témata hodná nejvyšší úcty,  a přesto nenásleduje kýžená odměna, jíž měl suplovat fakt, že jsem ve vyhrazených 3 hodinách vykleštěné téma alespoň stihl probrat. ;)

2) Je zvláštní přijít tak rozpolcený z přednášky na výsostné půdě Microsoftu, protože jsem navzdory svému obdivu vůči mnoha MS produktům musel po dotazech posluchačů doporučovat modelovací nástroje od jiných firem a dát najevo svoji vytříbenou nechuť k "vytváření návrhů" ve Visiu a také si opět otravně povzdychnout nad tím, že Visual Studio Team System, MSF a UML nejsou a nebudou nerozlučným triem - killerem konkurenčních nástrojů pro návrh a vývoj aplikací. ;)

Zájemci si mohou stáhnout prezentaci, i když na návrhové vzory nezbyl ve čtvrtek čas a budou v rozšířené podobě tématem až nějaké další .Net Developer Group.

V pátek bylo prvním účastníkům kurzu o návrhu aplikaci předáno osvědčení o jeho úspěšném absolvování ;)

Všem, kdo se zúčastnili prvního běhu, a byli tak chtě nechtě laboratorními zvířátky;), na nichž jsem si ověřoval , jaká témata musím zdůraznit a jaká naopak mohu jen letmo ve vyhrazeném čase zmínit, děkuji za věcné připomínky a náměty, které budou mít vliv na podobu kurzu v dalších termínech. Nejbližší další temín kurzu je 15.12-17.12 2004 a je, stejně jako následující jarní termín, plně obsazen.

Aby spot nebyl jen ozvěnou toho, co bylo nebo v dalších variacích bude, zde je předběžný a neúplný seznam věcí, které bych chtěl do konce tohoto roku a během příštího roku stihnout a které záležejí jen na mně.

22.11.2004 - přednáška Návrhové vzory nejen pro komerční aplikace a jejich implementace v .Net Frameworku na programátorských večerech ČVUT. Přednáška se soustředí na srovnání návrhových vzorů na odlišné úrovni abstrakce, bude se zabývat rozdíly mezi tradičními GoF vzory, vzory kodifikovanými Martinem Fowlerem, vzory pro integrační scénáře a způsobem implementace vzorů v .NET Frameworku.

Během příštího roku bych rád vydal knihu (nevím zatím, zda jen v podobě e-booku nebo v nějakém kamenném nakladatelství) o návrhových vzorech a aplikačních frameworcích, kde bych uvedl i některé své vlastní vzory a idiomy, které při návrhu aplikací používám. (největším lákadlem by měla být plně generická Identity Map).

V první polovině příštího roku chci spustit již dříve avizovanou vlastní doménu.

Ve druhé polovině roku by se mělo objevit pokračování kurzu o OOP a UML, které by u každého účastníka předpokládalo znalosti v rozsahu právě probíhajícího kurzu, takže bez jakýchkoli zdržování a srovnávání znalostí bychom se všemi účastníky ihned přikročili k návrhu informačního systému od analýzy přes systémový design a skončili bychom vytvořením tří různých klientů ve VS.NET 2005 (Windows Forms, ASP.NET, compact .NET Framework).

Protože se na školení o OOP a UML přihlásilo tolik účastníků, že máme nyní zcela zaplněny 3 kurzy a další zájemci se stále ozývají, chci upřesnit, jak to s kurzy já a školící středisko DIGI TRADE plánujeme:

1. První kurz proběhne v dříve avizovaném termínu 3.11-5.11 2004 a s jeho účastníky by již měly být vyřízeny všechny formality.
   
2. Druhý kurz se pravděpodobně uskuteční 15.12-17.12 2004 a všichni zájemci budou naším školícím střediskem s dostatečným předstihem informováni.
   
3. Třetí kurz bude uspořádán na jaře 2005 a přesné termíny zveřejním opět na blogu.
   
4. Zvláštním případem jsou firmy, které projevily zájem o in-house školení nebo si chtěly zarezervovat jeden či více termínů jen pro sebe. To není možné, protože nechceme ani nebudeme ulehčovat přežití na SW trhu naší přímé konkurenci. ;) Nijak ale neomezujeme počet účastníků z jedné firmy přihlášených na školení. Tohle je oficiální stanovisko společnosti DIGI TRADE, které se nezmění.

A hlavně díky všem přihlášeným za enormní zájem ;)

Další článek o UML mi dnes vyšel na serveru Interval.cz. I když pojem UML je dnes v názvu článku použit spíše jen ze setrvačnosti a také respektu k celému názvu seriálu, protože se zabývám návrhem struktury šablony dokumentu, ve které je umístěn podrobný popis případů užití.

Tímto článkem jsem opustil problematiku případů užití a příště již přijde na řadu (IMHO) nejzajímavější diagram v UML - diagram tříd.

Ve spotu z minulého týdne jsem sliboval překvapení pro příznivce OOP, UML a návrhových vzorů a hlavně pro ty, kdo mi psali, že by ode mě chtěli konzultaci nebo školení v designu aplikací. I když někteří z vás nabízeli opravdu zajímavé podmínky, musel jsem vždy odepsat, že žádné školení ani konzultaci neposkytuji. Důvody byly stále stejné. Mám dostatek vlastní práce a k courání po externích firmách nemám důvod. Žádostí ale bylo čím dál tím více, takže jsem se rozhodl s naším školícím střediskem  připravit cyklus přednášek  o OOP, UML a návrhových vzorech doprovázený  podrobnými praktickými příklady kódovanými v jazyce C#.

Orientační program kurzu:

1. den

1. Přivítání účastníků kurzu.
2. Úvodní informace o zaměření a organizaci kurzu.
3. Základní pojmy OOP a UML..
4. Mýty o OOP a UML.
5. Vysvětlení rozdílů mezi business analýzou, systémovým designem a implementací aplikace na konkrétní platformě.
   1. Světlo v temnotách – Model Driven Architecture (MDA)
6. Základní architektura a rozvrstvení aplikace.
7. Statický pohled na systém – vytváříme základní diagram tříd a ověřujeme, že jsou v něm zaneseny všechny informace, jež jsou nám známy z případů užití.
   1. Zvolení složitosti diagramu tříd. Potřebujeme vždy flexibilní doménový model?
   2. Zapouzdření objektů, polymorfismus, návrh metod.

                                                               i.      Důležitost principů kovariance a kontravariance.

                                                             ii.      Různé typy soudržnosti metod.

                                                            iii.      Rozhodnutí o typu viditelnosti u každého člena třídy.

                                                           iv.      Jaké konstruktory by měl nabízet každý objekt z problémové domény? Jak určit vlastnosti pouze pro čtení.

                                                             v.      Ověření bezpečného chování třídy vůči potenciálním klientům.

3. Precizní definice vztahů mezi třídami. Asociace, kompozice, agregace, závislost, realizace, generalizace.
4. Vysvětlení rozdílů mezi abstraktní třídou a rozhraním (interface).

                                                               i.      Vztah mezi typem a podtypem.

                                                             ii.      Rozpoznání primárního účelu (hlavního smyslu) třídy i jejich sekundárních odpovědností vynucených vztahy s objekty z různých vrstev.

8. Praktický příklad - ukázka implementace vzorových vztahů mezi objekty, perzistence objektů z problémové domény a zobrazování dat.  (jazyk C#)
   1. Separace kódu pro ukládání a obnovení objektů z perzistentního úložiště v samostatné vrstvě.
   2. Jak zajistíme, že v paměti počítače existuje nanejvýš jedna instance objektu se stejnou identitou.
   3. Ukázky různých způsobů mapování agregace, kompozice, generalizace a asociace do databáze.
   4. Zajištění existence maximálně jedné instance objektu v systému.
   5. Efektivní ukládání a nahrávání kolekcí.
   6. Jak se slučuje objektový přístup a přímé použití DataSetu (recordsetu) v uživatelském rozhraní?
9. Odpovědi na dotazy frekventantů kurzu.

2. den

1. Vysvětlení pojmu návrhový vzor.
2. Kdy byste měli používat návrhové vzory?
3. Základní vzory (GoF vzory)
   1. Vzory pro řízení vzniku objektů.
   2. Strukturální vzory.
   3. Vzory pro chování objektů.
4. Začlenění návrhového vzoru do designu aplikace. Kreativní aplikace vzorů.
5. Kompozice vzorů do vyšších sémantických celků.
6. Příklady odvozených návrhových vzorů často používaných při designu informačního systému.
7. Kdy byste neměli používat návrhové vzory?
8. Příklad - ukázky implementace složitějších vzorů. (jazyk C#).
9. Odpovědi na dotazy frekventantů kurzu.

3. den

1. Typické problémy při modelování informačního systému a jejich řešení.
2. Modelování  složitých organizačních struktur.
3. Výhody vytváření fasád (Facade) pro aplikace s více než jedním typem uživatelského rozhraní (lehký klient, těžký klient).
4. Evidence kompletní historie objektu.
5. Aplikační role a práva uživatelů.
6. Modelování toku peněz (zboží) v systému.
7. Vytvoření flexibilního systému, jehož chování je změněno bez rekompilace aplikace.
8. Příklad – ukázky řešení problémů při modelování informačního systému. (jazyk C#).
9. Odpovědi na dotazy frekventantů kurzu.
10. Ukončení kurzu.

Kurz se koná 3.11 - 5.11 2004 a jeho lektorem je samozřejmě moje maličkost. Jestliže vás program kurz zaujal, podívejte se prosím na jeho oficiální stránku, na které se můžete přihlásit. A pokud si stejně jako já myslíte, že zlatokopeckou dobu vývoje softwaru, kdy neznalý zákazník byl ochoten platit za zpatlanou aplikaci jakémukoli bastlíři, který za svoje excelentní know how považuje znalost syntaxe nějakého triviálního programovacího jazyka, halí opar blížícího se "fin de siecle”  a že v nové éře musí  kódování předcházet kvalitní návrh, jemuž rozumí všichni vývojáři, tak je kurz určen právě vám. Máte-li nějaké dotazy, napište je prosím do diskuze.

Aktualizace: Kurz je již obsazen (takový zájem mě opravdu těší), ale právě dohadujeme další termíny, aby se dostalo na všechny zájemce ;)

Na Interval.cz se konečně objevil další díl seriálu o UML , ve kterém se zabývám generalizací a vztahy Include a Extend mezi případy užití.

Slovo konečně jsem v předchozí větě použil záměrně, protože jak jste si jistě všimli, dva měsíce jsem nepsal články, nepřispíval do blogu a jen občas jsem napsal nějakou odpověď do konference. Důvod je prozaický, role otce mě přes mé původní ambiciozní plány vytížila natolik, že místo psaní článků o analýze a vývoji jsem měl dostatek času připravit si v hlavě koncept neplánovaného a  abundantní  horoucí životní zkušeností naplněného eseje "Život mezi řevem, nespavostí, přebalováním a  s absolutním nedostatkem času aneb poděkování manželkám, že si dovedou poradit v každé situaci”:)  - vydavatelem finální verze by byl ale asi server  eMimino, ne Interval . :)

Nyní jsem již většinu svých aktivit obnovil,  i když si více vybírám komu a čemu budu věnovat svůj volný čas. Moje články o UML a .NET Frameworku by ale na Interval.cz měly vycházet stále.

A pro zájemce o UML , návrh aplikací a návrhové vzory, kteří byli zklamáni frekvencí článků o UML  a psali mi motivující emaily :) jsem společně s DIGI TRADEm připravil jedno překvapení, o kterém ale napíšu více až příští týden. Myslím, že se máte opravdu na co těšit...

Návrhový vzor Mediator  zamezuje těsným vztahům mezi objekty zavedením  prostředníka (mediatora), který jejich interakci zapouzdří. Tak praví strohá, ale výstižná definice. Řečeno jinak, Mediator snižuje přímé i nepřímé zatížení třídy jinými třídami.

Vzor Mediator je většinou vykládán na příkladu interakce komponent v uživatelském rozhraní, které spolu komunikují přes prostředníka, jímž je formulář.  Listbox se seznamem zemí neví nic o Listboxu se sezamem měst - po výběru jiné země je vyvolána událostní procedura formuláře, v níž je kód pro naplnění druhého Listboxu městy ve vybrané zemi. Každý ovládací prvek spolupracuje jen s formulářem, který notifikuje o změně ve svých vlastnostech, a na formuláří je kód propagující změny do dalších prvků. Na způsobu chování nezáleží, formulář může být u prvku zaregistrován jako Observer (v terminologii jazyka JAVA Listener), jehož metoda je zavolána po změně stavu prvku, nebo v .NET zaregistrujeme u ovládacího prvku delegáta s obslužnou metodou, jejíž signatura se shoduje se signaturou události. Komplexního chování prezentační vrstvy není dosaženo přímou spoluprací mnoha objektů,  ale zavedením inteligentní mezivrstvy, která je recipientem heterogenních notifikačních zpráv objektů a současně  autorem a distributorem nových aktualizačních zpráv pro další objekty, jež po jejich přijetí změní svůj stav a přitom mohou prostředníkovi odeslat další notifikační zprávy. Zdůraznil bych, že prostředník je autorem zpráv, takže informaci o notifikaci nemusí jen přeposlat, ale také dokáže argumenty původní notifikační zprávy před odesláním kreativně pozměnit, filtrovat,  anebo dokonce rozešle události v jiném pořadí. Jak uvidíme, všechny tyto charakteristiky jsou klíčové pro mediatora koordinujícího synchronizaci stavových automatů business objektů.

Kdyby ovládací prvky mezi sebou komunikovaly přímo, tak i jednoduchá  změna chování prezentační vrstvy roztočí spirálu sisyfovského dohledávání a ošetřování dopadů změny v kódu všech prvků.

Použití vzoru Mediator ale není omezeno na prezentační vrstvu a jeho  kvality se plně projeví až při řízení složité interakce stavových automatů tříd v business vrstvě.

Představte si systém pro nábor zaměstnanců na různé pozice. V systému jsou evidovány nabízené pracovní pozice a uchazeči. Když uchazeč projeví zájem o pozici, je vytvořen nový objekt pro relaci mezi uchazečem a pozicí, v němž jsou uložena data o průběhu procesu výběru jednoho uchazeče. Platí pravidlo, že v jednom okamžiku může být Uchazeč přiřazen jen k jedné Pozici. Pozice,  Uchazeč  i Relace  mají své stavové diagramy. Uveďme si příklady stavů.

Pozice může být ve stavu:

 Nová - Zahájení životního cyklu pracovní pozice.

Přiřazen alespoň jeden uchazeč –  O pozici se zajímá alespoň jeden uchazeč. Tento stav je důležitý pro manažery, kteří jsou odpovědni za obsazení pozice a zajímá je, zda například týden po vypsání místa je o pozici zájem, nebo je třeba investovat více peněz do propagace.

Přijat alespoň jeden uchazeč – K pozici se může vázat více volných míst, tento stav manažery náboru informuje, že již byl vybrán alespoň jeden vhodný zaměstnanec.

Obsazená – Pozice byla obsazena. Počet nabízených míst je roven počtu přijatých uchazečů.

Zrušená – Pozice byla zrušena. Pozici je možné kdykoli zrušit, což značí, že k ní již není možné dále přiřadit uchazeče a přiřazení uchazeči, kteří ještě nebyli přijati, jsou ihned odmítnuti.

Stavy uchazeče

Nový – Založení uchazeče.

Zajímá se o pozici –Uchazeč byl přiřazen k pozici a prochází různými zkouškami. Nelze mu přiřadit další pozici.

 Přijat – Uchazeč byl přijat na pozici. Pozice musí být notifikována o přijetí uchazeče.

 Odmítnut – Uchazeč byl odmítnut, to znamená, že je ho možné přiřadit k jiné pozici.

 Propuštěn – Uchazeč (zaměstnanec) byl propuštěn. Opět ho je možné přiřadit k jiné pozici.

Zrušen – Uchazeč byl zrušen. Zrušit lze jen uchazeče ve stavu Nový, Odmítnutý a Propuštěný. Je nutné notifikovat aktivní relaci mezi Uchazečem a Pozicí.

Stavy relace mezi uchazečem a pozicí

Nová – Nová relace mezi uchazečem a pozicí založena. Je nutné notifikovat pozici i uchazeče, že byla mezi nimi vytvořena relace.

Uchazeč prošel psychotesty – Uchazeč úspěšně prošel psychotesty.

Uchazeč odmítnut po psychotestech –Uchazeč neprošel psychotesty, notifikovat pozici a uchazeče o odmítnutí.

Uchazeč splnil všechny požadavky – Notifikovat pozici o přijetí dalšího uchazeče, notifikovat uchazeče.

Zrušena – Došlo ke zrušení relace, důvodem může být to, že uchazeč o pozici ztrati zájem nebo je zrušena pozice. Notifikovat uchazeče a pozici o zrušení.

Jde sice jen o reprezentativní množinu tříd a jejich stavů, ale i mezi takto malým počtem tříd existuje poměrně složitá spolupráce.

Například při zrušení pozice musejí být notifikovány všechny aktivní Relace, ty přejdou do stavu zrušena . Je notifikován Uchazeč, že byl odmítnut. Relace zpětně notifikuje o svém zrušení i Pozici, protože důvodem zrušení může být jindy ztráta zájmu ze strany Uchazeče.

Další příklad. Když relace přejde do stavu Uchazeč splnil všechny požadavky, tak musí být notifikována pozice, u níž dojde ke změně stavu jen tehdy, když se jedná o prvního přiřazeného uchazeče. Dále je notifikován uchazeč, který přejde do stavu Přijat.

Představme si nyní, že třídy Uchazeč, Pracovní pozice a Relace informaci o změně svého stavu nabídnou okolí ve formě událostí. Každý objekt z jedné třídy si přihlásí odběr událostí asociovaných objektů z dalších tříd  a pak všichni spustí divokou událostní přestřelku se zběsilými kulkami v podobě vzájemných notifikací.

Když Pozice přejde do stavu zrušena, informuje první relaci, ta změní svůj stav na zrušena, relace svoji změnu stavu zašle uchazeči, ten přejde do stavu „Odmítnut“ a vyvolá svoji událost „Změna stavu“, tu odchytí Relace, která na stav „Odmítnut“ u uchazeče nereaguje. Relace informaci o svém zrušení zasílá vždy recipročně objektu Pozice. Pozice pod dokončení kolečka s první Relací notifikuje další Relaci a kolečko s mírně obměněnými aktéry proběhne znovu. Všechny objekty jsou při tomto vzájemném přeřvávání kandidáty na slušivou svěrací kazajku.

V čem je ale hlavní problém? Události nemusí být zpracovány ve správném pořadí. Představme si, že u Pozice z nějakého důvodu zavedeme další tranzientní stavy „Vyžádáno zrušení pozice“, „Pozice je rušena“ a teprve finálním stavem je náš původní stav „Zrušena“. Do stavu „Vyžádáno zrušení pozice“ přejde pozice ihned po žádosti uživatelem (přesněji po volání metody Cancel), do stavu „Pozice je rušena“ , když je zpětně notifikována první Relací o jejím přechodu do stavu Zrušena. Pozice přejde do finálního stavu  „Zrušena“ až po obdržení potvrzení o svém zrušení od všech dalších relací. Tady ale narazíme – když Pozice přejde do stavu „Pozice je rušena“, tak začne tuto událost rozesílat všem Relacím.

To znamená, že Relace2 a následující obdrží nejdříve informaci o přechodu Pozice do stavu „„Pozice je rušena“ a později o ( již nepravdivém)  přechodu do stavu  „Vyžádáno zrušení pozice“. Když se zkomplikují i stavové automaty dalších objektů, staneme se nechtěnými svědky rozhovoru bandy otrlých lhářů.:)

Pořadí při rozesílání událostí není sekvenční,  a i když bychom mohli do objektu Pozice a dalších dopsat logiku, která se o sekvenční distribuci postará, nepůjde o šťastné řešení. Aby třída konvenovala svému okolí, dosadíme do ní znalost, jak si okolí komunikací představuje, a porušíme tak princip zapouzdření. Třída svému okolí sděluje, jaké změny v ní nastaly, ale nesmí se starat o reakce okolí. Třída musí být vždy nonkonformní a kašlat  na své sousedy, jež ji nutí, aby se adaptovala na jejich způsob komunikace a chování.  (BTW: Zjsitil jsem, že  miluji OOP a návrhové vzory, protože k sousedům mám stejný postoj :) )

Odpovědnost za sekvenční rozesílání událostí přidělíme nové třídě Mediator. Po svém vytvoření budou objekty zaregistrovány v Mediatoru, který si přihlásí odběr jejich událostí. Třídám Pozice, Relace a Uchazeč přidáme metody, které budou volány mediátorem, když nastane událost. Například objekt Pozice bude mít metodu „NotifikujUchazečOdmítnut“, která bude mediátorem zavolána, když Relace přejde do stavu „Uchazeč odmítnut po psychotestech“ nebo do stavu  „Zrušena“.

Aby mediátor nebyl příliš komplikovaný a nepřehledný, vytvoříme pro každou třídu jednoho zpracovatele události. Každý zpracovatel událost bude implementovat rozhraní s jedinou metodou „ZpracujUdálost“, které přijímá dva argumenty. Prvním argumentem je odkaz na objekt, který událost vyvolal, a druhým jsou parametry události. Zpracovatel „ví“, jaké metody musí u objektů volat pro každou jedinečnou kombinaci argumentů události. (Když zpracovatel objektu Relace obdrží událost „Přechod do stavu Zrušena“, tak zavolá u asociovaného objektu Pozice metodu NotifikujUchazečOdmítnut“ a u Uchazeče metodu „ZůstávášNezaměstnaným“:) )

Jak zajistíme sekvenční zpracování?

V událostních metodách mediátor odchytne událost a zavolá vždy jen obecnou metodu handleEvent, které kromě odesílatele a argumentů události přijímá odkaz na zpracovatele (m_JobHandler), jenž reaguje na danou událost. Objekt m_JobHandler zpracovává událost „StavZměněn“ třídy Pracovní pozice.

handleEvent(sender, e, m_JobHandler);

Metoda handleEvent

private void handleEvent(object sender, EventArgs e, BProcessEventHandlerBase processor)

                        {

                                   EventStateHolder holder = new EventStateHolder(e, sender, processor);

                                   m_eventsQueue.Enqueue(holder);

                                   if (!m_inEventBubbling)

                                               initEventBubbling();

                        }

Metoda handleEvent nejdříve uloží všechny informace o události do nové instance naší třídyEventStateHolder. Zde mimochodem vidíte kouzlo polymorfismu, protože naše třída EventStateHolder se nestará o detaily událostí, ale vyžaduje jen, aby argumenty události byly odvozeny z třídy EventArgs a zpracovatelé událostí z třídy (rozhraní) BProcessEventHandlerBase. Poté je událost zařazena do fronty (v .NET třída Queue) a jestliže se jedná o první událost, je zavolána metoda initEventBubbling, která se postará o předání události do zpracovatele. Tento kód je důležitý –  bublání událostí je zahájeno jen při první události, všechny další události libovolných business objektů, které jsou přímou nebo nepřímou reakcí na první událost, jsou jen zařazeny do fronty a k novému  spuštění distribuce událostí realizovaného metodou initEventBubbling nesmí dojít.

private void initEventBubbling()

{

                                   Debug.Assert(m_eventsQueue.Count > 0, "BMediator events queue is empty!");

                                   m_inEventBubbling = true;

                                   while (m_eventsQueue.Count > 0)

                                   {

EventStateHolder eh = (EventStateHolder) m_eventsQueue.Dequeue();

eh.Processor.ProcessEvent(eh.Sender, eh.EventArguments);

                                   }                                 

m_inEventBubbling = false;

                        }

V metodě initEventBubbling se nejdříve ujistíme, že fronta událostí není prázdná. Pak nastavíme privátní proměnnou m_inEventBubbling na true, aby metoda handleEvent již při zpracovávání návazných událostí metodu initEventBubbling nevolala. V jednoduchém cyklu while zpracujeme sekvenčně všechny události postupně přidávané do fronty po rozeslání každé události.

Mediatora můžete vylepšit. Ke každé události mohou být registrovány preprocesory, kteří například zalogují všechny události a postprocesory, odesílající manažerovi informaci o provedených změnách. Když budeme chtít rychle změnit chování aplikace bez zásahu do existujícího kódu, můžeme napsat nový preprocesor, který událost zpracuje zcela jinak, a protože z metody vrátí true (nepokračovat v distribuci událostí, již jsem vše udělal), tak se originální zpracovatel události nedostane ke slovu. Preprocesory načteme dynamicky při startu aplikace  s využitím reflection API.

private void initEventBubbling()

{

                                   Debug.Assert(m_eventsQueue.Count > 0, "BMediator events queue is empty!");

                                   m_inEventBubbling = true;

                                   while (m_eventsQueue.Count > 0)

                                   {

                                               EventStateHolder eh = (EventStateHolder) m_eventsQueue.Dequeue();

                                               bool continueEventBubbling = distributeEventToPrePostProcessors(eh.Sender, eh.EventArguments, m_preProcessors);

                                               if (continueEventBubbling)

                                               {

                                                           eh.Processor.ProcessEvent(eh.Sender, eh.EventArguments);                                                        distributeEventToPrePostProcessors(eh.Sender, eh.EventArguments, m_postProcessors);

                                               }

                                   }

                                   m_inEventBubbling = false;

                        }

                        private bool distributeEventToPrePostProcessors(object sender, EventArgs e, ProcessorCollection processors)

                        {

                                   bool result = true;

                                   foreach (IProcessor processor in processors)

                                   {

                                               if ((processor.ProcessEvent(sender, e)))

                                               {

                                                           result = false;

                                                           break;

                                               }

                                   }

                                   return result;

                        }

Také můžete přes mediátora řídit distribuci událostí transakčně s potvrzováním a  vracením jednotlivých kroků a ukládat změny ve všech participujících objektech na konci úspěšné transakce do databáze.

Vzor Mediator je nepominutelnou dominantou každého návrhu aplikace, jež vyžaduje komplexní komunikaci mezi stavovými automaty různých tříd.

Se snad blížícím se datem uvolnění  finální verze 2.0 jazyka UML je myslím přínosné popsat mé první zkušenosti s novou verzí. Myslím, že se druhá verze jazyka UML stejně jako verze 1.0 stane nepřehlédnutelným periodizačním mezníkem v oblasti analýzy a vývoje softwaru. S uvedením první verze jazyka UML v roce 1996 skončilo neplodné období válek mezi vzájemně se potírajícími  metodikami a jejich občas málo soudnými tvůrci, kteří by pravděpodobně nejraději své výtvory šířili s pěnou "u huby" ohněm i mečem. Málokdo také tušil, že UML předznamenává novou epochu. Epochu, v níž znalost UML je povinností nejen pro analytiky a designéry, ale alespoň pasivní znalost se předpokládá také u  vývojáře, jehož nejvyšší pracovní ambicí není kreativní psaní formulářů na editaci číselníků. Nic na tomto světě není nikdy perfektní a i pro UML po sérii dílčích vylepšení, jež vyústily ve verzi 1.5, nadešel čas na nový velký "release“ zaměřený na zacelení dlouhodobě pociťovaných mezer ve specifikaci, které se staly neblahým impulsem pro vznik proprietárních rozšíření. Tato rozšíření se zaměřovala hlavně na silnější podporu analytika modelujícího dynamické chovaní systémů. Three amigos vrací úder a odvrací hrozbu nového vysilujícího souboje disparátních specifikací vylepšeními ve verzi 2.0 jazyka UML. Vylepšeny byly nejen diagramy pro dynamické chování, ale byly také přidány zcela nové diagramy (Composite structure diagram, Timing diagram,  Interaction overview diagram) a rozšířeny takřka všechny ostatní a z verzí 1.x známé strukturní prvky.

Dnes se podíváme na vylepšení případů užití (Use Case), ve kterých ale k žádným velkým změnám nedošlo, protože jejich hlavním účelem  je vizualizovat funkční rozsah systému pro zákazníka a tak by příliš mnoho fines, ornamentů a vychytávek mohlo smysl diagramu spíše zatemnit. Případy užití jsou  přesto ve verzi 2.0 více provázány s ostatními diagramy, aby model systému působil kompaktnějším dojmem.

1. Kromě seskupování případů užití do balíčků, je možné je nyní seskupit v klasifikátoru. Toho využijeme například tehdy, když budeme psát informační systém pro velkou společnost a v modelu bude klasifikátor divize vyjadřující rozdělení společnosti do menších celků. Jestliže se liší případy užití realizované zaměstnanci různých divizí, například divize finanční a divize technologické, můžeme z důvodu větší názornosti klasifikovat případy užití jejich seskupením pod jednotlivé divize.
   
2. U vztahu Extend mezi případy užití je doporučeno zachytit podrobnosti rozšíření v poznámce (Note). Poznámka by měla mít strukturu:
   Condition:[Podmínka, při které nastane rozšíření]
   Extension Point:[Bod rozšíření]
   
3. Když případ užití obsahuje větší množství bodů rozšíření, je možné pro jeho vyjádření použít alternativní symbol. Symbolem je obdélník, který je rozdělen nepřerušovanou čarou na dvě části. V horní části je jméno případu užití a ovál, který je tradičním symbolem případu užití. Ve spodní části se nachází seznam bodů rozšíření.
   
4. Případ užití může nyní  “vlastnit” jiný diagram. Příkladem může být stavový diagram popisující průběh vyřizování objednávky u případu užití s názvem zpracování objednávky. Vložené diagramy nejsou určeny pro zákazníka, ale pro rychlé zachycení složitých vazeb mezi různými částmi modelu budou neocenitelné.