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? :) 

Monday, September 11, 2006 3:55:02 PM (Central Europe Daylight Time, UTC+02:00)       
Comments [19]  Návrhové vzory | Ostatní | UML

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

Sunday, August 20, 2006 5:59:53 PM (Central Europe Daylight Time, UTC+02:00)       
Comments [0]  Kurzy UML a OOP | Návrhové vzory | UML

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

Thursday, April 27, 2006 7:25:16 PM (Central Europe Daylight Time, UTC+02:00)       
Comments [13]  Programátorské hádanky | UML

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

Tuesday, April 18, 2006 10:27:39 AM (Central Europe Daylight Time, UTC+02:00)       
Comments [27]  Programátorské hádanky | UML

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

Sunday, March 26, 2006 4:50:53 PM (Central Europe Daylight Time, UTC+02:00)       
Comments [5]  UML

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í!

Sunday, March 05, 2006 12:36:23 PM (Central Europe Standard Time, UTC+01:00)       
Comments [0]  Kurzy UML a OOP | Návrhové vzory | UML

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.

Sunday, February 26, 2006 8:27:49 PM (Central Europe Standard Time, UTC+01:00)       
Comments [0]  Kurzy UML a OOP | Návrhové vzory | UML

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

Tuesday, August 16, 2005 8:39:59 AM (Central Europe Daylight Time, UTC+02:00)       
Comments [0]  UML

Jak mě upozornil jeden ko