OOAD – Oliosuuntautunut suunnittelu

Analyysivaiheen jälkeen käsitemallia kehitetään edelleen oliosuuntautuneeksi malliksi oliosuuntautuneella suunnittelulla (Object-oriented Design, OOD). OOD:ssa analyysimallin teknologiariippumattomat käsitteet kartoitetaan toteuttaviin luokkiin, tunnistetaan rajoitteet ja suunnitellaan rajapinnat, jolloin saadaan aikaan ratkaisualueen malli. Pähkinänkuoressa, rakennetaan yksityiskohtainen kuvaus, jossa määritellään, miten järjestelmä rakennetaan konkreettisten teknologioiden varaan

Objektipainotteisen suunnittelun vaiheet voidaan tunnistaa seuraavasti: –

• Kontekstin määritteleminen järjestelmän
• Järjestelmän arkkitehtuurin suunnittelu
• Järjestelmän objektien tunnistaminen
• Suunnittelumallien rakentaminen
• Objektien rajapintojen määrittely

Järjestelmän suunnittelu

Objekti-orientoituneeseen järjestelmäsuunnitteluun kuuluu järjestelmän kontekstin määrittely ja sen jälkeen järjestelmän arkkitehtuurin suunnittelu.

• Konteksti – Järjestelmän kontekstissa on staattinen ja dynaaminen osa. Järjestelmän staattinen konteksti suunnitellaan käyttämällä yksinkertaista koko järjestelmän lohkokaaviota, joka laajennetaan osajärjestelmien hierarkiaksi. Osajärjestelmämalli esitetään UML-paketeilla. Dynaaminen konteksti kuvaa, miten järjestelmä on vuorovaikutuksessa ympäristönsä kanssa. Se mallinnetaan käyttötapauskaavioiden avulla.

• Järjestelmän arkkitehtuuri – Järjestelmän arkkitehtuuri suunnitellaan järjestelmän kontekstin perusteella arkkitehtuurisuunnittelun periaatteiden sekä toimialatiedon mukaisesti. Tyypillisesti järjestelmä jaetaan kerroksiin ja kukin kerros hajotetaan osajärjestelmiksi.

Objektipainotteinen hajottaminen

Hajottamisella tarkoitetaan suuren monimutkaisen järjestelmän jakamista hierarkkisesti pienempiin, kompleksisuudeltaan pienempiin komponentteihin hajota ja hallitse -periaatteiden mukaisesti. Järjestelmän kutakin pääkomponenttia kutsutaan osajärjestelmäksi. Oliosuuntautuneessa purkamisessa tunnistetaan järjestelmän yksittäiset autonomiset objektit ja näiden objektien välinen kommunikaatio.

Purkamisen etuja ovat –

• Yksittäiset komponentit ovat monimutkaisuudeltaan vähäisempiä ja siten ymmärrettävämpiä ja helpommin hallittavissa.

• Se mahdollistaa erikoisammattitaitoa omaavan työvoiman jakamisen.

• Se mahdollistaa osajärjestelmien korvaamisen tai muuttamisen vaikuttamatta muihin osajärjestelmiin.

Tunnistaminen Rinnakkaisuus

Rinnakkaisuus mahdollistaa sen, että useampi kuin yksi objekti voi vastaanottaa tapahtumia samanaikaisesti ja useampi kuin yksi aktiviteetti voidaan suorittaa samanaikaisesti. Rinnakkaisuus tunnistetaan ja esitetään dynaamisessa mallissa.

Rinnakkaisuuden mahdollistamiseksi jokaiselle rinnakkaiselle elementille osoitetaan oma kontrollisäie. Jos samanaikaisuus on objektitasolla, kahdelle samanaikaiselle objektille osoitetaan kaksi eri ohjaussäiettä. Jos yhden objektin kaksi operaatiota ovat luonteeltaan samanaikaisia, kyseinen objekti jaetaan eri säikeiden kesken.

Rinnakkaisuuteen liittyy datan eheyden, umpikujan ja nääntymisen ongelmia. Siksi on laadittava selkeä strategia aina, kun rinnakkaisuutta tarvitaan. Lisäksi rinnakkaisuus on tunnistettava jo suunnitteluvaiheessa, eikä sitä voi jättää toteutusvaiheeseen.

Mallien tunnistaminen

Sovelluksia suunniteltaessa omaksutaan joitakin yleisesti hyväksyttyjä ratkaisuja joihinkin ongelmaluokkiin. Nämä ovat suunnittelumalleja. Kuvio voidaan määritellä dokumentoiduksi joukoksi rakennuspalikoita, joita voidaan käyttää tietyntyyppisissä sovelluskehitysongelmissa.

Joitakin yleisesti käytettyjä suunnittelumalleja ovat –

• Façade pattern
• Model view separation pattern
• Observer pattern
• Model view controller pattern
• Publish subscribe pattern
• Proxy pattern

Controlling Events

Systeemin suunnittelun aikana, järjestelmän objekteissa mahdollisesti esiintyvät tapahtumat on tunnistettava ja käsiteltävä asianmukaisesti.

Tapahtuma on määrittely merkittävästä tapahtumasta, jolla on paikka ajassa ja tilassa.

Mallinnettavia tapahtumatyyppejä on neljä: –

• Signaalitapahtuma – Nimetyn objektin heittämä tapahtuma, jonka yksi objekti heittää ja jonka toinen objekti ottaa kiinni.

• Kutsutapahtuma – Synkroninen tapahtuma, joka edustaa operaation lähetystä.

• Aika-tapahtuma – Tapahtuma, joka edustaa ajan kulumista.

• Muutos-tapahtuma – Tapahtuma, joka edustaa tilassa tapahtuvaa muutosta.

Reunaehtojen käsittely

Järjestelmän suunnitteluvaiheessa on käsiteltävä sekä koko järjestelmän että kunkin osajärjestelmän initiaattorointia ja päättämistä. Dokumentoitavat eri näkökohdat ovat seuraavat –

• Järjestelmän käynnistys eli järjestelmän siirtyminen ei-initialisoidusta tilasta vakaaseen tilaan.

• Järjestelmän lopettaminen eli, kaikkien käynnissä olevien säikeiden sulkeminen, resurssien siivoaminen ja lähetettävät viestit.

• Järjestelmän alustava konfigurointi ja järjestelmän uudelleenkonfigurointi tarvittaessa.

• Järjestelmän vikojen tai ei-toivotun lopettamisen ennakointi.

Rajatilanteet mallinnetaan rajankäyttötilanteiden avulla.

Objektien suunnittelu

Kun osajärjestelmien hierarkia on kehitetty, tunnistetaan järjestelmän objektit ja suunnitellaan niiden yksityiskohdat. Tässä suunnittelija esittelee yksityiskohtaisesti järjestelmän suunnittelun aikana valitun strategian. Painopiste siirtyy sovellusalueen käsitteistä kohti tietokonekäsitteitä. Analyysin aikana tunnistetut objektit kaiverretaan toteutusta varten tavoitteena minimoida suoritusaika, muistin kulutus ja kokonaiskustannukset.

Objektien suunnittelu sisältää seuraavat vaiheet –

• Objektien tunnistaminen
• Objektien esittäminen, ts, suunnittelumallien rakentaminen
• Toimintojen luokittelu
• Algoritmien suunnittelu
• Suhteiden suunnittelu
• Ulkoisten vuorovaikutusten hallinnan toteuttaminen
• Luokkien ja assosiaatioiden paketoiminen moduuleiksi

Objektien tunnistaminen

Objektisuunnittelun ensimmäinen vaihe on objektien tunnistaminen. Oliopohjaisen analyysin vaiheissa tunnistetut objektit ryhmitellään luokiksi ja tarkennetaan siten, että ne soveltuvat varsinaiseen toteutukseen.

Tämän vaiheen tehtäviä ovat –

• Kunkin osajärjestelmän tai paketin luokkien tunnistaminen ja tarkentaminen

• Luokkien välisten yhteyksien ja assosiaatioiden määrittely

• Luokkien välisten hierarkkisten assosiaatioiden suunnitteleminen, ts, yleistäminen/erikoistaminen ja periytyminen

• Aggregaatioiden suunnittelu

Objektien esittäminen

Kun luokat on tunnistettu, ne on esitettävä objektimallinnustekniikoiden avulla. Tähän vaiheeseen kuuluu olennaisesti UML-kaavioiden rakentaminen.

Tarvitaan kahdenlaisia suunnittelumalleja –

• Staattiset mallit – Järjestelmän staattisen rakenteen kuvaaminen luokka- ja objektikaavioiden avulla.

• Dynaamiset mallit – Järjestelmän dynaamisen rakenteen kuvaaminen ja luokkien välisen vuorovaikutuksen esittäminen vuorovaikutuskaavioiden ja tilakaavioiden avulla.

Toimintojen luokittelu

Tässä vaiheessa määritetään objekteille suoritettavat operaatiot yhdistämällä OOA-vaiheessa kehitetyt kolme mallia eli objektimalli, dynaaminen malli ja toiminnallinen malli. Operaatio määrittää, mitä tehdään, mutta ei sitä, miten se tehdään.

Operaatioiden osalta suoritetaan seuraavat tehtävät –

• Kehitetään järjestelmän jokaisen objektin tilasiirtymäkaavio.

• Objektien vastaanottamille tapahtumille määritellään operaatiot.

• Tunnistetaan tapaukset, joissa yksi tapahtuma laukaisee muita tapahtumia samoissa tai eri objekteissa.

• Tunnistetaan operaatioiden sisällä olevat alaoperaatiot.

• Pääoperaatiot laajennetaan tietovirtakaavioiksi.

Algoritminsuunnittelu

Objekteissa olevat operaatiot määritetään algoritmeilla. Algoritmi on vaiheittainen menettely, joka ratkaisee operaatiossa asetetun ongelman. Algoritmeissa keskitytään siihen, miten se on tehtävä.

Joitakin operaatioita vastaavia algoritmeja voi olla useampia kuin yksi. Kun vaihtoehtoiset algoritmit on tunnistettu, valitaan optimaalinen algoritmi kyseiselle ongelma-alueelle. Optimaalisen algoritmin valinnassa käytettävät mittarit ovat –

• Laskennallinen monimutkaisuus – Monimutkaisuus määrittää algoritmin tehokkuuden laskenta-ajan ja muistivaatimusten suhteen.

• Joustettavuus – Joustavuus määrittää sen, voidaanko valittu algoritmi toteuttaa sopivasti ilman, että se menettää soveltuvuuttaan erilaisissa ympäristöissä.

• Ymmärrettävyys – Tämä määrittää, onko valittu algoritmi helposti ymmärrettävissä ja toteutettavissa.

Suhteiden suunnittelu

Suhteiden toteuttamisstrategia on laadittava kohteiden suunnitteluvaiheessa. Tärkeimmät käsiteltävät suhteet koostuvat assosiaatioista, aggregaatioista ja perinnöistä.

Suunnittelijan tulee tehdä assosiaatioiden osalta seuraavat toimet –

• Tunnista, onko assosiaatio yksisuuntainen vai kaksisuuntainen.

• Analysoi assosiaatioiden polku ja päivitä ne tarvittaessa.

• Toteuta assosiaatio erillisenä objektina, jos kyseessä on monesta moniin -suhteet; tai linkkinä toiseen objektiin, jos kyseessä on yksi yhteen tai yksi moniin -suhteet.

Perimän osalta suunnittelijan tulisi tehdä seuraavaa –

• Sovita luokkia ja niiden assosiaatioita.

• Tunnista abstraktit luokat.

• Tehdä määräyksiä, jotta käyttäytymistä voidaan tarvittaessa jakaa.

Hallinnan toteuttaminen

Objektisuunnittelija voi sisällyttää tarkennuksia tilakaavion mallin strategiaan. Järjestelmäsuunnittelussa tehdään perusstrategia dynaamisen mallin toteuttamiseksi. Oliosuunnittelun aikana tätä strategiaa kaunistellaan sopivaa toteutusta varten.

Lähestymistavat dynaamisen mallin toteuttamiseen ovat –

• Tilan esittäminen sijaintina ohjelmassa – Tämä on perinteinen menettelytapaan perustuva lähestymistapa, jossa ohjauksen sijainti määrittelee ohjelman tilan. Äärellinen tilakone voidaan toteuttaa ohjelmana. Siirtymä muodostaa syöttölauseen, pääohjauspolku muodostaa käskysarjan, haarautumat muodostavat ehdot ja taaksepäin kulkevat polut muodostavat silmukat tai iteraatiot.

• Tilakone-moottori – Tämä lähestymistapa esittää tilakoneen suoraan tilakone-moottoriluokan avulla. Tämä luokka suorittaa tilakonetta sovelluksen antamien siirtymien ja toimintojen kautta.

• Valvonta samanaikaisina tehtävinä – Tässä lähestymistavassa objekti toteutetaan ohjelmointikielen tai käyttöjärjestelmän tehtävänä. Tässä tapahtuma toteutetaan tehtävien välisenä kutsuna. Se säilyttää todellisten objektien luontaisen samanaikaisuuden.

Luokkien paketoiminen

Missä tahansa suuressa projektissa toteutuksen huolellinen jakaminen moduuleihin tai paketteihin on tärkeää. Oliosuunnittelun aikana luokat ja objektit ryhmitellään paketteihin, jotta useat ryhmät voivat työskennellä yhteistyössä projektin parissa.

Paketoinnin eri osa-alueet ovat –

• Sisäisen informaation piilottaminen ulkopuolisilta – Sen avulla luokkaa voidaan tarkastella ”mustana laatikkona”, ja se sallii luokkien toteutuksen muuttamisen ilman, että luokkien asiakkailta vaaditaan koodin muuttamista.

• Elementtien johdonmukaisuus – Elementti, kuten luokka, operaatio tai moduuli, on johdonmukainen, jos se on organisoitu johdonmukaisen suunnitelman mukaan ja kaikki sen osat liittyvät luontaisesti toisiinsa siten, että ne palvelevat yhteistä päämäärää.

• Fysikaalisten moduulien rakentaminen – Fysikaalisia moduuleja rakennettaessa auttavat seuraavat ohjeet –

  • Moduulin luokkien tulisi edustaa samankaltaisia asioita tai komponentteja samassa yhdistetyssä objektissa.

  • Lyhyesti toisiinsa yhteydessä olevien luokkien tulisi olla samassa moduulissa.

  • Kytkeytymättömät tai heikosti toisiinsa yhteydessä olevat luokat tulisi sijoittaa erillisiin moduuleihin.

  • Moduuleilla tulisi olla hyvä koheesio, ts, korkea yhteistyö sen komponenttien välillä.

  • Moduulilla tulisi olla vähäinen kytkentä muiden moduulien kanssa, eli vuorovaikutuksen tai keskinäisen riippuvuuden moduulien välillä tulisi olla minimaalista.

Suunnittelun optimointi

Analyysimalli kaappaa loogisen tiedon järjestelmästä, kun taas suunnittelumalli lisää yksityiskohtia, jotka tukevat tehokasta tiedonkäyttöä. Ennen kuin malli toteutetaan, se on optimoitava, jotta toteutus olisi tehokkaampi. Optimoinnin tavoitteena on minimoida kustannukset ajan, tilan ja muiden mittareiden suhteen.

Suunnittelun optimointi ei kuitenkaan saisi olla liiallinen, sillä myös toteutuksen helppous, ylläpidettävyys ja laajennettavuus ovat tärkeitä asioita. Usein nähdään, että täydellisesti optimoitu suunnittelu on tehokkaampaa mutta vähemmän luettavaa ja uudelleenkäytettävää. Suunnittelijan on siis löydettävä tasapaino näiden kahden välillä.

Erilaisia asioita, joita voidaan tehdä suunnittelun optimoimiseksi, ovat –

• Lisää turhia assosiaatioita
• Lupaa pois käyttökelvottomia assosiaatioita
• Algoritmien optimointi
• Tallenna johdettuja attribuutteja, jotta vältyttäisiin monimutkaisten lausekkeiden uudelleenkääntämiseltä

Turhien assosiaatioiden lisääminen

Suunnittelun optimoinnin aikana, tarkistetaan, voidaanko uusien assosiaatioiden johtamisella vähentää käyttökustannuksia. Vaikka nämä tarpeettomat assosioinnit eivät välttämättä lisää informaatiota, ne voivat lisätä kokonaismallin tehokkuutta.

Käyttökelvottomien assosiaatioiden lisääminen

Liian monien assosiaatioiden esiintyminen voi tehdä järjestelmästä käsittämättömän ja siten vähentää järjestelmän kokonaistehokkuutta. Niinpä optimoinnin aikana kaikki käyttökelvottomat assosiaatiot poistetaan.

Algoritmien optimointi

Objektipohjaisissa järjestelmissä tietorakenteiden ja algoritmien optimointi tehdään yhteistyössä. Kun luokkasuunnittelu on valmis, operaatiot ja algoritmit on optimoitava.

Algoritmien optimointi saadaan aikaan –

• Laskentatehtävien järjestyksen uudelleenjärjestelyllä
• Silmukoiden suoritusjärjestyksen muuttamisella toiminnallisessa mallissa määrätystä järjestyksestä

.

• Algoritmin kuolleiden polkujen poistaminen

Ohjattujen attribuuttien tallentaminen ja tallentaminen

Ohjattuja attribuutteja ovat ne attribuutit, joiden arvot lasketaan muiden attribuuttien (perusattribuuttien) funktiona. Johdettujen attribuuttien arvojen uudelleen laskeminen joka kerta, kun niitä tarvitaan, on aikaa vievä toimenpide. Tämän välttämiseksi arvot voidaan laskea ja tallentaa laskennallisessa muodossaan.

Tämä voi kuitenkin aiheuttaa päivityspoikkeamia, eli perusattribuuttien arvojen muuttumista ilman vastaavaa muutosta johdettujen attribuuttien arvoissa. Tämän välttämiseksi toteutetaan seuraavat toimenpiteet –

• Kunkin perusattribuutin arvon päivityksen yhteydessä myös johdettu attribuutti lasketaan uudelleen.

• Kaikki johdetut attribuutit lasketaan uudelleen ja päivitetään määräajoin ryhmässä eikä jokaisen päivityksen jälkeen.

Suunnitteludokumentaatio

Dokumentaatio on olennainen osa mitä tahansa ohjelmistokehitysprosessia, johon kirjataan ohjelmiston tekemisprosessi. Suunnittelupäätökset on dokumentoitava kaikissa ei-triviaaleissa ohjelmistojärjestelmissä, jotta suunnittelu voidaan välittää muille.

Käyttöalueet

Hyvä dokumentaatio on välttämätön, vaikka se onkin toissijainen tuote, erityisesti seuraavilla aloilla –

• Suunniteltaessa ohjelmistoja, joita useat kehittäjät kehittävät
• Iteratiivisissa ohjelmistokehitysstrategioissa
• Ohjelmistoprojektin myöhempien versioiden kehittämisessä
• Ohjelmiston arvioinnissa
• Testausehtojen ja -alueiden löytämisessä
• Ohjelmiston ylläpidossa.

Sisältö

Hyödyllisen dokumentaation tulisi sisältää olennaisesti seuraavat sisällöt –

• Korkean tason järjestelmäarkkitehtuuri – Prosessikaaviot ja moduulidiagrammit

• Keskeiset abstraktiot ja mekanismit – Luokkakaaviot ja objektikaaviot.

• Skenaariot, jotka havainnollistavat tärkeimpien osa-alueiden käyttäytymistä – Käyttäytymiskaaviot

Piirteet

Hyvän dokumentaation piirteet ovat –

• Ymmärrettävä ja samalla yksiselitteinen, johdonmukaisia ja täydellisiä

• Jäljitettävissä järjestelmän vaatimusmäärittelyihin

• Hyvin jäsennelty

• Diagrammimainen kuvailevien sijaan