Hirviö. Design Patterns

Transkriptio

1 Hirviö SEPA-päiväkirja Design Patterns Anssi Kalliolahti Liia Sarjakoski 15. maaliskuuta

2 Sisältö 1 Johdanto 3 2 Menetelmän käytäntöön soveltaminen 3 3 Kokemuksia ja muutoksia PP I Model View Controller Command Chain of Responsibility Visitor Singleton / Factory Composite Strategy Decorator I Viimeistely ja toimitus Analyysi Model View Controller Command Chain of Responsibility Visitor Singleton / Factory Composite Strategy Decorator Yhteenveto 8 2

3 1 Johdanto Tämä dokumentti on suunnittelumallien (Design Patterns) käytöstä kertova SEPA-päiväkirja, jonka tarkoituksena on esitellä, kuinka kirjoittajat ovat käyttäneet suunnittelumalleja Hirviöprojektissa. Suunnittelumallit ovat dokumentoituja ja toimiviksi todettuja ratkaisuja yleisiin suunnitteluongelmiin olio-ohjelmoinnissa. Toisin sanottuna suunnittelumallit ovat uudelleenkäytettävän suunnittelun rakennuspalikoita. Järjestelmäarkkitehti Liia Sarjakoski valitsi SEPA-aiheekseen suunnittelumallit, sillä hän oletti niiden olevan hyödyllisiä järjestelmän arkkitehtuurin suunnittelussa ja oli aikonut muutenkin tutkia niitä tarkemmin. Myös Anssi Kalliolahti on mukana Hirviön arkkitehtuurin suunnittelussa ja kokee suunnittelumallit hyödyllisiksi ja mielenkiintoisiksi. Tärkeimpänä lähteenä suunnittelumallien soveltamiseen on käytetty teosta Design Patterns: elements of reusable object-oriented software / Erich Gamma et al. Tämä teos on suunnittelumallien raamattu, katalogi, jota käytetään lähteenä useissa muissa suunnittelumalleja käsittelevissä teoksissa ja artikkeleissa. 2 Menetelmän käytäntöön soveltaminen Suunnittelumalleja käytetään Hirviön arkkitehtuurin suunnittelussa siten, että suunnittelun aikana mietitään valmiiden suunnittelumallien soveltuvuutta käsillä oleviin ongelmiin sen sijaan, että yritettäisiin keksiä kaikkiin ongelmiin ratkaisut itse. Suunnittelumalleja käytetään soveltuvilta osin, eikä arkkitehtuuria yritetä väkisin pakottaa suunnittelumallin mukaiseksi. Hirviö on jaoteltu osiin, joiden sisäinen kohensio on suuri. Nämä ovat järjestelmän moduleita (AAA, DataManagement, GUI ja sovelluslogiikka). Järjestelmä halutaan toteuttaa siten että moduleiden väliset sidokset ovat järkeviä, ja toisaalta itse moduleiden rakenteen tulee olla laajennuskelpoinen. Näiden ehtojen toteuttamiseksi tutkitaan rakenteellisia suunnittelumalleja, joiden toivotaan auttavan sekä kokonaisarkkitehtuurin että modulien sisäisen rakenteen suunnitellussa. Hirviö on sovellus, joka koostuu selkeästi HTML-käyttöliittymästä, tietokannasta ja sovelluslogiikasta. Arkkitehtuurisuunnitelijoilla on tarkoitus hyödyntää Hirviössä Model-View- Controller suunnittelumallia, jolla on ensisijaisesti tarkoitus eriyttää näkymä varsinaisesta sovelluslogiikasta. Tämä on tärkeää, koska perinteistä käyttöliittymäkoodin (XHTML) ja sovelluskoodin (PHP) sekoitusta on hankala lukea, se on heikosti ylläpidettävää ja virhealtista. Jotta MVC-mallin mukainen arkkitehtuuri olisi mahdollinen, on suunniteltava tätä tukeva alusta. Tämän suunnittelussa käytetään apuna sisäiseen käyttäytymiseen keskittyviä malleja (behavioral patterns) ja rakentamiseen keskittyviä malleja (creational patterns). Suunnittelumalleja käytetään ensisijaisesti iteraation I1 alussa, sillä järjestelmän perusarkkitehtuuri suunnitellaan silloin. Suunnittelumalleja pyritään soveltamaan myös iteraation I2 alussa arkkitehtuuriin tulevien tarkennusten osalta. On kuitenkin todennäköistä, että suunnittelumallien merkitys silloin on jo varsin pieni, ja suunnittelu keskittyy enemmän järjestelmän yksityiskohtiin. 3 Kokemuksia ja muutoksia 3.1 PP Suunnittelumalleja ei käytetty PP-iteraation aikana. 3

4 3.2 I1 Iteraation I1 aikana suunnittelumalleja käytettiin arkkitehtuurisuunnittelun apuna. Arkkitehtuurissa voitiin useissa kohdissa hyödyntää valmiita suunnittelumalleja ja toisaalta osan tehdyistä ratkaisuista huomattiin toteuttavan jo jonkin suunnittelumallin perusajatuksen. Suunnittelumalleihin liittyviä UML-kaavioita löytyy Hirviön teknisestä spesifikaatiosta Model View Controller Model-View-Controller -mallissa eriytetään näkymä, malli ja kontrolli. Hirviössä tämä toteutetaan siten että sovelluslogiikka toimii kontrollina, joka ottaa vastaan näkymältä saatuja käyttäjän aiheuttamia tapahtumia. Tapahtuman saatuaan Hirviö voi hakea, päivittää tai muokata mallia, joka käsittää tietokannan, sen käsittelyyn tarkoitetut luokat sekä muut väliaikaisdatan säilytykseen tarkoitetut luokat. Vastoin perinteistä MVC-mallia, Hirviössä näkymä ei suoraan hae muutoksia mallilta, vaan kontrolli välittää mahdolliset muutokset mallilta näkymälle. Tämä johtuu osittain siitä, että mallin ja näkymän välille ei haluttu suoria sidoksia, ja toisaalta siitä, että käyttöliittymän XHTML- ja PHP-kielien sekoitus haluttiin minimoida Command Hirviössä käytetään tapahtumapohjaista WWW-käyttöliittymää. Tämä on toteutettu yksinkertaisesti siten, että jokainen sovelluksen toimia vaativa input-elementti (linkit ja painikkeet) saavat automaattisesti generoidun uniikin ja satunnaisen tunnisteen, jota käytetään varsinaisessa käyttäjän selaimelle välitettävässä XHTML-sivussa. Sivun luontivaiheessa näitä uniikkeja tunnisteita vastaamaan luodaan tapahtumia, jotka enkapsuloidaan luokkaan Event, ja säilötään odottamaan käyttäjän toimia. Tälläinen toiminnon, tai komennon säilöminen luokkaan toteuttaa Command-suunnittelumallin Chain of Responsibility Jotta tapahtumilla olisi jokin merkitys on ne käsiteltävä. Kun käyttäjä painaa linkkiä tai painiketta, lähettää hän käytännössä palvelimelle vastaavan tapahtuman tunnisteen joko POST- tai GET-muuttujassa. Tämän tunnisteen perusteella säilötty tapahtuma voidaan ottaa käsiteltäväksi. Tätä varten järjestelmä tarjoaa abstraktin luokan, joka toimii tapahtumakuuntelijana. Tapahtumakuuntelijat voivat sisältää muita tapahtumakuuntelijoita, jolloin niistä muodostuu käytännössä puu. Lähetettävä tapahtuma ei tiedä suoraan mikä tapahtumankäsittelijä sen hoitaa, vaan se lähetetään etenemään puun juuresta, jolloin tapahtuma läpikäy kaikki tietyn haaran tapahtumakäsittelijät, kunnes se käsitellään. Tällainen käsittelijöiden ketjuttaminen toteuttaa Chain of Responsibility -suunnittelumallin Visitor Linkki- ja painike-elementtien lisäksi on XHTML:ssä tarjolla erilaisia syötteenantomahdollisuuksia kuten tekstikentät, checkboxit ja pudotusvalikot. Näiden käsittely ei aiheuta tapahtumia, mutta niiden sisältöön halutaan päästä käsiksi, ja niitä pitää pystyä päivittämään. Hirviössä tällaisten komponenttien käyttö on toteutettu siten, että niissä näkyvä data syötetään suoraan niitä esittäviin olioihin, ja vastaavasti käyttäjän antama syöte halutaan lukea suoraan niitä esittävistä olioista. Linkkien ja nappien tapaan jokainen syöte-elementti saa uniikin tunnisteen, joka välitetään käyttäjälle XHTML-sivussa. Kun käyttäjä operoi syöte-elementeillä, niihin syötetty data toimitetaan pavelimelle POST-muuttujissa, jotka on nimetty annetulla tunnisteella. 4

5 Jotta syöte saadaan takaisin haluttuihin olioihin, on niihin lisätty joukko visitor -metodeja joilla dataa voidaan operoida. Kun elementti luodaan ruudulle, se kutsuu alustan syötteenhallintaoliota saadakseen uniikin tunnisteen. Kutsuessaan tätä olioita, jokainen inputelementti antaa syötteenhallintaoliolle viittauksen itseensä, jolloin syötteenhallintaolio voi tätä viittausta ja visitor -metodeja hyväksikäyttäen operoida elementin datalla Singleton / Factory Jotta kaikkien syöte-elementtien tunnisteet olisivat yksilöllisiä ja niitä voitaisiin järkevästi hallita, tarvitaan keskitetty palvelu. Koska tämä keskitetty palvelu sijaitsee abstraktisti ajateltuna puun juuressa ja palvelua käyttävät elementit lehdissä, ei viittausta palveluun haluta välittää läpi puun haarojen. Hirviössä tämä palvelu toteutetaan staattisena luokkana, jonka ainoaa suorituksenaikaista instanssia voi käsitellä luokan staattisten metodien välityksellä. Luokan konstruktorista on tehty privaatti, jolloin sitä ei voida luoda, vaan luokka luo itse ainoan instanninsa, kun sen staattisia metodeja ensi kerran kutsutaan. Tällainen yhden instanssin luokka toteuttaa Singleton-suunnittelumallin. Tämä palvelu toimii samalla myös luokkana, joka luo jokaista toiminnon aiheuttavaa syöteelementtiä vastaavan tapahtumaolion, ja säilöö sitä niin pitkään kuin elementti on olemassa (kahden sivupyynnön välisen ajan). Tällainen toisia olioita tuottava luokka toteuttaa suunnittelumallin Factory Composite Hirviön käyttöliittymä on luonteeltaan sellainen, josta löytyy paljon uudelleenkäytettäviä elementtejä, kuten esimerkikis päävalikko. Näistä elementeista luodaan omia luokkia, joita voi yhdistellä. Hirviön käyttöliittymä koostuukin sisäkkäisistä elementeistä, joista muodostuu puumainen rakenne. Puussa olevia elementtejä voidaan hallita tarvittaessa isäelementtiensä avulla. Tälläinen yhdistely toteuttaa Composite-suunnittelumallin Strategy Strategy-mallia on käytetty mahdollistamaan erilaisten todennusmenetelmien ja tietokantojen käyttö järjestelmässä. Eri todennusmenetelmillä on yhteinen rajapinta siten, että mitä tahansa menetelmää voidaa käyttää sen kautta. Eri todennusmenetelmät ovat siis vaihdettavissa keskenään. Käytettävä menetelmä valitaan käyttäjän asetuksien mukaan. Järjestelmä voi käyttää myös erilaisia SQL-tietokantaohjelmistoja vastaavalla menettelyllä, mutta luonnollisesti vain yhtä kerrallaan ja vain niin kauan kuin SQL-lauseet tuottavat kaikilla tietokannoilla saman lopputuloksen. Ratkaisu eroaa puhtaasta Strategy-mallista siten, että Context käyttämisen lisäksi myös luo tarvitsemansa Strategyn. Context ja Strategy ovat Strategy-mallin käsitteitä Decorator Decorator on suunnittelumalli, jolla täydennetään jo olemassaolevaa luokkaa. Hirviössä tietokantayhteydet hoidetaan DatabaseConnection -rajapinnan toteuttavien luokkien avulla. Sovelluslogiikan tasolla ei kuitenkaan haluta käyttää suoraan SQL:ää, joten DatabaseConnection -luokkaa luodaan täydentämään DataManager-luokka, joka abstraktoi SQL:n pois sovelluslogiikan näkyvistä. 3.3 I2 Suunnittelumalleja ei käytetty I2-iteraation aikana. 5

6 Järjestelmän arkkitehtuuri suunniteltiin kokonaisuudessaan iteraation I1-aikana. Iteraatiolla I2 arkkitehtuuriin ei tehty mitään muutoksia, jolloin myös käytetyt suunnittelumallit pysyivät muuttumattomina. Kierroksen aikana oli tarkoitus implementoida varsinainen sovellus, käyttäen hyväksi kierroksella I1 valittuja ratkaisuja. Näiden ratkaisujen soveltuvuus havaittiin hyväksi, eikä alustaan kaivattu mitään muutoksia. SEPA-pari on tyytyväinen tekemiinsä valintoihin. Käytettyjen suunnittelumallien soveltuvuutta pyritään tarkemmin analysoimaan vasta viimeisellä iteraatiolla, jolloin sovellus on valmis, sekä kaikki mahdolliset kokemukset (tämän projektin puitteissa) ovat käytössä. 3.4 Viimeistely ja toimitus Suunnittelumalleja ei käytetty FD-iteraation aikana. Käytettyjen suunnittelumallien soveltuvuutta on analysoitu seuraavassa kappaleessa 4 Analyysi Alla on arvoitu käytettyjen mallien soveltuvuutta sovelluksen valmistuttua. Suunnittelumallien varsinainen käyttö on esitetty kappaleessa Model View Controller PHP ei sellaisenaan pakota sovelluksia mihinkään tiettyyn malliin, eikä sille ole mitään vakiintunutta kirjastoa / runkoa, jota käyttäen sovelluksia voisi toteuttaa. Tämä antaa toteuttajalle vapaat kädet luoda mieleisensä runkoarkkitehtuurin. Ryhmän koon, sekä iteratiivisen toteutuksen vuoksi yhtenäinen tapa toteuttaa ja lisätä toiminnallisuutta kuitenkin nähtiin välttämättömyytenä. Arkkitehtuurin suunnittelussa pyörää ei haluttu lähteä keksimään uudelleen, vaan lähtökohdaksi otettiin tapahtumapohjainen MVCmalli, jollainen esimerkiksi Javan Swing on. MVC-malli oli ehkä kaikkein tärkein käytetyistä suunnittelumalleista. Yksittäisten komponettien luonti käyttäen tätä arkkitehtuuria oli perinteistä HTML:n skriptailua hitaampaa, mutta kokonaisuudessa sen edut olivat huomattavasti tätä haittaa suuremmat. Malli mahdollisti useiden käyttöliittymäkomponenttien ja käyttöliittymäkokonaisuuksien uudelleenkäytön sovelluksen eri osissa (nopeuttaen kehitystä kokonaisuudessaan). Ehkä kaikkein tärkeimpänä, se helpotti toiminnallisuuden lisäämistä iteratiivisesti, sekä teki siitä huomattavasti vähemmän virhealttiimpaa. (Vertailukohteena on käytetty muita vastaavanlaisia, mutta perinteisin tavoin tehtyjä työ- ja kouluprojekteja). Sovelluksen rungon arkkitehtuuri noudatti siis MVC-mallia. PHP ei kuitenkaan tarjonnut suoraan mahdollistuutta toteuttaa sovellusta käyttäen tätä suunnittelumallia, joten ensin oli luotava tämän mahdollistava runko. Rungon oli hoidettava tapahtumien käsittely, sekä samalla piiloitettava sovellustason ohjelmoijilta kaikki heille tarpeeton toiminnallisuus. Loput käytetyistä suunnittelumalleista mahdollistivat tämän. 4.2 Command Tämä oli erittain käyttökelpoinen ratkaisu. Alla on esimerkkinä yksittäisen linkin luominen, sekä tälle määriteltävä tapahtumankäsittelijä, jota runko kutsuu sovellusohjelmoijalle näkymättömästi kun linkkiä on painettu. Sovellusohjelmoija luo linkin ja määrittelee kutsuttavan käsittelijän nimen: 6

7 $do_something_link = new Link( DoSomethingPressed, Press this to do foo ); Sekä määrittelee varsinaisen tapahtumakäsittelijän sovelluslogiikkaluokkaan: public function ondosomethingpressed(event $event) { } dofoo(); dobar(); Malli mahdollisti käyttäjän syötteen keskitetyn käsittelyn. Tämä oli eräs eniten sovellusohjelmoijiin vaikuttaneista suunnittelumalleista, palaute ohjelmoijilta oli myönteinen. 4.3 Chain of Responsibility Tämän mallin tarkoituksena oli mahdollistaa tapahtumia kuuntelevien olioiden ketjutus puuksi siten, että sovelluslogiikka olisi voitu pilkkoa useisiin osiin. Kaikki sovelluslogiikka kuitenkin keskittyi yksittäiseen luokkaan, jolloin tätä mahdollisuutta ei hyödynnetty. Jälkeenpäin kuinenkin huomattiin, että logiikka olisi ollut järkevää pilkkoa useampiin oliohin (jo päivityskonfliktien estämiseksi), mutta tässä vaiheessa koodia oli jo niin paljon, ettei sitä enää jälkikäteen tehty ongelmien välttämiseksi (tai refaktoroitu vastaavan SEPA-parin toimesta). 4.4 Visitor Erilaisten syöte-elementtien (tekstikenttien ja valikoiden) haluttiin toimivan mahdollisimman samankaltaisesti kuin muissa vastaavissa toteutuksissa (esimerkiksi Java Swing). Tavoitteena oli toteuttaa sellaisia syöte-elementtejä, joihin käyttäjän antama syöte siirrettiin sovellusohjelmoijalta näkymättömästi seuraavan sivulatauksen yhteydessä. Käytännössä tämä tarkoitti sovellusohjelmoijan kannalta sitä, että esimerkiksi tallennusnappia vastaavassa tapahtumakäsittelijässä ohjelmoija pystyi lukemaan käyttäjän antaman syötteen suoraan inputelementtiä kuvaavasta olioista: $search_field = new FormTextField(); Ja tallennuksen jälkeisessä tapahtumakäsittelijässä käyttäjän syöttämään arvoon päästiin käsiksi seuraavasti: $search_field->getvalue(); Tällä suunnittelumallilla toteutettu toiminnallisuus oli myös sovellusohjelmoijille näkyvä. Ohjeilmoijien palaute tästä oli myönteinen. 7

8 4.5 Singleton / Factory Tämän suunnittelumallin mukaisesti toteutettiin tapahtumien käsittelyn ydin (InputProcessor, joka ei ole sovellustasolla näkyvissä). Ratkaisu osoittautui toimivaksi ja sitä ei ollut tarve muttaa jälkikäteen. 4.6 Composite Käyttöliittymäoliot luotiin composite-mallia hyödyntäen. Mallin käyttö mahdollisti yksittäisten komponenttien, ja jopa suurempien kokonaisuuksien uusiokäytön eri sovelluksen osissa. Hyvä ratkaisu, joka omalta osaltaan vähensi työtä loppuvaiheessa. 4.7 Strategy Tämän suunnittelumallin tarkoituksena on mahdollistaa sovelluksen helppo siirrettävyys tietokantaympäristöstä toiseen (esimerkiksi PostgreSQL:stä MySQL:ään), sekä mahdollistaa useiden erilaisten autentikontimenetelmien käytön, siten että vaaditut muutokset keskittyisivät yksittäiseen sovelluksen osaan (ei varsinaiseen sovelluslogiikkaan). Projektin aikana sovellukseen ei kuitenkaan luotu kuin yksi autentikointimenetelmä sekä yksi kantayhteys (PostgreSQL), joten mallin toimivuuden toteaminen jää mahdollisille jatkokehittäjille. 4.8 Decorator Tätä suunnittelumallia käyttäen saatiin abstraktoitua sovellusohjelmoijilta tietty monimutkaisuus pois. Mallin hyödyntäminen keskittyi käytännössä tietokannan käsittelyyn: PostgreSQLConnection on varsinainen tietokantayhteysluokka, joka toteuttaa DatabaseConnectionrajapinnan. Tälle rajapinnalle on kuitenkin syötettävä SQL-lauseita, jotta niitä voi käyttää. Varsinaiseen sovelluslogiikkaan ei kuitenkaan haluttu SQL:ää, joten DatabaseConnectionia hyödyntämään luotiin DataManager-decorator luokka, joka käytti DatabaseConnectionin tarjoamaa toiminnallisuutta ja tarjosi samalla itsensä käyttäjälle hyvin yksinkertaisen rajapinnan haluttujen hakujen tekemiseen. Mallin käyttö oli hyödyllistä, koska näin kantariippuvainen SQL saatiin varsinaisesta sovelluslogiikasta täysin pois. 5 Yhteenveto Suunnittelumalleja käyttämällä saatiin aikaan normaali tapahtumapohjainen, MVC-mallin mukainen sovellus, ilman että pyörää olisi tarvinnut keksiä useassa paikassa uudelleen (tai oikeastaan pyörän muotoa, varsinainen pyörä oli käytännössä toteutettava). Toteutettu sovellus on näin myös tilallinen (palvelimen osalta), mikä poikkeaa yleisestä käytännöstä websovelluksien yhteydessä. Suunnittelumalleja hyödyntämällä varsinaisille sovellusohjelmoijille saatiin luotua ympäristö, joka oli tarpeeksi nopeasti opittavissa ja mahdollisti helpon iteratiivisen kehityksen, ilman suurempia sudenkuoppia. Arkkitehtuurista, käytetyistä suunnittelumalleista, sekä tilallisesta sovelluksesta johtuva suurin negatiivinen asia on näkyvissä loppukäyttäjälle oli se, että selaimen navigointinappeja ei voi käyttää (toisaalta nyt käyttäjä ei voi myöskään korruptoida sovellusta tai tietokantaa käyttämällä navigointinappeja). 8