Při zavádění OOP a UML ve firmách se při konzultacích často setkávám s těmito otázkami: Jaké všechny znalosti potřebuje vývojový pracovník k tomu, aby efektivně zvládal moderní technologie tvorby SW v objektově orientovaném prostředí? Stačí znát pouze základy OOP a syntaxi daného objektového programovacího jazyka anebo něco navíc? A pokud ano, tak co všechno je třeba znát? Zajímavé je, že se neptají pouze vývojoví pracovníci pro potřeby svého vlastního samostudia, ale stále častěji se takto dotazují vedoucí pracovníci SW firem resp. pracovníci metodických oddělení těchto firem. Jaké je tedy minimum onoho známého vývojářského "skills" v objektových technologiích?

Pokud zjistíme, že máme nějakou mezeru ve vzdělání, kterou bychom měli rychle zacelit, buďme nad tímto zjištěním potěšeni a nebuďme rozčarováni. Platí totiž stará osvědčená pravda, že nejhorší situace při vzdělávání nastane tehdy, když ani nevíme, co vlastně nevíme .

Podobně je tomu i při zvládání OOP. Velmi často se při konzultacích ve firmách anebo na školeních setkávám s otázkou: "Jaké znalosti bych si měl doplnit, abych dobře zvládal problematiku objektově orientovaného programování?" A hned na to následuje další dotaz: "A jak si mohu tyto znalosti doplnit a odkud?" Pokusím se na tyto otázky odpovědět, přičemž budu vycházet z několikaleté praxe zavádění OOP a objektového modelování ve firmách.

Jedním z důležitých faktorů je pozice, kterou vývojový pracovník zastává. Soustředíme se na tyto základní role pracovníků v projektu:

• analytik
• designér
• programátor
• vedoucí projektu

Pokud pominu další fáze vývoje a tvorby SW (testování, nasazení, servis atd.), lze tyto role považovat za "nejzákladnější minimum" pro tvorbu SW (viz například ekniha "Základy řízení..." na serveru http://www.objects.cz). I když každá z těchto rolí je svým způsobem specifická, přesto všichni tito účastníci projektu by měli mít některé znalosti společné. Samozřejmě každá z těchto rolí vyniká ještě svými znalostmi specifickými. O nich se zmíním na konci tohoto článku.

Vyjmenujme si, co by tito pracovníci měli v každém případě ovládat:

Znalost 1: Velmi dobré zvládnutí objektově orientovaného přístupu a objektového myšlení

Osvědčuje se, aby všichni jmenovaní pracovníci (včetně vedoucího projektu!) byli velmi dobře obeznámeni se základními principy OOP. Bez této znalosti se nemohou pracovníci plnohodnotně podílet na týmové práci v projektu. Pokud je totiž některý z nich takříkajíc "mimo", vnáší do projektu cizí a chaotické prvky strukturálního myšlení. To se týká i vedoucích pracovníků projektů, kteří většinou sklouznou pouze do role manažerů a opominou tuto část vzdělání. Přece jen není na škodu, aby v případě, když se dva vývojoví pracovníci v týmu (znalí OOP) přou a hádají nad řešením, vedoucí projektu alespoň věděl, o čem je reč.

Nikdo po vedoucím projektu nechce, aby objektově tvořil, ale je žádoucí a dostatečné, pokud by objektům aspoň rozuměl a chápal myšlenky předložené od tvůrců systému (od analytika, resp. designéra).

Základy OOP jsou například podány v knihách "Základy OOP" (internetové knihkupectví Vltava), "Objektové modelování v praxi 2000". Vysvětlení OOP je také nedílnou součástí intenzivního 5-denního (resp. 3-denního) školení "OOP + UML + komponentní technologie" buď pobytového anebo in-house (viz http://www.objects.cz ).

Znalost 2: Objektové modelování a UML

Modelování systému (v UML) patří již k neodmyslitelné části tvorby SW. Modelování se prolíná všemi fázemi vývoje SW (úrovněmi abstrakce) od analýzy (resp. od fáze strategického modelování), přes design až po nasazení. V moderním pojetí se tvorba modelů IS nechápe jako vedlejší produkty tvorby IS, ale tvorba modelu je považována přímo za součást tvorby tohoto systému. Jinak řečeno, hotový systém není pouhou snůšku zdrojového kódu, ale chápe se jako celý komplex viděný ve všech svých modelech (včetně výsledného kódu). Vyplývá z toho jednoduchý fakt: Co se týká tvorby informačních systémů, neznalost modelování (týká se i vedoucího projektu) hraničí s analfabetismem...

Základy modelování a UML jsou například podány v knize "Objektové modelování v praxi 2000" (nyní se slevou ve výprodeji, viz http://www.objects.cz ), je také nedílnou součástí zmíněného intenzivního školení "OOP + UML + komponenntí technologie" buď pobytového anebo in-house (http://www.objects.cz ).

Znalost 3: Základní principy postupů tvorby systémů v objektově orientovaném prostředí

Patří sem znalosti: Abstraktní úrovně systému, vrstvení systému, pravidla správné architektury systému, komponentní technologie, postupy tvorby systému metodou I+I, atd.

Tyto znalosti jsou většinou opojímeny, přitom bývají velmi často pro vývoj systému kritické. Neznalosti v této oblasti mohou zavést tvorbu zejména rozsáhlejších systémů takříkajíc až ke krachu anebo do velkých problémů. Nedodržením určitých obecně známých pravidel se ze systému stává nepřehledný, netransparentní, nedělitelný a nezdokumentovaný obrovský "moloch".

Nedodržení pravidel tvorby systému podle úrovní abstrakce (minimálně modely analýzy a designu, potom kód) vede k zásadním chybám v projektu. Navíc výsledkem takového chybného postupu je jediná "dokumentace" systému ve tvaru zdrojového kódu. Velmi těžko se takovýto systém kontroluje (například uživatelem), testuje (tester neví, co má systém umět), těžko se tvoří další nutná dokumentace (například uživatelská), těžko se mění technologie při zachování funkcionalit apod.

Nedodržení pravidel pro vrstvení systému způsobují ve vývoji, testování, správě a údržbě takového systému neskonalé problémy, protože každá část systému je vždy "součástí" jiné části systému. Někdy dokonce ani nelze určit, od které části systému je třeba zahájit testování při nalezení chyby (díky circular dependency apod.). Při nesprávných postupech návrhu vrstev anebo při chybějícím návrhu vrstev se vedoucímu projektu velmi špatně řídí práce. Neustále se "skáče" z jedné části systému do druhé (...protože aby chodilo toto, musí chodit toto atd. ...a bohužel chodíme do kruhu). Nelze zavést efektivní způsob vývoje metodou I + I (iterativní a inkrementální způsob vývoje), přičemž tato metoda je právě u větších systémů velmi žádoucí.

Znalosti a zkušenosti shrnuté do vět: "Jak se máme na systém dívat z hlediska abstraktních úrovní (minimálně analýza, design, kód)" a na straně jedné a na straně druhé: "Jak se na systém dívat hlediska vrstev (svazků, package)" musejí mít všichni účastníci projektu, jak analytik, designér, programátor, tak i vedoucí projektu. Analytik navrhuje svazky (package) na logické úrovni. Designér navrhuje na základě těchto svazků komponenty na implementační úrovni. Programátor je realizuje v kódu. Vedoucí projektu na základě rozložení do svazků efektivně řídí projekt za použití metody I + I. Paradoxně největší "tíha a odpovědnost" za to, aby tento postup byl v projektu dodržen, je na vedoucím projektu. On sám sice svazky (package) nenavrhuje ani na jedné z úrovní, ale jako vedoucí projektu je velmi obezřetný, aby vrstvení systému do package na všech úrovních abstrakce bylo provedeno pokud možno co nejlépe. Pokud totiž tento postup dodržen není a vznikne zmíněný netransparentní "moloch", pocítí to na své kůži nejvíce právě on při řízení dalších vývojových prací na projektu. Mohu z vlastní zkušenosti vedoucího projektu potvrdit, že řízení projektu bez dodržení těchto pravidel a řízení projektu při jejich dodržení jsou lidově řečeno "nebe a dudy".

Pro získání znalostí v této oblasti doporučuji zejména studium odpovídající normy ISO pro tvorbu a vývoj SW (nedejte se zmást tím, že je to norma, jedná se o velmi kvalitní dokument), eknihu "Zásady řízení...", eknihu "Objektové modelování v praxi 2000", příručky postupů prací k jednotlivým CASE nástrojům (Enterprise Architect apod.). Důkladné seznámení se s touto problemetikou je také součástí již zmíněného školení "OOP + UML + komponentní technologie".

Znalost 4: Design Patterns (návrhové vzory) v OOP

Další velmi opomíjenou a přitom nezbytnou součástí vzdělání každého vývojáře v OOP je oblast zvaná Design Patterns. Mohu potvrdit, že teprve až po prostudování této oblasti jsem mohl zodpovědně prohlásit, že jsem se seznámil s OOP jako takovým. Přitom někteří vývojáři ani nevědí, že tato oblast existuje!

Návrhové vzory (Design Patterns) zavádějí obecná řešení stejných situací v OOP. Uveďme klasické příklady problémů, které se pomocí vzorů řeší:

• Jak se získá flexibilita řešení v OOP,
• Jak se získá znovupoužitelnost řešení v OOP,
• Jak se zbavit nepříjemného efektu "namnožení tříd" při tvorbě stromů dědičnosti,
• Jak se zbavit složitosti formulářů a maximálně je zprůhlednit,
• Jak vytvořit "Undo efekt" s návratem objektů k původnímu stavu ve vaší aplikaci,
• Jak vyřešit situaci, kdy je třeba poslat požadavek objektu aniž bychom dopředu znali konkrétní operaci, která má být vyvolána (dynamické menu apod.)
• Jak vytvořit funkcionalitu u množiny objektů, které musí reagovat na změnu stavu jiného objektu,
• Jak flexibilně rozšířit funkcionalitu třídy a přitom nezasahovat do jejího kódu,
• Jak zvolit třídu na základě dat, například obsluha vybere v menu položku a vy musíte vytvořit podle toho objekt z dané třídy,
• Jak zabezpečit, aby z dané třídy vznikl pouze jeden a sdílený objekt (například spooler tiskárny, datový objekt, konekt apod.),
• Jak zavést kompatibilitu mezi dvěma jinak nekompatibilními interfacy,
• Jak zvýšit flexibilitu třídy pomocí dynamicky přilinkovaných objektů jako alternativní řešení k dědičnosti,
• Jak zabezpečit, aby libovolný objekt z dané rodiny "uměl" danou funkcionalitu na daný dotaz, tj. klient se může dotázat libovolného z těchto objektlů a dostane správnou a relevantní odpověď (například dotaz v helpu apod.),
• Jak ukládat objekty do relační databáze,
• a další...

Pro neznalého je pojem návrhový vzor natolik cizí, že si ani neumí představit jeho význam. Myslím, že nejlepší vysvětlení podá literatura zdarma na našem serveru "DESIGN PATTERNS V OOP".

Po přečtení předešlého vzoru v odkazu se určitě shodneme v názoru, který se mi osobně potvrdil, že studium vzorů je dobré i z důvodů pedagogických při pronikání do tajů OOP. Nabízená řešení totiž velmi pěkně ukazují úvahy a postupy zkušených tvůrců v OOP. Proto studium vzorů vřele doporučuji (i vedoucím projektů) a to i v případě, že už nikdy nenarazíte ani na jeden problém vzorů k řešení.

Ke studiu Design Patterns doporučuji jednak knihu čtyř autorů : "Design Patterns" (ISBN 0-201-63361-2) anebo skripta na našem serveru. Pořádáme také cenově přijatelné dvoudenní školení "Známá řešení v OOP - Desing Patterns" pod vedením RNDr. Ilji Kravala, autora knih "Základy OOP", "Základy komponentní technologie COM", "Objektové modelování v praxi 2000" a dalších. Přihlásit se mohou i úplní začátečníci v OOP, ale i zkušenější, blíže viz zde

Kromě uvedených znalostí je třeba, aby každý pracovník ve své roli navíc ovládal také "něco specifického pro svou roli". Tedy kromě již uvedených znalostí by každý pracovník navíc měl velmi dobře znát a ovládat:

Vedoucí projektu

• pasivní znalost UML
• principy řízení projektů, metoda I+I apod.
• základní ekonomické znalosti pro odhady nákladů apod.
• řídící, rozhodovací a komunikativní schopnosti navenek projektu (poznámka: spoustě klasických vývojářů SW tyto schopnosti jednání chybí, jsou tzv. introvertní)

Analytik

• zvýšená znalost UML oproti ostatním rolím do (takřka) všech detailů
• abstaktní a kreativní myšlení, představivost (systém "vidí" v abstrakci před sebou)
• schopnost rychle a přesně formulovat myšlenky a zapsat je do modelů
• schopnost komunikace s uživatelem nad systémem (a z toho plynoucí další bod:)
• zvýšené nároky na schopnost asertivního jednání (schopnost dotlačit uživatele ke správnému řešení pokud možno bez kolizí)

Designér

poznámka: existují specialisté na jednotlivé oblasti, zde jsou srhnuty do jedné role designéra

• pasivní znalost UML
• databázová teorie, návrh ERD
• vlastnosti používané databáze (administrace apod.)
• principy návrhu GUI daného prostředí
• znalsot vývojového prostředí
• problematika bezpečnosti daného prostředí
• operační systém
• sítě
• HW pro návrh nasazení SW

Programátor

• pasivní znalost UML
• vývojové prostředí a syntaxe daného jazyka (např. Java, C# apod.)
• znalosti syntaxe spolupráce s danou databází (např. SQL syntaxe apod.)
• základní znalosti designéra (nikoliv detailní)

V uvedených oblastech, které navazují na před tím uvedené "společné" znalosti, by jednotliví pracovníci měli být vyhlášenými specialisty, tak zvanými "guru". V mnoha případech "pendlují" pracovníci v rolích designér - programátor.

Roli analytika doporučuji zachovat úplně oddělenu, protože nutnost předávky analytických modelů designérovi tímto zapebezpečí existenci dokumentů analýzy.