På fjorårets JavaOne-konferanse deltok jeg på en økt der foredragsholderen snakket om Suns plan for den virtuelle Java-maskinen (JVM). I denne samtalen uttalte høyttaleren at Sun blant annet planla å rydde opp nåværende ytelsesflaskehalser i sin virtuelle maskin, for eksempel treghet av synkroniserte metoder og ytelseskostnadene ved søppeloppsamling. Foredragsholderen uttalte Suns mål: Med forbedringene til JVM, trenger ikke programmerere å tenke på å unngå flaskehalser på virtuelle maskiner når de utformet programmene sine; de trenger bare å tenke på å lage "gode objektorienterte, trådsikre design."
Høyttaleren utdypet imidlertid ikke hva som faktisk utgjør en god objektorientert, trådsikker design. Det er målet med denne nye kolonnen. Gjennom artiklene i Designteknikker kolonne, håper jeg å svare på spørsmålet: Hva er en god Java-programdesign, og hvordan lager du en?
Kolonnens fokus
Mitt fokus i denne kolonnen vil være å gi praktiske designteknikker som du kan bruke i dine daglige programmeringsoppgaver. Jeg antar at du er kjent med Java-språket og API-ene. Jeg planlegger å diskutere teknikker, ideer og retningslinjer som vil hjelpe deg med å bruke språket og API-ene i de virkelige programmene dine.
For å gi deg en ide om hva du kan forvente i denne kolonnen, er det en liste over hvilke emner jeg planlegger å skrive om:
- Måter å forbedre utformingen av objektene dine
- Bygge klassehierarkier
- Hva er grensesnitt for?
- Hva er poenget med polymorfisme?
- Velge mellom komposisjon og arv
- Design for trådsikkerhet
- Design for trådsamarbeid
- Model / Controller / View-arkitekturen som brukes av JFC-klassene
- Design mønstre
Mye av materialet som allerede er skrevet om programvaredesign kan brukes på Java. Det er mange komplette designmetoder og tykke lærebøker som beskriver dem. I denne kolonnen vil jeg ikke fremme en metode fremfor en annen. Jeg vil heller ikke fremme en ny metode for min egen oppfinnelse. Snarere vil jeg trekke på og kombinere innsikt som jeg har fått fra flere eksisterende metoder og funnet å være nyttig i min egen programmeringspraksis.
Tilnærmingen til design som jeg vil anbefale i disse artiklene, kommer av mine erfaringer gjennom årene i avlukke: designe ny programvare, forbedre gammel programvare, vedlikeholde programvare skrevet av andre, vedlikeholde programvare skrevet av meg selv, arbeide med forskjellige språk, verktøy datamaskiner og andre programmerbare maskiner. Designfilosofien min vil være veldig "kubikkorientert": basert på og rettet mot, ekte kommersiell programmering.
Denne måneden: Prosessen beskrevet, "design" definert
I denne første artikkelen av Designteknikker kolonne, vil jeg gi en detaljert redegjørelse for konseptet med programvaredesign basert på min egen erfaring som utvikler. I resten av denne artikkelen vil jeg diskutere prosessen med programvareutvikling og forklare hva jeg mener med begrepet "design".
Programvareutviklingsprosessen
Etter min erfaring har prosessen med programvareutvikling en tendens til å være ganske kaotisk. Teammedlemmer kommer og går, krav endres, tidsplaner endres, hele prosjekter blir kansellert, hele selskaper går ut av drift, og så videre. Programmererens jobb er å lykkes med å navigere i dette kaoset og til slutt produsere et "kvalitets" produkt på en "betimelig" måte.
Foruten å være kaotisk, har programvareutviklingsprosessen også en tendens til å være ganske iterativ. Etter hvert som et programvareprodukt utvikles, utvikler det seg kontinuerlig basert på tilbakemelding fra mange parter. Denne iterative prosessen fungerer fra utgivelse til utgivelse (hver utgivelse er en iterasjon) og innenfor utviklingssyklusen til en enkelt utgivelse. Fra utgivelse til utgivelse, for eksempel, indikerer tilbakemeldinger fra kunder med den nåværende versjonen hvilke feilrettinger og forbedringer som er viktigst å gjøre i neste versjon. Innen utviklingssyklusen til en enkelt utgivelse justeres visjonen om sluttmålet kontinuerlig av krefter i selskapet etter hvert som utviklingen utvikler seg.
Til tross for kaos og iterasjon har jeg imidlertid funnet ut at de fleste utviklingsteam prøver å håndheve en viss struktur på utviklingsarbeidet. I forbindelse med denne kolonnen vil jeg løst dele programvareutviklingsprosessen til en enkelt utgivelsessyklus i disse fire fasene:
- Spesifikasjon
- Design
- Gjennomføring
- Integrasjon og test
Med disse fire fasene har jeg tenkt å fange en struktur som jeg har observert i de fleste programvareutviklingsprosjekter. Fordi hvert selskap er forskjellig, hvert team er forskjellig, og hvert prosjekt er forskjellig, danner disse fire fasene bare en grov oversikt over en typisk utviklingssyklus. I praksis kan noen faser hoppes over eller skje i en annen rekkefølge. Og fordi den iterative naturen til programvareutvikling har en tendens til å boble opp gjennom en hvilken som helst pålagt struktur, kan disse fasene til en viss grad overlappe eller blø inn i hverandre.
Når jeg snakker om design i Designteknikker kolonne snakker jeg om aktivitetene som finner sted under trinn to i listen ovenfor. For å gi deg en bedre ide om hva jeg mener med hver fase, beskriver jeg hver enkelt i de neste fire avsnittene.
Fase 1: Spesifisere problemdomenet
De spesifikasjonsfase av et programvareprosjekt innebærer å samle alle berørte parter for å diskutere og definere sluttproduktet til programvareutviklingsprosessen. Under spesifikasjonen definerer du "visjonen" - målet du vil sikte mot for resten av prosjektet. Leveransen som skal komme ut av spesifikasjonsfasen er et skriftlig dokument som definerer kravene til programvaresystemet.
Kravspesifikasjonen er omtrent som en kontrakt. Det er en kontrakt mellom alle berørte parter, men viktigst av alt fra utviklerens perspektiv er det en kontrakt mellom utvikleren og den parten som ønsker sluttproduktet i utgangspunktet: kanskje en klient, en kunde, ledelse eller markedsavdelingen . Når en spesifikasjon er avtalt i muntlige termer, men ikke er nedskrevet, er det i utgangspunktet en muntlig kontrakt. Selv om en muntlig kontrakt er juridisk bindende, er det i mange tilfeller ikke en oppskrift på problemer. Ulike mennesker har en tendens til å ha forskjellige erindringer om muntlige avtaler, spesielt når det gjelder detaljer. En uenighet om detaljer er enda mer sannsynlig hvis detaljene aldri ble diskutert som en del av den muntlige avtalen i utgangspunktet, noe som er et vanlig trekk ved muntlige kontrakter.
Når alle involverte parter kommer sammen og prøver å skrive ned kravene til et programvareprosjekt, tvinger det en utforsking av problem domene. Problemdomenet er sluttproduktet som er beskrevet på et menneskelig (ikke dataprogrammeringsspråk) språk. Det samme sluttproduktet uttrykt på et dataspråk er løsningsdomenet. I løpet av å utforske problemdomenet kan mange tvetydige detaljer identifiseres og diskuteres, og uenigheter kan løses helt fra begynnelsen.
En god spesifikasjon gir deg et veldefinert mål å sikte på når du utvikler deg. Men det garanterer ikke at målet ikke beveger seg. Noen justeringer i visjonen om sluttproduktet er nesten uunngåelige i design- og implementeringsfasene; Imidlertid kan en god spesifikasjon bidra til å redusere størrelsen på slike justeringer. Å hoppe over spesifikasjonsfasen, eller ikke dekke detaljene tilstrekkelig, kan føre til samme slags misforståelse mellom parter som kan oppstå med en muntlig kontrakt. Dermed vil det å ha en god spesifikasjon først bidra til å fremme de påfølgende design- og implementeringsfasene til en vellykket avslutning.
Fase 2: Designe løsningsdomenet
Når du har en skriftlig spesifikasjon som alle involverte er enige i, er du klar for det jeg kaller designfase - prosessen med å planlegge, og på en eller annen måte dokumentere, arkitekturen til løsningsdomenet ditt. Jeg inkluderer mange aktiviteter under navnet "design", inkludert:
Definere systemet:
- Partisjonere systemet i individuelle programmer (og dokumentere det)
- Definere og dokumentere grensesnittene mellom de enkelte programmene
- Bestemme og dokumentere tredjepartsbiblioteker (Java-pakker) som Java-programmene dine vil bruke
- Når du bestemmer deg for og dokumenterer nye biblioteker (Java-pakker), bygger du flere komponenter i systemet ditt
Bygge prototyper for brukergrensesnitt:
- Bygge prototyper for brukergrensesnitt for de systemkomponentene som har hvilket som helst brukergrensesnitt
Gjør objektorientert design:
- Designe og dokumentere klassehierarkier
- Designe og dokumentere de enkelte klassene og grensesnittene
Definere systemet
Som et første trinn i designfasen, må du dele systemet ditt inn i komponentdelene. For eksempel kan det hende du trenger flere prosesser på forskjellige steder i et nettverk. Du kan ha noen appletter og noen applikasjoner. Noen komponenter i systemet kan være bestemt for å bli skrevet i Java, og andre ikke. Hvis du vil bruke JDBC, kan det hende du må velge et tredjeparts JDBC-bibliotek som gjør at du får tilgang til den valgte databasen. Alle disse beslutningene må tas før du kan begynne med objektorientert design av de enkelte programmene i systemet.
Når du definerer systemet, vil du sannsynligvis ønske å dokumentere arbeidet ditt i en eller flere tekniske spesifikasjoner. Dokumentasjon lar deg kommunisere designet til andre interesserte i organisasjonen og få tilbakemeldinger. Du kan gi spesifikasjonen ut, ringe et designanmeldelsesmøte og deretter presentere systemdesignet på møtet. Gruppen kan diskutere designet ditt og forhåpentligvis finne problemer og komme med forslag. Å få tilbakemelding - og gjøre justeringer av systemdesignet ditt som et resultat av tilbakemeldingen - er et eksempel på iterasjon i prosessen med programvareutvikling.
Bygge brukergrensesnitt prototyper
Å bygge en brukergrensesnittprototype er ofte en verdifull aktivitet i designfasen. Når prototypen for brukergrensesnittet er fullført, kan partene som ble enige om spesifikasjonen samles igjen for å gjennomgå forhåndsvisningsversjonen. Å ha en prototype gir partene en ny sjanse til å visualisere og diskutere sluttmålet. Ved å kreve at alle som godtok spesifikasjonen, skal gjennomgå og logge av på en prototype for brukergrensesnitt, hjelper du med å sikre at alle parter har kompatible forventninger til sluttproduktet. Med de visuelle verktøyene som er tilgjengelige i dag for utvikling av Java-baserte brukergrensesnitt, kan utviklingen av en prototype for brukergrensesnittet være veldig rask, og sluttresultatet er et rammeverk av Java-kode som du deretter kan gi funksjonalitet i løpet av implementeringsfasen.
Merk at prosessen med å demonstrere en prototype for brukergrensesnittet er et godt eksempel på utviklingsprosessens iterative natur. Når interesserte (som alle er enige om en skriftlig spesifikasjon) faktisk ser prototyper for brukergrensesnitt, har de ofte nye ideer, eller en bedre forståelse, eller en mer detaljert forståelse - med andre ord, en klarere visjon - om slutten produkt. Under demonstrasjonen kan noen justeringer gjøres i spesifikasjonen. På dette tidspunktet vil forhåpentligvis justeringene være mindre.
Gjør en objektorientert design
Når du designer et Java-program, må du tenke på alle programmeringsteknologiene som tilbys av Java-språket, inkludert multitrading, søppelinnsamling, strukturert feilhåndtering og objektorientering. Likevel, fordi den dominerende arkitektoniske egenskapen til Java-programmeringsspråket er objektorientering, er en Java-programdesignfase fundamentalt en prosess med objektorientert design.
Å gjøre en objektorientert design innebærer å skape arvshierarkier og designe felt og metoder for individuelle klasser og grensesnitt. Tre grunnleggende kategorier av klasser du vil komme opp med i et design er:
- Klasser for brukergrensesnitt
- Problem domene klasser
- Datastyringsklasser
Brukergrensesnittklasser er de som komponerer programmets brukergrensesnitt, for eksempel klasser som representerer vinduer og dialoger. Problem domene klasser er de som representerer objekter du identifiserte i problemdomenet. For eksempel, hvis problemdomenet ditt involverte heiser, kan det hende du har et Heis klasse i løsningsdomenet ditt. Datastyringsklasser er de du oppretter for å administrere objekter eller data. Verken brukergrensesnittklasser eller dataadministrasjonsklasser har tilsvarende objekter i problemdomenet.
Fase 3: Implementering
Implementering er koding. Skrive for sløyfer, hvis utsagn, fangstklausuler, variabler og kommentarer; kompilering; enhetstesting; bug fixing - det er implementering: den sterke handlingen med programmering.
Fase 4: Integrasjon og test
I løpet av integrasjons- og testfasen møtes medlemmene av prosjektgruppen, som hver har til oppgave å bygge en bestemt del av helheten, og prøver å få alle delene av programvaresystemet til å fungere sammen. I løpet av denne fasen finner teammedlemmene ut hvor godt grensesnittene mellom de enkelte systemkomponentene ble definert og kommunisert i løpet av systemdelingsfasen. Kodingen som finner sted i denne fasen, bør først og fremst være feilretting.
Dokumentasjon av programvaredesign
Det er mange tilnærminger til programvaredesign. Formelle metoder prøver å veilede deg gjennom prosessen med å transformere et problemdomene til et løsningsdomene. Når du designer Java-programmer, kan du velge å bruke en formell metodikk, å kombinere flere formelle metoder eller å avstå fra formell metodikk og design ved buksesetet. Men uansett hvordan du angriper designfasen til programvareprosjektet ditt, bør du på en eller annen måte dokumentere designet ditt.
