Viime vuoden JavaOne-konferenssissa osallistuin istuntoon, jossa puhuja puhui Sunin suunnitelmasta Java-virtuaalikoneelle (JVM). Tässä puheessa puhuja totesi, että Sun suunnitteli muun muassa selvittävän virtuaalikoneensa nykyiset suorituskyvyn pullonkaulat, kuten synkronoitujen menetelmien hitauden ja roskakorin suorituskykykustannukset. Puhuja totesi Sunin tavoitteen: JVM: n parannusten myötä ohjelmoijien ei tarvitse miettiä virtuaalikoneiden pullonkaulojen välttämistä suunnitellessaan ohjelmiaan; heidän tarvitsee vain miettiä luoda "hyviä olioihin suuntautuvia, langattomia malleja".
Puhuja ei kuitenkaan tarkentanut, mikä oikeastaan on hyvä olio-suuntautunut, langattomasti turvallinen muotoilu. Se on tämän uuden sarakkeen tavoite. Artikkeleiden kautta Suunnittelutekniikat sarakkeessa, toivon voivani vastata kysymykseen: Mikä on hyvä Java-ohjelman suunnittelu, ja miten luot sen?
Sarakkeen kohdistus
Keskityn tässä sarakkeessa tarjoamaan käytännön suunnittelutekniikoita, joita voit käyttää päivittäisissä ohjelmointitehtävissäsi. Oletan, että olet perehtynyt Java-kieleen ja sovellusliittymiin. Aion keskustella tekniikoista, ideoista ja ohjeista, jotka auttavat sinua käyttämään kieltä ja sovellusliittymiä todellisissa ohjelmissasi.
Tässä on luettelo aiheista, joista aion kirjoittaa:
- Tapoja parantaa esineidesi suunnittelua
- Luokan hierarkioiden rakentaminen
- Mille liitännät ovat?
- Mikä on polymorfismin tarkoitus?
- Valinta kokoonpanon ja perinnön välillä
- Suunnittelu kierteen turvallisuuden takaamiseksi
- Suunnittelu lankaa varten
- JFC-luokkien käyttämä malli / ohjain / näkymä -arkkitehtuuri
- Suunnittelumalleja
Suuri osa ohjelmistosuunnittelusta jo kirjoitetusta materiaalista voidaan soveltaa Java-sovellukseen. On monia monipuolisia suunnittelumenetelmiä ja paksuja oppikirjoja, jotka kuvaavat niitä. Tässä sarakkeessa en mainosta yhtä metodologiaa toisen sijaan. En myöskään edistä uutta keksintöni menetelmää. Pikemminkin hyödyn ja yhdistän oivalluksia, jotka olen saanut useista olemassa olevista menetelmistä ja jotka ovat todenneet hyödyllisiksi omassa ohjelmointikäytännössäni.
Lähestymistapa suunnitteluun, jota suosittelen näissä artikkeleissa, johtuu kokemuksistani vuosien mittaisesta kopiosta: uusien ohjelmistojen suunnittelu, vanhojen ohjelmistojen parantaminen, muiden kirjoittamien ohjelmistojen ylläpito, itse kirjoittamieni ohjelmistojen ylläpito, työskentely eri kielten kanssa, tietokoneet ja muut ohjelmoitavat koneet. Suunnittelufilosofiani tulee olemaan hyvin "ohjaamokeskeinen": perustuu todelliseen kaupalliseen ohjelmointiin ja suunnattu siihen.
Tässä kuussa: Prosessi kuvattu, "suunnittelu" määritelty
Tässä alkuperäisessä artikkelissa Suunnittelutekniikat sarakkeessa, annan yksityiskohtaisen selvityksen ohjelmistosuunnittelun käsitteestä, joka perustuu omaan kokemukseeni kehittäjänä. Tämän artikkelin loppuosassa keskustelen ohjelmistokehityksen prosessista ja selitän, mitä tarkoitan termillä "suunnittelu".
Ohjelmistokehitysprosessi
Kokemukseni mukaan ohjelmistokehitysprosessi on yleensä melko kaoottinen. Tiimin jäsenet tulevat ja menevät, vaatimukset muuttuvat, aikataulut muuttuvat, kokonaiset projektit perutaan, kokonaiset yritykset lopettavat toimintansa ja niin edelleen. Ohjelmoijan tehtävänä on navigoida onnistuneesti tässä kaaoksessa ja lopulta tuottaa "laadukas" tuote "oikeaan aikaan".
Kaoottisuuden lisäksi ohjelmistokehitysprosessi on yleensä melko iteratiivinen. Kun ohjelmistotuotetta kehitetään, se kehittyy jatkuvasti useiden tahojen palautteen perusteella. Tämä iteratiivinen prosessi toimii julkaisusta julkaisuun (jokainen julkaisu on yksi iterointi) ja yhden julkaisun kehitysjakson sisällä. Esimerkiksi julkaisusta julkaisuun nykyisen version asiakkaiden palaute kertoo, mitä virhekorjauksia ja parannuksia on tärkein tehdä seuraavassa versiossa. Yhden julkaisun kehitysvaiheessa yrityksen lopullisen tavoitteen näkymää sopeutetaan jatkuvasti yrityksen kehityksen edetessä.
Kaaoksesta ja iteraatiosta huolimatta olen kuitenkin huomannut, että suurin osa kehitystiimeistä yrittää saada aikaan jonkinlaisen rakenteen kehitystyöhönsä. Tässä sarakkeessa jaan löyhästi yhden julkaisusyklin ohjelmistokehitysprosessin näihin neljään vaiheeseen:
- Erittely
- Design
- Toteutus
- Integrointi ja testi
Näillä neljällä vaiheella aion kaapata rakenteen, jonka olen havainnut useimmissa ohjelmistokehitysprojekteissa. Koska jokainen yritys on erilainen, jokainen tiimi on erilainen ja jokainen projekti on erilainen, nämä neljä vaihetta muodostavat vain karkean hahmotelman tyypillisestä kehitysjaksosta. Käytännössä jotkut vaiheet voidaan ohittaa tai ne voivat tapahtua eri järjestyksessä. Ja koska ohjelmistokehityksen iteratiivinen luonne pyrkii kuplimaan minkä tahansa pakotetun rakenteen läpi, nämä vaiheet voivat jossain määrin olla päällekkäisiä tai vuotaa toisiaan.
Kun puhun suunnittelusta Suunnittelutekniikat sarakkeessa, puhun toiminnoista, jotka tapahtuvat yllä olevan luettelon toisen vaiheen aikana. Jotta saisit paremman käsityksen siitä, mitä tarkoitan jokaisella vaiheella, kuvaan kutakin erikseen seuraavissa neljässä osassa.
Vaihe 1: Ongelma-alueen määrittäminen
määrittelyvaihe ohjelmistoprojektin mukaan kaikkien asianomaisten osapuolten kokoaminen yhteen keskustelemaan ja määrittelemään ohjelmistokehitysprosessin lopputuote. Määrittelyn aikana määrität "vision" - tavoitteen, johon tähtäät loppuosan projektin ajan. Määrittelyvaiheesta tulevan toimituksen on oltava kirjallinen asiakirja, joka määrittelee ohjelmistojärjestelmän vaatimukset.
Vaatimusmäärittely on paljon kuin sopimus. Se on sopimus kaikkien osapuolten välillä, mutta mikä tärkeintä kehittäjän näkökulmasta, se on sopimus kehittäjän ja minkä tahansa osapuolen välillä, joka haluaa ensisijaisesti lopputuotteen: ehkä asiakkaan, asiakkaan, johdon tai markkinointiosaston . Kun eritelmä hyväksytään suullisesti, mutta sitä ei kirjoiteta, se on pohjimmiltaan suullinen sopimus. Vaikka suullinen sopimus on oikeudellisesti sitova, monissa tapauksissa se, että jotain ei ole kirjoitettu, on ongelmaongelma. Eri ihmisillä on taipumus muistaa suulliset sopimukset eri tavoin, varsinkin kun on kyse yksityiskohdista. Erimielisyys yksityiskohdista on vieläkin todennäköisempää, jos yksityiskohdista ei koskaan keskusteltu suullisen sopimuksen osana, mikä on suullisten sopimusten yhteinen piirre.
Kun kaikki osapuolet kokoontuvat yhteen ja yrittävät kirjoittaa ohjelmistoprojektin vaatimukset, se pakottaa tutkimaan ongelma-verkkotunnus. Ongelma-alue on lopputuote, joka on kuvattu ihmisen (ei tietokoneohjelmointi) kielellä. Sama tietokonekielellä ilmaistu lopputuote on ratkaisun verkkotunnus. Ongelmadomeenin tutkinnan aikana voidaan tunnistaa ja keskustella monista epäselvistä yksityiskohdista ja erimielisyydet voidaan ratkaista alusta alkaen.
Hyvä eritelmä antaa sinulle tarkkaan määritellyn tavoitteen, johon voi pyrkiä kehittäessäsi. Mutta se ei takaa, että kohde ei liiku. Jotkut lopputuotteen vision mukautukset ovat lähes väistämättömiä suunnittelu- ja toteutusvaiheissa; hyvä eritelmä voi kuitenkin auttaa vähentämään tällaisten säätöjen suuruutta. Määrittelyvaiheen ohittaminen tai yksityiskohtien peittämättä jättäminen voi johtaa samanlaisiin väärinkäsityksiin osapuolten välillä, joita voi esiintyä suullisen sopimuksen yhteydessä. Siten hyvä määrittely auttaa ensin edistämään seuraavia suunnittelu- ja toteutusvaiheita onnistuneeseen lopputulokseen.
Vaihe 2: Ratkaisudomainin suunnittelu
Kun sinulla on kirjallinen eritelmä, jonka kaikki osapuolet hyväksyvät, olet valmis siihen, mitä kutsun suunnitteluvaihe - ratkaisualueesi arkkitehtuurin suunnitteluprosessi ja jollain tavalla dokumentointi. Lisään monia toimintoja nimellä "suunnittelu", mukaan lukien:
Järjestelmän määrittely:
- Järjestelmän osiointi yksittäisiin ohjelmiin (ja sen dokumentointi)
- Yksittäisten ohjelmien välisten rajapintojen määrittely ja dokumentointi
- Kolmansien osapuolien kirjastojen (Java-paketit) valitseminen ja dokumentointi, joita Java-ohjelmat käyttävät
- Uusista kirjastoista (Java-paketit) päätettäessä ja dokumentoimalla rakennat, että järjestelmän useita komponentteja jaetaan
Käyttöliittymän prototyyppien rakentaminen:
- Käyttöliittymän prototyyppien rakentaminen niille järjestelmäkomponenteille, joilla on käyttöliittymä
Suunnittelu olio-suunnitelma:
- Luokkahierarkioiden suunnittelu ja dokumentointi
- Yksittäisten luokkien ja rajapintojen suunnittelu ja dokumentointi
Järjestelmän määrittely
Ensimmäisenä vaiheena suunnitteluvaiheessa sinun on jaettava järjestelmä osiinsa. Voit esimerkiksi vaatia useita prosesseja verkon eri paikoissa. Sinulla voi olla joitain sovelmia ja joitain sovelluksia. Jotkin järjestelmän komponentit on tarkoitettu kirjoitettaviksi Java-kielellä ja toiset eivät. Jos haluat käyttää JDBC: tä, sinun on ehkä valittava kolmannen osapuolen JDBC-kirjasto, jonka avulla voit käyttää valitsemaasi tietokantaa. Kaikki nämä päätökset on tehtävä, ennen kuin voit aloittaa järjestelmän yksittäisten ohjelmien olio-suunnittelemisen.
Kun määrität järjestelmää, haluat todennäköisesti dokumentoida työsi yhdessä tai useammassa teknisessä eritelmässä. Dokumentaation avulla voit välittää suunnittelun muille organisaation kiinnostuneille osapuolille ja saada palautetta. Voit antaa eritelmän, kutsua suunnittelun tarkastuskokouksen ja sitten esittää järjestelmän suunnittelun kokouksessa. Ryhmä voi keskustella suunnittelustasi ja toivottavasti löytää ongelmia ja tehdä ehdotuksia. Palautteen saaminen - ja säätöjen tekeminen järjestelmän suunnitteluun palautteen seurauksena - on esimerkki iteroinnista ohjelmistokehityksessä.
Käyttöliittymän prototyyppien rakentaminen
Käyttöliittymän prototyypin rakentaminen on usein arvokasta toimintaa suunnitteluvaiheessa. Kun käyttöliittymän prototyyppi on valmis, spesifikaation hyväksyneet osapuolet voivat kokoontua uudelleen tarkistamaan esikatseluversiota. Prototyypin saaminen antaa osapuolille uuden mahdollisuuden visualisoida ja keskustella loppukohteesta. Vaadimalla kaikkia, jotka hyväksyvät eritelmän, tarkistamaan ja kirjautumaan sisään käyttöliittymän prototyypillä, autat varmistamaan, että kaikilla osapuolilla on yhteensopivat odotukset lopputuotetta kohtaan. Nykyisin käytettävissä olevien visuaalisten työkalujen avulla Java-pohjaisten käyttöliittymien kehittämiseen käyttöliittymän prototyypin kehittäminen voi olla erittäin nopeaa, ja lopputulos on Java-koodin kehys, jonka voit sitten varustaa toiminnallisuudella toteutusvaiheessa.
Huomaa, että käyttöliittymän prototyypin esittelyprosessi on erinomainen esimerkki kehitysprosessin iteratiivisesta luonteesta. Kun asianomaiset osapuolet (jotka ovat kaikki sopineet kirjallisesta spesifikaatiosta) todella näkevät käyttöliittymän prototyypit, heillä on usein uusia ideoita tai parempi ymmärrys tai tarkempi käsitys - toisin sanoen selkeämpi visio - lopusta. tuote. Esittelyn aikana eritelmään voidaan tehdä joitain muutoksia. Tähän mennessä toivottavasti muutokset ovat kuitenkin vähäisiä.
Suunnittelu olio-suunnitteilla
Suunnitellessasi Java-ohjelmaa sinun on ajatteltava kaikkia Java-kielen tarjoamia ohjelmointitekniikoita, mukaan lukien monisäikeisyys, roskien keräys, jäsennelty virheenkäsittely ja kohteen suunta. Koska Java-ohjelmointikielen hallitseva arkkitehtoninen ominaisuus on olio-orientaatio, Java-ohjelman suunnitteluvaihe on pohjimmiltaan olio-suunnitteluprosessi.
Objektipohjaisen suunnittelun tekeminen edellyttää perintöhierarkioiden luomista ja yksittäisten luokkien ja rajapintojen kenttien ja menetelmien suunnittelua. Kolme luokkaluokkaa, jotka keksit suunnittelussa, ovat:
- Käyttöliittymäluokat
- Ongelma verkkotunnusluokissa
- Tiedonhallintaluokat
Käyttöliittymäluokat ovat ne, jotka muodostavat ohjelman käyttöliittymän, kuten luokat, jotka edustavat ikkunoita ja valintaikkunoita. Ongelma verkkotunnusluokissa ovat niitä, jotka edustavat ongelma-toimialueella tunnistamiasi objekteja. Esimerkiksi, jos ongelma-alueesi sisältää hissejä, sinulla saattaa olla Hissi luokka ratkaisuverkkotunnuksessasi. Tiedonhallintaluokat ovat niitä, jotka luot luomalla objektien tai tietojen hallintaa. Käyttöliittymäluokilla eikä tiedonhallintaluokilla ei ole vastaavia objekteja ongelma-alueella.
Vaihe 3: Toteutus
Toteutus on koodausta. Kirjoittaminen silmukoille, jos lauseita, saalislausekkeita, muuttujia ja kommentteja; kokoaminen; yksikkötestaus; virheenkorjaus - se on toteutus: kova teko ohjelmointiin.
Vaihe 4: Integrointi ja testi
Integraatio- ja testausvaiheessa projektitiimin jäsenet, joiden jokaisen tehtävänä on rakentaa tietty osa kokonaisuudesta, tapaavat ja yrittävät saada kaikki ohjelmistojärjestelmän osat toimimaan yhdessä. Tämän vaiheen aikana tiimin jäsenet selvittävät, kuinka hyvin yksittäisten järjestelmäkomponenttien väliset rajapinnat määritettiin ja kommunikoitiin järjestelmän osiointivaiheen aikana. Tämän vaiheen aikana tapahtuvan koodauksen tulisi olla ensisijaisesti virheenkorjaus.
Ohjelmistosuunnitelmien dokumentointi
Ohjelmistosuunnittelussa on monia lähestymistapoja. Muodolliset metodologiat yrittävät opastaa sinua prosessissa, jolla ongelma-alue muutetaan ratkaisualueeksi. Suunnitellessasi Java-ohjelmia voit halutessasi käyttää muodollista metodologiaa, yhdistää useita muodollisia menetelmiä tai luopua muodollisesta metodologiasta ja suunnittelusta housuissasi. Mutta riippumatta siitä, miten hyökät ohjelmistoprojektisi suunnitteluvaiheeseen, sinun tulisi jollain tavalla dokumentoida suunnittelu.
