SE-02 Olioperustainen ohjelmistokehitys Tampereen yliopisto, syksy 2000 Roope 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 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} KonkrSubjekti KonkrTarkkailija 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 :KonkrSubjektit1: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ä() 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.