Olioperustainen ohjelmistokehitys Tampereen yliopisto, syksy 2000 Roope Raisamo

1. Olioperustainen ohjelmistokehitysTampereen yliopisto, syksy 2000Roope Raisamo perustuu Kai Koskimiehen Oliokirjaan ja kurssin aiempiin materiaaleihin

2. OSA 2: Olioperustainen analyysi ja suunnittelu Sisältö: UML-notaatio, mallinnusmenetelmät, olioperustainen analyysi- ja suunnitteluprosessi

3. Luku 7: Esimerkki ohjelmiston kehittämisestä Olioperustainen ohjelmistokehitysprosessi

4. 7.2. Arkkitehtuuri-suunnittelu Arkkitehtuurisuunnittelussakiinnitetään järjestelmän arkkitehtuuriin kuuluvat valinnat.

5. 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]

6. Arkkitehtuurisuunnittelu Rakenteen kuvaukseen käytetään esimerkiksi: • luokkakaavioita • komponenttikaavioita • sijoittelukaavioita

7. 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

8. 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.

9. 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.

10. 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.

11. 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.

12. Tarkkailija-suunnittelumallin luokkakaavio Tarkkailija {abstract} päivitä() {abstract} päivitä() for all g in tarkkailee { g.päivitä() } tarkkailee Subjekti {abstract} * liitä(x: Tarkkailija) poista(x: Tarkkailija) ilmoita() rekisteröityy KonkrSubjekti KonkrTarkkailija

13. Tarkkailija-suunnittelumallin sekvenssikaavio Muuttaa tilaansa päivitä() :KonkrSubjekti t1:KonkrTarkkailija t2:KonkrTarkkailija :Alustaja liitä(t1) liitä(t2) ilmoita() päivitä()

14. 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ä()

15. 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.

16. Arkki-tehtuuri-tason sekvenssi-kaavio käyttö-tapaukselle Askellus :Peli :PeliNäkymä :PeliOhjain :Käyttäjä heitä noppaa nopanHeitto() Heittää noppaa Hakee kohdepaikat näytä noppatulos ja kohteet päivitä() kohteen valinta (q) siirräPelaaja(q) Pelaajan siirto, tulee lappupaikalle näytä siirto, käännetäänkö? päivitä() kyllä käännäLappu() Lappu käännetään, pelaajan päivitys päivitä() näytä tilanne

17. 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.