Når det kommer til godt OO-design, skal du holde det enkelt

En af mine tidligere studerende udbrød engang den uhyggelige erklæring: "Jeg kan umuligt lave objektorienteret (OO) design; jeg har ikke pengene!" Efterspørgsel viste det sig, at OO-design efter hans mening krævede et produkt kaldet Rational Rose, som på det tidspunkt kostede omkring 500,00 pr. Sæde. I hans sind var design ikke mulig uden Rational Rose. Desværre er denne slags balderdash udbredt; for mange mennesker tror, at OO er en højteknologisk proces, der kræver højteknologiske værktøjer. I praksis sidder ublu priser værktøjer ubrugte på hylden (eller er meget underudnyttede).

Med dette i tankerne diskuterer jeg i denne artikel forskellige OO-designværktøjer, hvordan de fungerer, og hvorfor jeg tror, de ikke er nyttige. Jeg forklarer også, hvordan jeg arbejder, og hvad der viser sig at være nyttigt (i det mindste for mig; du er velkommen til at være uenig).

Værktøjerne guider dig ikke gennem processen

Hvert vellykket OO-design, jeg har fundet frem til, har fulgt omtrent den samme proces:

Lær om problem domæne (regnskab, lektionsplanlægning osv.)
Udvikle, i tæt samråd med en levende bruger, en problemformulering der udtømmende beskriver brugerens problem samt eventuelle domæneniveauløsninger. Dette dokument beskriver ikke et computerprogram.
Udfør en formel brugsanalyse, hvor jeg bestemmer de opgaver, der kræves for at løse brugerens problem, igen og arbejde tæt sammen med en reel slutbruger. Typisk opretter jeg et UML (Unified Modeling Language) aktivitetsdiagram til enhver ikke-privat brugssag. (UML er en symbolsk gengivelse af softwaren som et billede.)
Begynd at bygge dynamisk model viser objekterne i systemet og de meddelelser, som disse objekter sender til hinanden, mens en bestemt brugssag bliver handlet ud. Jeg bruger en UML sekvensdiagram til dette formål.
Jeg indfanger samtidig nyttige oplysninger om statisk model diagram. Bemærk: Jeg laver aldrig den statiske model (klassediagram) først. Jeg har smidt for mange statiske modeller, der viste sig at være ubrugelige, når jeg begyndte at lave den dynamiske model. Jeg er ikke længere villig til at spilde den tid, der kræves for at lave den statiske model i et vakuum.
De ovennævnte trin giver typisk to eller tre anvendelsestilfælde, hvorefter jeg begynder at kode og løser modellen om nødvendigt.
Til sidst arbejder jeg på en anden brugssag som beskrevet, og omlægger designet og koden efter behov for at imødekomme den nye sag.

Ingen af nutidens designværktøjer guider dig gennem denne proces. For det meste er de for dyre tegneprogrammer, der ikke fungerer særlig godt, selv som tegneværktøjer. (Rational Rose, som jeg anser for at være en af de mindst i stand til partiet, understøtter ikke engang hele UML.)

Rundtursteknik er en grundlæggende mangelfuld proces

Ikke kun fungerer disse værktøjer ikke godt, det eneste trick disse værktøjer udfører - genererer kode - er værdiløst. Næsten alle OO-designværktøjer følger forestillingen om rundtursteknik hvor du begynder i et designværktøj ved at angive dit design i UML. Du opretter to vigtige sæt af diagrammer: den statiske model, der viser klasserne i designet, deres forhold til hinanden og de metoder, de indeholder; og den dynamiske model, som er en stak af diagrammer, der viser objekterne i systemet, der udfører forskellige opgaver under kørsel.

Når du er færdig med modellen, trykker du på en magisk knap, og værktøjet genererer kode. Den værktøjsgenererede kode er dog ikke særlig god af to grunde: For det første oprettes der i mange værktøjer skeletter til klassedefinitionerne, men metoderne er simpelthen tomme stubber - den dynamiske model ignoreres. For det andet understøtter ingen værktøjer UML fuldt ud, primært fordi ingen kan. UML er et sprog i sig selv, som tilskynder til improvisation, og meget af det faktiske designindhold udtrykkes i kommentarer, der typisk ignoreres af designværktøjet.

Som et resultat hacker du den genererede kode (de fleste butikker hacker den virkelig). Inden for et par uger har koden typisk lidt eller intet at gøre med det originale design. Faktisk smider du effektivt dit design og falder tilbage i WHISKEY-syndromet (hvorfor "koder ikke nogen" endnu?). År og år med mislykkede programmer beviser for mig, at kodning uden design øger den samlede udviklingstid med mindst en faktor på tre og resulterer i meget buggier-kode.

Nu kommer rundtursprocessen: Du åbner dit værktøj, skubber på den magiske knap og importerer koden, teoretisk genopbygger du designet, så det afspejler den faktiske tilstand for koden. Sådan reverse engineering fungerer dog ikke. Værktøjerne opretter typisk nye klassediagrammer, men opdaterer aldrig den dynamiske model. Da den dynamiske model er central i processen, er dit design nu værdiløst, medmindre du går tilbage og opdaterer det manuelt, noget sjældent gjort.

I fare for at gentage mig selv opfordrer rundtursprocessen programmører til at ignorere designet helt og bare kode og derefter konvertere koden til billeder så ofte. I denne situation designer programmererne imidlertid ikke; de hacker kode og skaber derefter billeder af det resulterende rod. Hacking svarer ikke til design.

Mens design faktisk er en iterativ proces (designet ændres, når koden udvikles), skal du starte en iteration ved først at ændre designet og derefter omlægge koden for at afspejle det nye design. For at gøre dette skal du være i stand til at specificere hele softwareproduktet i værktøjet (når du trykkede på den magiske knap, ville et fuldt funktionelt program blive output), og processen ville være envejs uden reverse engineering mekanisme.

CASE-værktøjerne

CASE (computerstøttet software engineering) værktøjer som Rational Rose sætter typisk rundtursteknologi i produktets kerne. Men da returflyvning ikke gør noget nyttigt, bruger mange udviklere værktøjerne som dyre tegneprogrammer. Af de tilgængelige værktøjer synes jeg tre er værd at overveje (selvom jeg ikke bruger nogen af dem):

Det gratis, open source ArgoUML-værktøj, skrevet i Java, gør et rimeligt godt stykke arbejde med UML-diagrammer. Den nyeste version forsøger endda at guide dig gennem processen (med marginal succes indtil videre, men det er en god start).
Embarcaderos GDPro, tidligere distribueret af Advanced Software, tilbyder god support til en gruppe, der arbejder på et enkelt softwaredesign, men har også mangler i denne afdeling. For eksempel kan en designer ikke tjekke et dynamisk modeldiagram, mens den automatisk låser de klasser, der er knyttet til objekter på den dynamiske model.
TogetherSofts Together ControlCenter sidesteps omvendt trip-problemet ved ikke at gøre det. Koden og designet vises på skærmen samtidigt, og når du skifter en, ændres den anden automatisk. Sammen understøtter ControlCenter dog ikke grupper af programmører godt.
Jeg skal også nævne Microsofts Visio kort. Visio er et tegneprogram, der understøtter UML efter en mode, men dets support efterligner Rational Roses elendige brugergrænseflade. Forskellige tegningsskabeloner til UML-figurer i Visio fungerer bedre end den indbyggede UML-understøttelse, inklusive en i afsnittet "Goodies" på mit websted.

Så hvis jeg tænker så dårligt på disse værktøjer, hvad bruger jeg så? Langt det mest produktive OO-designværktøj er et whiteboard (et værelse med wall-to-wall, gulv til loft-whiteboards er ideelt) og Post-it-pads med flip-chart, ark, som du kan trække af holde fast på væggen. Jeg har brugt disse til at designe vigtige projekter med stor succes. Desuden bruger arbejde på en tavle langt mindre tid end at kæmpe med et OO CASE-værktøj.

Det eneste problem med whiteboardtilgangen er at fange oplysningerne på tavlen. Whiteboards, der udskriver, findes, men de er dyre, ugudelige og for små. Et pænt hardwareprodukt, der sporer bevægelsen af en pen hen over en tavle og fanger pennestrøg i computeren. Andre whiteboards fungerer som gigantiske digitizer-tabletter. Disse løsninger viser sig imidlertid at være for begrænsende; design finder sted samtidigt på tavler i flere kontorer, på servietter, på papirrester og så videre. Du kan ikke bære et tavle på 300 pund til den lokale cafe.

Så hvad fungerer

Så hvad skal en mor gøre? Hvordan fanger du disse artefakter for at arkivere dem på computeren, så de laver rimelig dokumentation, som de er, uden at skulle overføre dem til et tegneprogram?

Løsningen:

Et digitalt kamera
Et vidunderligt softwareprodukt kaldet Whiteboard Photo fra Pixid

Desværre producerer et digitalt foto ofte billeder, der er utilfredsstillende til dokumentation. For at kompensere gør Whiteboard Photo digitale billeder til noget nyttigt. Billeder er virkelig tusind ord værd her. Figur 1 viser et typisk digitalt foto af en tavle.

Figur 2 illustrerer et andet eksempel.

Figur 3 viser, hvordan Whiteboard Photo transformerer figur 1.

Og her er hvordan figur 2 ser ud efter Whiteboard Photo gjorde sin magi.

Som billederne viser, er forskellen fantastisk. For at omdanne det originale billede til den oprensede version ramte jeg simpelthen Ctrl-L. Softwaren fandt automatisk tavlens grænser, korrigeret for forvrængning forårsaget af at tage billedet fra en vinkel (nødvendigt for at undgå blænding fra flashen), plukkede designens linjer ud og tegnede dem. Alt, hvad produktet har brug for for at opnå perfektion, er håndskriftsgenkendelse, men jeg kildes lyserødt med det, som det er. Jeg kan nu fremstille tegninger af dokumentationskvalitet direkte fra den originale tavle uden at spilde timer på at tegne tegningen i en halt undskyldning for et CASE-værktøj.

Hold det simpelt

Efter min erfaring fungerer lavteknologiske værktøjer bedst, når det kommer til OO-design. De er faktisk hurtigere, lettere at bruge og klarer sig godt i samarbejdsmiljøer. Indtil videre har jeg fundet ud af, at kombinationen af et whiteboard, et digitalt kamera og Whiteboard Photo giver den bedste metode til at få programdesign til en maskine.

Allen Holub leverer konsulenttjenester, træning og mentoring i OO-design, OO-proces og Java-programmering. Han præsenterer regelmæssigt et intensivt OO-designværksted for dem, der er interesserede i hurtigt at udvikle deres OO-færdigheder. (Find flere oplysninger på //www.holub.com.) Allen har arbejdet i computerbranchen siden 1979, senest som Chief Technology Officer hos NetReliance, Inc. Han er bredt publiceret i magasiner (Dr. Dobbs Journal, Programmers Journal, Byte og blandt andet MSJ). Allen har otte bøger til sin kredit, hvoraf den seneste - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - dækker fælder og faldgruber ved Java-threading. Han underviser i OO-design og Java for University of California, Berkeley Extension (siden 1982).

Lær mere om dette emne

For det gratis, open source ArgoUML designværktøj, gå til
//argouml.tigris.org/
Embarcaderos GDPro kan findes på
//www.embarcadero.com
Du finder flere oplysninger om TogetherSofts Together ControlCenter på
//www.togethersoft.com
Microsoft Visio-hjemmesiden
//www.microsoft.com/office/visio/default.htm
Gå til produktsiden for Pixid Whiteboard Photo for at få flere oplysninger om dette interessante værktøj
//www.pixid.com/home.html
Allen Holubs hjemmeside indeholder sin "Goodies" -side, hvor du finder OO-designtips, programmering af tommelfingerregler og noter fra nogle af Allens foredrag
//www.holub.com/goodies/goodies.html
JavaWorld's Objektorienteret design og programmering Indeks indeholder adskillige artikler, der vedrører design
//www.javaworld.com/channel_content/jw-oop-index.shtml
Du finder flere gode produktanmeldelser i JavaWorld's Produktanmeldelser Indeks
//www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml
Læs mere kommentar i JavaWorld's Kommentarindeks
//www.javaworld.com/news-reviews/jw-nr-commentary.shtml
Tilmeld dig vores for at få tip og vejledninger, der dækker designmønstre, udviklingsværktøjer, performance tuning, sikkerhed, test og mere Anvendt Java nyhedsbrev
//www.javaworld.com/subscribe
Tal ud i vores Programmeringsteori og praksis diskussion
//forums.idg.net/webx?50@@.ee6b806
Du finder et væld af it-relaterede artikler fra vores søsterpublikationer på .net