6. Suunnittelu Suunnittelun tulos 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 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 Suunnitteluprosessi Suunnitteluprosessin työvaiheet Requirements analysis Architectural design System architecture Requirements Abstract Software Kuvalla (C) I. Sommerville 2004 Interface design Interface Design activities Component design Component Design products Data structure design Data structure Algorithm design Algorithm Oliopohjainen suunnittelu voidaan jakaa kuuteen osavaiheeseen: 1. Arkkitehtuurisuunnittelu (Architectural design) 2. Abstrakti määrittely (Abstract ) 3. Rajapintasuunnittelu (Interface design) 4. Komponenttisuunnittelu (Component design) 5. Tietorakennesuunnittelu (Data structure design) 6. Algoritmisuunnittelu (Algorithm design) Kevät 2005 Ohjelmistotuotanto / Taina 3 Kevät 2005 Ohjelmistotuotanto / Taina 4 6.1 Arkkitehtuurisuunnittelu Osajärjestelmät 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ä 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 1
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 Arkkitehtuurimallit - II Lisää osajärjestelmistä 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 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 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 2
Esimerkkiarkkitehtuuri 6.2 Abstrakti määrittely Radar P o siti on processor Aircraft s imulatio n Weather map Accounting Transpo nd er Kuvalla (C) I. Sommerville 2004 Backup p os ition processor Da ta com ms. Flight plan d atabas e C o ntro l er info. C o m m s. processor Aircraft c om m s. Activ ity logging Telep ho ne Backup comms. processor Air Traffic Control architecture Controller consoles 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 13 Kevät 2005 Ohjelmistotuotanto / Taina 14 6.3. Rajapintasuunnittelu Rajapintojen määrittely 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 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 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. 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 17 Kevät 2005 Ohjelmistotuotanto / Taina 18 Taina 3
Rajapinnan kuvaus - II Rajapinnan kuvaus - III 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 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 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 Nimi: Juuri Rajapintaesimerkki 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 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 4
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. 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 25 Kevät 2005 Ohjelmistotuotanto / Taina 26 Suunnittelun ja toteutuksen suhde 6.5. Tietorakennesuunnittelu 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 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 6.6. Algoritmisuunnittelu 6.7. Olioiden tunnistus 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 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 5
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. 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 31 Kevät 2005 Ohjelmistotuotanto / Taina 32 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. 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 33 Kevät 2005 Ohjelmistotuotanto / Taina 34 Olioiden tunnistus - VI 6.8. Uudelleenkäyttö 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 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 6
Uudelleenkäytön prosessi Komponenttipohjainen suunnittelu 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 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 Komponentit uudelleenkäytössä Komponenttien tarjoamat palvelut 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 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 Komponentin rajapinnat Komponentin rakenne 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 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 7
Ohjelmistojen tuoteperheet Esimerkkituoteperheitä 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 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 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 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 8
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. 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 49 Kevät 2005 Ohjelmistotuotanto / Taina 50 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. 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 51 Kevät 2005 Ohjelmistotuotanto / Taina 52 Suunnittelumallin rakenne Suunnittelumallin rakenne - II 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 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 9
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. 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 55 Kevät 2005 Ohjelmistotuotanto / Taina 56 Suunnittelumalliesimerkki (jatkuu) C D B A Subject A B C D 0 Observer 1 A: 40 B: 25 C: 15 D: 20 Observer 2 Kuvalla (C) I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 57 50 25 Nimi Suunnittelumalli Observer 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 Suunnittelumalli Observer - II Ratkaisukuvaus Observer Ratkaisukuvaus Seuraavalla kalvolla UML:lla. Seuraukset Tilan esitysten optimointi on epäkäytännöllistä. Subject Attach (Observer) Detach (Observer) Notify () ConcreteSubject for all o in observers o -> Update () Observer Update () ConcreteObserver GetState () subjectstate return subjectstate Update () observerstate observerstate = subject -> GetState () Kuvalla (C) I. Sommerville 2004 Kevät 2005 Ohjelmistotuotanto / Taina 59 Kevät 2005 Ohjelmistotuotanto / Taina 60 Taina 10