Pokud jde o dobrý design OO, je to jednoduché

Bývalý můj student kdysi vyhnal absurdní prohlášení: „Nemohu udělat objektově orientovaný (OO) design; nemám peníze!“ Při dalším dotazování se ukázalo, že podle jeho názoru design OO vyžadoval produkt s názvem Rational Rose, který v té době stál asi 500,00 za sedadlo. V jeho mysli bez Rational Rose nebyl design možný. Bohužel je tento druh balderdash rozšířený; příliš mnoho lidí si myslí, že OO je high-tech proces vyžadující high-tech nástroje. V praxi nástroje za přemrštěné ceny sedí nepoužívané na polici (nebo jsou značně nedostatečně využívány).

S ohledem na to v tomto článku pojednávám o různých OO designových nástrojích, o tom, jak fungují, a proč si myslím, že nejsou užitečné. Vysvětlím také, jak pracuji a co se ukázalo jako užitečné (alespoň pro mě; můžete nesouhlasit).

Tyto nástroje vás procesem neprovedou

Každý úspěšný design OO, který jsem přišel, následoval zhruba stejným procesem:

Další informace o problémová doména (účetnictví, plánování lekcí atd.)
V úzké spolupráci se živým uživatelem vyvinout, a problémové prohlášení který vyčerpávajícím způsobem popisuje problém uživatele i všechna řešení na úrovni domény. Tento dokument nepopisuje počítačový program.
Proveďte formální analýza případu použití, ve kterém určuji úkoly potřebné k vyřešení problému uživatele, opět úzce spolupracuji se skutečným koncovým uživatelem. Obvykle vytvářím UML (Unified Modeling Language) diagram činnosti pro každý netriviální případ použití. (UML je symbolické znázornění softwaru jako obrázku.)
Začněte stavět dynamický model zobrazující objekty v systému a zprávy, které tyto objekty posílají jeden druhému, zatímco probíhá konkrétní případ použití. Používám UML sekvenční diagram pro tento účel.
Současně zaznamenávám užitečné informace na statický model diagram. Poznámka: Nikdy nejdříve nedělám statický model (diagram tříd). Jakmile jsem začal dělat dynamický model, vyhodil jsem příliš mnoho statických modelů, které se ukázaly jako zbytečné. Už nejsem ochoten ztrácet čas potřebný k provedení statického modelu ve vakuu.
Výše uvedené kroky obvykle přinášejí dva nebo tři případy použití, po kterých začnu kódovat a v případě potřeby model opravím.
Nakonec pracuji na jiném popsaném případu použití, který podle potřeby refaktoruje design a kód, aby vyhověl novému případu.

Tímto procesem vás neprovede žádný z dnešních návrhových nástrojů. Většinou jsou to kreslicí programy za příliš vysokou cenu, které nefungují zvlášť dobře, dokonce ani jako kreslicí nástroje. (Rational Rose, kterou považuji za jednu z nejméně schopných šarže, dokonce nepodporuje všechny UML.)

Round-trip engineering je zásadně chybný proces

Nejen, že tyto nástroje nefungují dobře, ale trik, který tyto nástroje provádějí - generování kódu - je bezcenný. Téměř všechny návrhové nástroje OO se řídí pojmem zpáteční inženýrství ve kterém začnete v návrhovém nástroji zadáním svého návrhu v UML. Vytvoříte dvě základní sady diagramů: statický model zobrazující třídy v návrhu, jejich vzájemné vztahy a metody, které obsahují; a dynamický model, což je hromada diagramů, které zobrazují objekty v systému provádějící různé úkoly za běhu.

Jakmile dokončíte model, stisknete kouzelné tlačítko a nástroj vygeneruje kód. Kód vygenerovaný nástrojem však není zvlášť dobrý ze dvou důvodů: Za prvé, v mnoha nástrojích jsou vytvořeny kostry pro definice tříd, ale metody jsou jednoduše prázdné útržky - dynamický model je ignorován. Zadruhé, žádný nástroj plně nepodporuje UML, hlavně proto, že žádný nemůže. UML je jazyk sám o sobě, který podporuje improvizaci a velká část skutečného obsahu návrhu je vyjádřena v komentářích, které návrhový nástroj obvykle ignoruje.

Ve výsledku hacknete vygenerovaný kód (většina obchodů ho skutečně hackne). Během několika týdnů má kód obvykle málo nebo nemá nic společného s původním designem. Ve skutečnosti efektivně zahodíte svůj design a upadnete zpět do syndromu WHISKEY (Proč ještě někdo „nekóduje“?). Roky a roky neúspěšných programů mi dokazují, že kódování bez návrhu prodlužuje celkovou dobu vývoje alespoň o faktor tři a vede k mnohem chybnějšímu kódu.

Nyní přichází proces zpáteční cesty: Otevřete svůj nástroj, stiskněte kouzelné tlačítko a importujte kód, teoreticky znovu sestavte design tak, aby odrážel skutečný stav kódu. Takové reverzní inženýrství však nefunguje. Nástroje obvykle vytvářejí nové diagramy tříd, ale nikdy neaktualizují dynamický model. Jelikož je dynamický model ústředním bodem procesu, váš návrh je nyní bezcenný, pokud se nevrátíte zpět a ručně ho neaktualizujete, což se zřídka děje.

S rizikem opakování se proces zpáteční cesty vybízí programátory, aby úplně ignorovali design a jen kódovali, a pak kód tak často zpětně analyzovali do obrázků. V této situaci však programátoři nenavrhují; hackují kód a vytvářejí obrázky výsledného nepořádku. Hackování se nerovná designu.

Zatímco design je skutečně iterační proces (design se mění s vývojem kódu), měli byste zahájit iteraci nejprve úpravou designu a následným refaktorováním kódu tak, aby odrážel nový design. Chcete-li to provést, musíte být schopni specifikovat celý softwarový produkt v nástroji (po stisknutí magického tlačítka by se vytvořil plně funkční program) a proces by byl jednosměrný bez reverzního inženýrství mechanismus.

Nástroje CASE

Nástroje CASE (počítačově podporované softwarové inženýrství), jako je Rational Rose, obvykle kladou na jádro produktu zpáteční inženýrství. Jelikož však zpáteční inženýrství nedělá nic užitečného, mnoho vývojářů používá nástroje jako drahé kreslicí programy. Z dostupných nástrojů si myslím, že stojí za zvážení tři (i když žádný z nich nepoužívám):

Bezplatný nástroj ArgoUML s otevřeným zdrojovým kódem, napsaný v Javě, zvládá diagramy UML poměrně dobře. Nejnovější verze se vás dokonce pokusí provést celým procesem (zatím s okrajovým úspěchem, ale je to dobrý začátek).
Embarcadero GDPro, dříve distribuované Advanced Software, nabízí dobrou podporu pro skupinu pracující na jediném softwarovém designu, ale má také nedostatky v tomto oddělení. Návrhář například nemůže rezervovat dynamický modelový diagram, když automaticky uzamkne třídy přidružené k objektům na dynamickém modelu.
Společně ControlCenter společnosti TogetherSoft obchází problém zpětného chodu tím, že to nedělá. Kód a design se objeví na obrazovce současně, a když jeden změníte, druhý se změní automaticky. Společně ControlCenter nepodporuje skupiny programátorů dobře.
Krátce bych měl zmínit také Visio společnosti Microsoft. Visio je kreslící program, který po módě podporuje UML, ale jeho podpora napodobuje mizerné uživatelské rozhraní Rational Rose. Různé šablony kreslení pro tvary UML ve Visiu fungují lépe než integrovaná podpora UML, včetně jedné v sekci „Goodies“ na mém webu.

Pokud tedy o těchto nástrojích uvažuji tak špatně, co použiji? Zdaleka nejproduktivnějšími nástroji OO-design jsou tabule (místnost s tabulemi od stěny ke zdi, od podlahy ke stropu) a podložky Post-it o velikosti flipchartu, jejichž listy můžete odlepit a držet na zdi. Použil jsem je k navrhování významných projektů s velkým úspěchem. Práce na tabuli navíc spotřebuje mnohem méně času než zápas s nástrojem OO CASE.

Jedinou potíž s přístupem k tabuli je zachytit informace na tabuli. Tabule, které tisknou, sice existují, ale jsou drahé, nemotorné a příliš malé. Jeden elegantní hardwarový produkt, který sleduje pohyb pera přes tabuli a zachycuje tahy pera v počítači. Ostatní tabule fungují jako obří tablety digitalizátoru. Tato řešení se však ukazují jako příliš omezující; design probíhá současně na tabulích v několika kancelářích, na ubrouscích, na útržcích papíru atd. Do místní kavárny nemůžete nést tiskovou tabuli o hmotnosti 300 liber.

Co tedy funguje

Co tedy má matka dělat? Jak tyto artefakty zachytíte, abyste je archivovali v počítači, takže budou po celou dobu vytvářet rozumnou dokumentaci, aniž byste je museli přenášet do kreslícího programu?

Řešení:

Digitální fotoaparát
Skvělý softwarový produkt s názvem Whiteboard Photo od Pixidu

Digitální fotografie bohužel často vytváří obrázky, které nejsou pro dokumentaci uspokojivé. Aby to kompenzovala, aplikace Whiteboard Photo přemění digitální obrázky na něco užitečného. Fotografie tady opravdu stojí za tisíc slov. Obrázek 1 ukazuje typickou digitální fotografii tabule.

Obrázek 2 ilustruje další příklad.

Obrázek 3 ukazuje, jak aplikace Whiteboard Photo transformuje obrázek 1.

A tady je obrázek 2, jak Whiteboard Photo provedla své kouzlo.

Jak ukazují obrázky, rozdíl je úžasný. Chcete-li převést původní obrázek na vyčištěnou verzi, jednoduše jsem zasáhl Ctrl-L. Software automaticky našel hranice tabule, opravil zkreslení způsobené pořízením obrázku z úhlu (nutné, aby se zabránilo oslnění bleskem), vybral čáry designu a nakreslil je. Všechno, co produkt potřebuje k dosažení dokonalosti, je rozpoznávání ručního psaní, ale ve stavu, v jakém jsem, jsem s ním lechtal růžově. Nyní mohu vytvářet výkresy v kvalitě dokumentace přímo z původní tabule, aniž bych ztrácel hodiny zadáváním výkresu do nějaké chromé výmluvy pro nástroj CASE.

Snažte se o to

Podle mých zkušeností, pokud jde o OO design, low-tech nástroje fungují nejlépe. Ve skutečnosti jsou rychlejší, snáze použitelné a fungují dobře v prostředích pro spolupráci. Zatím jsem zjistil, že kombinace tabule, digitálního fotoaparátu a Whiteboard Photo nabízí nejlepší způsob, jak dostat návrhy programů do stroje.

Allen Holub poskytuje poradenské služby, školení a školení v oblasti OO designu, OO procesu a programování v Javě. Pravidelně představuje intenzivní OO design workshop pro zájemce o rychlý rozvoj jejich OO dovedností. (Více informací naleznete na //www.holub.com.) Allen pracuje v počítačovém průmyslu od roku 1979, naposledy jako technologický ředitel společnosti NetReliance, Inc. Je široce publikován v časopisech (Dr. Dobb's Journal, Programmers Journal, Byte a MSJ, mimo jiné). Allen má na svém kontě osm knih, z nichž nejnovější - Zkrocení Java Threads (APpress, 2000; ISBN: 1893115100) - pokrývá pasti a úskalí Java threadingu. Vyučuje design OO a Java pro University of California, Berkeley Extension (od roku 1982).

Další informace o tomto tématu

Zdarma bezplatný návrhový nástroj ArgoUML s otevřeným zdrojovým kódem přejděte na
//argouml.tigris.org/
Embarcadero GDPro lze nalézt na
//www.embarcadero.com
Více informací najdete na Společné ControlCenter Společnosti Společnosti na
//www.togethersoft.com
Domovská stránka Microsoft Visio
//www.microsoft.com/office/visio/default.htm
Další informace o tomto zajímavém nástroji najdete na stránce produktu Pixid Whiteboard Photo
//www.pixid.com/home.html
Web Allena Holuba obsahuje jeho stránku „Goodies“, kde najdete tipy na design OO, pravidla programování a poznámky z některých Allenových přednášek
//www.holub.com/goodies/goodies.html
JavaWorldje Objektově orientovaný design a programování Rejstřík obsahuje řadu článků zabývajících se designem
//www.javaworld.com/channel_content/jw-oop-index.shtml
Více skvělých recenzí produktů najdete v JavaWorldje Rejstřík recenzí produktů
//www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml
Přečtěte si více komentářů v JavaWorldje Rejstřík komentářů
//www.javaworld.com/news-reviews/jw-nr-commentary.shtml
Chcete-li získat tipy a výukové programy týkající se návrhových vzorů, vývojových nástrojů, ladění výkonu, zabezpečení, testování a dalších, přihlaste se k odběru Aplikovaná Java zpravodaj
//www.javaworld.com/subscribe
Mluvte v našem Teorie a praxe programování diskuse
//forums.idg.net/webx?50@@.ee6b806
Spoustu článků o IT z našich sesterských publikací najdete na .net