olioperustainen ohjelmistokehitys tampereen yliopisto, syksy 2000 roope raisamo

SE-02

Olioperustainen ohjelmistokehitysTampereen yliopisto, syksy 2000Roope Raisamo

perustuu Kai Koskimiehen Oliokirjaan ja kurssin aiempiin materiaaleihin

SE-02

OSA 2: Olioperustainen analyysi ja suunnittelu

Sisältö: UML-notaatio, mallinnusmenetelmät,

olioperustainen analyysi- ja suunnitteluprosessi

SE-02

Luku 7: Esimerkki ohjelmiston kehittämisestä

Olioperustainen ohjelmistokehitysprosessi

SE-02

7.2.Arkkitehtuuri-suunnittelu

Arkkitehtuurisuunnittelussa kiinnitetään järjestelmän arkkitehtuuriin

kuuluvat valinnat.

SE-02

Arkkitehtuurisuunnittelu

Arkkitehtuurivalintoja:– järjestelmän kerrokset– merkittävät komponentit– korkean tason suunnittelumallit– arkkitehtuurityylit– mahdollisen kehysarkkitehtuurin ydin– ohjelmistojen sijoittelu laitteistoihin– ohjelmistoalustat– prosessit ja niiden kommunikointi– käyttöliittymäratkaisut– [muut keskeiset ratkaisut]

SE-02

Arkkitehtuurisuunnittelu

Rakenteen kuvaukseen käytetään esimerkiksi:– luokkakaavioita– komponenttikaavioita– sijoittelukaavioita

SE-02

Arkkitehtuurisuunnittelu

Käyttäytymisen kuvaamiseen käytetään sekvenssikaavioita:– osallistujina arkkitehtuuritason elementtejä

• kuten komponentteja

– tarkentavat vaatimusanalyysin sekvenssikaavioita• kuvaavat tehtävien suorituksen arkkitehtuuritason yksiköiden välisenä

vuorovaikutuksena

SE-02

Arkkitehtuurisuunnittelu

• Esimerkkisovelluksessa ainoa merkittävä arkkitehtuuritason kysymys koskee käyttöliittymän toteutusta. – Haluamme, että varsinainen pelilogiikka on selkeästi erotettu

käyttöliittymästä• tällöin näitä voidaan muuttaa toisistaan riippumatta.

– Lisäksi haluamme varautua monen käyttäjän versioon, jossa usealla pelaajalla on näkymä samaan peliin.

SE-02

Tarkkailija-suunnittelumalli (Observer)

• Tarkkailija-suunnittelumallissa ajatellaan, että maailma koostuu kahdenlaisista olioista: subjekteista, joita tarkkaillaan, ja tarkkailijoista, jotka tarkkailevat.

• Kullakin subjektilla voi olla mielivaltaisen monta tarkkailijaa, joiden laatua subjekti ei tunne.

• Aina, kun subjektin tila muuttuu, se ilmoittaa tästä muutoksesta kaikille tarkkailijoilleen.– tarkkailijat reagoivat tähän kukin omalla tavallaan

• Kun tarkkailija haluaa alkaa tarkkailla tiettyä subjektia, se ilmoittautuu tälle.

SE-02

Tarkkailija-suunnittelumalli (Observer)

Esimerkkinä käyttöliittymäarkkitehtuuri:– Subjektina on itse sovellus tai sen osa ja tarkkailijana tämän

näkymä näytöllä.– Kun sovelluksen tila muuttuu, kaikille sen näkymille ilmoitetaan

muutoksesta.– Elementtien ei tarvitse tuntea toisiaan, vaikka ne riippuvatkin

toisistaan.– Sovelluksen ei tarvitse tuntea näyttöjen tarkempaa laatua eikä

toteutustapaa• ainoastaan tarkkailijarajapinta (operaatio), jolla muutoksesta ilmoitetaan.

SE-02

Tarkkailija-suunnittelumalli (Observer)

Tämä suunnittelumalli sopii sellaisiin tilanteisiin, joissa toisistaan riippuvat oliot halutaan toteuttaa mahdollisimman riippumattomasti.– vaikka subjektin on tunnettava tarkkailijoiden ilmoitusoperaatio

(rajapinta), subjekti ei tule riippuvaiseksi tietystä tarkkailijaluokasta.

– Tarkkailijarajapinta voidaan määritellä kutakin subjektiluokkaa kohden erikseen.

– Kaikki tarkkailijarajapinnan toteuttavat luokat voivat toimia kyseisen subjektin tarkkailijoina.

SE-02

Subjekti {abstract}

Subjekti {abstract}

Tarkkailija {abstract}

Tarkkailija {abstract}

päivitä() {abstract}päivitä() {abstract}

KonkrSubjektiKonkrSubjekti KonkrTarkkailijaKonkrTarkkailija

päivitä()päivitä()

tarkkailee *

rekisteröityy

for all g in tarkkailee { g.päivitä()}

liitä(x: Tarkkailija)poista(x: Tarkkailija)ilmoita()

Tarkkailija-suunnittelumallin luokkakaavio

SE-02

:KonkrSubjekti t1:KonkrTarkkailija

liitä(t1)

päivitä()

t2:KonkrTarkkailija

liitä(t2)

ilmoita()

päivitä()

:Alustaja

Muuttaa tilaansa

Tarkkailija-suunnittelumallin sekvenssikaavio

SE-02

Tarkkailija-suunnittelumallin soveltaminen

Esimerkkisovelluksessa:– pelikartan ja -tilanteen näyttö– käyttöliittymäelementit, joilla pelaajat vaikuttavat pelin kulkuun

Sovitaan, että näyttö on yksi yhtenäinen piirtoalue, johon piirtää vain yksi luokka.– Tämä luokka, PeliNäkymä, on tarkkailijana pelitilanteen

kuvaavalle Peli-luokalle.– PeliNäkymä-luokalla operaatio piirrä()

SE-02

Tarkkailija-suunnittelumallin soveltaminen

– Lisäksi tarvitaan luokka, joka käsittelee käyttäjän antamat syötteet.

– Tämä luokka, PeliOhjain, tarkkailee käyttöliittymätapahtumia ja kutsuu sopivia Peli-olion operaatiota päivittääkseen pelitilanteen.

– Pelitilanteen päivitys aiheuttaa PeliNäkymä-olioiden päivityksen.

SE-02

:PeliOhjain:PeliNäkymä :Peli

:Käyttäjäheitä noppaa

nopanHeitto()

päivitä()näytä noppatulos ja kohteet

kohteen valinta (q)siirräPelaaja(q)

päivitä()

päivitä()

näytä siirto, käännetäänkö?

kylläkäännäLappu()

näytä tilanne

Heittää noppaa

Lappu käännetään,pelaajan päivitys

Hakee kohdepaikat

Pelaajan siirto,tulee lappupaikalle

Arkki-tehtuuri-tason sekvenssi-kaavio käyttö-tapaukselle Askellus

SE-02

Arkkitehtuurisuunnittelu

• Tässä esimerkissä arkkitehtuurivalinnalla ei ollut kovin suurta merkitystä ja se koski vain käyttöliittymän toteutusta.

• Tarkemmin arkkitehtuureihin ja niiden suunnitteluun liittyviin asioihin perehdytään kurssin kolmannessa osassa.– erittäin tärkeä osa ohjelmiston suunnittelua erityisesti

laajemmissa ohjelmistoissa.