Vaihe 5 - Suunnittelu I - staattinen mallintaminen

• Tehtävät
• Vinkkejä

Analyysikurssilla on tarkasteltu pääasiassa järjestelmän rakenteellisia ominaisuuksia. Näkemys on esitetty analyysivaiheen luokkakaaviona ja tekstikuvauksina. Viidennen ja kuudennen vaiheen tarkoituksena on tuottaa kuvauksia järjestelmän käyttäytymisestä ja täydentää järjestelmän rakenteellinen kuvaus suunnitteluvaiheen luokkakaavioilla. Dynaaminen kuvaus esitetään sekvenssi- ja tilakaavioina. Nykyisissä oliopohjaisissa menetelmissä järjestelmän kehitysprosessi on useimmiten luonteeltaan iteratiivinen (ts. vaiheet toteutetaan sykleinä, sarjoina peräkkäisiä "minivesiputouksia") ja inkrementaalinen (so. kuvauksia täydennetään ja tarkennetaan jokaisessa iteraatiossa ja uusia komponentteja otetaan vaiheittain käyttöön). Tähän pyritään myös viidennen ja kuudennen vaiheen ohjauksissa.

Analyysivaiheen luokkakaaviossa on kuvattu pääasiallisesti liiketoimintaluokkia. Suunnitteluvaiheen luokkakaaviossa esitetään liiketoimintaluokkien lisäksi myös tärkeimmät käyttöliittymä- ja ohjausluokat sekä tietorakenteita hallinnoivat luokat. Täydennetään luokkakaaviota tarvittaessa myös uusilla liiketoimintaluokilla, assosiaatioilla.

Tehtävät

1. Piirrä analyysivaiheen luokkakaavion ja yhteistoimintakaavioiden pohjalta suunnitteluvaiheen luokkakaavio. Täydennä/osita käyttöliittymä- ja ohjausluokkia ja lisää luokkiin operaatioita. Vastaavia muutoksia / täydennyksiä ei tehdä analyysivaiheen kuvauksiin (muuten kuin suunnitteluvaiheessa mahdollisesti löytyneiden uusien kohdealueluokkien osalta).
2. Määritä luokkakaavion keskeisimpien luokkien vastuut CRC-korttien avulla. Täsmennä vastuut metodeiksi ja merkitse luokkakaavioon.
   
3. Täydennä luokkakaaviota myös assosiaatioiden toteutuksen osalta: lisää viitearvoiset attribuutit, taulukkotyyppiset viiteattribuutit tai mahdolliset säiliöluokat. Kuvauksesta tulisi näkyä vähintään karkealla tasolla, millaisen tietorakenteen kautta kohdealueluokkien tietoja käytetään tai säilytetään (varsinaiseen tietokantarajapintaan ei tarvitse ottaa kantaa)
   
4. Hahmottele järjestelmän looginen arkkitehtuuri ryhmittelemällä luokat paketteihin. Käyttämästäsi työkalusta riippuen varsinaisia pakettisymboleja ei tarvitse välttämättä käyttää, kunhan pakettirakenne (ja keskeisimmät rajapinnat eri paketteihin kuuluvien luokkien välillä) käy selville luokkien asettelusta tai kommenttimerkinnöistä. Varsinaisen pakettikaavion voi piirtää erikseen. Laajemmilla järjestelmillä voit vaihtoehtoisesti piirtää eri paketeille omat luokkakaaviot. 

Vinkkejä

• Hyödynnä analyysivaiheen yhteistoimintakaaviota ja CRC-kortteja määritellessäsi metodeja luokkiin. Voit käyttää esim. seuraavaa CRC-korttipohjaa (html, doc, odt).
• Ohjeita suunnitteluvaiheen luokkakaavion laadintaan:
  
• • Jos analyysivaiheessa on mallinnettu vain yksi käyttöliittymä- ja ohjainluokka käyttötapausta kohti, tule harkita näiden ositusat erillisiin luokkiin tarvittavasta toiminnallisuudesta riippuen  (huom. käyttöliittymäluokista ei tarvitse erotella esim. yksittäisiä ikkunoita tai niiden komponentteja, vaan tarkastelu laite- tai lomake(ryhmä)tasolla riittää). Tarkastele tätä varten vaatimusmäärittelyä (=aiheen kuvaus), käyttötapauskuvauksia ja yhteistoimintakaavioita:
  • 1. Millaisten laitteiden avulla käyttäjä vuorovaikuttaa järjestelmän kanssa, voiko käyttöliittymää osittaa käyttäjien mukaan eli tarjota eri käyttäjille eri tapoja vaikuttaa järjestelmän kanssa, voiko käyttöliittymää osittaa järjestelmän tarjoamien palvelujen mukaan eli yksi käyttöliittymän osa tarjoaa yhden palvelun?
    2. Voiko ohjaimia jaotella palvelemaan eri aktoreita, tai määrätä eri ohjaimia hoitamaan eri järjestelmän toimintojen (= käyttötapausten) mukaista sovelluslogiikkaa? Jos teit vaiheen 2 yhteistoimintakaaviot ICONIX-tyylillä, kaavioon merkittyjä ohjaimia pitää erottelun sijaan tässä vaiheessa yhdistää (ICONIX-ohjaimista tulee pääosin ohjaus- ja muiden luokkien metodeja) - mieti sopivaa vastuiden jakoa CRC-korttien avulla.
       
  • Assosiaatioiden toteutus (ks. luentomonisteen kohta 5.2.5, detailed design -luentokalvot, malliharjoitustyö (ks. myös englanninkielinen versio - luokkakaaviota kehitetty) ja esim. demojen 3 vastaukset):
  • 1. Yhden-suhde-yhteen assosiaatio: Jos viestintä tapahtuu vain toiseen suuntaan, määrittele lähettävälle luokalle viitearvoinen attribuutti, joka sisältää  vastaanottavan olion viitteen (esim. nide_ref). Jos viestitään molempiin suuntiin, määrittele viiteattribuutti molempiin luokkiin.
    2. Yhden-suhde-moneen assosiaatio: Tässä luokan A mukainen olio voi olla kytketty useampaan luokan B mukaiseen olioon, mutta B:n mukainen olio vain yhteen A:n mukaiseen olioon. Toteuta siten, että määrittele luokkaan A taulukko- tai kokoelmatyyppinen (Collection, ArrayList jne) viiteattribuutti joka sisältää viitteitä B:n mukaisiin olioihin TAI määrittele erillinen "säiliöluokka" (Collection), jonka mukaiseen olioon tallennetaan viitteet - tällöin luokaan A tulee määritellä viite luotuun säiliöluokkaan (esim. AsiakasSäiliö tai pikemminkin Asiakkaat). Voit myös käyttää jotain valmista luokkakirjastoa (esim. Java Collections Framework, C++:n Standard Template Libraryn säiliöluokat tai Pythonin perustietorakenteet) tietorakenteen toteutukseen. Luokan B kannalta toteutetaan kuin 1-1-assosiaatio assosiaation kaksisuuntaisuudesta riippuen.
       
    3. Monen-suhde-moneen assosiaatio: Tässä luokan A mukainen olio voi olla kytketty useampaan luokan B mukaiseen olioon, ja B:n mukainen olio useaan A:n mukaiseen olioon. Toteutus kuten edellä TAI kahdella säiliöluokalla (ks. luentomonisten kuva 5.39).
  • Järjestelmän käyttötarkoituksesta riippuen luokkiin voi edelleen olla tarvetta lisätä liiketoimintaluokkien hakuihin ja päivityksiin liittyviä yleisiä operaatioita (lisää, hae, muokkaa,..).
• Pakettirakenne on pohja järjestelmän arkkitehtuurille ja komponenteille. Pohdi, miten eri paketeissa olevien luokkien keskinäinen kommunikointi saadaan toteutettua mahdollisimman selkeäksi.
  
• • Malliharjoitustyössä käytetty tarkkuus pakettien erottelussa riittää vaiheen hyväksymiseen. Voit kuitenkin halutessasi määritellä myös erillisiä rajapintoja (interface, pelkästään abstrakteja metodimäärityksiä sisältävä "luokka"), jotka toteuttavia (=rajapinnasta perittyjä) luokkia käytetään toteuttamaan paketin (=komponentin) tarjoamia operaatioita.
    
  • Jos rajapintoja on käytetty, paketin ulkopuoliset luokat assosioidaan ensisijaisesti paketin rajapintoihin, ei paketissa oleviin luokkiin. Näin pystytään käytännössä erottamaan järjestelmän eri "kerrokset" toisistaan ottamatta kantaa toteutukseen.