Når det gjelder god OO-design, hold det enkelt

En tidligere student av meg utbrøt en gang den latterlige uttalelsen: "Jeg kan umulig gjøre objektorientert (OO) design; jeg har ikke pengene!" Når han spurte videre, viste det seg at OO-design i hans sinn krevde et produkt kalt Rational Rose, som den gang kostet rundt 500,00 per sete. I hans sinn, uten Rational Rose, var design ikke mulig. Dessverre er denne typen balderdash utbredt; for mange mennesker tror OO er en høyteknologisk prosess som krever høyteknologiske verktøy. I praksis ligger ublu prisede verktøy ubrukt på hyllen (eller er veldig underutnyttet).

Med dette i tankene diskuterer jeg i denne artikkelen forskjellige OO-designverktøy, hvordan de fungerer og hvorfor jeg tror de ikke er nyttige. Jeg forklarer også hvordan jeg jobber, og hva som viser seg nyttig (i det minste for meg; du er velkommen til å være uenig).

Verktøyene veileder deg ikke gjennom prosessen

Hver vellykkede OO-design jeg har kommet på har fulgt omtrent samme prosess:

Lær om problem domene (regnskap, leksjonsplanlegging osv.)
Utvikle, i nær samråd med en live bruker, en problemstilling som uttømmende beskriver brukerens problem, samt eventuelle løsninger på domenenivå. Dette dokumentet beskriver ikke et dataprogram.
Utfør en formell bruksanalyse, der jeg bestemmer hvilke oppgaver som kreves for å løse brukerens problem, igjen, i tett samarbeid med en ekte sluttbruker. Vanligvis lager jeg et UML (Unified Modeling Language) aktivitetsdiagram for alle ikke-kommersielle tilfeller. (UML er en symbolsk fremstilling av programvaren som et bilde.)
Begynn å bygge dynamisk modell viser objektene i systemet, og meldingene disse objektene sender til hverandre, mens en bestemt brukssak blir handlet ut. Jeg bruker en UML sekvensdiagram for dette formålet.
Jeg fanger samtidig nyttig informasjon på statisk-modell diagram. Merk: Jeg gjør aldri den statiske modellen (klassediagram) først. Jeg har kastet for mange statiske modeller som viste seg å være ubrukelige når jeg begynte å gjøre den dynamiske modellen. Jeg er ikke lenger villig til å kaste bort tiden som kreves for å gjøre den statiske modellen i et vakuum.
De ovennevnte trinnene gir vanligvis to eller tre brukstilfeller, hvoretter jeg begynner å kode, og fikser modellen om nødvendig.
Til slutt jobber jeg med en annen brukssak som beskrevet, og omformer designet og koden etter behov for å imøtekomme den nye saken.

Ingen av dagens designverktøy veileder deg gjennom denne prosessen. For det meste er de overprisede tegneprogrammer som ikke fungerer spesielt bra, selv ikke som tegneverktøy. (Rational Rose, som jeg anser som en av de minst i stand til mye, støtter ikke engang hele UML.)

Rundtursteknikk er en grunnleggende feil prosess

Ikke bare fungerer disse verktøyene ikke bra, det eneste trikset disse verktøyene utfører - genererer kode - er verdiløst. Nesten alle OO-designverktøy følger forestillingen om rundtursteknikk der du begynner i et designverktøy ved å spesifisere designet ditt i UML. Du lager to viktige sett med diagrammer: den statiske modellen som viser klassene i designet, deres forhold til hverandre og metodene de inneholder; og den dynamiske modellen, som er en stabel med diagrammer som viser objektene i systemet som utfører forskjellige oppgaver ved kjøretid.

Når du har fullført modellen, trykker du på en magisk knapp, og verktøyet genererer kode. Imidlertid er den verktøygenererte koden ikke spesielt bra av to grunner: For det første, i mange verktøy opprettes skjeletter for klassedefinisjonene, men metodene er rett og slett tomme stubber - den dynamiske modellen blir ignorert. For det andre støtter ingen verktøy UML fullt ut, primært fordi ingen kan. UML er et språk i seg selv, som oppmuntrer til improvisasjon, og mye av det faktiske designinnholdet kommer til uttrykk i kommentarer som vanligvis ignoreres av designverktøyet.

Som et resultat hacker du opp den genererte koden (de fleste butikker hacker den virkelig). I løpet av få uker har koden vanligvis lite eller ingenting å gjøre med det originale designet. Faktisk kaster du effektivt designen din og faller tilbake i WHISKEY-syndromet (hvorfor "koder ikke noen" ennå?). År og år med mislykkede programmer beviser for meg at koding uten design øker den samlede utviklingstiden med minst en faktor på tre, og resulterer i mye feilkode.

Nå kommer tur-retur-prosessen: Du åpner verktøyet ditt, trykker på den magiske knappen og importerer koden, og teoretisk gjenoppbygger du designet slik at det gjenspeiler den faktiske tilstanden til koden. Slike revers engineering virker ikke. Verktøyene lager vanligvis nye klassediagrammer, men oppdaterer aldri den dynamiske modellen. Siden den dynamiske modellen er sentral i prosessen, er designen din nå verdiløs med mindre du går tilbake og oppdaterer den for hånd, noe sjelden er gjort.

I fare for å gjenta meg selv, oppfordrer rundtursprosessen programmerere til å ignorere designet helt og bare kode, og deretter konvertere koden til bilder så ofte. I denne situasjonen designer programmererne imidlertid ikke; de hacker kode og lager bilder av det resulterende rotet. Hacking tilsvarer ikke design.

Selv om design faktisk er en iterativ prosess (designet endres etter hvert som koden utvikles), bør du starte en iterasjon ved å modifisere designet først, og deretter omforme koden for å gjenspeile den nye designen. For å gjøre dette, må du kunne spesifisere hele programvareproduktet i verktøyet (når du trykket på den magiske knappen, ville et fullt funksjonelt program bli sendt ut) og prosessen ville være enveis uten omvendt utvikling mekanisme.

CASE-verktøyene

CASE (datamaskinstøttet programvareteknikk) verktøy som Rational Rose setter vanligvis rundtursteknikk i produktets kjerne. Men siden rundtursteknikken ikke gjør noe nyttig, bruker mange utviklere verktøyene som dyre tegningsprogrammer. Av verktøyene som er tilgjengelige, tror jeg tre er verdt å vurdere (selv om jeg ikke bruker noen av dem):

Det gratis, åpne kildekoden ArgoUML-verktøyet, skrevet i Java, gjør en rimelig god jobb med UML-diagrammer. Den siste versjonen prøver til og med å guide deg gjennom prosessen (med marginell suksess så langt, men det er en god start).
Embarcaderos GDPro, tidligere distribuert av Advanced Software, tilbyr god støtte for en gruppe som jobber med en enkelt programvaredesign, men har også mangler i denne avdelingen. For eksempel kan en designer ikke sjekke ut et dynamisk modelldiagram mens den automatisk låser klassene knyttet til objekter på den dynamiske modellen.
TogetherSofts Together ControlCenter omgår problemet med omvendt tur ved ikke å gjøre det. Koden og designet vises på skjermen samtidig, og når du endrer en, endres den andre automatisk. Sammen støtter ikke ControlCenter grupper av programmerere godt.
Jeg bør også nevne Microsofts Visio kort. Visio er et tegneprogram som støtter UML etter en mote, men støtten etterligner Rational Roses elendige brukergrensesnitt. Ulike tegningsmaler for UML-former i Visio fungerer bedre enn den innebygde UML-støtten, inkludert en i delen "Godbiter" på nettstedet mitt.

Så hvis jeg tenker så dårlig på disse verktøyene, hva bruker jeg da? Det desidert mest produktive OO-designverktøyet er en tavle (et rom med vegg-til-vegg-gulv-til-tak-tavler er ideelt) og Post-it-pads i flipp-diagram, ark du kan trekke av og stikk på veggen. Jeg har brukt disse til å designe viktige prosjekter med stor suksess. Videre tar arbeid på en tavle mye kortere tid enn å bryte med et OO CASE-verktøy.

Den eneste vanskeligheten med tavlemetoden er å fange informasjonen på tavlen. Whiteboards som skrives ut eksisterer, men de er dyre, ugudelige og for små. Et pent maskinvareprodukt som sporer bevegelsen til en penn over en tavle og fanger pennestrøk i datamaskinen. Andre tavler fungerer som gigantiske digitizer-nettbrett. Imidlertid viser disse løsningene seg for begrensende; design foregår samtidig på tavler i flere kontorer, på servietter, på papirrester og så videre. Du kan ikke bære en tavle på 300 pund til den lokale kafeen.

Så hva fungerer

Så hva skal en mor gjøre? Hvordan fanger du disse gjenstandene for å arkivere dem på datamaskinen, slik at de lager rimelig dokumentasjon slik de er, uten å måtte overføre dem til et tegneprogram?

Løsningen:

Et digitalt kamera
Et fantastisk programvareprodukt kalt Whiteboard Photo fra Pixid

Dessverre produserer et digitalt bilde ofte bilder som ikke er tilfredsstillende for dokumentasjon. For å kompensere gjør Whiteboard Photo digitale bilder til noe nyttig. Bilder er virkelig verdt tusen ord, her. Figur 1 viser et typisk digitalt bilde av en tavle.

Figur 2 illustrerer et annet eksempel.

Figur 3 viser hvordan Whiteboard Photo transformerer figur 1.

Slik ser figur 2 ut etter at Whiteboard Photo gjorde sin magi.

Som bildene viser, er forskjellen fantastisk. For å overføre originalbildet til den oppryddede versjonen, slo jeg ganske enkelt Ctrl-L. Programvaren fant automatisk tavleens grenser, korrigert for forvrengning forårsaket av å ta bildet fra en vinkel (nødvendig for å unngå blending fra blitsen), plukket ut designlinjene og tegnet dem. Alt produktet trenger for å oppnå perfeksjon er håndskriftgjenkjenning, men jeg er kittet rosa med den slik den ser ut. Jeg kan nå produsere tegninger av dokumentasjonskvalitet direkte fra den originale tavlen, uten å kaste bort timer på å tegne inn i en halt unnskyldning for et CASE-verktøy.

Hold det enkelt

Etter min erfaring, når det gjelder OO-design, fungerer lavteknologiske verktøy best. De er faktisk raskere, enklere å bruke og fungerer godt i samarbeidsmiljøer. Så langt har jeg funnet ut at kombinasjonen av en tavle, et digitalt kamera og Whiteboard Photo gir den beste metoden for å få programdesign til en maskin.

Allen Holub tilbyr konsulenttjenester, opplæring og veiledning i OO-design, OO-prosess og Java-programmering. Han presenterer regelmessig et intensivt OO-designverksted for de som er interessert i å raskt utvikle sine OO-ferdigheter. (Finn mer informasjon på //www.holub.com.) Allen har jobbet i dataindustrien siden 1979, sist som teknologidirektør i NetReliance, Inc. Han er mye publisert i magasiner (Dr. Dobbs Journal, Programmers Journal, Byte, og MSJ, blant andre). Allen har åtte bøker til kreditt, den siste av dem - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - dekker feller og fallgruvene ved Java-threading. Han underviser i OO-design og Java for University of California, Berkeley Extension (siden 1982).

Lær mer om dette emnet

For gratis, åpen kildekode ArgoUML designverktøy, gå til
//argouml.tigris.org/
Embarcaderos GDPro finner du på
//www.embarcadero.com
Du finner mer informasjon 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 mer informasjon om dette interessante verktøyet
//www.pixid.com/home.html
Allen Holubs nettsted inneholder "Goodies" -siden, der du finner OO-designtips, programmering av tommelfingerregler og notater fra noen av Allens foredrag
//www.holub.com/goodies/goodies.html
JavaWorlds Objektorientert design og programmering Indeks har mange artikler som adresserer design
//www.javaworld.com/channel_content/jw-oop-index.shtml
Du finner flere flotte produktanmeldelser i JavaWorlds Produktanmeldelser Indeks
//www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml
Les mer kommentarer i JavaWorlds Kommentarindeks
//www.javaworld.com/news-reviews/jw-nr-commentary.shtml
For tips og veiledninger som dekker designmønstre, utviklingsverktøy, ytelsesjustering, sikkerhet, testing og mer, kan du registrere deg for vårt Påført Java nyhetsbrev
//www.javaworld.com/subscribe
Snakk ut i vår Programmeringsteori og praksis diskusjon
//forums.idg.net/webx?50@@.ee6b806
Du finner et vell av IT-relaterte artikler fra søsterpublikasjonene våre på .net