Aktualizace 15.10.2009  - veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 je zcela obsazen včetně náhradníků. Je možné se již hlásit pouze na kurz Pokročilé návrhové vzory a objektové principy 2.

Rád bych Vás pozval na podzimní kurzy OOP a UML a představil oficiálně InHouse kurz, který postupně vykrystalizoval z požadavků zákazníků (OOP 0 - Objektové programování a UML prakticky - rychlý úvod do světa (nejen) objektového programování).

Osnova InHouse kurzu OOP 0 – Objektové programování a UML prakticky – rychlý úvod do světa (nejen) objektového programování:

Školení má dvě varianty -  pro vývojáře i u konstrukcí a prvků jazyka UML, které jsou považovány za analytické, se 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 varianty pro „čisté“ analytiky jsou digrese do kódu minimalizovány, i když v některých místech 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 (mnohdy oprávněně) považují za nesmyslnou, drahou a projektu nic nepřinášející.

V kurzu se naučíte modelovat jednoduché i složité aplikace s využitím jazyka UML tak, aby následné kódování nebylo výletem do neznáma s nejistými výsledky, ale dobře čitelnou cestou bez temných a záludných míst vedoucích k selhání projektu.

Kurz je vhodný zvláště pro ty, kteří již nejsou spokojeni s vývojem projektů naivním "hurá" způsobem, kdy bez ohledu na složitost systému nevzniká žádný návrh a ihned se přistupuje ke kódování se všemi špatnými důsledky jako jsou podcenění technické a časové náročnosti implementace nebo vytváření drahých a nespravovatelných systémů.

Kurz je určen pro vývojáře, systémové designery, analytiky a projektové manažery, kteří se chtějí se seznámit se základními principy objektového programování a s modelováním v jazyce UML.

· Požadavky na systém a modelování pomocí případů užití (+ příklady).

· Zrychlená funkční specifikace bez zbytečných formalit – příklady.

· Diagram tříd v UML - 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. Třída, základní principy OOP, operace, atributy, viditelnost členů třídy. Nenásilný přechod k jednoduchým návrhovým vzorům.

· Příklady složitých diagramů tříd.

· Objektový diagram + příklady.

· Sekvenční diagramy a diagramy interakce.

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

· Výhody a nevýhody UML - vyzdvižení nejvíce používaných postupů, odhození nepotřebné veteše z jazyka UML.

Pokud máte o kurz zájem nebo potřebujete další informace, napište prosím na adresu petra@renestein.net.

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

Datum konání kurzu:  2. 11. – 4. 11. 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í.

Na kurzu jsou samozřejmě po celý den teplé a studené nápoje a 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 Pokročilé návrhové vzory a objektové principy 2

Datum konání kurzu:  23. 11. – 25. 11. 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í.

Na kurzu jsou samozřejmě po celý den teplé a studené nápoje a 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

Několik zájemců o veřejný kurz OOP a návrhových vzorů raději zvolilo inhouse variantu kurzu, proto bych vás rád upozornil,  že se můžete ještě nyní dodatečně hlásit na kurz OOP a návrhových vzorů.

Pozvánka s odkazy na podrobné informace o kurzu.

Je vzrušující pozorovat, jak na svém počátku amorfní a abstraktní vzor nabývá svébytného a ostře ohraničeného tvaru pri svém dospívání, když je adoptován různými technologiemi. Zasazením vzoru do jednoho vývojového prostředí a kontextu se může zdát, že je na univerzálnost svého použití aspirující smysl vzoru zastřen a překryt dominantním zaměřením a převládajícími výrazovými prostředky jedné technologie. Každý dobrý návrhový vzor se ale svojí konkretizací v jedné nebo i více technologiích nevyčerpává, ale je připraven vymanit se ze sevření každé technologie a při změně IT paradigmatu znovu nabídnout svoji plnou formativní potenci pro nové postupy, pravidla a vazby ve vývoji. Když se mění technologie, programovací jazyky nebo celé zažité programátorské návyky (strukturální versus objektové programování), tak esence kvalitního návrhového vzoru není dotčena a jeho abstraktní smysl začne být jen artikulován výrazovými prostředky žezlo přebírajícího paradigmatu a z něj vyplývajícího znalostního a pojmového horizontu. Dobrý návrhový vzor participuje na tvorbě struktur nového paradigmatu a současně je nově vznikajícími strukturami přetavován ve svou jinou, parciální a dočasnou formu.

Když nechcete, aby vaše znalosti beznadějně zastaraly za pár měsíců, nebazírujte na zvládnutí programovacích jazyků, vývojových prostředí nebo frameworků, ale stavte své znalosti na návrhových vzorech. .Net Framework nebo J2EE jsem se naučil tak, že jsem se za jednotlivými knihovnami nesnažil vidět deprimující změť tříd a metod, ale harmonii návrhových vzorů.

Jak se projevují migrace a proměny vzorů?

Vezměme si za příklad vzor Asynchronous Completion Token (ACT) popsaný v knize Patterns Oriented Software Architecture (autor Frank Buschmann a kolektiv). Tento vzor popisuje, jak dosáhneme efektivního a na zdroje počítače nenáročného zpracování odpovědí z více asynchronních požadavků. ACT je objekt (v obecném slova smyslu), který unikátně identifikuje každý asynchronní požadavek a slouží k výběru správného zpracovatele odpovědí. Participanti vzory jsou tři - iniciátor asynchronního požadavku, služba, která je volána a ACT pro korelaci požadavků a odpovědí.

V .NET je ACT vzor transformován do speciálního vzoru pro asynchronní volání, kdy je zavedena formální konvence, že asynchronní metody jsou prefixovány slovy Begin (začátek požadavku) a End (Konec požadavku), Každý delegát nabízí metody Begin a End, jejichž posledním parametrem je zase dle konvence jakýkoli objekt, který pak v systému hraje roli ACT. ACT neslouží ale k výběru primárního zpracovatele asynchronní odpovědi, protože ten je na začátku asynchronního volání determinován předposledním parametrem, jímž je delegát AsyncCallBack ukazující na metodu s kompatibilní signaturou. Předaný ACT ale může být klíčem k dynamickému určení sekundárního zpracovatele a/nebo je objektem pro přenos stavových informací.

.Net si tedy ACT vzor přizpůsobil k obrazu svému a vybral si jen některé jeho myšlenky.

ACT se také uplatňuje v SOA - v architektuře založené na službách, které si mezi sebou asynchronně vyměňují tisíce zpráv denně, potřebujeme prostředek pro korelaci zpráv-požadavků a návazných zpráv-odpovědí. V SOA je uplatňován návrhový vzor s názvem Correlation Identifier - v hlavičce zprávy je uložen jednoznačný identifikátor požadavku, který je v hlavičce odpovědi zaslán zpět odesílateli. Jsme v SOA a stále pracujeme se starým dobrým ACT vzorem, jen místo delegátů mluvíme o zprávách, dokumentech a hlavičkách s ACT informací.

Vzor Correlation identifier (a ACT) je dále rozpracováván ve specifikacích pro jednotlivé technologie. Když budeme mít SOA založenou na webových službách, setkáme se s normovaným ACT ve standardu ws:addressing, kde je stanovena a přijata konvence, že ACT musí odesílatel poslat v hlavičce nazvané MessageId a kdy je vyžadováno, aby hlavičku uvedl, a odesílatel je povinen hodnotu z MessageId poslat v hlavičce odpovědi s názvem RelatesTo.

Až skončí éra SOA, webových služeb, .Net Frameworku a přijde jiná, úžasnější, oslnivější a zase skoro dokonalá technologie, na které se bude hlavně dobře vydělávat,;) nepřežijí dílčí implementace ACT v těchto prostředích, ale můžeme si být skoro jisti, že vzor ACT jako bájný Fénix vstane omlazený z popela, změní svůj vnější vzhled, aby byl "in", ale jeho podstata zůstane beze změny, dokud budou existovat asynchronní volání.

Již dlouhou dobu se mluví o tom, že business frameworky a komponenty se stanou standardem při vývoji aplikací, již tradičně zlevní a zjednoduší jejich tvorbu (někteří cynici si myslí, že se jedná jen o další etapu v procesu geneze nového druhu cvičené opice z programátora ;)) a budou stejně populární jako vizuální komponenty v uživatelském rozhraní. Zatím se tak nestalo, ale zajímalo by mě, o jaké komponenty byste měli zájem. Všechny komponenty by byly samozřejmě doplněny o komplexní podporu v IDE (VS.NET, Eclipse atd.), byly by dodávány s průvodci pro nejběžnější úlohy a kvalitní dokumentací - jinými slovy, šlo by o komponenty s veškerým servisem, který znáte z UI komponent.

Protože v .TEXTu neudělám anketu:(, odpovídejte prosím v komentářích.

1) Komponenta pro generování kódu vrstvy pro přístup do databáze zvládající různé způsoby mapování objektů a jejich vztahů (agregace , asociace, dědičnost...). Pozor, nejedná se o netypový mapper, jakými měly být ve VS.NET Whidbey třeba Object Spaces, ale o "inteligentní" generátor typových metod databázové vrstvy, metod pro nahrání a uložení business objektů, storovaných procedur a DDL skriptů.

2) Komponenta pro kompletní evidenci historie business objektů. Logování změn všech nebo vybraných atributů objektu, volba mezi mělkou nebo hlubokou historií objektů, zapnutí podpory historie u třídy jedním konfiguračním klíčem i po nasazení projektu, výběr mezi mnoha formáty pro ukládání historie.

3) Komponenta pro vizuální definici jakéhokoli workflow nad objekty - generování kódu pro přechody mezi stavy, vizuální definice podmínek přechodu, komunikace mezi různými stavovými automaty, validace workflow, změna průběhu workflow by byla řešena za běhu aplikace výměnou jednoho definičního souboru.

4) Jiná komponenta. Napište prosím, jakou komponentu byste potřebovali.

Díky za odpovědi.