SEPA päiväkirja Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen
1. Johdanto...3 2. Menetelmän käyttö...4 3. Kokemukset ja muutokset...5
1. Johdanto SEPAn aiheenamme meillä on suunnittelumallit (design patterns). Lähtökohdaksi otimme Craig Larmanin kirjasta "Applying UML and Patterns" löytyvät Gang-of- Four suunnittelumallit adapter, factory, singleton, strategy, composite, facade, abstract factory, observer/publish-subscribe ja proxy. Kyseinen kirja oli kurssimateriaalina kurssilla Ohjelmistojen määrittely- ja suunnittelumenetelmät, joten mallien kuvaukset löytyvät myös kurssin prujuista. Tämä on hyödyksi, koska ryhmästämme osa on kyseisen kurssin suorittanut, joten heillekin nämä mallit ovat ainakin nimeltä tuttuja. Aiheen valitsimme yksinkertaisesti siitä syystä, että se sopii meille ja projektiin hyvin. Suunnittelumalleja olisi joka tapauksessa jouduttu käyttämään ja on luontevinta, että pääarkkitehti on mukana suunnittelumalleista tehtävässä SEPAssa. Suunnittelumallien lähteet: Larman, Craig. Applying UML and patterns: an introduction to objectoriented analysis and design and iterative development, 3rd ed., 2005
2. Menetelmän käyttö Suunnittelumallien käyttö painottuu pääosin järjestelmän arkkitehtuurin sekä matalamman tason suunnitteluun että toteutusteknologioiden valintaan. Myös koodikatselmoinnit ja refraktorointi voivat tuoda esiin tarvetta suunnittelumallien soveltamiselle. Pääarkkitehdilla on suurin vastuu suunnittelumallien soveltamisessa, joten hänellä on vahvin kokemus ja tieto kyseisestä menetelmästä. Tätä varten olemme koonneet muutaman referenssiteoksen aiheesta. Pääarkkitehti sekä myös muut suunnitteluun osallistuvat kehittäjät tutustuvat järjestelmän kannalta merkittäviin suunnittelumalleihin sekä hyviksi havaittuihin menetelmiin ja tilanteisiin joissa malleja kannattaa käyttää. Suunnittelun edetessä ja kun tarvittavat teknologiat on saatu päätettyä, välitetään kehittäjille tietoa tehdyistä valinnoista ja miksi niihin päädytty. Kehittäjät pystyvät aloittamaan tutustumisen teknologioihin ja sen sisältämiin suunnittelumalleihin, joita pyrimme tuomaan esiin mm. wikissä. Järjestelmästä laaditut suunnitelmat ja UML-kaaviot dokumentoivat kehittäjille suunnittelumallien käyttöä. Lisäksi toteutusteknologiat sisältävät usein monia suunnittelumalleja ja ajavat automaattisesti käyttämään niitä. Teknologioiden oikeaoppinen käyttö on siis tärkeää, joten Wikiin kootaan materiaalia, vinkkejä ja ratkotaan ongelmia niille varatuilla sivuilla. Suunnittelumallien käyttöä pyritään kontrolloimaan pääarkkitehdin aktiivisella osallistumisella kehittäjien kohtaamien ongelmien ratkomiseen sekä koodikatselmoineilla. Suunniteltaessa järjestelmää huomioitavaa on ainakin mallien ylisoveltamisen välttäminen. Käytetään niitä vain kun voidaan saavuttaa merkittävää hyötyä jatkossa modulaarisuuden tms. osalla ja tällä on kyseisessä järjestelmän osassa jotain merkitystä.
3. Kokemukset ja muutokset 3.1 Iteraatio 1 3.1.1 Kehittäjille suunnattu kysely suunnittelumalleista Iteraatio 1:n lopuksi kehittäjille lähetettiin sähköpostitse seuraava kysely: 1. Käytitkö design patterneja suunnitellessasi ohjelmaa? 2. Missä ja mitä design patterneja käytit? 3. Miten design patternin tarve tuli esiin? 4. Kuinka kauan käytit aikaa sopivan design patternin etsimiseen? 5. Mitä laatuatribuutteja (testattavuus yms.) design patternin avulla parannettiin? 6. Koitko että design patternien käytöstä oli hyötyä suunnittelussa ja/tai ohjelmoinnissa? 7. Olisitko käyttänyt design patterneja ilman että käytäntö oli "pakollinen"? Kehittäjistä kaikki mainitsivat käyttäneensä suunnittelumalleja. Simulaattorin kehittäjät kertoivat käyttäneensä luokkarakenteen suunnittelussa Facadea ja Strategyä. TetraConnetion-paketin kehittäjä Markku Huttunen kertoi suunnittelumallien käytöstä seuraavasti: "Luokka MessageTransferer toimii eräänlaisena Julkisivuna eli Facadena. Se kokoaa ja piilottaa osan alijärjestelmän tarjoamista toiminnallisuuksista ja pyrkii näin tarjoamaan yksinkertaisemman rajapinnan corelle. Tavallaan luokan MessageHandler voitaisiin ajatella toimivan eräänlaisena Sovittimena eli Adapterina. Se kääntää EPA:n ymmärtämiä viestejä Valppaan ymmärtämään muotoon ja päinvastoin. Luokat MessageHandler ja MessageTransferer tekevät myös tarkkailua siinä määrin, että MessageHandler luokassa hoidetaan istunnon uudelleen loggaaminen ja MessageTransferer luokassa luodaan uusi istunto jos vanha on jo ehtinyt vanheta. Toisaalta koska tämä tarkkailu tapahtuu vain viestejä lähetettäessä/vastaanotettaessa, joka tapahtuu coresta käsin, on vähän kyseenalaista voidaanko sanoa Tarkkailija(Observer) design patternia käytettäneen." Kehittäjien mielestä suunnittelumallien käyttö oli itsestään selvää ja suurin tarve malleille oli rajapinnoissa. Kukaan kehittäjistä ei raportoinut käyttäneensä sopivan suunnittelumallin etsimiseen juurikaan aikaa. Malleja sovellettiin joko "siinä sivussa" tai tajuttiin vasta myöhemmin että mallia oli käytetty, joten kehittäjät kokivat vaikeaksi erotella nimenomaan suunnittelumallien etsimiseen käytettyä aikaa. Laatuattribuuteista kehittäjät kokivat parantaneensa käytettävyyttä, ylläpidettävyyttä, siirrettävyyttä, tehokkuutta ja testattavuutta.
Kaikki kehittäjät kokivat suunnittelumallien käytön hyödylliseksi ja olisivat käyttäneet suunnittelumalleja myös ilman SEPAa. 3.1.2 Suunnittelumallien käytön analyysi 3.1.2.1 Valpas Valppaan toteuttamiseen valittiin avoimen lähdekoodin komponentit Spring, Hibernate ja Quartz. Komponentit toivat mukanaan omat mallinsa, jotka tiedettiin suunnittelumallien kannalta toimiviksi. Spring mahdollistaa olioiden kytkemisen toisiinsa koskematta lähdekoodiin ja se tarjoaa olioiden instantiointiin singleton ja tehdastyyppiset tavat. Tähän mennessä tarvitsimme tosin vain singletoneja. Laitteidenvalvontapalvelin Hibernate ja Springin tarjoamat luokat sen käyttöön abstrahoivat kannan käytön muulta sovellukselta tietokannan aksessointiolioilla (DAO suunnittelumalli). Tällä saavutetaan joustavuutta, jos kantaa joudutaan vaihtamaan tai Hibernaten käyttö ei enää ole soveliasta. Laitteiden valvonnassa on käytetty tarkkailija-suunnittelumallia, joka helpottaa tulevassa iteraatiossa vikatilanteista ilmoittavien komponenttien toteutuksessa. Lisäksi TETRA-verkossa EPA:n avulla viestiminen on abstrahoitu viestintää suorittavan julkisivun (Facade) taakse. Tällä saadaan koottua mm. Apache Axis:sta ja EPA:sta riippuvat osat yhteen paikkaan ja muulle sovellukselle tarjotaan laitteiden valvonnan kannalta riittävä, mutta yksinkertainen rajapinta. Valppaan komentorivikäyttöliittymä Komentorivikäyttöliittymä on pyritty toteuttamaan helposti laajennettavaksi. Tämä on saavutettu käyttämällä tehdassuunnittelumallia komentoparserien luontiin, jolloin varsinaisen parserin ei tarvitse tietää mitkä komennot ovat mahdollisia. Lisäksi parsitusta datasta luodaan komentoja, jotka välitetään niitä suorittavalle luokalle käyttäen viestin tai tässä tapauksessa komennon edelleen lähettämistä (Double Dispatch). Ratkaisu on hieman kömpelö, sillä komentoja suorittavan luokan rajapintaa joudutaan laajentamaan lisättäessä komentoja ja lisäksi se sen koko paisuu tarpeettoman suureksi. Jatkossa olisi syytä siirtää suoritus itse komentoihin ja käyttää niiden luomiseen vaikka tehdasta, joka yhdistää tarvittavat Valppaan komponentit niihin. 3.1.2.2 Simulaattori Simulaattorissa puhelimen ohjaus käyttämällä sarjaporttia abstrahoitiin omaan julkisivuunsa. Tällä päästiin simulaattorin muissa osissa eroon turhista yksityiskohdista ja viestintä sarjaportin välityksellä on mahdollisimman yksinkertaista. Simulaattorin toteutuksessa tuli vastaan ongelmia käyttöjärjestelmien kanssa ja jouduttiin käyttämään eri kirjastoja eri käyttöjärjestelmissä. Julkisivu helpotti kirjaston vaihtamista.
3.1.2.3 Analysaattori Analysaattorissa suunnittelumallien käyttö rajoittui käyttöliittymään, joka toteutettiin Swingillä. Swing perustuu MVC-suunnittelumalliin, jonka ideana on erottaa käyttöliittymäkomponenttien malli, näkymä ja ohjauslogiikka toisistaan. Lisäksi toteutuksessa käytettiin tarkkailijoita kuuntelemaan komponenttien tapahtumia. MVC:n ja Swingin hyödyt Analysaattorissa rajoittuivat suurimmaksi osaksi käyttöliittymän rakentamisen helppouteen ja nopeuteen. Analysaattoria ei ole tarkoitus jatkokehittää, joten MVC:n kehittyneemmät edut tuskin tulevat ilmi.