Suunnittelumallit OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Oliosuuntautunut analyysi ja -suunnittelu 27. joulukuuta 2003 Mikael Kujanpää mahead@ee.oulu.fi LuTK / TOL -03
Tiivistelmä Suunnittelumallit ovat tärkeä työkalu nykypäivän oliopohjaisessa ohjelmistotuotannossa. Mallit tarjoavat tiettyihin ongelmiin valmiit, ajankuluessa hyviksi todetut ratkaisut. Mallien avulla jokaisen ongelman kohdalla suunnittelijoiden ei tarvitse keksiä pyörää uudelleen. Suunnittelumallien avulla voidaan parantaa ohjelmiston ylläpidettävyyttä, kustannustehokkuutta ja vähentää loogisten ohjelmointivirheiden määrää. Toisaalta ohjelmistomalleja oikeaoppisesti sovellettuna saavutetaan ylläpidettävämpi ja rakenteellisesti looginen, hyvin toimiva ohjelmisto. Antisuunnittelumallit ovat malleja, joiden avulla voidaan etsiä huonoja, epätoivottavia ohjelmistosuunnitteluratkaisuja. Olio-ohjelmoinnin kultakausi alkoi 1980-luvulta, alettaessa esittää graafisten käyttöliittymien osia olioiden avulla. Vaikka oliot ovatkin varsin luonnollinen tapa mallintaa ohjelmistoja ja niiden komponentteja, on niidenkin hyödyntämisessä omat ongelmansa. Näihin ongelmiin suunnittelumallit ovat syntyneet vastaukseksi. Suunnittelumallit voidaan nähdä myös hieman toisenlaisessa merkityksessä: ne ovat kokeneiden ohjelmistosuunnittelijoiden ja -ohjelmoijien laatimia dokumentteja, jotka sinällään sisältävät arvokasta informaatiota erilaisten ongelmien ratkaisemiseksi.
Sisältö Tiivistelmä Sisältö 1 Johdanto 2 2 Aiheen kartoitus 3 2.1 Suunnittelumallien historiaa..................... 3 2.2 Mitä ovat suunnittelumallit?..................... 3 2.2.1 Antisuunnittelumallit..................... 5 2.3 Suunnittelumallien luokittelu..................... 5 2.4 Esimerkki: abstrakti tehdas...................... 6 3 Analyysi 7 3.1 Minkä verran eri suunnittelumalleja käytetään ja miltä tulevaisuus näyttää?................................ 7 3.2 Suunnittelumallien hyviä ja huonoja puolia............. 8 4 Yhteenveto 10 Viitteet
1 Johdanto Tarkastelen tässä esseessäni suunnittelumalleja. Mitä ne ovat, miksi niitä on ja miten niitä käytetään. Teksti on kuitenkin vain pintapuolinen näkemys aihepiiristä, ei mikään kaiken kattava selvitys. En esittele käytännössä kuin yhden suunnittelumallin, abstraktin tehtaan. Tämän esseen tarkoitus ei ole olla opas eri suunnittelumalleista, eikä esseen pituudeksi asetettu raja antaisi sille myötenkään. Yritän siis keskittyä tekstissäni enemmän suunnittelumalleihin yleensä, enkä kasvattaa sivumäärää mekaanisella, eri mallien esittelyllä. Tämän jälkeen analysoin yleisellä tasolla suunnittelumallien tarkoitusta, sekä hyötyjä ja haittoja. Tarkastelen aihetta etenkin suunnittelijan näkökulmasta. Toisaalta mallit ovat nimenomaan tarkoitettukin suunnittelijoille, joten loppukäyttäjälle näkyviä ominaisuuksia saavutetaan suunnittelumallien avulla varsin vähän jollei sellaiseksi lasketa ohjelmiston mahdollista yleistä laadukkuutta. Suunnittelumallit ovat varsin paljon käytetty menetelmä tietynlaisten ongelmien ratkaisemiseksi. Pohjimmiltaan suunnittelumallit ovat ainoastaan kokoelma hyviksi havaittuja sääntöjä ja menetelmiä. Suunnittelumallit eivät ole valmista koodia. 2
2 Aiheen kartoitus Käsittelen tässä luvussa suunnittelumallien historiaa, millaisia ne ovat ja miten niitä käytetään. Esimerkinomaisesti esittelen yhden suunnittelumallin yksityiskohtaisesti, abstraktin tehtaan. 2.1 Suunnittelumallien historiaa Suunnittelumallien idea tulee ehkä hiukan yllättäen perinteisestä arkkitehtien maailmasta. Arkkitehti Christopher Alexander suunnitteli järjestelmän, jolle monet nykyajan oliosuunnittelumallit perustuvat. Hän ja hänen kollegansa kehittelivät kahdenkymmenen vuoden ajan suunnittelumalleja arkkitehtuuriin Berkleyssä, Kaliforniassa. Ward Cunningham ja Kent Beck lukivat Alexanderin kirjoittamia kirjoja, ja innostuivat kokeilemaan ideoita myös ohjelmistokehityksessä. He kehittivät ja toteuttivat smalltalk -kieleen viisi suunnittelimallia, jotka käsittelivät graafisen käyttöliittymän suunnittelua: Window per Task, Few Panels, Standard Panels, Nouns and Verbs ja Short menus. [5] Erich Gamma kirjoitti väitöskirjan 1991 suunnittelumallien käytöstä ohjelmistokehityksessä. Valitettavasti kirja kirjoitettiin saksaksi, joten se ei saanut ansaitsemaansa arvostusta keski-euroopan ulkopuolella. Gamma oli kuitenkin neljä vuotta myöhemmin mukana kirjoittamassa yhdessä Richard Helmin, Ralph Johnssonin ja John Vlissidesin kanssa yhtä tunnetuimmista suunnittelumalleja käsittelevistä kirjoista: Design Patterns Elements of Reusable Object-Oriented Software [1]. Kyseisen kirjan jälkeen on kirjoitettu monia muita vastaavanlaisia teoksia, mutta useimmat niistä pohjaavat ajatuksensa enemmän tai vähemmän suoraan Gamman kirjaan. 2.2 Mitä ovat suunnittelumallit? Suunnittelumallit ovat kokoelma erilaisia menetelmiä tietyntyyppisten ongelmien ratkaisemiseksi. Mallit eivät ole valmista koodia, vaan ne ovat ainoastaan ratkaisukuvauksia. Näin ollen niitä voidaan ja niitä tuleekin hyödyntää suunnitteluvaiheessa ainoastaan. Mallit ovat syntyneet ajan saatossa tavallaan itsestään, mutta niistä on laadittu yleiset säännönalaisuudet jottei jokaisen ohjelmiston kohdalla tarvitsisi aina keksiä pyörää uudelleen. [4] Suunnittelumallien avulla ei synny laadukasta ohjelmistoa itsestään. Malleja voidaan soveltaa vain tietyissä, tarkasti rajatuissa tapauksissa. Silloinkin toteutus loppuviimein ratkaisee, miten ohjelmisto toimii suunnittelumalli ei siis automaattisesti luo laadukasta ohjelmistoa. Ei ole myöskään epätavallista, että johonkin ongelmaan ei löydy ollenkaan valmista suunnittelumallia. 3
Mirja Immonen on määritellyt suunnitellumallin näin: [3] Suunnittelumalli nimeää, tarjoaa taustatietoa ja selittää käytännössä hyväksi todetun tavan ratkaista jokin järjestelmissä usein esiintyvä arkkitehtuuri- tai suunnitteluongelma. Ratkaisu on yleinen kokoelma olioita ja luokkia, joita sovelletaan ja muokataan ratkaisemaan ongelma erilaisissa käytännön tilanteissa. Raine Lehto [5] on poiminut Desing Patterns -kirjasta [1] seuraavat neljä suunnittelumalliin kuuluvaa osaa. Osat ovat periaatteessa toisenlainen määritelmä suunnittelumallille, joskin näiden ohjeiden perusteella voi paremminkin tutkia voidaanko jotain sääntökokoelmaa kutsua suunnittelumalliksi. 1. Mallin nimi kuvaa kuvaa muutamalla sanalla ongelmaa, ratkaisua ja seurauksia. Hyvin valittu nimi helpottaa mallin hyödyntämistä jatkossa. 2. Ongelma. Kappaleessa kuvaillaan kohteena oleva ongelma, sen tyypillisiä ilmenemisalueita sekä sen perinteisiä ratkaisutapoja. Joskus ongelma voi sisältää listan ehtoja, joiden tulee täyttyä ennenkuin on järkevää käyttää mallia. 3. Ratkaisu. Kappale kuvailee ratkaisun rakenteen jollakin yleisellä esitystavalla, yleensä olioperustaisin menetelmin sanallisesti tarkennettuina UMLkaavioina. 4. Seuraukset. Kappaleessa analysoidaan mallin hyviä ja huonoja puolia, sekä esitellään tilanteita, joihin malli ei sovellu. Lasse Harjumaa on listannut seuraavat asiat huomioon otettavaksi, ennenkuin suunnittelumallia tulisi alkaa hyväksikäyttämään: [2] 1. Varmista, että malli on oikea kyseiseen tarkoitukseen. 2. Varmista, että ymmärrät mallin. 3. Hyödynnä esimerkkikoodia. 4. Määrittele vaikutuksen alaiset luokat. 5. Toteuta. Nämä ohjeet ovat eräänlainen muistilista suunnittelijalle, jotta hän varmasti on hyödyntämässä ongelmaansa siihen tarkoitettua suunnittelumallia. 4
2.2.1 Antisuunnittelumallit Mielenkiintoinen lähestymistapa suunnittelumalleihin ovat niin sanotut antisuunnittelumallit. Mallien ideana on esittää erilaisia ei-toivottuja malleja. Vaikka ajatus kuulostaakin äkkiseltään typerältä, on näistä malleista käytännössä paljonkin hyötyä koska niiden avulla voidaan löytää huonoja ratkaisumalleja ohjelmistoista. Mallit ovat luenteeltaan varsin yleismaailmallisia, etenkin perinteisiin suunnittelumalleihin verrattuna. Esimerkki antisuunnittelumallista voisi olla vaikkapa sovelluksen yleinen liian kookkaaksi kasvanut ohjausluokka, joka sisältää suuren määrän toisiinsa liittymättömiä attribuutteja ja operaatioita. [4] 2.3 Suunnittelumallien luokittelu Tämän kappaleen ajatukset ovat lainattu lähes suoraan Mirja Immosen [3] tekemästä erikoistyöstä. Suunnittelumallit luokitellaan tavallisesti kahteen luokkaan: 1. Mitä suunnittelumalli tekee, eli käyttötarkoitus. 2. Onko suunnittelumalli tarkoitettu käytettäväksi luokkien vai olioiden kanssa? Käyttötarkoituksen mukaan suunnittelumallit voidaan luokitella kolmeen luokkaan: 1. Toiminnalliset- tai käyttäytymismallit 2. Luontimallit 3. Rakennemallit Ensimmäiseen ryhmään luetaan luokkamallit, jotka käyttävät perintää jakamaan eri toiminnot eri luokkiin. Samaan kategoriaan kuuluvat myös olioiden yhdistämiseen tähtäävät oliomallit. Toiseen ryhmään luetaan muun muassa mallit, jotka auttavat ratkaisemaan miten luodaan olioita ympäristössä, jossa liittymänä on joukko tapauskohtaisia abstrakteja luokkia tai kuinka varmistetaan, että luokalla on vain yksi ilmentymä joka on kaikkien muiden luokkien saatavilla. Kolmanteen ryhmään katsotaan kuuluvaksi mallit, jotka kuvaavat olioiden välisiä suhteita, ja kuinka olioita yhdistelemällä saadaan uusia toimintoja. Ratkaisumallit auttavat suurten järjestelmien yhteydessä muistinkäytön optimointiin ja tehokkuuden maksimointiin. 5
2.4 Esimerkki: abstrakti tehdas Esittelen tässä esimerkkinä erään yleisesti käytössä olevan suunnittelumallin. Lähteenä olen käyttänyt tässä kappaleessa erittäin laajasti Kai Koskimiehen Oliokirjaa [4]. Tarkoitus: Mallin avulla voidaan luoda oliokokoelmia, vaikka ei tunnettaisi näiden olioiden konkreettisia perusluokkia. Motivointi: Oletetaan, että täytyy mallintaa ajoneuvovuokraamo. Kyseisestä liike myös tarvittaessa myy ajokkeja. Abstraktin tehtaan avulla voidaan suunnitella luokkarakenne, jossa on yleinen Ajoneuvo-luokka. Kyseinen luokka on abstrakti luokka, jossa on määritelty ainoastaan rajapinta jonka Ajoneuvoluokan perivät oliot toteuttavat. Rajapinta voisi määritellä esimerkiksi metodit Ajoneuvo.vuokraa(), Ajoneuvo.myy() ja niin edelleen. Tällöin yksittäinen olio voi olla mikä tahansa olio joka on luotu Vene, Polkupyörä, Henkilöauto tai muusta vastaavasta luokasta, ja silti sitä voidaan käsitellä yleisen Ajoneuvo-rajapinnan kautta. Soveltuvuus: Mallia voidaan käyttää silloin, kun: järjestelmän tulisi olla riippumaton siitä, miten sen tuotteita luodaan, kootaan ja esitetään järjestelmän tulisi olla konfiguroitavissa tietylle tuoteperheelle järjestelmän tulisi taata, että tietyn tuoteperheen jäseniä käytetään yhdessä halutaan esittää erilaiset järjestelmän tuotteet luokkakirjastona, ja halutaan paljastaa vain niiden abstraktit rajapinnat, ei toteutustapaa Rakenne: Abstraktin tehtaan rakenne on esitettynä kuvassa 1 Osallistujat: AbstractFactory: määrittelee konkreettisten tuoteolioiden luontioperaatioiden kutsumuodon ConcreteFactory: toteuttaa konkreettisten tuoteolioiden luontioperaatiot AbstractProduct: määrittelee tietyntyyppisen tuoteolion operaatioiden kutsumuodon ConcreteProduct: määrittelee tuoteolion ja toteuttaa AbstractProductluokassa annetut operaatiot Client: käyttää AbstractFactory- ja AbstractProduct-luokkien määrittelemää rajapintaa 6
Seuraukset: Mallin avulla voidaan eristää olioiden konkreettiset luokat asiakkaasta Mallin avulla konkreettiset luokat voidaan vaihtaa helposti toisiksi Malli edistää luokkien standardointia yhteisen rajapinnan mukaisiksi Malli ei tue uusien tuotteiden lisäämistä Kuva 1: Abstraktin tehtaan rakenne 3 Analyysi Tässä luvussa analysoin hiukan suunnittelumallien etuja ja haittoja. Pohdin myös lyhyesti suunnittelumallien tulevaisuutta. 3.1 Minkä verran eri suunnittelumalleja käytetään ja miltä tulevaisuus näyttää? Olio-ohjelmoinnin yleistyttyä 1980-luvulla lähinnä graafisten käyttöliittymien myötä myös suunnittelumalleille syntyi luontainen tarve. Graafisissa käyttöliittymissä kuvataan erilaisia käyttöliittymän osia esimerkiksi painonappeja, tekstikenttiä, listoja ynnä muita olioiden avulla. Koska GUI 1 :t ovat loppujen lopuksi varsin samanlaisia ympäristöstä riippumatta, syntyivät suunnittelumallien kaltaiset yleisohjeet varsin luontevasti. Graafiset käyttöliittymät olivat siis yksi tekijä jotka edesauttoivat suunnittelumallien syntymistä. Tältä pohjalta ei liene kovinkaan erikoista, että myös nykyään suunnittelumalleja hyödynnetään paljon etenkin käyttöliittymien yhteydessä. 1 Graphical User Interface 7
Koska suunnittelumallit ovat kieli- ja toteutusriippumattomia, kykenevät ne myös elämään ajan mukana vaikka erilaisia ohjelmointikieliä syntyykin. Tosin mallit ovat käytännössä myös nivoutuneet tiiviisti olio-ohjelmointiin, joten mikäli olioiden tilalle kehittyy jotain uutta ja mullistavaa, voi hyvinkin käydä niin että suunnittelumallit katoavat tosin huomattavasti todennäköisempää on, että oliomaiset suunnittelumallit jäävät käytöstä pois, ja niiden tilalle syntyy joitain uusia kyseistä tekniikkaa hyödyntäviä malleja. Olio-ohjelmointikielet, kuten C++ ja Java, ovat kuitenkin tällä hetkellä niin vahvasti käytössä, että suunnittelumalleille näyttää olevan vain entistä enemmän tilausta. Niiden merkitys tulee myös epäilemättä korostumaan tulevaisuudessa. Javan luokkakirjastossa on myös lukemattomia Design Patterns -kirjan malleja hyödyntäviä luokkakirjastoja [5]. Suunnittelumalleja voi kehittää kuka tahansa, jopa tyhjästä. Käytännössä vain tämä on erittäin vaikeata, koska mallit ovat yleensä itsestään syntyneet monien toisistaan riippumattomien ongelmien ratkaisujen yhteisenä kuvauksena. Oman mallin kehittäminen olisi siis huomattavasti helpompaa tutkimalla tietyntyyppisten ongelmien ratkaisuja eri ohjelmistoista, ja laatimalla näistä mahdollisimman yleiskäyttöisen kuvauksen. 3.2 Suunnittelumallien hyviä ja huonoja puolia Suunnittelumalleilla saavutetaan merkittäviä säästöjä resursseissa. Samaa ongelmaa ei tarvitse ratkaista joka kerta uudelleen, vaan voidaan tyytyä yleiskäyttöisiin, hyviksi havaittuihin menetelmiin. Tämä nopeuttaa ohjelmistokehitystä, ja useimmiten myöskin mahdollistaa laadukkaampien ja ylläpidettävimpien ohjelmistojen tuottamisen. Lisäksi suunnittelumallien avulla voidaan välttää joitakin ohjelmointivirheitä. Suunnittelumallien avulla myös komponenttien uudelleenkäytettävyys helpottuu. Vaikka olio-ohjelmointi paradigmana ylipäätään tukee komponenttien uudelleenkäytettävyyttä, on kokemattoman suunnittelijan vaikea suunnitella ohjelmistoa joka mukautuu helposti erilaisiin käyttötilanteisiin. Tässä suunnittelumallit voivat olla suurena apuna, koska niiden avulla ohjelmiston yleisestä mallista saattaa syntyä hyvinkin yleiskäyttöinen ja kohtuullisen vähällä vaivalla hyödynnettävissä oleva kokonaisuus. Suunnittelumallien eräänlaisena haittana voidaan pitää sitä, että mikäli niitä ei ole ennen hyödynnetty, täytyy henkilöstön opetella niiden käyttö. Tämä voi olla aikaavievää, ja vaatii koulutusta tai itseopiskelua. Suunnittelumalleja voi myös tahattomasti väärinkäyttää, esimerkiksi valitsemalla väärän mallin. Pienessä projektissa tätä ei välttämättä edes huomaa eikä se ehkä haittaakaan, mutta suuressa projektissa virhe voidaan havaita vasta myöhään, jolloin viikkojen työ voi mennä hukkaan 8
tai joudutaan tehdä purkkaliimakorjaus, joka todennäköisesti on tie vielä pahempiin vaikeuksiin. On siis erittäin tärkeätä käyttää riittävästi aikaa oikean mallin etsimiseen. Suunnittelumallit eivät myöskään ratkaise jokaista vastaan tulevaa ohjelmistosuunnitteluongelmaa; siksi kaikkeen ei kannata yrittää edes etsiä ratkaisua suunnittelumalleista. Tosin antisuunnittelumalleista voi olla näissäkin tapauksissa hyötyä. Toisenlainen ongelma suunnittelumalleista voi syntyä silloin, jos niiden käyttö muodostuu itsetarkoitukseksi. Kokematon suunnittelija saattaa erehtyä luulemaan, että ohjelmistosta syntyy sitä parempi mitä useampaa suunnittelumallia on hyödynnetty. Näinhän ei missään nimessä ole, vaan jokaista mallia tulisi käyttää ainoastaan silloin kun projekti sitä edellyttää. Mallit ovat ohjelmistoja varten, ei toisinpäin. 9
4 Yhteenveto Suunnittelumallien avulla voidaan ratkoa monia ohjelmistosuunnitteluun liittyviä ongelmia. Nykyään erilaisia malleja on olemassa hyvin paljon, joten jotakuinkin kaikkiin yleisiin ongelmiin löytynee jo valmis ratkaisumalli. Mallien huolellinen käyttö auttaa luomaan laadukkaamman ohjelmiston nopeammin. Mallia tarkasti seuraamalla myös joitakin rakenteellisia ongelmia on mahdollista välttää. Toisaalta suunnittelumallien käyttöä täytyy opiskella, ja niitä voi myös etenkin kokematon suunnittelija käyttää vahingossa myös väärin. Suunnittelumallit ovat tarkoitettu kuitenkin etupäässä kokemattomille suunnittelijoille ja ohjelmoijille. Suunnittelumallit ovat tiettyjen ongelmien hyviksi havaittuja ratkaisumenetelmiä, joista on koottu ajan saatossa yleiset ratkaisuohjeet, suunnittelumallit. 10
Viitteet [1] E. Gamma. Desing Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [2] Lasse Harjumaa. Luentomateriaali: olio-ohjelmointi. Oulun yliopisto, 2003. [3] Mirja Immonen. Erikoistyö: suunnittelumallit. Kuopion yliopisto, tietojenkäsittelytieteen ja sovelletun matematiikan laitos, http://www.cs.uku.fi/research/ Teho/Suunnittelumallit.pdf, 2002. [4] Kai Koskimies. Oliokirja. Satku - Kauppakaari, Gummerus kirjapaino, Jyväskylä, 2000. [5] Reijo Lehto. Seminaariesitelmän alustus: olioarkkitehtuurit. Helsingin yliopisto, tietojenkäsittelytieteen laitos, http://www.helsinki.fi/ rmelehto/olioarkkiteh tuurit/esitelma.html, 1999. 11