olioperustainen ohjelmistokehitys tampereen yliopisto, syksy 2000 roope raisamo
DESCRIPTION
Olioperustainen ohjelmistokehitys Tampereen yliopisto, syksy 2000 Roope Raisamo. perustuu Kai Koskimiehen Oliokirjaan ja kurssin aiempiin materiaaleihin. OSA 2: Olioperustainen analyysi ja suunnittelu. - PowerPoint PPT PresentationTRANSCRIPT
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.