Ko gre za dober dizajn OO, naj bo preprost

Nekdanji moj študent je nekoč izmuznil nesmiselno izjavo: "Ne morem narediti objektno usmerjenega (OO) oblikovanja; nimam denarja!" Po nadaljnjem poizvedovanju se je izkazalo, da je po njegovem mnenju projekt OO zahteval izdelek, imenovan Rational Rose, ki je takrat stal približno 500,00 na sedež. Po njegovem mnenju oblikovanje brez Rational Rose ni bilo mogoče. Na žalost je takšen balderdash zelo razširjen; preveč ljudi misli, da je OO visokotehnološki postopek, ki zahteva visokotehnološka orodja. V praksi orodja z izjemno visoko ceno sedijo neuporabljena na polici (ali pa so zelo premalo uporabljena).

S tem v mislih v tem članku razpravljam o različnih orodjih za oblikovanje OO, kako delujejo in zakaj menim, da niso uporabna. Razložim tudi, kako delam, in kaj se mi izkaže za koristno (vsaj zame; z vami se ne strinjate).

Orodja vas ne vodijo skozi postopek

Vsak uspešen dizajn OO, ki sem ga zasnoval, je sledil približno istemu postopku:

Spoznajte domeno problema (računovodstvo, načrtovanje pouka itd.)
V tesnem posvetovanju z uporabnikom v živo razvijte a izjava o težavi ki izčrpno opisuje uporabnikov problem in vse rešitve na ravni domene. Ta dokument ne opisuje računalniškega programa.
Opravite formalno analiza primerov uporabe, v katerem določim naloge, potrebne za reševanje uporabnikove težave, spet v tesnem sodelovanju s pravim končnim uporabnikom. Običajno ustvarim UML (Unified Modeling Language) diagram aktivnosti za vsak netrivialni primer uporabe. (UML je simbolična predstavitev programske opreme v obliki slike.)
Začnite graditi dinamični model prikaz predmetov v sistemu in sporočil, ki si jih ti predmeti medsebojno pošiljajo, medtem ko se igra poseben primer uporabe. Uporabljam UML diagram zaporedja Za ta namen.
Hkrati zaberem koristne informacije na statični model diagram. Opomba: Nikoli ne delam statičnega modela (diagrama razredov). Zavrgel sem preveč statičnih modelov, ki so se izkazali za neuporabne, ko sem začel delati dinamični model. Nisem več pripravljen zapravljati časa, potrebnega za izdelavo statičnega modela v vakuumu.
Zgoraj omenjeni koraki običajno prinesejo dva ali tri primere uporabe, nakar začnem s kodiranjem in po potrebi popravljam model.
Nazadnje delam na drugem primeru uporabe, kot je opisano, refaktoriziram dizajn in kodo, kot je potrebno, da se prilagodi novemu primeru.

Nobeno od današnjih orodij za oblikovanje vas ne vodi skozi ta postopek. Večinoma gre za predrage programe za risanje, ki ne delujejo posebej dobro, niti kot orodja za risanje. (Racionalna vrtnica, za katero menim, da je ena najmanj sposobnih, sploh ne podpira celotnega UML.)

Povratni inženiring je v osnovi napačen postopek

Ta orodja ne samo, da ne delujejo dobro, en trik, ki ga ta orodja izvajajo - ustvarjanje kode - je brez vrednosti. Skoraj vsa orodja za oblikovanje OO sledijo pojmu povratni inženiring v katerem začnete z orodjem za oblikovanje tako, da v UML navedete svoj dizajn. Ustvarite dva bistvena sklopa diagramov: statični model, ki prikazuje razrede v zasnovi, njihove medsebojne odnose in metode, ki jih vsebujejo; in dinamični model, ki je sveženj diagramov, ki prikazujejo predmete v sistemu, ki med izvajanjem izvajajo različne naloge.

Ko dokončate model, pritisnete čarobni gumb in orodje ustvari kodo. Vendar orodno ustvarjena koda ni posebej dobra iz dveh razlogov: Prvič, v mnogih orodjih se ustvarijo okostja za definicije razredov, vendar so metode preprosto prazne škrbine - dinamični model se prezre. Drugič, nobeno orodje v celoti ne podpira UML, predvsem zato, ker nobeno ne more. UML je samostojen jezik, ki spodbuja improvizacijo, večina dejanske vsebine oblikovanja pa je izražena v komentarjih, ki jih orodje za oblikovanje običajno prezre.

Kot rezultat, vdrete v ustvarjeno kodo (večina trgovin jo resnično vdre). V nekaj tednih ima koda običajno le malo ali nič skupnega z izvirnim dizajnom. Pravzaprav dejansko zavržete svoj dizajn in spet padete v sindrom WHISKEY (Zakaj nekdo še ne "kodira?"). Leta in leta neuspešnih programov mi dokazujejo, da kodiranje brez zasnove poveča celoten razvojni čas vsaj za trikrat in povzroči veliko večjo kodo.

Zdaj sledi postopek povratnega potovanja: odprete orodje, pritisnete čarobni gumb in uvozite kodo ter teoretično obnovite zasnovo tako, da odraža dejansko stanje kode. Tak obratni inženiring pa ne deluje. Orodja običajno ustvarijo nove diagrame razredov, vendar dinamičnega modela nikoli ne posodobijo. Ker je dinamični model osrednjega pomena za postopek, je vaš dizajn zdaj brez vrednosti, razen če se vrnete in ga ročno posodobite, kar se le redko naredi.

V nevarnosti, da se ponovim, postopek povratnega potovanja spodbuja programerje, da popolnoma ignorirajo zasnovo in samo kodirajo, nato pa vsake toliko kode spremenijo v slike. V tej situaciji pa programerji ne načrtujejo; vdirajo v kodo, nato pa ustvarijo slike nastalega nereda. Vdiranje ni enako oblikovanju.

Čeprav je načrtovanje v resnici ponavljajoč se postopek (načrt se spreminja, ko se koda razvija), morate iteracijo začeti tako, da najprej spremenite zasnovo, nato pa refaktorizirate kodo, da odraža novo zasnovo. Če želite to narediti, bi morali imeti možnost, da v orodju določite celoten programski izdelek (ko pritisnete čarobni gumb, se izpiše popolnoma funkcionalen program) in postopek bi bil enosmeren brez povratnega inženiringa mehanizem.

Orodja CASE

Orodja CASE (računalniško podprto programsko inženirstvo), kot je Rational Rose, običajno postavljajo jedro izdelka v središče. Ker pa inženirstvo povratnega potovanja ne naredi nič koristnega, mnogi razvijalci orodja uporabljajo kot drage programe za risanje. Menim, da je med razpoložljivimi orodji vredno razmisliti o treh (čeprav nobenega ne uporabljam):

Brezplačno odprtokodno orodje ArgoUML, napisano v Javi, razmeroma dobro opravi diagramiranje UML. Najnovejša različica vas celo poskuša voditi skozi postopek (zaenkrat še vedno z malo uspeha, vendar je dober začetek).
Embarcaderov GDPro, ki ga je prej distribuirala Advanced Software, ponuja dobro podporo skupini, ki se ukvarja z enim samim oblikovanjem programske opreme, vendar ima v tem oddelku tudi pomanjkljivosti. Na primer, oblikovalec ne more preveriti diagrama dinamičnega modela, medtem ko samodejno zaklene razrede, povezane z objekti v dinamičnem modelu.
Skupaj nadzorni center TogetherSoft zaobide problem vzvratne vožnje tako, da tega ne stori. Koda in oblika se na zaslonu prikažeta hkrati, ko spremenite eno, se druga samodejno spremeni. Vseeno ControlCenter ne podpira dobro programerjev.
Na kratko naj omenim tudi Microsoftov Visio. Visio je program za risanje, ki podpira modul UML po modi, vendar njegova podpora posnema nesrečen uporabniški vmesnik Rational Rose. Različne predloge za risanje oblik UML v programu Visio delujejo bolje kot vgrajena podpora za UML, vključno s tisto v razdelku »Dobrote« na mojem spletnem mestu.

Torej, če tako slabo razmišljam o teh orodjih, kaj naj uporabim? Daleč najbolj produktivna orodja za oblikovanje OO so bela tabla (idealna je soba z belimi tablami od stene do tal) in post-it blazinice velikosti flip-chart, katerih liste lahko odlepite in palico na steni. Z njimi sem z velikim uspehom oblikoval pomembne projekte. Poleg tega delo na tabli porabi veliko manj časa kot rokoborba z orodjem OO CASE.

Edina težava pri pristopu na beli tabli je zajemanje informacij na tabli. Bele table, ki jih tiskate, sicer obstajajo, vendar so drage, neugodne in premajhne. Lep izdelek strojne opreme, ki spremlja gibanje pisala po beli tabli in zajema poteze pisala v računalnik. Druge table delujejo kot ogromne tablete za digitalizacijo. Vendar se te rešitve izkažejo za preveč omejujoče; oblikovanje poteka istočasno na belih tablah v več pisarnah, na servietah, na ostankih papirja itd. V lokalno kavarno ne morete odnesti 300-kilogramske tiskovne table.

Torej, kaj deluje

Torej, kaj naj naredi mati? Kako zajeti te artefakte, da jih arhivirate v računalniku, tako da bodo naredili razumno dokumentacijo, kot so, ne da bi jih morali prenesti v risalni program?

Rešitev:

Digitalni fotoaparat
Čudovit programski izdelek z imenom Whiteboard Photo podjetja Pixid

Digitalna fotografija na žalost pogosto daje slike, ki niso zadovoljive za dokumentacijo. Za kompenzacijo Whiteboard Photo digitalne slike spremeni v nekaj koristnega. Tukaj so slike vredne tisoč besed. Slika 1 prikazuje tipično digitalno fotografijo table.

Slika 2 prikazuje še en primer.

Slika 3 prikazuje, kako fotografija Whiteboard Photo transformira Slika 1.

In tukaj je, kako slika 2 izgleda po Whiteboard Photo, ki je naredila svojo čarovnijo.

Kot kažejo slike, je razlika neverjetna. Za pretvorbo izvirne slike v očiščeno različico sem preprosto udaril Ctrl-L. Programska oprema je samodejno našla meje table, popravila izkrivljanje zaradi fotografiranja pod kotom (potrebno, da se izogne bleščanju bliskavice), izbrala črte zasnove in jih narisala. Vse, kar potrebuje izdelek za popolnost, je prepoznavanje rokopisa, vendar sem z njim žgečkal rožnato, kakršen je. Zdaj lahko izdelam risbe v kakovostni dokumentaciji neposredno z originalne table, ne da bi zapravljal ure, da bi risbo vložili v nek hrom izgovor za orodje CASE.

Naj bo preprosto

Po mojih izkušnjah pri oblikovanju OO najbolje delujejo nizkotehnološka orodja. Dejansko so hitrejši, enostavnejši za uporabo in dobro delujejo v okoljih za sodelovanje. Do zdaj sem ugotovil, da kombinacija bele table, digitalnega fotoaparata in Whiteboard Photo ponuja najboljši način za vgradnjo programov v stroj.

Allen Holub nudi svetovalne storitve, usposabljanje in mentorstvo pri oblikovanju OO, OO procesu in programiranju Java. Redno predstavlja intenzivno delavnico za oblikovanje OO za tiste, ki jih zanima hiter razvoj njihovih sposobnosti. (Več informacij najdete na //www.holub.com.) Allen je v računalniški industriji delal od leta 1979, nazadnje pa je bil glavni tehnološki direktor pri NetReliance, Inc. Veliko objavlja v revijah (Dr. Dobb's Journal, Programmers Journal, Byte in MSJ, med drugim). Allen ima osem knjig, od katerih zadnja - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - pokriva pasti in pasti navojev Java. Poučuje OO oblikovanje in Java na Kalifornijski univerzi, Berkeley Extension (od 1982).

Preberite več o tej temi

Za brezplačno odprtokodno orodje za oblikovanje ArgoUML pojdite na
//argouml.tigris.org/
Embarcaderov GDPro najdete na
//www.embarcadero.com
Več informacij o podjetju TogetherSoft's Together ControlCenter boste našli na naslovu
//www.togethersoft.com
Domača stran Microsoft Visio
//www.microsoft.com/office/visio/default.htm
Za več informacij o tem zanimivem orodju pojdite na stran izdelka Pixed Whiteboard Photo
//www.pixid.com/home.html
Spletno mesto Allena Holuba vsebuje njegovo stran "Dobrote", kjer boste našli nasvete za oblikovanje OO, splošna pravila programiranja in opombe iz nekaterih Allenovih pogovorov.
//www.holub.com/goodies/goodies.html
JavaWorldje Objektno usmerjeno načrtovanje in programiranje Kazalo vsebuje številne članke o oblikovanju
//www.javaworld.com/channel_content/jw-oop-index.shtml
V mestu boste našli več odličnih ocen izdelkov JavaWorldje Kazalo ocen izdelkov
//www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml
Preberite več komentarjev v JavaWorldje Kazalo komentarjev
//www.javaworld.com/news-reviews/jw-nr-commentary.shtml
Za nasvete in vadnice, ki zajemajo vzorce oblikovanja, razvojna orodja, nastavitev zmogljivosti, varnost, preskušanje in še več, se prijavite na našo Uporabljena Java glasilo
//www.javaworld.com/subscribe
Spregovorite v naši Teorija in praksa programiranja diskusija
//forums.idg.net/webx?50@@.ee6b806
Na naslovu .net boste našli ogromno člankov, povezanih z IT, iz naših sestrskih publikacij