6. Suunnittelu Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja. Tavoitteena on kuvata tehtävä ohjelmisto sellaisella tarkkuudella, että sen toteutus on suoraviivaista. Kevät 2005 Ohjelmistotuotanto / Taina 1 Suunnittelun tulos Suunnittelun tuloksena saadaan kuvaukset toteutettavasta ohjelmistosta, sen tarvitsemista ja tuottamista tiedoista, ulkomaailman rajapinnoista ja mahdollisesti käytetyistä algoritmeista. Tulokset kirjataan suunnitteludokumenttiin. Dokumentti on sekä suunnittelun että ylläpidon lähdeteos. Kevät 2005 Ohjelmistotuotanto / Taina 2 Taina 1
Suunnitteluprosessi Requirements analysis Requirements specification Design activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design products Kuvalla (C) I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 3 Suunnitteluprosessin työvaiheet Oliopohjainen suunnittelu voidaan jakaa kuuteen osavaiheeseen: 1. Arkkitehtuurisuunnittelu (Architectural design) 2. Abstrakti määrittely (Abstract specification) 3. Rajapintasuunnittelu (Interface design) 4. Komponenttisuunnittelu (Component design) 5. Tietorakennesuunnittelu (Data structure design) 6. Algoritmisuunnittelu (Algorithm design) Kevät 2005 Ohjelmistotuotanto / Taina 4 Taina 2
6.1 Arkkitehtuurisuunnittelu Käytännössä jokainen ohjelma rakentuu osajärjestelmistä, jotka ovat itsenäisiä yhteistyötä tekeviä järjestelmiä. Osajärjestelmiä käytetään erottamaan metsä (koko järjestelmä) puilta (yksittäiset komponentit). Ilman osajärjestelmiä saatava arkkitehtuuri luokkineen olisi niin laaja, että sitä ei voisi hahmottaa kunnolla. Kevät 2005 Ohjelmistotuotanto / Taina 5 Osajärjestelmät Osajärjestelmä on kokonainen järjestelmä, joka toimii itsenäisesti riippumatta muiden järjestelmien tarjamista palveluista. Osajärjestelmä rakentuu komponenteista ja sisältää rajapinnat muille osajärjestelmille. Osajärjestelmä saattaa rakentua useasta aliosajärjestelmästä. Kevät 2005 Ohjelmistotuotanto / Taina 6 Taina 3
Moduulit/komponentit Moduuli on komponentti, joka tarjoaa palveluita muille moduuleille. Moduuli ei ole itsenäinen kuten osajärjestelmä. Se on vahvasti sidottu muihin moduuleihin. Sommerville ei anna selkeitä määritelmiä osajärjestelmälle, moduulille ja komponentille. Jatkossa pidämme moduulia ja komponenttia synonyymeina. Kevät 2005 Ohjelmistotuotanto / Taina 7 Arkkitehtuurimallit Osajärjestelmät tunnistetaan ja jaotellaan suunnittelun alkuvaiheessa. Apuna käytetään arkkitehtuurimalleja, kuten esimerkiksi seuraavia: Tietovarastomalli (Repository model) Osajärjestelmät erotellaan tehtävien mukaan. Kaikki osajärjestelmät käyttävät tietokantaosajärjestelmää, johon talletetaan yhteiskäytössä oleva tieto. Kukin osajärjestelmä pitää yllä omaa paikallista tietovarastoa. Kevät 2005 Ohjelmistotuotanto / Taina 8 Taina 4
Arkkitehtuurimallit - II Asiakas-palvelin -arkkitehtuuri (Clientserver architecture) Osa osajärjestelmistä on palvelimia, jotka tarjoavat palveluja. Loput ovat asiakkaita, jotka käyttävät palvelimien tarjoamia palveluita. Abstraktin koneen malli (Abstract machine model) Osajärjestelmät ovat sisäkkäisiä. Jokainen tarjoaa abstraktiotason palveluihin. Mitä alemmalla abstraktiotasolla ollaan, sitä lähempänä ollaan laitteistotasoa. Kevät 2005 Ohjelmistotuotanto / Taina 9 Lisää osajärjestelmistä Osajärjestelmien jaottelun täytyy olla sellainen, että sen tehtävällä ja tarjoamilla palveluilla on selvät rajat. Sitä mukaa kun osajärjestelmät tunnistetaan ja suunnitellaan, niiden täytyy toteuttaa seuraavat ehdot: Jokaisella osajärjestelmällä on hyvin määritelty rajapinta, jonka kautta se tarjoaa palveluja muille osajärjestelmille. Kevät 2005 Ohjelmistotuotanto / Taina 10 Taina 5
Osajärjestelmälle asetetut ehdot Osajärjestelmiä on vain muutama. Osajärjestelmä voidaan osittaa sisäisesti aliosajärjestelmiksi, jos tällainen jaottelu on luonnollinen ja jos muussa tapauksessa osajärjestelmästä tulisi laaja ja vaikeaselkoinen. Osajärjestelmä rakentuu rajapinnan toteuttavista ulkoisista komponenteista ja palvelut toteuttavista sisäisistä komponenteista. Kevät 2005 Ohjelmistotuotanto / Taina 11 Arkkitehtuurisuunnitelma Arkkitehtuurisuunnittelun tuloksena saadaan arkkitehtuurisuunnitelma. Se kuvaa löydetyt osajärjestelmät, niiden tehtävät, jaottelun moduuleiksi ja osajärjestelmien välisen yhteistyön. Arkkitehtuurisuunnitelma sisältää yleensä joukon kaaviokuvia ja yksityiskohdista kertovat kuvaustekstit Kevät 2005 Ohjelmistotuotanto / Taina 12 Taina 6
Esimerkkiarkkitehtuuri Radar system Transponder system Data comms. system Aircraft comm s. Telep ho ne system Position processor Backup position processor C o m m s. processor Backu p comms. processor Aircraft s imu lation system Flight plan d at abas e Air Traffic Control system architecture Weather map system Acco un ting system Controller info. system Controller consoles Kuvalla (C) I. Sommerville 2004 Activ ity log ging system Kevät 2005 Ohjelmistotuotanto / Taina 13 6.2 Abstrakti määrittely Löydetyille osajärjestelmille tehdään kuvaus, joka sisältää seuraavat kohdat: osajärjestelmän tehtävä, osajärjestelmän tarjoamat palvelut, osajärjestelmän säännöt ja rajoitukset, osajärjestelmän mahdollinen rinnakkaisuus muiden osajärjestelmien kanssa ja mahdolliset aliosajärjestelmät abstrakteine määrittelyineen. Kevät 2005 Ohjelmistotuotanto / Taina 14 Taina 7
6.3. Rajapintasuunnittelu Rajapintasuunnittelu on ehkä suunnittelun tärkein työvaihe. Siinä jokaisen osajärjestelmän rajapinta muihin osajärjestelmiin suunnitellaan ja dokumentoidaan yksityiskohtaisesti. Osajärjestelmien rajapintojen pitää olla sellaiset, että osajärjestelmän tarjoamia palveluja voidaan käyttää tietämättä niiden toteutuksesta mitään. Kevät 2005 Ohjelmistotuotanto / Taina 15 Rajapintojen määrittely Osajärjestelmien rajapintojen määrittelyt tulee tehdä yksiselitteisiksi ja ristiriidattomiksi. Luonnollinen kieli ei moniselitteisyytensä vuoksi riitä rajapintojen määrittelyyn. Ohjelmointikielikään ei välttämättä ole paras tapa määritellä rajapintoja, sillä ohjelmointikieli menee helposti turhan matalalle abstraktiotasolle. Kevät 2005 Ohjelmistotuotanto / Taina 16 Taina 8
Rajapintaformalismi Rajapinnan määrittelyyn voidaan käyttää jotain formalismia, kuten Sommervillen luvussa 10.2. Toisaalta formalismia tärkeämpää on valittu abstraktiotaso. Kuvauksesta täytyy selvitä tarvittavat tiedot ilman turhia toteutusriippuvia yksityiskohtia. Kevät 2005 Ohjelmistotuotanto / Taina 17 Rajapinnan kuvaus Esimerkiksi seuraava kuvaustapa sopii rajapinnoille: Rajapinnan nimi: Nimi voi kuvata myös yhtä rajapinnan palvelua tai palvelujoukkoa. Yleinen kuvaus: Yleinen kuvaus on vapaamuotoinen selostus rajapinnan tarjoamista palveluista. Kevät 2005 Ohjelmistotuotanto / Taina 18 Taina 9
Rajapinnan kuvaus - II Rajapinnan tarjoamat palvelut. Jokaisesta palvelusta nimi, yleinen kuvaus, sisään otettavat parametrit arvojoukkoineen, ulos annettavat tulokset arvojoukkoineen, poikkeustilanteet, alkuehdot ja loppuehdot. Kevät 2005 Ohjelmistotuotanto / Taina 19 Rajapinnan kuvaus - III Sisään otettavat parametrit arvojoukkoineen vastaavat metodin parametreja. Ulos annettavat tulokset arvojoukkoineen vastaavat metodin tulosta. Poikkeustilanteet kertovat, mihin erikoistapauksiin palvelussa varaudutaan. Kevät 2005 Ohjelmistotuotanto / Taina 20 Taina 10
Rajapinnan kuvaus - IV Alkuehto on jokin ehto, jonka on oltava voimassa ennen kuin palvelua voidaan käyttää. Loppuehto on jokin ehto, joka on voimassa, kun palvelu on suoritettu. Alku- ja loppuehdot eivät ole pakollisia. Kevät 2005 Ohjelmistotuotanto / Taina 21 Rajapintaesimerkki Nimi: Juuri Kuvaus: Toisen asteen yhtälön ratkaisu. Palvelu Juuri Kuvaus: Toteuttaa rajapinnan Juuri Parametrit sisään: a,b,c : R (reaalilukuja) Parametrit ulos: r 1,r 2 : R (reaalilukuja) Poikkeustilanteet: a = 0 (ei toisen asteen yhtälö) Alku- ja loppuehdot: Ei ole Kevät 2005 Ohjelmistotuotanto / Taina 22 Taina 11
Edellinen rajapinta Javalla public interface Juuri { class result { double r1; double r2; // juuret int roots; // juurten määrä }; public result Juuri(double a, double b, double c) throws aiszeroexception; }; Kuvaukset, alku- ja loppuehdot pitää laittaa kommentteina: ei ehkä sovi kuvauskieleksi. Kevät 2005 Ohjelmistotuotanto / Taina 23 6.4. Komponenttisuunnittelu Kun osajärjestelmien rajapinnat on suunniteltu huolellisesti, rajapintojen tarjoamien palveluiden toteutus ei vaikuta rajapintoihin. Rajapinnalle voi olla monta toteutusta ja toteutus voi toteuttaa monta rajapintaa. Komponenttisuunnittelu on osajärjestelmien rajapinnan toteutusta. Kevät 2005 Ohjelmistotuotanto / Taina 24 Taina 12
Komponentit Komponentti ei ole täysin itsenäinen. Se toimii yhteistyössä muiden osajärjestelmän komponenttien kanssa. Jokaisella komponentilla on rajapinta, jonka kautta päästään käsiksi komponentin tarjoamiin palveluihin, ja rajapinta, joka luettelee palvelut, jotka komponentti tarvitsee toimiakseen. Kevät 2005 Ohjelmistotuotanto / Taina 25 Oliot Lopuksi jokainen komponentti rakentuu joukosta yhteistyötä tekeviä olioita, jotka komponenttien tapaan ovat joko sisäisiä tai ulkoisia olioita. Ulkoiset oliot toteuttavat komponentin määrittelemän rajapinnan. Sisäiset oliot tarjoavat palvelut, joita ulkoiset oliot tarvitsevat rajapinnan toteutukseen. Kevät 2005 Ohjelmistotuotanto / Taina 26 Taina 13
Suunnittelun ja toteutuksen suhde Suunnittelutasolla jaottelu järjestelmäosajärjestelmä-komponentti-olio toimii hyvin. Toteutuksessa osajärjestelmistä alaspäin oliot ovat kaikkien rajapintojen toteuttajina. Suoritettavassa ohjelmistossa on vain olioita ja osajärjestelmiä. Kevät 2005 Ohjelmistotuotanto / Taina 27 6.5. Tietorakennesuunnittelu Kun järjestelmä on saatu jaettua osajärjestelmiin, komponentteihin ja olioluokkiin, voidaan miettiä kunkin elementin käyttämiä tietorakenteita. Tietorakenteet voivat olla ulkoisia, jolloin niitä käytetään osajärjestelmän sisällä useista komponenteista tai olioluokista, tai ne voivat olla sisäisiä, jolloin ne näkyvät vain tietylle olioluokalle. Kevät 2005 Ohjelmistotuotanto / Taina 28 Taina 14
6.6. Algoritmisuunnittelu Algoritmisuunnittelu on suunnitteluprosessin viimeinen vaihe. Siinä valituista ei-triviaaleista palveluista tehdään pseudokieliset kuvaukset. Kaikista palveluista ei kannata tehdä kuvauksia, sillä varsinkin sisäisiä palveluita on paljon ja useimmat niistä ovat kohtullisen suoraviivaisia toteutettavia. Kevät 2005 Ohjelmistotuotanto / Taina 29 6.7. Olioiden tunnistus Ohjelmiston jako osajärjestelmiin, komponentteihin ja olioihin on hyvä idea, mutta mistä nämä hienot elementit löydetään? Osajärjestelmät löydetään yleensä vaatimusanalyysissa ja viimeistään arkkitehtuurisuunnittelussa. Samat arkkitehtuurit toimivat samantyyppisissä ohjelmistoissa. Kevät 2005 Ohjelmistotuotanto / Taina 30 Taina 15
Olioiden tunnistus - II Seuraavat menetelmät sopivat osajärjestelmien, komponenttien ja olioiden tunnistamiseen: Sanalistat (grammatical analysis). Järjestelmän kuvauksista etsitään substantiiveja ja verbejä. Substantiivit ovat luokka-, komponentti- ja osajärjestelmäehdokkaita. Verbit ovat palveluehdokkaita. Kevät 2005 Ohjelmistotuotanto / Taina 31 Olioiden tunnistus - III Konkreettiset ehdokkaat. Järjestelmästä tunnistetaan konkreettisia kohteita (esim. koneita), toimijoita (esim. asiakkaita), tapahtumia (esim. palvelupyyntöjä), yhteistyötä (esim. tapaamisia), paikkoja (esim. toimistoja), organisaatiota (esim. yrityksiä) jne. Näitä käytetään analyysin pohjana. Analyysia täydennetään tietorakenteilla ja algoritmeilla. Kevät 2005 Ohjelmistotuotanto / Taina 32 Taina 16
Olioiden tunnistus - IV Toiminnan ymmärrys. Ensin kootaan joukko näkemyksiä tehtävästä ohjelmistosta. Jokainen näkemys sisältää joukon palveluita, jotka tunnistetaan ja sijoitellaan osajärjestelmiin. Lisäksi tunnistetaan järjestelmän toimijat ja toiminnan tulokset. Kevät 2005 Ohjelmistotuotanto / Taina 33 Olioiden tunnistus - V Skenaariolähtöinen analyysi. Jokainen löydetty skenaario analysoidaan. Skenaarion perusteella mietitään tarvittavat osajärjestelmät, komponentit ja luokat, joiden avulla skenaario on toteutettavissa. Skenaarioista eristetyt elementit yhdistetään yhteen koko järjestelmän kuvaukseksi. Kevät 2005 Ohjelmistotuotanto / Taina 34 Taina 17
Olioiden tunnistus - VI Listatut menetelmät antavat raakaelementtejä, jotka on jalostettava lopullisiksi osajärjestelmiksi, komponenteiksi ja luokiksi. Kaikkia menetelmiä käytetään usein samaan aikaan, jolloin yhdessä saadaan kattava kuva järjestelmän komponenteista ja korkean tason olioluokista. Kevät 2005 Ohjelmistotuotanto / Taina 35 6.8. Uudelleenkäyttö Oliopohjaisten menetelmien aikakaudella ohjelmiston osien uudelleenkäyttö on lisääntynyt huomattavasti. Uudelleenkäyttö säästää suunnittelu- ja toteutuskustannuksia, mutta voi lisätä ylläpitokustannuksia. Muuttuvat vaatimukset vaikuttavat sekä rajapintoihin että toteutukseen. Kevät 2005 Ohjelmistotuotanto / Taina 36 Taina 18
Uudelleenkäytön prosessi Koko suunnitteluprosessi tehdään sellaiseksi, että toteutuksessa voidaan käyttää jo aiemmin suunniteltuja, toteutettuja ja dokumentoituja ohjelman osia; suunnittelussa voidaan eristää osia, jotka voidaan dokumentoida ja tallettaa käytettäväksi muissa projekteissa. Kevät 2005 Ohjelmistotuotanto / Taina 37 Komponenttipohjainen suunnittelu Komponenttipohjaisessa suunnittelussa pyritään yhtäältä käyttämään jo olemassaolevia komponentteja ja toisaalta eristämään uusia komponentteja yleiseen käyttöön. Pelkät olioluokat ovat huonoja eristettäviä. Luokat ovat erikoistuneita ja oliot ovat usein vahvasti kytkeytyneitä muihin olioihin. Kevät 2005 Ohjelmistotuotanto / Taina 38 Taina 19
Komponentit uudelleenkäytössä Komponentti on abstraktimpi käsite kuin olio(luokka). Komponentti kapseloi yhden tai useamman yhteistyössä olevan olioluokan kokonaisuudeksi. Komponentti sopii hyvin uudelleenkäyttöön. Olioa korkeamman abstraktiotason käsitteenä se on toteutusriippumatomampi ja itsenäisempi kuin olio. Kevät 2005 Ohjelmistotuotanto / Taina 39 Komponenttien tarjoamat palvelut Komponentit tarjoavat palveluja rajapintansa kautta. Palveluiden toteutus, käytetty ohjelmointikieli ja jopa suoritusalusta eivät näy palvelupyynnön esittäjälle. Komponenttien koko ja kompleksisuus voivat vaihdella yksinkertaisista funktioista täydellisiin järjestelmiin, kuten tietokannan hallintajärjestelmä. Kevät 2005 Ohjelmistotuotanto / Taina 40 Taina 20
Komponentin rajapinnat Komponentilla on kaksi rajapintaa, sisään ja ulos: Komponentti tarjoaa rajapinnan, joka määrittelee komponentin tarjoamat palvelut. Komponentti tarvitsee rajapinnan, joka kuvaa järjestelmältä vaadittavat palvelut. Kevät 2005 Ohjelmistotuotanto / Taina 41 Komponentin rakenne Kuvalla (C) I. Sommerville 2004 Sommervillen mukaan komponentin lähdekoodi ei ole saatavilla - komponentti on määritelty rajapintansa mukaan. Todellisuudessa vain jotkut valmiina ostetut komponentit ovat vailla lähdekoodia. Tarkoitus on kuitenkin, että komponentin lähdekoodia ei käytetä, vaan luotetaan komponentin tarjoamaan Provides-rajapintaan. Kevät 2005 Ohjelmistotuotanto / Taina 42 Taina 21
Ohjelmistojen tuoteperheet Ohjelmistojen tuoteperhe (software product family) on joukko tuotteita, joilla on jokin suunnittelua helpottava yhteys. Tuoteperheen jäsenet voivat toteuttaa ohjelmistot, joilla on samankaltainen käyttöliittymä ja ulkonäkö (look and feel), saman ohjelmiston eri alustoille, saman ohjelmiston eri ulkoisille liittymille tai ohjelmistot, joilla on yhteinen ydin. Kevät 2005 Ohjelmistotuotanto / Taina 43 Esimerkkituoteperheitä Esimerkiksi seuraavat ovat ohjelmistojen tuoteperheitä: Microsoft Office (yhteinen ydin) Nokian kännyköiden käyttöohjelmistot (yhteinen ydin ja käyttöliittymä) Halo (videopeli) (sama ohjelmisto eri alustoille) ja ohjelmoitavien logiikoiden tuoteperheet (sama ohjelmisto eri ulkoisille liittymille) Kevät 2005 Ohjelmistotuotanto / Taina 44 Taina 22
Tuoteperheen edut Tuoteperheen tunnistaminen ja käyttö helpottaa vaatimusanalyysiä. Yhteisistä piirteistä seuraa yhteisiä vaatimuksia. suunnittelua. Yhteiset osat voidaan suunnitella kerralla. Vain sovellusriippuvat osat joudutaan suunnittelemaan erikseen. testausta. Testaus voidaan yhtenäistää ja yksinkertaistaa käyttämällä samoja testitapauksia sovellusten välillä. Kevät 2005 Ohjelmistotuotanto / Taina 45 Tuoteperheen haitat Toisaalta tuoteperheet vaikeuttavat vaatimusanalyysia. Aina ei ole selvää, mitkä tuotteet kuuluvat tuoteperheeseen. suunnittelua. Jotta tuoteperheestä on etua, perheen yhteiset osat on tunnistettava, rajapinnoista on tehtävä sellaiset, että tuoteperheen tuotteet voidaan toteuttaa ja ytimen toimintojen on sovittava kaikille tuotteille testausta. Hallintatyötä tulee lisää. Kevät 2005 Ohjelmistotuotanto / Taina 46 Taina 23
Hyvä tuoteperhe Hyvän tuoteperheen edut ovat selvästi vahvemmat kuin haitat. Hyvä tuoteperhe: perheen tuotteilla on niin paljon yhteistä, että yhteisistä osista saatava säästö voittaa haitoista syntyvät kustannukset. Tuoteperheen suunnittelussa on oltava tarkkana, että ei yritetä tehdä tuoteperhettä tuotteista, joilla ei ole tarpeeksi yhteistä. Kevät 2005 Ohjelmistotuotanto / Taina 47 Tuoteperheen suunnittelu Tuoteperhe suunnitellaan vaiheittain: Ensin tunnistetaan ja suunnitellaan tuoteperheen yhteinen osa (ydin). Jatkossa tuotteita lisätään perheeseen yksitellen. Jokaisen tuotteen kohdalla tarkistetaan, että tuote voi käyttää tunnistettua ydintä. Riittää, että lisättävä tuote käyttää osaa ytimestä, jos ytimen käyttämättömät osat eivät häiritse sovelluskohtaisia osia. Kevät 2005 Ohjelmistotuotanto / Taina 48 Taina 24
Suunnittelumallit Valmiiden komponenttien käyttö suunnittelussa onnistuu silloin, kun sopivia komponentteja on saatavilla. Vaikka komponentit olisi suunniteltava ja toteutettava itse, suunnittelussa voidaan käyttää hyväksi hyväksi havaittuja suunnitteluperiaatteita. Kevät 2005 Ohjelmistotuotanto / Taina 49 Suunnittelumallit - II Hyväksi havaittuja suunnitteluperiaatteita kutsutaan suunnittelumalleiksi (design patterns). Suunnittelumallit lähtevät ajatuksesta, että samat perusrakenteet toistuvat oliopohjaisessa suunnittelussa jatkuvasti. Kevät 2005 Ohjelmistotuotanto / Taina 50 Taina 25
Suunnittelumallit - III Malli tarjoaa nimensä mukaisesti hyväksi havaitun menetelmän ratkaista tunnettu suunnitteluongelma. Ratkaisu on yleensä esitetty sellaisella abstraktiotasolla, että sen perusteella voidaan tehdä sopivia toteutuksia erilaisiin sovelluksiin ja ympäristöihin. Kevät 2005 Ohjelmistotuotanto / Taina 51 Suunnittelumallien edut ja haitat Vaikeinta suunnittelumalleissa on tunnistaa oikea malli oikeaan tehtävään. Yleisimmät mallit tulevat kuitenkin hyvin nopeasti tutuiksi ja käyttökelpoisiksi. Mallien hallinta ja käyttö helpottaa huomattavasti hyvien oliopohjaisten ratkaisujen suunnittelua. Kevät 2005 Ohjelmistotuotanto / Taina 52 Taina 26
Suunnittelumallin rakenne Suunnittelumallin kuvaus sisältää seuraavat osat: Mallin nimi Nimi on mallia kuvaava tunniste suunnittelumallille. Kuvaus Kuvaus selittää, mikä on mallin tehtävä ja miten malli toimii. Mallin nimi ja kuvaus yhdessä kertovat suunnittelijalle, onko mallille käyttöä suunnitelmassa. Kevät 2005 Ohjelmistotuotanto / Taina 53 Suunnittelumallin rakenne - II Ongelmakuvaus Ongelmakuvaus selittää ongelmakentän, mihin malli tuo ratkaisun. Ratkaisukuvaus Ratkaisukuvaus selittää ratkaisussa tarvittavat osat, niiden tehtävät ja osien väliset suhteet. Ratkaisukuvaus astetta abstraktimmalla tasolla kuin yksityiskohtainen kieliriippuva toteutus. Seuraukset Seurauksissa kuvataan mallin käytön seuraukset ja mahdolliset sivuvaikutukset. Kevät 2005 Ohjelmistotuotanto / Taina 54 Taina 27
Suunnittelumalliesimerkki Esimerkkinä suunnittelumalleista esitän Observer-suunnittelumallin (tarkkailija? no miten vaan). Observer-mallia käytetään, kun olion tilasta tarvitaan useita erilaisia esityksiä. Malli erottaa esitettävän olion esityksen toteuttavista olioista. Kevät 2005 Ohjelmistotuotanto / Taina 55 Suunnittelumalli (jatkuu) Obsever-mallin avulla voidaan esimerkiksi kuvata samaa tietoa taulukkona, piirakkana tai käyränä. Kun tieto muuttuu, muutokset näkyvät automaattisesti kaikissa Observermallilla toteutetuissa tiedon esitysnäkymissä. Kevät 2005 Ohjelmistotuotanto / Taina 56 Taina 28
Suunnittelumalliesimerkki (jatkuu) C D B A 50 25 A B C D 0 Subject Observer 1 A: 40 B: 25 C: 15 D: 20 Observer 2 Kuvalla (C) I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 57 Suunnittelumalli Observer Nimi Observer Kuvaus Eristää olion tilan esityksen itse oliosta Ongelmakuvaus Observer ratkaisee tilanteen, missä samasta oliosta tarvitaan automaattisesti muuttuvia erilaisia näkymiä. Kevät 2005 Ohjelmistotuotanto / Taina 58 Taina 29
Suunnittelumalli Observer - II Ratkaisukuvaus Seuraavalla kalvolla UML:lla. Seuraukset Tilan esitysten optimointi on epäkäytännöllistä. Kevät 2005 Ohjelmistotuotanto / Taina 59 Ratkaisukuvaus Observer Subject Observer Attach (Observer) Detach (Observer) Notify () for all o in observers o -> Update () Update () ConcreteSubject ConcreteObserver GetState () subjectstate return subjectstate Update () observerstate observerstate = subject -> GetState () Kuvalla (C) I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 60 Taina 30