SEPA päiväkirja. Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen Ryhmä: Neptune T Ohjelmistoprojekti I

Transkriptio

1 SEPA päiväkirja Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen Ryhmä: Neptune T Ohjelmistoprojekti I

2 1. Johdanto Menetelmän käyttö Kokemukset ja muutokset Yhteenveto...9

3 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

4 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 refaktorointi 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ä.

5 3. Kokemukset ja muutokset 3.1 Iteraatio 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ä. TetraConnection-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.

6 Kaikki kehittäjät kokivat suunnittelumallien käytön hyödylliseksi ja olisivat käyttäneet suunnittelumalleja myös ilman SEPAa Suunnittelumallien käytön analyysi 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 Laitteidenvalvontapalvelimen arkkitehtuurissa otettiin huomioon mahdolliset vaihtoehtoiset käyttöliittymät tarjoten palvelimen toimintoihin RMI-rajapinnat. Käytimme näiden toteuttamiseen Springin tarjoamia proxy-tehtaita, jolloin ainoaksi työksi jäi irrottaa erilleen RMI:n yli käytettävistä palveluista niiden rajapinnat. Rajapinnat muodostettiin ConfigurationFacadeBeanista sekä DeviceFacadeBeanista, jotka tarjoavat selkeät palvelut Valppaan ohjaamiseen. Proxy-suunnittelumallia käytimme lisäksi transaktioiden hallintaan käyttäen Springin TransactionInterceptoria, joka toimii näkymättömänä proxynä varsinaisen tietokantaa käyttävän objektin välissä. Transaktiot on määritelty deklaratiivisesti ja niiden käyttö ei näy itse koodissa. Tietokannan saanti on toteutettiin käyttäen Hibernatea sekä Springin tarjoamia luokkia sen käyttöön. Luokat 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. Lisäksi 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ää

7 niiden luomiseen vaikka tehdasta, joka yhdistää tarvittavat Valppaan komponentit niihin 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 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. 3.2 Iteraatio Suunnittelumallien käytön analyysi Valpas Web-käyttöliittymä Toisen iteraation ainut suunnittelumallien kannalta merkittävä tehtävä oli webkäyttöliittymän kehittäminen. Alkuperäisessä arkkitehtuurissa päätimme käyttää liittymän suunnittelemiseen jotain MVC-pohjaista frameworkiä. Koska valitsimme Springin tukemaan Valppaan toteutusta ja käytimme sitä siinä erittäin tehokkaasti ottaen huomioon kehittäjien kokemuksen aiheesta, päätimme jatkaa samoilla linjoilla myös web-käyttöliittymän kanssa. Lisäksi käytimme Struts-tilesiä käyttöliittymän erillisten komponenttien rakentamiseen. Springin MVC osoittautui sopivan kevyeksi ja antoi paljon liikkumavapautta toteutukseen. Spring ei ota kantaa käytettävään view-teknologiaan, mutta päätimme käyttää JSP-sivuja ja JSTL:ää. Pyrimme mahdollisimman puhtaasti erottamaan datan näyttämisen sen käsittelystä, joten JSP-sivuissa on pyritty käyttämään mahdollisimman vähän logiikkaa. Mallina käytimme suoraan Valppaan transferobjekteja ja logiikka on sisällytetty kontrollerien toteutuksiin. Lisäksi määritimme, että käyttöliittymässä kaikki tilaa muuttavat operaatiot tehdään POST-metodilla ja muut GET-metodilla. Tähän ei kuitenkaan aivan päästy sillä konsepti ei ollut kaikissa kohtaa täysin selvä kehittäjille. Lisäksi käytimme ns. redirect after post - suunnittelumallia lomakkeiden kanssa estämään ylimääräiset lähetykset ja näistä johtuvat väärät tilamuutokset.

8 Laitteidenvalvontapalvelin Ensimmäisessä iteraatiossa laitteiden valvonnassa käytetty tarkkailija-suunnittelumalli ei osoittautunut hyödylliseksi sillä asiakkaan haluamia vaatimuksia muutettiin realistisemmiksi ja vähemmän merkittäviä toimintoja karsittiin. Tosin GSMmuistutusten toteutus oli pöydällä vielä loppumetreille ja se oltaisiin voitu toteuttaa käyttäen suunniteltua rajapintaa. Muu laitteidenvalvontapalvelimen kehitys painottui lähinnä refaktorointiin ja bugien korjaukseen Analysaattori Analysaattoriin toteutettiin I2:ssa joitakin käyttäjän elämää helpottavia lisätoiminnallisuuksia. Koska kyseessä olivat käyttöliittymäkomponentit, jotka toteutettiin Swingillä, käytettiin edelleenkin MVC-mallia ja tarkkailijoita, eivätkä kokemukset muuttuneet iteraatio 1:stä Simulaattori Simulaattorin osalta iteraatio 2:ssa keskityttiin lähinnä bugikorjauksiin. Pieniä lisäominaisuuksia myös toteutettiin, mutta suunnittelumallien osalta uusia kokemuksia ei tullut.

9 4 Yhteenveto Yhteenvetona voidaan todeta, että SEPAn aihe oli hyödyllinen, mutta SEPAn teko aiheesta osoittautui kohtuullisen hankalaksi. Tämä siitä syystä että projektin aikana oli hyvin vaikea erottaa milloin teki SEPAa, milloin "normaalia" suunnittelua, joka teki kokemusten keräämisen hieman hankalaksi. Lisäksi aihe oli sen verran tuttu kaikille, että varsinaista hyötyä SEPAsta ei ollut, koska suurin osa tiesi jo etukäteen mitä suunnittelumallit ovat ja miten niitä käytetään, ja todennäköisesti olisivat käyttäneet suunnittelumalleja muutenkin. SEPAn ansiosta myös tuli kiinnitettyä huomiota siihen, millaisia suunnittelumalleja valmiissa komponenteissa, kuten Springissä ja Swingissä, on käytetty. Tästä ei kuitenkaan projektille suoraa lisäarvoa tullut, koska näitä komponentteja olisi käytetty myös ilman SEPAa. SEPAn hyödyksi voi lukea, että kaikki kuitenkin varmasti kiinnittivät huomiota suunnittelumallien käyttöön. Ehkä ilman SEPAa suunnittelumalleja ei olisi käytetty yhtä paljon ja yhtä hyödyllisesti, joka taas olisi saattanut aiheuttaa vaikeuksia projektin etenemiselle varsinkin toisessa iteraatiossa, kun "vanhan" koodin päälle piti rakentaa uusia ominaisuuksia. Suunnittelumallien käyttö selkeytti luokkatason arkkitehtuuria, kun luokan nimestä pystyi päättelemään, mitä mallia luokassa oli käytetty (esimerkiksi luokka DeviceFacade oli julkisivu).