Kun kyseessä on hyvä OO-suunnittelu, pidä se yksinkertaisena

Eräs entinen opiskelijani kerran pilkkassi julistavan lausunnon: "En osaa tehdä objektiivista (OO) suunnittelua; minulla ei ole rahaa!" Kysyttäessä edelleen kävi ilmi, että hänen mielestään OO-suunnittelu vaati Rational Rose -nimistä tuotetta, joka maksoi tuolloin noin 500,00 paikkaa kohti. Hänen mielestään suunnittelu ei ollut mahdollista ilman Rational Rosea. Valitettavasti tällainen balderdash on laajalle levinnyt; liian monien mielestä OO on korkean teknologian prosessi, joka vaatii korkean teknologian työkaluja. Käytännössä kohtuuttoman hinnoitellut työkalut istuvat käyttämättömänä hyllyllä (tai ovat huomattavasti alikäytettyjä).

Tässä mielessä keskustelen tässä artikkelissa useista OO-suunnittelutyökaluista, miten ne toimivat ja miksi mielestäni niistä ei ole hyötyä. Selitän myös kuinka työskentelen ja mikä osoittautuu hyödylliseksi (ainakin minulle; olet tervetullut olemaan eri mieltä).

Työkalut eivät opasta sinua prosessin läpi

Jokainen onnistunut OO-suunnittelu on seurannut suunnilleen samaa prosessia:

Opi ongelma-verkkotunnus (kirjanpito, oppituntien suunnittelu jne.)
Kehitä tiiviissä yhteistyössä live-käyttäjän kanssa a ongelman selvitys joka kuvaa tyhjentävästi käyttäjän ongelman sekä kaikki verkkotunnustason ratkaisut. Tämä asiakirja ei kuvaa tietokoneohjelmaa.
Suorita muodollinen käyttötapausanalyysi, jossa määritän käyttäjän ongelman ratkaisemiseksi tarvittavat tehtävät jälleen tiiviissä yhteistyössä todellisen loppukäyttäjän kanssa. Tyypillisesti luon UML: n (Unified Modeling Language) toimintakaavio jokaiseen ei-triviaaliseen käyttötapaukseen. (UML on symbolinen esitys ohjelmistosta kuvana.)
Aloita dynaaminen malli näytetään järjestelmän objektit ja viestit, jotka nämä objektit lähettävät toisilleen, kun tiettyä käyttötapaa toteutetaan. Käytän UML: ää sekvenssikaavio tähän tarkoitukseen.
Sieppaan samanaikaisesti hyödyllistä tietoa staattinen malli kaavio. Huomaa: En koskaan tee staattista mallia (luokkakaavio) ensin. Olen heittänyt liian monta staattista mallia, jotka osoittautuivat hyödyttömiksi, kun aloin tehdä dynaamista mallia. En ole enää valmis tuhlaamaan aikaa, joka tarvitaan staattisen mallin tekemiseen tyhjiössä.
Edellä mainitut vaiheet tuottavat tyypillisesti kaksi tai kolme käyttötapausta, minkä jälkeen aloitan koodaamisen, korjaan mallin tarvittaessa.
Viimeinkin työskentelen toisen kuvatun käyttötapauksen kanssa, korjaan suunnittelun ja koodin tarvittaessa uuden tapauksen huomioon ottamiseksi.

Mikään nykypäivän suunnittelutyökalu ei opasta sinua tämän prosessin läpi. Suurimmaksi osaksi ne ovat ylihinnoiteltuja piirustusohjelmia, jotka eivät toimi erityisen hyvin edes piirtotyökaluina. (Rational Rose, jota pidän eränä vähiten kykenevänä, ei edes tue kaikkea UML: ää.)

Meno-paluu suunnittelu on periaatteessa puutteellinen prosessi

Paitsi että nämä työkalut eivät toimi hyvin, yksi temppu, jonka nämä työkalut tekevät - koodin luominen - on arvoton. Lähes kaikki OO: n suunnittelutyökalut noudattavat käsitystä edestakainen suunnittelu jossa aloitat suunnittelutyökalun määrittämällä suunnittelun UML-muodossa. Luot kaksi välttämätöntä kaaviojoukkoa: staattinen malli, joka näyttää suunnittelun luokat, niiden suhteet toisiinsa ja niiden sisältämät menetelmät; ja dynaaminen malli, joka on pino kaavioita, jotka esittävät järjestelmän objektit, jotka suorittavat erilaisia tehtäviä ajon aikana.

Kun olet valmis malliin, osut taika-painiketta ja työkalu luo koodin. Työkalujen luoma koodi ei kuitenkaan ole erityisen hyvä kahdesta syystä: Ensinnäkin monissa työkaluissa luodaan luokka luokka-määritelmille, mutta menetelmät ovat yksinkertaisesti tyhjiä tukia - dynaaminen malli jätetään huomiotta. Toiseksi mikään työkalu ei tue täysin UML: ää, lähinnä siksi, ettei kukaan voi. UML on itsenäinen kieli, joka kannustaa improvisointiin, ja suuri osa todellisesta suunnittelun sisällöstä ilmaistaan kommenteissa, jotka suunnittelutyökalu yleensä jättää huomiotta.

Seurauksena on, että hakkeroit luomasi koodin (useimmat kaupat todella hakkeroivat sen). Muutaman viikon kuluessa koodilla on yleensä vähän tai ei mitään tekemistä alkuperäisen mallin kanssa. Itse asiassa heität suunnittelusi tehokkaasti pois ja putoat takaisin WHISKEY-oireyhtymään (miksi joku ei vielä "koodaa"?). Vuosien ja vuosien epäonnistuneet ohjelmat osoittavat minulle, että koodaaminen ilman suunnittelua pidentää kehitysaikaa vähintään kolminkertaisesti ja johtaa paljon vankempaan koodiin.

Nyt tulee edestakainen prosessi: Avaat työkalun, painat maagista painiketta ja tuod koodin, teoreettisesti rakentamalla rakenteen uudelleen siten, että se heijastaa koodin todellista tilaa. Tällainen käänteinen suunnittelu ei kuitenkaan toimi. Työkalut luovat tyypillisesti uusia luokkakaavioita, mutta eivät koskaan päivitä dynaamista mallia. Koska dynaaminen malli on prosessin keskeinen osa, suunnittelusi on nyt arvoton, ellet palaa takaisin ja päivitä sitä käsin, jotain harvoin tehtyä.

Riskinä toistaa itseäni edestakainen prosessi kannustaa ohjelmoijia sivuuttamaan suunnittelun kokonaan ja vain koodaamaan, sitten muokkaamaan koodin kuviksi niin usein. Tässä tilanteessa ohjelmoijat eivät kuitenkaan suunnittele; he hakkeroivat koodia ja luovat sitten kuvia tuloksena olevasta sotkusta. Hakkerointi ei ole sama muotoilu.

Vaikka suunnittelu on todellakin iteratiivinen prosessi (muotoilu muuttuu koodin kehittyessä), sinun on aloitettava iterointi muokkaamalla ensin suunnittelua ja korjaamalla koodi uudelleen vastaamaan uutta mallia. Tätä varten sinun on pystyttävä määrittämään koko ohjelmistotuote työkalussa (kun painat maagista painiketta, tulostetaan täysin toimiva ohjelma) ja prosessi olisi yksisuuntainen ilman käänteistä suunnittelua mekanismi.

CASE-työkalut

CASE (tietokoneavusteinen ohjelmistotuotanto) -työkalut, kuten Rational Rose, asettavat edestakaisen suunnittelun tuotteen ytimeen. Koska edestakainen suunnittelu ei kuitenkaan tee mitään hyödyllistä, monet kehittäjät käyttävät työkaluja kalliina piirustusohjelmina. Käytettävissä olevista työkaluista mielestäni kolme kannattaa harkita (vaikka en käytä niitä):

Ilmainen, avoimen lähdekoodin Java-kirjoitettu ArgoUML-työkalu tekee kohtuullisen hyvää työtä UML-kaavioiden tekemisessä. Uusin versio yrittää jopa opastaa sinut prosessin läpi (toistaiseksi marginaalilla, mutta se on hyvä alku).
Embarcaderon GDPro, jonka aiemmin jakoi Advanced Software, tarjoaa hyvän tuen ryhmälle, joka työskentelee yhden ohjelmistosuunnittelun parissa, mutta sillä on myös puutteita tässä osastossa. Suunnittelija ei voi esimerkiksi tarkistaa dynaamisen mallikaavion lukitessaan automaattisesti kohteisiin liittyvät luokat dynaamisessa mallissa.
TogetherSoftin Together ControlCenter ohittaa peruutusmatkan ongelman tekemättä sitä. Koodi ja malli näkyvät näytöllä samanaikaisesti, ja kun vaihdat yhtä, toinen muuttuu automaattisesti. ControlCenter ei kuitenkaan tue ohjelmoijaryhmiä hyvin.
Mainitsen myös Microsoftin Vision lyhyesti. Visio on piirustusohjelma, joka tukee UML: ää muodin jälkeen, mutta sen tuki jäljittelee Rational Rosen kurjaa käyttöliittymää. Useat Vision UML-muotojen piirustusmallit toimivat paremmin kuin sisäänrakennettu UML-tuki, mukaan lukien yksi verkkosivustoni "Herkut" -osasta.

Joten jos ajattelen näitä työkaluja niin huonosti, mitä käytän? Ylivoimaisesti tuottavimmat OO-suunnittelutyökalut ovat valkotaulu (huone, jossa on seinästä seinään, lattiasta kattoon ulottuvat taulut ovat ihanteellisia) ja fläppitaulun kokoiset Post-it-tyynyt, joiden levyt voit irrottaa kiinni seinälle. Olen käyttänyt näitä suunnitellessani merkittäviä projekteja erittäin menestyksekkäästi. Lisäksi työskentely taululla vie huomattavasti vähemmän aikaa kuin paini OO CASE -työkalulla.

Ainoa vaikeus taululähestymistavassa on taululla olevien tietojen kaappaaminen. Tulostettuja tauluja on olemassa, mutta ne ovat kalliita, epämiellyttäviä ja liian pieniä. Yksi siisti laitteistotuote, joka seuraa kynän liikettä taulun yli ja sieppaa kynän lyönnit tietokoneeseen. Muut taulut toimivat kuin jättiläinen digitointitabletti. Nämä ratkaisut osoittautuvat kuitenkin liian rajoittaviksi; suunnittelu tapahtuu samanaikaisesti taulukoilla useissa toimistoissa, lautasliinoilla, paperiräpylöillä ja niin edelleen. Et voi kuljettaa 300 kilon tulostustaulua paikalliseen kahvilaan.

Joten mikä toimii

Joten mitä äiti tekee? Kuinka sieppaat nämä artefaktit arkistoimaan ne tietokoneeseen, jotta ne tekevät kohtuullisen dokumentaation sellaisenaan, ilman että niitä tarvitsee siirtää piirustusohjelmaan?

Ratkaisu:

Digitaalikamera
Pixidin upea ohjelmistotuote nimeltä Whiteboard Photo

Digitaalinen valokuva tuottaa valitettavasti usein kuvia, jotka eivät ole tyydyttäviä dokumentointia varten. Tasoituksena Whiteboard Photo muuttaa digitaalikuvat hyödyllisiksi. Kuvat ovat todella tuhannen sanan arvoisia täällä. Kuvassa 1 on tyypillinen digitaalinen valokuva taulusta.

Kuvassa 2 on esitetty toinen esimerkki.

Kuvassa 3 on esitetty, kuinka Whiteboard Photo muuntaa kuvan 1.

Ja näin kuva 2 näyttää tauluvalokuvasta sen taika.

Kuten kuvat osoittavat, ero on hämmästyttävä. Muuntaaksesi alkuperäisen kuvan puhdistetuksi versioksi, lyön vain Ctrl-L. Ohjelmisto löysi taulun rajat automaattisesti, korjattiin kuvan vääristymästä kulmasta (välttämätön salaman häikäisyn välttämiseksi), valitsi piirustuksen viivat ja piirrti ne. Tuotteen tarvitsee vain täydellisyyden saavuttamiseksi käsinkirjoituksen tunnistus, mutta olen kutitettu vaaleanpunaisella sen kanssa. Pystyn nyt tuottamaan dokumentaation laatuisia piirustuksia suoraan alkuperäiseltä taululta tuhlaamatta tuntikausia kirjoittamalla piirroksen CASE-työkalun rampaan tekosyyn.

Pidä se yksinkertaisena

Kokemukseni mukaan matalan teknologian työkalut toimivat parhaiten OO-suunnittelussa. Ne ovat todellakin nopeampi, helpompi käyttää ja toimivat hyvin yhteistyöympäristöissä. Toistaiseksi olen huomannut, että taulun, digitaalikameran ja Whiteboard Photo -yhdistelmän yhdistelmä tarjoaa parhaan tavan saada ohjelmamallit koneeseen.

Allen Holub tarjoaa konsultointipalveluja, koulutusta ja mentorointia OO-suunnittelussa, OO-prosessissa ja Java-ohjelmoinnissa. Hän esittelee säännöllisesti intensiivisen OO-suunnittelutyöpajan niille, jotka ovat kiinnostuneita kehittämään OO-taitojaan nopeasti. (Löydät lisätietoja osoitteesta //www.holub.com.) Allen on työskennellyt atk-teollisuudessa vuodesta 1979, viimeksi NetReliance, Inc. -yrityksen teknologiajohtajana. Hän on julkaistu laajalti lehdissä (Dr.Dobb's Journal, Programmers Journal, Muun muassa tavu ja MSJ). Allenin ansioksi on kahdeksan kirjaa, joista viimeisin - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - käsittelee Java-ketjutuksen ansoja ja sudenkuoppia. Hän opettaa OO-suunnittelua ja Javaa Kalifornian yliopistossa, Berkeley Extensionissa (vuodesta 1982).

Lisätietoja tästä aiheesta

Saat ilmaisen, avoimen lähdekoodin ArgoUML-suunnittelutyökalun siirtymällä kohtaan
//argouml.tigris.org/
Embarcaderon GDPro löytyy osoitteesta
//www.embarcadero.com
Löydät lisätietoja TogetherSoftin Together ControlCenter -sivustolta
//www.togethersoft.com
Microsoft Vision kotisivu
//www.microsoft.com/office/visio/default.htm
Mene Pixid Whiteboard Photo -sivulle saadaksesi lisätietoja tästä mielenkiintoisesta työkalusta
//www.pixid.com/home.html
Allen Holubin verkkosivustolla on hänen "Goodies" -sivunsa, josta löydät OO: n suunnitteluvinkkejä, ohjelmointisääntöjä ja muistiinpanoja joistakin Allenin keskusteluista
//www.holub.com/goodies/goodies.html
JavaWorldon Kohdesuuntautunut suunnittelu ja ohjelmointi Hakemisto sisältää lukuisia artikkeleita, jotka koskevat suunnittelua
//www.javaworld.com/channel_content/jw-oop-index.shtml
Löydät lisää upeita tuotearvioita JavaWorldon Tuotearvosteluhakemisto
//www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml
Lue lisää kommentteja JavaWorldon Kommenttihakemisto
//www.javaworld.com/news-reviews/jw-nr-commentary.shtml
Jos tarvitset vinkkejä ja opetusohjelmia suunnittelumalleista, kehitystyökaluista, suorituskyvyn säätämisestä, tietoturvasta, testauksesta ja muusta, kirjaudu palveluun Applied Java uutiskirje
//www.javaworld.com/subscribe
Puhu meidän Ohjelmointiteoria ja käytäntö keskustelu
//forums.idg.net/webx?50@@.ee6b806
Löydät runsaasti tietotekniikkaan liittyviä artikkeleita sisarjulkaisuistamme .net