JULKAISUJÄRJESTELMÄN JA OHJELMISTOKEHYKSEN VÄLISSÄ - OHJELMA KEVYIDEN WEB-SOVELLUSTEN TOTEUTTAMISEEN

Transkriptio

1 JULKAISUJÄRJESTELMÄN JA OHJELMISTOKEHYKSEN VÄLISSÄ - OHJELMA KEVYIDEN WEB-SOVELLUSTEN TOTEUTTAMISEEN Annika Granlund Opinnäytetyö Joulukuu 2011 Tietojenkäsittelyn koulutusohjelma Ohjelmistotuotanto Tampereen ammattikorkeakoulu

2 2 TIIVISTELMÄ Tampereen ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Ohjelmistotuotanto GRANLUND, ANNIKA: Julkaisujärjestelmän ja ohjelmistokehyksen välissä ohjelma kevyiden web-sovellusten toteuttamiseen Opinnäytetyö 48 sivua, liitteet 1 sivu Joulukuu 2011 Opinnäytteeni ideointi lähti liikkeelle, kun Futurable Oy tarvitsi kevyen järjestelmän, joka helpottaisi pienten web-sovellusten rakentamista. Kun sopivaa avoimen lähdekoodin ohjelmistoa ei ollut saatavilla, päätettiin aloittaa oman kehittäminen. Sen tarkoituksena oli olla kevyt ja helppokäyttöinen, mutta kuitenkin muunneltavissa erilaisten projektien tarpeisiin. Henkilökohtaiseksi tavoitteeksi asetin oman oliopohjaisen ohjelmointitaitoni kehittämisen sekä suunnittelumalleihin ja kerrosarkkitehtuuriin tutustumisen. Käytin opinnäytetyössäni konstruktiivista tutkimusotetta, jonka tarkoituksena oli tuottaa PHP-ohjelmointikielellä avoimen lähdekoodin järjestelmä kevyiden websovellusten toteuttamiseen. Tuotteen toimivuus testattiin asiakasprojektien yhteydessä. Opinnäytetyöni kirjalliseen osuuteen olen valinnut kaksi esimerkkiprojektia, joissa järjestelmä on otettu käyttöön. Työni käytännön tuloksena valmistui julkaisujärjestelmän ja ohjelmistokehyksen risteytys: perusversio ohjelmistosta, joka helpottaa ja nopeuttaa rajallisesti sisältöä omaavien web-sovellusten toteuttamista. Järjestelmän suunnittelussa ja toteutuksessa käytin hyödyksi PHP-kielen oliomaisia ominaisuuksia, kerrosarkkitehtuuria sekä suunnittelumalleja. Teoreettisessa viitekehyksessä pohdin Futurable Oy:n järjestelmän ominaisuuksia julkaisujärjestelmän sekä ohjelmistokehyksen näkökulmasta sekä kerron lukijalle käytännön työssä käytetyistä tekniikoista. Työn tuloksena syntynyt järjestelmä vastaa sille asetettuja tavoitteita, mutta siinä on myös paljon kehitettävää: hallintapaneelin käytettävyyttä voisi esimerkiksi parantaa ja monipuolistaa lisättävien komponenttien osalta. Komponenttilähtöisyys mahdollistaa järjestelmän käytön erilaisissa projekteissa sekä helpon laajennettavuuden, jotka olivat tavoitteista ehkä tärkeimpiä. Opinnäytetyön tekeminen vei myös omaa ammatillista osaamistani valtavasti eteenpäin. Asiasanat: Julkaisujärjestelmä, ohjelmistokehys, suunnittelumallit, PHP, olioohjelmointi, kerrosarkkitehtuuri

3 3 ABSTRACT Tampereen ammattikorkeakoulu Tampere University of Applied Siences Degree Programme in Business Information Systems Option of Software Development GRANLUND, ANNIKA: Between the Content Management System and Framework - Software to Create Lightweight Web Applications Bachelor s thesis 48 pages, appendices 1 page December 2011 The ideation of the Bachelor s thesis begun when Futurable Oy needed a lightweight computer system that would ease the construction of small-scale web applications. When there was no suitable open source product available, it was decided to start the process to producing one. Its intention was to be lightweight and easy to use, but at the same time modifiable enough to meet the demands of different projects. As a personal goal the thesis writer aimed to improve her object oriented programming skills and become familiar with design patterns and layered architectural pattern. In the thesis constructive research method was used, whose aim was to produce an open source system that creates lightweight web applications and which is written with PHP programming language. The functionality of the created system was tested in actual production environment with real customer projects. For the literary part of the thesis were selected two example projects where the system has been taken into use. A hybrid system between a content management system and a programming framework was created as a hands-on result of this thesis: basic version of a program that helps and quickens actualizing web applications with limited content. In the design and implementation process of the system object oriented features of PHP-language were used, combined with layered architectural pattern and design patterns. In the theoretical context of this thesis the characteristics of Futurable Oy's system are examined from the viewpoints of content management system and programming framework. Some techniques that were used in the practical work are also shared with the reader. The produced system fulfills its requirements that were set in the beginning of the process, but it also has a great number of features to be improved. For example, the usability of control panel could be better and more versatile regarding the components. The component-centered design approach fulfills two of the maybe most important design goals: the system is easy to expand and easy to use in different kind of projects. Key words: CMS, framework, design patterns, PHP, object oriented programming, layered architectural pattern

4 4 SISÄLTÖ 1 JOHDANTO TAUSTA JULKAISU- JA SISÄLLÖNHALLINTAJÄRJESTELMÄT SEKÄ OHJELMISTO- KEHYKSET Julkaisu- ja sisällönhallintajärjestelmät Ohjelmistokehykset Julkaisujärjestelmän ja ohjelmistokehyksen välissä - Futurable Oy:n järjestelmä JÄRJESTELMÄSSÄ KÄYTETYT TEKNIIKAT Oliopohjainen ohjelmointi PHP-kielellä Kerrosarkkitehtuuri Suunnittelumallit FUTURABLE OY:N JÄRJESTELMÄN SUUNNITTELU, TOTEUTUS JA TOIMINTA Tarkoitus ja tavoite Oliopohjaisuus Kerrosarkkitehtuurin käyttö Suunnittelumallien käyttö Rekursiokooste (Composite) Data Mapper Operaatiorunko (Template Method) Kehitysideat ESIMERKIT FUTURABLE OY:N JÄRJESTELMÄN KÄYTÖSTÄ Tampereen akateemisen sinfoniaorkesterin web-sivusto Kuullos Orchestran web-sivusto POHDINTA LÄHTEET LIITTEET... 49

5 5 1 JOHDANTO Opinnäytteeni tarkoituksena oli luoda Futurable Oy:lle kevyt järjestelmä pienten web-sovellusten tekemisen helpottamiseksi. Henkilökohtaisella tasolla halusin oppia lisää oliopohjaisesta ohjelmoinnista (erityisesti PHP-kielellä), suunnittelumalleista ja kerrosarkkitehtuureista. Opinnäytetyön ohessa oli tarkoitus kerätä kokemusta suurten järjestelmien suunnittelusta ja toteutuksesta, jotta voisin työelämässä ottaa vastaavanlaisia projekteja vastaan. Tavoitteena oli suunnitella ja toteuttaa PHP-ohjelmointikielellä järjestelmä, jota olisi helppo laajentaa ja kehittää tulevaisuudessa. Järjestelmän tuli olla kevytrakenteinen ja helppokäyttöinen, mutta kuitenkin joustava, jotta sitä voitaisiin soveltaa erilaisten projektien yhteydessä. Tavoitteena oli toteuttaa järjestelmä, joka mahdollistaa sisällön päivittämisen hallintapaneelin kautta ilman ohjelmointitietämystä. Työn ulkopuolelle rajattiin ulkoasun, metatietojen, rakenteen ja ajastusten muokkaamisen mahdollisuus hallintapaneelin kautta. Näiden tietojen konfiguroinnin haluttiin kuitenkin olevan helppoa ohjelmointia osaavalle henkilölle. Futurable Oy:lle kehitetty järjestelmä on julkaisujärjestelmän ja ohjelmistokehyksen yhdistelmä, joten kuvaan opinnäytetyössäni ensin molempien ominaisuuksista sekä siitä, miten niitä on sovellettu Futurable Oy:n järjestelmässä. Sen jälkeen tarkastelen käyttämiäni tekniikoita yleisesti sekä niiden soveltamisesta käytännön työhöni. Lopuksi esittelen kaksi esimerkkiprojektia, joissa on käytössä kehittämäni järjestelmä.

6 6 2 TAUSTA Tämä opinnäytetyö sekä opinnäytetyöhön liittyvä käytännön osuus on tehty Futurable Oy:lle, jossa olen itsekin osakkaana. Futurable Oy on tammikuussa 2011 perustettu ohjelmistoalan yritys, joka toimittaa erilaisia web-sovelluksia sekä yrityksille että oppimisen tueksi. Toiminnan käynnistyessä ilmeni, että yrityksellämme on tarvetta kevyelle järjestelmälle, joka helpottaa pienten websovellusten rakentamista. Futurable Oy tarvitsi työkalun, joka mahdollistaa kevyiden web-sovellusten toteuttamisen helposti, mutta kuitenkin joustavasti. Kevyillä web-sovelluksilla tarkoitetaan tässä yhteydessä sellaisia pieniä järjestelmiä, joiden sisältöä voi muokata ohjelmointia ymmärtämättä, mutta jonka toiminnallisuuden ja ulkoasun määrittelee ohjelmoinnin tunteva henkilö. Järjestelmän rungon tulee olla joustava, jotta sitä pystytään hyödyntämään mahdollisimman monessa projektissa. Se ei kuitenkaan saa olla liian kankea ja moniulotteinen, vaan sen pitää pysyä helppokäyttöisenä sekä järjestelmän käyttäjälle että sisällön hallinnoijalle. Tarvittiin siis järjestelmä, jonka avulla voidaan luoda erilaisia toimintoja sisältäviä pieniä web-sovelluksia, mutta joka on niin kevyt ja helppokäyttöinen, että sisällön muokkaaminen on vaivatonta myös ohjelmointia ymmärtämättä. Halusimme PHP (Hypertext Preprocessor) -ohjelmointikielellä toteutetun järjestelmän, jota voidaan hyödyntää mahdollisimman laajasti erilaisissa projekteissa. Sen tuli olla jotain ohjelmistokehyksen ja julkaisujärjestelmän väliltä, jotta se vastaisi yrityksemme tarpeita. Ajatus oman järjestelmän kehittämisestä syntyi, kun sopivaa avoimen lähdekoodin järjestelmää ei ollut tarjolla.

7 7 3 JULKAISU- JA SISÄLLÖNHALLINTAJÄRJESTELMÄT SEKÄ OHJELMISTO- KEHYKSET 3.1 Julkaisu- ja sisällönhallintajärjestelmät Julkaisujärjestelmä-käsitteellä tarkoitetaan tyypillisesti kevyttä tai keskiraskasta sisällönhallintajärjestelmää jolla hallitaan internet-, intranet- tai extranetsivustoja (Tolvanen 2008). Sisällönhallintajärjestelmä (content management system, CMS) puolestaan voidaan käsittää monella eri tavalla riippuen käyttäjän näkökulmasta. Yleisesti se kuitenkin käsitetään laajana ja monipuolisena järjestelmänä tai työkaluna, joka kokoaa, hallinnoi ja julkaisee tietoa sekä toiminnallisuutta (Boiko 2005, 85). On hieman häilyvää, missä sisällönhallintajärjestelmän ja julkaisujärjestelmän raja kulkee. Tolvasen (2008) mukaan voidaan todeta, että järjestelmää voidaan lisääntyvässä määrin kutsua sisällönhallintajärjestelmäksi, jos siinä on useita sisältöjen hallintaan liittyviä ominaisuuksia, kuten hajautettu sisällönhallinta, monipuolinen metatietojen ja monikielisten sisältöjen hallinta sekä mahdollisuus monipuolisiin asiointipalveluihin. Boikon (2005, 86) mukaan sisällönhallintajärjestelmällä hallinnoidaan tietoja ja julkaistaan niitä erilaisissa kanavissa. Sisällönhallinnassa on hänen mukaansa enemmänkin kyse siitä, että sisältö talletetaan tietokantaan sisältökomponentteina, tiedon palasia eli komponentteja haetaan kannasta kuhunkin tilanteeseen sopivilla argumenteilla ja haetusta tiedosta koostetaan ja julkaistaan materiaalia erilaisissa medioissa. Julkaisujärjestelmä voikin olla osa sisällönhallintajärjestelmää (Boiko 2005, 86). Sisällönhallintajärjestelmässä on kyse siis laajemmasta kokonaisuudesta kuin pelkästä websivuista ja niiden sisällön hallinnasta. Kuviossa 1 selvennetään sisällönhallintajärjestelmän toimintaperiaatetta, kun kyseessä on web-sisällön julkaiseminen.

8 8 KUVIO 1. Sisällönhallintajärjestelmän toiminta (Boiko 2005, 76) Tolvasen (2008) mukaan järjestelmä on lähempänä julkaisujärjestelmää, jos se vaikuttaa olevan paranneltu versio kotisivujen päivitystyökalusta. Tolvanen (2008) toteaa myös, että tyypillisesti julkaisujärjestelmän tarkoituksena on nopeuttaa ja helpottaa verkkopalvelun julkaisua ja sisällönhallintaa. Boiko (2005, 86,106) kirjoittaa, että osana sisällönhallintajärjestelmää julkaisujärjestelmän tarkoituksena on julkaista materiaalia eri medioissa, kuten webissä, muissa sähköisissä medioissa sekä printtimediassa. Joomlaportalin (2007) mukaan julkaisujärjestelmän perustarkoituksena on erottaa sisältö esityskerroksesta ja tehdä sisällön (esim. tekstin, kuvien) tuottaminen ja julkaiseminen mahdollisimman helpoksi. Oma päätelmäni asiasta on, että julkaisujärjestelmän tarkoituksena on auttaa käyttäjää julkaisemaan materiaalia, joka voi olla tekstiä, kuvia, ääntä, liikkuvaa kuvaa jne. Järjestelmän ja sillä tehtävän julkaisun laajuus riippuu siitä, onko kyseessä pelkkä julkaisujärjestelmä vai onko se osana suurempaa sisällönhallintajärjestelmää. Järjestelmän monipuolisuudesta riippuu myös se, voiko käyttäjä hallinnoida pelkästään sivuston sisältöä vai sisältyykö myös ulkoasun editointi järjestelmän ominaisuuksiin. Julkaisujärjestelmä on oikea ratkaisu silloin kun web-palvelun käyttäjä haluaa siirtyä yhden sisältöpäivittäjän järjestelmästä hajautettuun sisällönhallintaan ja tuotantoon. Jos taas kaivataan järeitä työkaluja suurien web-järjestelmien ylläpitoon ja muokkaamiseen, käytettäväksi järjestelmäksi on hyvä valita tarkoitukseen sopiva, tarvittavilla ominaisuuksilla varustettu sisällönhallintajärjestelmä. (Tolvanen 2008.) Boikon (2005, introduction) mukaan sisällönhallinta on väylä todelliseen ja toimivaan sähköiseen liiketoimintaan. Se auttaa yritystä organisoimaan ja hallitsemaan informaatiota. Sisällönhallintajärjestelmän avulla yritys voi luoda ja hallinnoida informaatiopalasia sekä linkittää niitä sivustoihin tai si-

9 9 vuihin, joiden kokee olevan hyödyllisiä sisällön kannalta. (Boiko 2005, introduction.) Tolvasen (2008) mukaan julkaisujärjestelmiin liitetään usein käyttäjien matala oppimiskynnys, helpot ajastettavat toiminnot sekä monipuoliset mahdollisuudet muokata verkkopalvelun rakennetta, sivuja ja sisältöä. Viimeisin aiheuttaa melkoista päänvaivaa julkaisujärjestelmien toimittajille. Oman kokemukseni mukaan usein käy niin, että julkaisujärjestelmästä yritetään tehdä käyttäjän näkökulmasta mahdollisimman monipuolinen. Tämä johtaa siihen, että järjestelmässä on liikaa tarpeettomia ominaisuuksia ja sen käytettävyys kärsii. Tällaiset suuret, monipuolisia palveluja tarjoavat julkaisujärjestelmät ovat usein paitsi hankalia käyttää ylläpitäjän kannalta, myös rakenteellisesti haastavia ottaa haltuun ohjelmoijan näkökulmasta. Julkaisujärjestelmän ja sisällönhallintajärjestelmän parhaimpiin puoliin kuuluu omasta mielestäni se, että järjestelmät ovat web-pohjaisia eli eivät ole riippuvaisia tietystä koneesta vaan päivitys onnistuu miltä tahansa koneelta, jossa on Internet-yhteys. Eduksi voidaan lukea myös se, että ohjelmointitaitoa ei välttämättä tarvita, mutta oman kokemukseni mukaan se on kuitenkin eduksi. Ilman ohjelmointitaitoa sisällön päivittäminen kyllä onnistuu, mutta vaatii hieman perehtymistä järjestelmän rakenteeseen ja toimintaan. Ulkoasun ja sivuston rakenteen muokkaaminen ilman ohjelmointitaitoa on työläämpää, ellei jopa mahdotonta. Esimerkiksi Joomla-julkaisujärjestelmässä rakennetta muutetaan muun muassa muokkaamalla index.php-tiedostoa, jonka ymmärtäminen ohjelmointitaidoitta voi olla hankalaa. Mielestäni julkaisujärjestelmät voivat rajoittaa websivuston ulkoasua. Usein julkaisujärjestelmän rakenne on tietynlainen tai perustuu ainakin tiettyihin komponentteihin (ja niiden järjestykseen), jolloin kaikkein luovimmat ratkaisut eivät onnistu ilman lähdekoodin muokkaamista eli räätälöintiä. Perttu Tolvasen (2010a) mukaan avoimen lähdekoodin julkaisujärjestelmät ovat olleet jo useita vuosia merkittävä tekijä julkaisujärjestelmien markkinakentällä. Hänen mukaansa avoimen koodin järjestelmät ovat alkaneet haastaa myös suurimpia kaupallisia tuotteita viime vuosina. Tolvanen (2010a) on tutkinut

10 10 avoimen lähdekoodin julkaisujärjestelmien vahvuuksia. Hänen mukaansa avoimuus mahdollistaa järjestelmäntoimittajan vaihtamisen helpommin eikä asiakas ole enää riippuvainen tietystä toimittajasta. Avoimuus tarjoaa myös sen, että kuka tahansa ohjelmointia ymmärtävä voi ladata järjestelmän ja opetella sen käytön. Tolvasen (2010a) mukaan työvoimaa järjestelmän kehittämiseen ja ylläpitoon voi sen seurauksena löytyä helpommin. Omasta mielestäni avoimuus voi tehostaa järjestelmän kehittymistä, sillä kehittäjäyhteisöön voi liittyä ympäri maailmaa. Tämä johtaa siihen, että yhteisö on laaja ja osaaminen on monipuolista sekä vahvaa. Koska kehittäjäyhteisö on aktiivinen ja suuri, löytyy verkosta paljon ilmaisia, valmiita lisäosia ja parannuksia (Tolvanen 2010a). Avoimuudessa hyödyksi nousee myös se, ettei lisenssikustannuksia tule lainkaan. Tämä on erityisen positiivista silloin, kun ohjelmistolla oletetaan olevan pitkä elinkaari. (Tolvanen 2010a.) Avoimen lähdekoodin julkaisujärjestelmissä on myös heikkouksia. Koska avointa lähdekoodia kehittää usein laaja yhteisö, on virallisen tuen ja tukipalveluiden saatavuus epävarmaa (Tolvanen 2010a). Lisäksi tuotteen kehitys perustuu usein sen suosioon ja mikäli suosio laskee voi tuotteen kehitys hidastua tai loppua ja yhteistyökumppanit voivat vähentyä nopeastikin. Vaikka avoimissa julkaisujärjestelmissä ei lisenssimaksuja joudukaan maksamaan, voivat tuotteen ylläpitokustannukset nousta korkeiksi, varsinkin jos järjestelmää on räätälöity ja päivityksiä joutuu tekemään tiheään tahtiin. (Tolvanen 2010a.) Avoimessa lähdekoodissa on omasta mielestäni riskinä myös se, että kuka tahansa voi tarjota osaamistaan siihen, vaikka ei oikeasti järjestelmää osaisikaan käyttää. Tämä voi johtaa siihen, että asiakkaiden luottamus järjestelmää ja sen toimintaa kohtaan voi laskea. Tolvasen (2010b) sekä oman kokemukseni mukaan käytetyimpiä avoimen lähdekoodin julkaisujärjestelmiä Suomessa ovat WordPress, Joomla ja Drupal, joilla voi sekä rakentaa web-sivuston että hallinnoida sen sisältöä yllättävän laajasti. Kaupallisia versioita on myös runsaasti tarjolla, esimerkkeinä Dokumentum sekä suomalaiset Crasmaganer, ewriter ja P4 muutamia mainitakseni.

11 Ohjelmistokehykset Ohjelmistokehys on ohjelmistorunko, jota voidaan täydentää eri tavoin eri tarkoitusta varten; ohjelmistokehys on siten vaillinaisesti toteutettu ohjelmistotuote, jossa on aukkoja ennalta odotettuja täydennyksiä varten. (Koskimies & Mikkonen 2005, 187.) Kehystä voidaan kuvata myös yhteistyössä toimivaksi luokkakokoelmaksi, joka muodostaa uudelleenkäytettävän suunnitteluratkaisun tietyn sovellusalueen tarpeisiin (Gamma, Helm, Johnson & Viissides 2000, 26). Gamma ym. (2000, 26) mukaan kehys sanelee sovelluksen arkkitehtuurin ja näin määrää myös sovelluksen kokonaisrakenteen. Kokonaisrakenteella tarkoitetaan muun muassa sovelluksen luokka- ja oliojakoa, niiden vastuualueita sekä kontrollin kulkua. Kun ohjelmistokehys määrittelee nämä suunnitteluratkaisut, voi ohjelmoija keskittyä ratkomaan sovelluskohtaiset kysymykset (Gamma ym. 2000, 26-27). Ohjelmistokehyksen perustavoitteena on muodostaa ohjelmistolle runko, joka mahdollistaa laajamittaisen ja systemaattisen ohjelmistojen uudelleenkäytön (Koskimies & Mikkonen 2005, 187). Kehystekniikassa voidaan käyttää uudelleen komponenttien ja perustoiminnallisuuksien lisäksi myös arkkitehtuuria. Gamma ym. (2000, 27) mukaan ohjelmistokehykset korostavatkin enemmän suunnittelun kuin koodin uudelleenkäyttöä. Kun kehys on suunniteltu hyvin, sitä voidaan käyttää joustavasti ja monipuolisesti omalla sovellusalueellaan. Näin laaja uudelleenkäyttö mahdollistaa nopean ja laadukkaan ohjelmistokehityksen (Koskimies & Mikkonen 2005, 187). Ohjelmistokehykset eivät varsinaisesti ole sidottuja mihinkään tiettyyn ohjelmistokehitysparadigmaan, mutta niistä on tullut suosittuja oliopohjaisessa kehityksessä. Oliopohjaisessa ohjelmoinnissa kehyksestä puhuttaessa tarkoitetaan kiinteästi toisiinsa liittyvien luokkien ja/tai rajapintojen kokoelmaa, joka toteuttaa tietyn ohjelmistoperheen perusarkkitehtuurin (Koskimies 2000, 260). Ohjelmistokehys on siis laaja, hyvin suunniteltu kokonaisuus, jota käyttämällä sovellusten rakentaminen nopeutuu ja sillä tehtyjen ohjelmistojen rakenne pysyy yhdenmukaisena (Gamma ym. 2000, 27). Kehyksien ohjelmistorungon avulla ko-

12 12 konaisen ohjelmistoperheen rakentaminen on tehokasta, tuotteiden ylläpito helpottuu ja ne ovat käyttäjäystävällisiä yhdenmukaisen ulkoasunsa vuoksi (Gamma ym. 2000, 26). Gamma ym. (2000, 27) mukaan ohjelmistokehykset ovat kaikkein vaikeimmin suunniteltavia kokonaisuuksia. Vaikeaksi suunnittelun tekee se, että suunnittelijan tulisi miettiä, mikä arkkitehtuuri olisi sopiva kaikille kyseisen alueen sovelluksille. Jotta suunnittelija pystyisi arkkitehtuurin miettimään, hänen tulee tuntea sovellusalue erittäin hyvin. Lisäksi suunnittelijan tulee olla tietoinen tekemiensä ratkaisuiden vaikutuksesta arkkitehtuuriin ja näin ollen koko kehykseen. Kehyksen suurin hyöty on sen tarjoama arkkitehtuuri ja jokainen merkittävä muutos sen suunnitteluratkaisussa vähentää kehyksen hyödyllisyyttä, toteavatkin Gamma ym. (2000, 27). Ohjelmistokehystä suunniteltaessa tulee ottaa sovellusalueen lisäksi huomioon se, että kehyksen avulla tehdyt sovellukset ovat täysin riippuvaisia siitä. Jos kehystä joudutaan jälkikäteen muuttamaan, sovellustakin on muutettava, kirjoittavat Gamma ym. (2000, 27). Löyhällä luokkien välisellä sidonnalla muutoksien vaikutuksia pystytään estämään, mutta sekään ei välttämättä ratkaise kaikkia ongelmia. Suunnittelumallien käyttö ohjelmistokehyksien suunnittelussa on erittäin suotavaa, sillä ne tarjoavat valmiita suunnitteluratkaisuja olio-ohjelmoinnin yleisiin ongelmiin. Ne auttavat suunnittelijaa löytämään ratkaisuja, joita on testattu ja joiden on todettu olevan toimivia ja kestäviä. Suunnittelumalleja käyttävä kehys onnistuu todennäköisesti luomaan enemmän suunnittelun ja koodin uudelleenkäyttöä kuin kehys, joka ei käytä suunnittelumalleja (Gamma ym. 2000, 27). Mallit auttavat sekä suunnittelutyössä että käytössä, kunhan ne dokumentoidaan riittävän tarkasti. Koskimies & Mikkonen (2005, 190) kirjoittavat, että suunnittelumalleilla on keskeinen asema kehysten arkkitehtuurissa, sillä useimpien mallien tavoitteena on lisätä joustavuutta ja muunneltavuutta, johon myös kehykset pyrkivät. Ohjelmistokehyksen käyttö kääntää kontrollin suunnan sovelluksen ja ohjelmiston välillä (Gamma ym. 2000, 27). Perinteisessä ohjelmoinnissa, jossa käytetään esimerkiksi kirjastoja tai valmiita työkalupakkeja, ohjelmoijan tehtävänä on

13 13 suunnitella ja toteuttaa ohjelmiston runko, joka kutsuu olemassa olevaa koodia. Tällöin sovelluksella on toiminnan pääkontrolli (Koskimies & Mikkonen 2005, 191). Ohjelmistokehystä käytettäessä tilanne on päinvastainen: runko ja suunnitteluratkaisut ovat valmiina ja ohjelmoijan tehtäväksi jää rungon kutsuman osan koodaaminen (Gamma ym. 2000, 27). Tätä käänteistä kontrollin kulkua kutsutaan Hollywood-periaatteeksi ( don t call us, we ll call you ), kirjoittavat Koskimies & Mikkonen (2005, 191). Kuviossa 2 selvennetään kontrollin suunnan muutosta. KUVIO 2. Perinteinen ohjelmakirjasto (vas.) ja kehys (oik.) (Koskimies 2000, 260) Koskimiehen (2000, 260) mukaan kehyksestä saadaan yksittäinen sovellus tai komponentti erikoistamalla. Erikoistaminen tarkoittaa, että kehyksen erikoistamisrajapintaa hyväksikäyttäen voidaan saada aikaan tuote, jonka pohjana kehys toimii. Erikoistamisrajapinta kertoo, mitä kehyksen osia voi muokata ja miten. Kehystä voidaan erikoistaa useilla eri tavoin, kuten periyttämällä, rajapintoja hyödyntäen ja konfiguroimalla (Koskimies 2000, 260). Kehyksen ja sen käyttämien suunnittelumallien sekä rajapintojen dokumentointi on äärimmäisen tärkeää (Gamma ym. 2000, 27), jotta kehyksen edut saataisiin tehokkaasti käyttöön. Kehyksen suurin etu lienee sen uudelleenkäyttö, joka mahdollistaa nopean ja laadukkaan ohjelmistojen valmistamisen. Koskimiehen (2000, 265) mukaan ohjelmistokehyksillä on myös muita etuja, kuten muutoksia ja variaatioita ennakoivan ohjelmistokehityksen vahvistaminen. Lisäksi kehystekniikka standardisoi ohjelmistotuotantoa sekä yrityksen sisällä että yritysten välillä ja muodostaa yri-

14 14 tykselle arkkitehtuuria korostavan ohjelmointikulttuurin (Koskimies 2000, 265). Jos kehys käyttää suunnittelumalleja ja on hyvin dokumentoitu, sen käyttöönotto voi olla vaivatonta ja kohtuullisen nopeaa. Gamma ym. (2000, 27) mukaan kehyksiä käyttämällä sovellusten rakentaminen nopeutuu ja rakenteista tulee yhdenmukaisia, mikä helpottaa ylläpidettävyyttä ja parantaa käytettävyyttä. Kehyksissä on myös ongelmia, tai ainakin haasteita. Ongelmaksi voi Koskimiehen (2000, 265) mukaan muodostua esimerkiksi kehyksen aukkojen täyttäminen, jos kehys on dokumentoitu puutteellisesti. Kehykset ovat valtavia luokkakokoelmia, joita voi olla mahdoton käyttää ilman riittävää dokumentointia. Ongelmia voi syntyä myös, jos samassa tuotteessa käytetään kahta eri kehystä ja niiden toiminnallisuudet ovat ristiriidassa keskenään (Koskimies 2000, 265). Kehys voi olla myös liian kankea, jolloin se ei tarjoa riittävää joustavuutta, mitä siltä vaadittaisiin erikoistamiseen. Koskimies (2000, 266) toteaa myös, että kehyksellä voi olla vaikeaa tuottaa pientä, riisuttua sovellusta, koska se saattaa sisältää kehyksen perusominaisuudet, vaikkei niitä tarvittaisikaan. Ohjelmistokehykset ovat vaikeita suunnitella (Gamma ym. 2000, 27) ja ongelmana voi olla myös huonosti suunniteltu kehys, jota joudutaan korjaamaan myöhemmässä vaiheessa. Sovellukset, jotka käyttävät kehystä, ovat tällöin alttiina muutoksille ja tarvitsevat mahdollisesti itsekin muutoksia, mikä aiheuttaa ylimääräistä työtä ja kustannuksia. Kehysarkkitehtuuri on Koskimiehen (2000, 261) mukaan harkinnan arvoinen ratkaisu silloin, kun kysymys on tuotteesta, josta on pystyttävä tekemään nopealla aikataululla erilaisia variaatioita. Koska kehyksen suunnittelu on vaikeaa, tulisi suunnittelijan tuntea sovellusalue läpikotaisin, jotta kehys olisi taloudellisesti kannattava ratkaisu. Koskimies (2000, 262) kertoo myös, että kehyksen suunnittelu- ja toteutuskulut (esimerkiksi ajallisesti) ovat niin suuret, että kehys on kannattamaton, ellei siitä tehdä vähintään kolmesta kuuteen erilaista sovellusta. Ehkäpä tunnetuimpia ohjelmistokehyksiä ovat erilaiset graafisten käyttöliittymien toteutukseen tarkoitetut luokkakirjastot, kuten Microsoftin MFC, Sunin AWT sekä Java-ympäristöön kuuluva Swing (Koskimies 2000, 261; Koskimies & Mikkonen 2005, 188)

15 Julkaisujärjestelmän ja ohjelmistokehyksen välissä - Futurable Oy:n järjestelmä Futurable Oy:n järjestelmä on risteytys julkaisu-/sisällönhallintajärjestelmästä ja ohjelmointikehyksestä. Kyseessä on julkaisujärjestelmä siinä mielessä, että sen tarkoituksena on helpottaa ja nopeuttaa web-sovelluksen julkaisua. Yhtenä perusajatuksena on ollut se, että asiakkaalle toteutettavan web-sovelluksen tekemisen pitää olla kustannustehokasta. Usein esimerkiksi web-sivustot ovat perusrakenteeltaan samanlaisia, minkä vuoksi on hyvä olla olemassa runko, jota konfiguroimalla saadaan sivuston perusrakenne nopeasti ja vaivattomasti. Kuten ohjelmistokehyksen, myös Futurable Oy:lle kehitetyn järjestelmän avulla saadaan asiakkaalle toimitettava sovellus konfiguroimalla ja erikoistamalla sitä (Koskimies 2000, 260). Rungon rakenteen konfigurointi tapahtuu XML (extensible Markup Language) -tiedostoja muokkaamalla. Konfiguroimalla määritellään paitsi rakenne myös esimerkiksi tietokantayhteyteen tarvittavat tiedot sekä ladattavat CSS (Cascading Style Sheet)- ja JavaScript-tiedostot. Kehittämäni tuote ei kuitenkaan ole ohjelmistokehykseen verrattavissa siinä mielessä, että se on hyvin kevytrakenteinen ja sen käyttötarkoitus sekä sovellusalue ovat melko suppeat. Se on suunniteltu helpottamaan pienten ja kevyiden web-sovellusten julkaisua eikä sillä ole tarkoitus saada aikaan massiivia sovelluksia eikä tuoteperheitä, kuten ohjelmistokehyksellä. Järjestelmä perustuu sisällönhallintajärjestelmän tapaan komponenttiajatteluun. Järjestelmä koostuu abstraktista, komponenttien yleiset piirteet sisältävästä yläluokasta ja siitä erikoistetuista aliluokista (konkreettisista komponenteista). Perusjärjestelmä sisältää kahdeksan erilaista komponenttia, muun muassa otsikko-, kappale-, teksti- ja kuvakomponentit. Sovelluksen sisältö muodostetaan näistä komponenteista ja asiakkaan tarpeen mukaan niitä voidaan kehittää myös lisää. Komponenttiajattelu viittaa myös ohjelmistokehykseen, sillä se mahdollistaa sovelluksen käänteisen kontrollin: runko on aina olemassa, mutta osa sen kutsumasta ohjelmakoodista voidaan kirjoittaa jälkikäteen.

16 16 Järjestelmän suunnittelussa ja toteutuksessa käytin apuna suunnittelumalleja. Malleja käytetään usein ohjelmistokehyksien yhteydessä, mutta ne sopivat myös kehittämääni sovellukseen hyvin. Vaikka suunnittelumallien ymmärtäminen oli aluksi hankalaa niiden abstraktin luonteen vuoksi, niiden käyttö osoittautui toimivaksi ratkaisuksi. Järjestelmässäni käytin muun muassa Rekursiokooste-, Data Mapper- ja Operaatiorunko-malleja. Rekursiokooste-malli soveltuu tilanteisiin, jossa halutaan esittää hierarkisia rekursiivisia oliorakenteita (Gamma ym. 2000, 165). Data Mapper -malli puolestaan on malli, jossa tietty luokka (nk. data mapper) vastaa tiedon siirtymisestä tietokannasta olioiksi (Zandstra 2010, 276). Operaatiorungossa luokkien yhteiset toiminnot (runko) määritellään yläluokan metodissa, mutta aliluokille jätetään aliluokkakohtaisten vaihtelevien osien toteutus (Gamma ym. 2000, 325). Suunnittelumalleihin ja niiden käyttöön palataan luvuissa 4.3 Suunnittelumallit ja 5.4 Suunnittelumallien käyttö. Sovelluksessa päivittäjän näkymä on samantapainen kuin julkaisujärjestelmässä. Hallintapaneelin kautta käyttäjä voi lisätä, muokata ja poistaa sisältökomponentteja. Koska en halunnut työstäni liian laajaa enkä halunnut toteuttaa täysimittaista julkaisujärjestelmää, päädyin siihen, ettei käyttäjä voi hallita sovelluksen ulkonäköä, metatietoja tai rakennetta hallintapaneelin kautta. Ratkaisu on myös toimeksiantajan kannalta mieluinen, sillä vaikka kyseessä on avoimen lähdekoodin tuote, asiakkaalle voi tarjota avaimet käteen -palvelun, jossa hän saa valmiin sivuston ulkoasuineen sekä mahdollisine sisältöineen. Asiakkaalle jää mahdollisuus lisätä ja päivittää sisältöä helposti, mutta esimerkiksi ulkoasun uudistaminen tai lisäominaisuuksien toteuttaminen myöhemmin onnistuu yrityksemme avulla. Futurable Oy:n järjestelmässä ei ole mahdollista tehdä ajastettuja toimintoja, joiden mahdollisuus perinteisistä julkaisujärjestelmistä usein löytyy. Järjestelmä ei myöskään mahdollista monitasoisia käyttäjiä. Web-sivustolle ei esimerkiksi voi luoda kirjautumista vaativaa puolta hallintapaneelin kautta, vaan tällaiset toiminnot kuuluvat ohjelmiston konfiguroinnin ja erikoistamisen piiriin. Sivuston metatietojen ja ulkoasun muokkaaminen eivät myöskään ole peruskäyttäjän toimintoja, vaan vaativat ohjelmakoodia ymmärtävän henkilön perehtymisen järjestelmän toimintaan.

17 17 4 JÄRJESTELMÄSSÄ KÄYTETYT TEKNIIKAT 4.1 Oliopohjainen ohjelmointi PHP-kielellä Olioperustaisella ohjelmoinnilla tarkoitetaan ohjelmistojen rakentamistapaa, joka perustuu ohjelmiston kuvaamiseen keskenään kommunikoivina olioina. (Koskimies 2000, 21.) Se on tapa ryhmitellä metodeita ja dataa yksikköön, jota kutsutaan nimellä olio (Trachtenberg 2004, 9). Ensimmäiset oliokeskeiset ajatukset ja ideat ovat peräisin 1960-luvulta ja niitä on käytetty rutiininomaisesti jo vuosikymmenien ajan, eri nimillä tosin (Haikala & Märijärvi 2004, 350). Kuitenkin vasta 1990-luvulla olio-ohjelmointi saavutti enemmän suosiota ja nykyisin tuskin on olemassa yhtäkään alan oppikirjaa, jossa olio-ohjelmoinnista ei puhuttaisi (Koskimies 2000, 27; Haikala & Märijärvi 2004, 350). Olioperustaisuus on yksi yleisesti käytössä olevista ohjelmointiparadigmoista. Muita paradigmoja ovat esimerkiksi proseduraalinen ohjelmointi, funktionaalinen ohjelmointi sekä logiikkaohjelmointi. Koskimiehen (2000, 21) mukaan olioohjelmoinnista on tullut suosittua, sillä se vastaa hyvin ihmisen tapaa hahmottaa maailmaa ja on näin luonnollisempaa ihmiselle kuin esimerkiksi laskentamalleihin perustuvat ohjelmointitavat. Olioperustaisen ohjelmiston yksi ehkä suurimmista eduista on se, että se on samanrakenteinen sovelluksen käsitemaailman kanssa (Koskimies 2000, 24). Samanrakenteisuus on tärkeä etu, sillä jos käsitemaailma on suunniteltu hyvin, ohjelmiston rakenne pysyy aina samanlaisena, vaikka siihen jouduttaisiinkin tekemään muutoksia tai korjauksia. Samanrakenteisuus antaa ohjelmiston kehittyä systemaattisesti ja hallittavasti: sovelluksen käsiteanalyysistä muodostuu vähitellen ajettavissa oleva ohjelmakoodi (Koskimies 2000, 24). Koskimies (2000, 21) kirjoittaa myös, että olio-ohjelmointi systematisoi ohjelmistojen rakentamista, lisää niiden uudelleenkäytettävyyttä ja helpottaa niiden ylläpitoa. On tutkittu, että uusissa järjestelmissä vain 15 % koodista on täysin uutta ja loput 85 % on saatu muokkaamalla tai kopioimalla vanhaa koodia (Koskimies 2000, 24). Tämä on varmasti myös merkittävä tekijä siinä, miksi olio-

18 18 ohjelmointia on alettu suosia. Se mahdollistaa hyvin uudelleenkäytettävien luokkien ja komponenttien tekemisen. Olio-ohjelmointi ei itsessään kuitenkaan takaa ohjelmiston tai koodin uudelleenkäytettävyyttä, vaan se pitää ottaa huomioon jo suunnitteluvaiheessa. PHP ei alun perin ole ollut olioperustainen kieli eikä ole vieläkään nk. puhdas oliokieli. Sen käytön yhteydessä on usein havaittavissa proseduraalista koodia, joka vain käyttää olioita hyväkseen (Zandstra 2010, 100). PHP:n virallisen dokumentaation (php.net) mukaan oliomalli uudelleenkirjoitettiin PHP:n 5. versioon. PHP 5 sisältää paremmat ja laajemmat olioperustaiset ominaisuudet sekä mahdollistaa täyspainoisen oliopohjaisen ohjelmoinnin. Php.net:n (2001) mukaan PHP 5. versiossa on monipuolisemmat oliopiirteet kuin aikaisemmassa versiossaan. PHP 5 tukee muun muassa seuraavia käsitteitä: näkyvyys (public/protected/private), staattiset metodit ja attribuutit, abstraktit luokat ja metodit, rajapintaluokat (interface) sekä final-avainsana, joka estää aliluokkia ylikirjoittamasta sillä määriteltyä metodia. Lisäksi PHP 5 sisältää nk. taikametodeja (magic methods), kuten olion elinkaareen liittyvät muodostaja ( construct) ja tuhoaja ( destruct). PHP 5:ssa esiteltiin myös olioiden tyypitys. Esimerkiksi metodin parametrien määrittelyyn voi tarkentaa, millaisen olion metodi voi hyväksyä parametrikseen. Esimerkiksi jos metodin määrittely on public function settext (Text $text), se hyväksyy vain Text-tyyppisen olion parametrinaan. PHP ei kuitenkaan ole vahvasti tyypitetty kieli, joten tällaista tapaa voi käyttää vain metodin määrittelyissä. Asiaa hankaloittaa myös se, että se toimii ainoastaan olioiden, ei primitiivitietotyyppien kanssa. Primitiivitietotyypit suositellaan tarkistamaan erikseen niihin tarkoitetuilla metodeilla (esim. is_int, is_bool). 4.2 Kerrosarkkitehtuuri Koskimiehen ja Mikkosen (2005, 126) mukaan kerrosarkkitehtuuri koostuu tasoista, jotka on järjestetty jonkin abstrahointiperiaatteen mukaan nousevaan järjestykseen. Useimmiten tämä järjestys tarkoittaa, että ylin kerros on lähinnä

19 19 käyttäjää (käyttöliittymäkerros) ja alin kerros lähimpänä laitteita (data-kerros). Yhden kerroksen ideana on, että se sisältää kyseessä olevalle kerrokselle tarkoitetut toiminnot. Useimmiten esimerkiksi ylin kerros sisältää käyttöliittymän piirtämiseen tarkoitetut luokat. Alin kerros puolestaan keskustelee tietokannan kanssa ja sisältää siihen tarkoitetut toiminnot. Kerrosarkkitehtuurin periaatteena on helpottaa järjestelmän rakentamista ja ymmärtämistä (Koskimies & Mikkonen 2005, 126). Perusajatuksena on, että tietyllä tasolla oleva komponentti tai palvelu toteutetaan alemmalla kerroksella olevien palveluiden tai komponenttien avulla (Koskimies 2000, 212, Koskimies & Mikkonen 2005, 126). Arkkitehtuurin tavoitteena on olla hierarkkinen siten, että ylempi kerros voi kutsua alempaa, mutta ei koskaan toisinpäin. Arkkitehtuuri on puhdas, mikäli näin tapahtuu aina eikä kerrosten välillä ole ohituksia (Koskimies 2000, 212). Ohitus tarkoittaa tässä yhteydessä sitä, että ylempi kerros ei kutsu seuraavana olevaa alempaa kerrosta, vaan kutsuu tämän ohi vielä alempaa kerrosta. Täysin ohitukseton, puhdas arkkitehtuuri on harvinainen, sillä tehokkuussyistä ohituksia joudutaan välillä tekemään. Kuitenkin aina pyritään siihen, ettei alempi kerros olisi riippuvainen ylemmästä (Koskimies & Mikkonen 2005, 127). Kuviossa 3 on kuvattuna sekä puhdas että ohituksellinen kerrosarkkitehtuuri. KUVIO 3. Ohitukseton ja ohituksen salliva kerroksittainen arkkitehtuuri (Koskimies 2000, 215) Kerrosarkkitehtuuri toimii normaalisti niin, että käyttäjä tai toinen ohjelma kutsuu ylimmän kerroksen palveluja (Koskimies 2000, 213). Tämä puolestaan kutsuu alemmalla kerroksella olevia palveluja ja näin ohjelman kontrolli siirtyy pala palalta alemmaksi. Alin kerros suorittaa palvelukutsun ja suorittamisen jälkeen se palauttaa kontrollin astetta ylemmälle tasolle. Lopulta kontrolli on jälleen kutsun antaneella kerroksella, joka palauttaa tuloksen kutsun lähettäjälle. Kuviossa 4

20 20 on esitetty ohitukseton kontrollin kulku tyypillisessä kerrosarkkitehtuurissa. Koskimiehen (2000, 213) mukaan toiminta voi joskus alkaa myös alemmilta kerroksilta. Esimerkiksi laitteita lähinnä oleva alin kerros voi ilmoittaa laitteen olevan tietyssä tilassa, jolloin viesti lähtee alimmalta kerrokselta ja etenee ylöspäin. KUVIO 4. Kontrollin kulku tyypillisessä kerrosarkkitehtuurissa (mukaillen Koskimies 2000, 212) Kerrosarkkitehtuuri helpottaa ohjelman ylläpitoa, siirrettävyyttä ja komponenttien uudelleenkäyttöä (Haikala & Märijärvi 2004, 386). Haikalan ja Märijärven (2004, 386) mukaan varsinainen sovelluslogiikka on hyvä pitää erillään sitä ympäröivistä rajapinnoista, erityisesti käyttöliittymästä. Erillään pito mahdollistaa muun muassa sen, että sama sisältö voidaan esittää monella eri tavalla käyttöliittymästä riippuen (Gamma ym. 2001, 4). Tästä seuraa se, että käyttöliittymää on helppo muuttaa tarpeen mukaan koskematta varsinaiseen sovelluksen logiikkaan. Jokaisella kerroksella on omat rajapintansa, joiden kautta kerroksen toiminnot ovat käytettävissä (Koskimies, 2000, 214). Näin kerroksisuus antaa myös mahdollisuuden uusia osia tai komponentteja vain tiettyyn kerrokseen ilman, että kerrosten välinen toiminta muuttuu. Koska ohjelmisto koostuu kerroksista, voivat eri henkilöt tai tiimit erikoistua tiettyihin kerroksiin, mikä auttaa ja nopeuttaa ohjelmiston kehittämisessä ja ylläpidossa. Kerrosarkkitehtuuri tukee ohjelman uudelleenkäyttöä, sillä uusia sovelluksia voidaan rakentaa alempien kerrosten päälle ja olemassa olevaa ohjelmakoodia voidaan käyttää tehokkaasti hyväksi (Koskimies & Mikkonen 2005, 131). Kerrosarkkitehtuurin eduksi voi lukea myös helpon päivittämisen. Sovelluksen päivittäminen nopeutuu ja helpottuu, kun sovelluslogiikka ja tietokantamääritykset ovat eri kerroksissa. Kerrosarkkitehtuurissa on myös ongelmia. Yleisin ongelma on tehokkuushäviö (Koskimies & Mikkonen 2005, 131). Koska kontrolli kulkee kerrosten läpi ylhääl-

21 21 tä alas ja sieltä taas takaisin ylös (katso kuvio 4), ei sovelluksen toiminta aina ole tehokkainta mahdollista. Esimerkiksi PHP:lla ohjelmoitaessa parametrit joudutaan tarkistamaan jokaisella kerroksella, mikä tarkoittaa usein moninkertaisia tarkistuksia, joka puolestaan vähentää ohjelman tehokkuutta. Myös poikkeusten käsittely voi olla ongelmallista (Koskimies & Mikkonen 2005, 131). Jos virhetilanne ilmenee alimmilla kerroksilla, se siirtyy hierarkiassa niin ylös, kunnes sille löytyy käsittelijä. Ongelmana on tällöin se, että virheitä ei käsitellä siellä, missä ne ovat syntyneet, vaan ylemmällä tasolla, jolloin käsittelijä ei välttämättä pysty enää korjaamaan tilannetta (Koskimies & Mikkonen 2005, 131). McConnellin (2004, ) mukaan virheet pitäisikin aina käsitellä paikallisesti ja ennen kaikkea samalla abstraktiotasolla, jolla ne muodostuvat. Tällöin Koskimiehen ja Mikkosen kuvaamaa tilannetta ei pääse syntymään. 4.3 Suunnittelumallit Suunnittelumallit (design patterns) ovat yksi ehkä eniten vaikuttaneista tekniikoista ohjelmistosuunnittelussa 1990-luvulla (Koskimies & Mikkonen 2005, 101). Koskimies ja Mikkonen (2005, 102) kirjoittavat, että inspiraatio suunnittelumalleista sai alkunsa 1970-luvun lopulla rakennusarkkitehtuurin puolelta, kun arkkitehti Christopher Alexander julkaisi kirjasarjan rakennusarkkitehtuuriin liittyvistä toimivista ideoistaan. Gamma ym. (2000, 2) mukaan Alexander on kirjoittanut seuraavaa: Jokainen suunnittelumalli kuvaa ongelman, joka toistuu jatkuvasti ympäristössämme ja määrittelee ongelmalle ratkaisuperiaatteen, jota voidaan soveltaa miljoonia kertoja aina uudella tavalla. Tämä ajatus toimii paitsi rakennusarkkitehtuurissa myös ohjelmistosuunnittelussa. Ajatuksen pohjalta pieni joukko kokeneita ohjelmistoalan asiantuntijoita alkoi päättäväisesti tutkia ja kehittää ideaa. Merkittävä läpimurto syntyi vuonna 1995, kun Gamma, Helm, Johnson ja Viissides (tunnetaan myös nimellä Gang of Four, GoF) julkaisivat kirjansa Design Patterns. Kirjaan on kerätty yleisimpiä suunnittelumalleja ja annettu niistä käytännön esimerkkejä tai esitelty niiden tunnettuja käyttökohteita. Kirja on edelleen ajankohtainen, mikä on harvinaista nopeasti muuttuvassa tietotekniikan maailmassa (Koskimies & Mikkonen 2005, 103).

22 22 Suunnittelumallin tarkoituksena on esittää ratkaisu yleiseen ongelmaan (Gamma ym. 2000, 3). Koskimiehen ja Mikkosen (2005, 102) mukaan suunnittelumallit ovat tunnettujen ja käytännössä hyväksi havaittujen ratkaisujen kuvauksia yleisiin ohjelmistojen suunnittelua koskeviin ongelmiin tietyissä tilanteissa. McArthur (2008, 21) puolestaan kuvaa malleja oliomaailman resepteiksi, joiden avulla suunnittelija löytää tarvittavat ainesosat ohjelmiston rakentamiseen. Suunnittelumallit eivät varsinaisesti ole sidottuja mihinkään tiettyyn paradigmaan, mutta niitä kokoava yhteisö on toiminut lähinnä oliomaailmassa, joten on luonnollista, että myös mallit esitetään tavallisesti olioparadigmaa noudattaen (Koskimies & Mikkonen 2005, 104). Suunnittelumallit ovat tavallisimmin sovellusalueesta riippumattomia, yleisiä ja abstrakteja ratkaisuja, joita sovelletaan ohjelmiston suunnittelun aikana (Koskimies 2000, 245). Gamma ym. (2000, 3) mukaan suunnittelumalli nimeää, abstrahoi ja määrittää yleisen suunnittelurakenteen avainkohdat, jotka hyödyntävät uudelleenkäytettävän oliopohjaisen suunnitteluratkaisun luomista. Mallissa määritellään toimintaan osallistuvat luokat sekä oliot ja kerrotaan niiden vastuut, roolit ja mahdollinen yhteistyö. Kukin suunnittelumalli keskittyy tietyn (yleensä yhden) ongelman ratkaisuun. Malli esittelee ongelman ja ratkaisun sekä kertoo, missä tilanteissa se on sovellettavissa, mitkä ovat sen huonot ja hyvät puolet sekä mallin käytön seuraamukset (Gamma ym. 2000, 4). Mallissa on siis kolme olennaista osaa: ongelma, ongelmayhteys ja ratkaisu (Koskimies & Mikkonen 2005, 102; Zandstra 2010, ). Mallin nimeäminen on myös tärkeää. Gamma ym. (2000, 6) mukaan mallin nimen tulisi kertoa mallin olemus ytimekkäästi. Nimestä tulee osa suunnittelijoiden ammattisanastoa, joten myös sen vuoksi nimen tulisi olla yksiselitteinen ja ratkaisua hyvin kuvaava (Gamma ym. 2000, 6; Koskimies & Mikkonen 2005, 106). Mallit ovat hyödyllisiä, sillä ne auttavat suunnittelijaa luomaan vakaan ja tasapainoisen sovelluksen säilyttäen silti joustavuuden (McArthur 2008, 21). Vaikka mallit ovat usein luonteeltaan abstrakteja, ne ovat silti paljon käytettyjä ja testattuja käytännön ratkaisuja, joiden tarkoituksena on auttaa ohjelmistosuunnittelijaa löytämään ongelmaan oikea ratkaisu nopeammin (Gamma ym. 2000, 2, 4; Zandstra 2010, 127). Koskimiehen ja Mikkosen (2005, 104) mukaan suunnitte-

23 23 lumallien käyttö voi parantaa joitakin ohjelmiston laatuominaisuuksia, kuten muunneltavuutta, siirrettävyyttä, ylläpidettävyyttä, uudelleenkäytettävyyttä ja suorituskykyä. Yksi suunnittelumalli ei useimmiten pysty parantamaan kaikkia edellä lueteltuja ominaisuuksia, esimerkiksi muunneltavuuden ja suorituskyvyn parantaminen yhtäaikaisesti saattaa olla mahdotonta. Suunnittelumallin kuvauksessa tulisikin käydä ilmi ratkaisun hyvät ja huonot puolet, jotta suunnittelijan olisi helppo arvioida kyseisen mallin sopivuus juuri tietyn ongelman ratkaisuksi (Koskimies & Mikkonen 2005, 106). Koska suunnittelumallit ovat yleisellä tasolla esitettyjä ja abstrakteja, ne ovat myös kielestä riippumattomia, mikä tekee niiden käytöstä mahdollista millä tahansa olio-ominaisuudet omaavalla kielellä (Zandstra 2010, 127). Suunnittelumallit luovat tietotekniikan alalle uusia ammattitermejä, jotka helpottavat tiimien ja yksilöiden välistä kommunikaatiota, dokumentaatiota ja vaihtoehtoisten ratkaisujen tutkimista (Gamma ym. 2000, 352). Lisäksi ne helpottavat olemassa olevien järjestelmien ymmärtämistä sekä antavat suunnittelijalle työkaluja luoda hyvin suunniteltuja oliomaisia ohjelmistoja (Gamma ym. 2000, 352; Zandstra 2010, 128). Suunnittelumallien avulla kokeneiden suunnittelijoiden oppima ja keräämä tieto siirtyy uusille sukupolville ja samalla koko ohjelmistoalan käyttöön (Koskimies & Mikkonen 2005, 102). Suunnittelumalleista puhuttaessa on mainittava myös antisuunnittelumallit. Antitai vastasuunnittelumallit (antipatterns) ovat myös ratkaisuja yleisesti tunnistettuihin ongelmiin, mutta päinvastoin kuin suunnittelumalleissa, ratkaisut ovat epätoivottuja ja johtavat ongelmiin ohjelmiston elinkaaren aikana (Koskimies 2000, 247; Koskimies & Mikkonen 2005, 107). Myös huonojen suunnitteluratkaisujen tunnistaminen voi olla Koskimiehen (2000, 247) mukaan hyödyllistä, sillä se voi auttaa suunnittelijaa löytämään tarvittavan hyvän ratkaisun huonon sijaan. Koska yleistä huonoa ratkaisua on vaikea kuvata kovin tarkasti, ovat antisuunnittelumallit luonteeltaan suunnittelumalleja yleisempiä ja niiden oheen liitetään usein hyvän ratkaisun käyttöön perustuvat muutosohjeet (Koskimies & Mikkonen 2005, 107).

24 24 5 FUTURABLE OY:N JÄRJESTELMÄN SUUNNITTELU, TOTEUTUS JA TOI- MINTA 5.1 Tarkoitus ja tavoite Tavoitteena oli toteuttaa PHP-ohjelmointikielellä järjestelmä, jota voidaan kehittää ja laajentaa tarpeen mukaan myöhemmin. Suunnitellessani järjestelmää, lähdin siitä, että sen pitää olla kevyt, mutta kuitenkin muokattavissa erilaisten asiakasprojektin tarpeisiin. Sen pitää lisäksi olla helppokäyttöinen ja selkeä sekä asiakkaalle että ohjelmoijalle. Se ei saa olla liian vaikea toteuttaa eikä liian laaja, jottei opinnäytetyöni työtuntimäärä kasva kohtuuttomaksi. Suunnittelussa olen ottanut huomioon järjestelmän käytön vaatimukset. Järjestelmää tullaan käyttämään lähinnä eri laajuisissa web-sivustoprojekteissa, mutta rungossa on pyritty ottamaan huomioon myös muunlaisten web-sovellusten tarpeet eikä sitä ole sidottu ainoastaan yhteen tarkoitukseen. Yksi tavoitteista oli myös oman oppimisen vieminen uudelle tasolle. Tarkoituksena oli siis myös saada kokemusta laajemman järjestelmän suunnittelusta ja toteutuksesta, jotta työelämässä voisin ottaa myös vastaavia toimeksiantoja vastaan. Halusin opinnäytetyötä tehdessä oppia lisää oliopohjaisesta ohjelmoinnista (erityisesti PHP-kielellä), arkkitehtuureista ja suunnittelumalleista sekä niiden soveltamisesta eri tilanteissa. 5.2 Oliopohjaisuus Yksi opinnäytetyön henkilökohtaisista tavoitteistani oli oppia ohjelmoimaan PHP-kielellä täysin oliomaisesti, joten oli luonnollista, että tutustuin PHP 5:n oliopiirteisiin ja sovelsin niitä opinnäytetyössäni mahdollisimman laajasti. Olioohjelmointi oli luonteva vaihtoehto, sillä se on yksi suosituimmista tavoista valmistaa ohjelmistoja ja halusin syventää oppimistani kyseisellä alueella. Lisäksi

25 25 oliopohjaisuus antoi työkaluja työn alkuun pääsemiseksi: sovelluksen käsiteanalyysin jälkeen luokkajaon tekeminen helpottui. Koska kyseessä on tuote, jota aiotaan kehittää jatkossa, on hyvä, että sen rakenne on selkeä ja siihen on helppo palata myös jälkikäteen. Gamma ym. (2001, 1) mukaan uudelleenkäytettävän oliopohjaisen ohjelmiston suunnittelu on vaikeaa. Vaikka oliomainen suunnittelu antoikin työkaluja työn alkuun pääsemiseksi, se tuntui aluksi hankalalta ja hieman monimutkaiselta, sillä luokkien lukumäärä nousi suureksi ja oli vaikeaa päättää, kuinka luokkajako olisi riittävän tehokas, mutta silti selkeä. Halusin kuitenkin harjoitella oliomaista ohjelmistojen suunnittelua, sillä se on tehokas ja johdonmukainen tapa valmistaa ohjelmistoja (Koskimies 2000, 21). Koskimiehen (2000, 21, 24) mukaan olioperustaisuus sopii kaikkiin sovelluksiin ja tukee ohjelmiston uudelleenkäyttöä ja kehitystä, joten siinäkin mielessä sitä on hyvä harjoittaa. Mielestäni oliomaisella ohjelmoinnilla saavutetaan helpommin ymmärrettävää koodia, kunhan rakenne on suunniteltu hyvin. Vaikka olioohjelmointi on aluksi haastavaa ja aikaa vievää, sen harjoittaminen on mielestäni tärkeää ja sitä kautta ohjelmoinnista voi oppia paljon uusia piirteitä ja käyttötapoja. 5.3 Kerrosarkkitehtuurin käyttö Opinnäytetyöni käytännön osuudessa käytin ohituksen sallivaa kerroksittaista arkkitehtuuria, jotta järjestelmän rakenteesta tulisi johdonmukainen ja selkeä. Ohituksen sallivaan arkkitehtuuriin päädyin, sillä tarvitsin palveluita, joita jokainen kerros tulisi käyttämään. Toteutin nämä palvelut (Common Services) niin sanottuna arkkitehtuuriviipaleena. Arkkitehtuuriviipale (architecture/design fragment) on järjestelmän primäärin jakoperusteen kanssa ristiin menevä, mutta kuitenkin jonkun kriteerin perusteella loogisesti yhteenkuuluva arkkitehtuurin osa (Koskimies & Mikkonen 2005, 39). Sovelluksessani CommonServices on arkkitehtuuriviipale, joka on kaikkien kerrosten käytettävissä. Se sisältää yhteisessä käytössä olevia toimintoja, kuten virheiden etsintään tarkoitetun Debug-

26 26 osan, sessioiden käsittelyyn tarkoitetun SessionManagerin ja kryptauksessa käytettävän Crypt-osan. Kuviosta 5 voi nähdä Futurable Oy:lle kehittämäni järjestelmän kerrosarkkitehtuurin. KUVIO 5. Futurable Oy:n järjestelmän kerrosarkkitehtuuri Toiminta lähtee liikkeelle joko Main.php- tai Admin.php-tiedostojen avulla, kun käyttäjä navigoi sovelluksen Internet-sivulle. Jos kyse on hallintapaneeliin kirjautumisesta, käyttäjä navigoi Admin.php-sivulle, jolloin kirjautuminen vahvistetaan AuthComponentin kautta. Ylin Presentation-kerros sisältää käyttöliittymän piirtämiseen tarvittavat osat. Presentation-kerros käyttää hyväkseen Confkansiossa olevia tiedostoja, joita muokkaamalla sovelluksen rakenne muodostetaan. Presentation-kerros toimii yhteistyössä myös Services-komponentin kanssa, joka sisältää muun muassa lomakkeiden käsittelyyn tarvittavat toiminnot. Model-kerroksen tarkoituksena on yleensä mallintaa sovelluksen olioita ja niiden toimintoja (Haikala & Märijärvi 2004, 387). Kehittämäni järjestelmän Modelkerros onkin rakennettu suunnitellun oliomallin pohjalta. Se sisältää abstraktin yläluokan, joka tarjoaa rajapinnan kerroksen käyttämiseen, sekä sen aliluokat, jotka edustavat varsinaisia olioita. Järjestelmän perusversiossa on kahdeksan erilaista Model-kerroksen oliota, joista sivuston sisältö koostetaan. Käyttäjällä

27 27 on mahdollisuus lisätä, muokata ja poistaa näitä olioita hallintapaneelin kautta. Osa Model-kerroksen olioista voi sisältää myös toisia Model-kerroksen olioita, esimerkiksi Kappale-olio (Paragraph) voi sisältää Teksti- (Text), Kuva- (Photo) sekä Linkki (Link) -olioita. Oliokoosteen toteutuksessa on käytetty Rekursiokooste-suunnittelumallia (Composite). Data-kerros keskustelee tietokannan kanssa. Sen tehtävänä on tallentaa uudet oliot kantaan, muuttaa ja poistaa niitä tarvittaessa sekä tehdä kyselyjä kantaan ylemmän kerroksen pyynnöstä. Myös Data-kerroksella on käytetty abstraktia yläluokkaa (DataMapper) antamaan rajapinta Data-kerroksen toimintoihin. Yläluokasta on periytetty jokaista Model-kerroksen luokkaa vastaava Datakerroksen luokka. Data-kerroksella on käytetty Data Mapper -suunnittelumallia. Sekä Model- että Data-kerroksella on lisäksi käytetty Operaatiorunkosuunnittelumallia. Kaikki edellä mainitut suunnittelumallit ja niiden käyttö on esitelty tarkemmin seuraavassa luvussa. Opinnäytetyön liitteistä löytyy lisäksi Futurable Oy:n järjestelmän luokkakaavio (LIITE 1). 5.4 Suunnittelumallien käyttö Yksi opinnäytetyöni henkilökohtaisista tavoitteista oli tutustua yleisesti suunnittelumalleihin ja niiden toimintaan sekä perehtyä muutamaan malliin ja soveltaa niitä käytännön työssä. Valitsin tarkemman tutkinnan kohteeksi seuraavat mallit: Rekursiokooste, Data Mapper sekä Operaatiorunko. Valitsin nämä kyseiset mallit, sillä ohjelman luokkajaon jälkeen huomasin niiden käyttöön viittaavia piirteitä. Mallien abstraktin luonteen vuoksi joskus käy myös niin, että suunnitellessaan järjestelmää tai kirjoittaessaan ohjelmakoodia, käyttää suunnittelumalleja tietämättään. Itse olen löytänyt käytännön työstäni jälkeenpäin merkkejä myös muiden kuin yllämainittujen mallien käytöstä, vaikka työtä tehdessäni en niiden käyttöä rekisteröinyt lainkaan. Seuraavissa alaluvuissa esittelen kolme opinnäytetyöni käytännön osuudessa selkeimmin esiintynyttä suunnittelumallia. Esittelen ensin mallin idean yleisesti

28 28 ja kerron lyhyesti, kuinka sitä käytetään ja millaisiin tilanteisiin se sopii käytettäväksi. Kerron sen jälkeen kuinka sovelsin kyseistä mallia opinnäytetyössäni. Mallien esittelyitä ja käyttötilanteita on havainnollistettu kuvilla Rekursiokooste (Composite) Rekursiokoosteen ideana on esittää oliot rekursiivisesti koostettuna puurakenteena (Gamma ym. 2000, 163). Tämä mahdollistaa olioiden ja oliokoosteiden käsittelemisen samalla tavalla. Rekursiokooste-malli siis ratkaisee ongelman, jossa olio voi olla oma itsensä (primitiiviolio) tai voi koostua toisista samanlaisista tai tapaisista oliosta (koosteolio). Gamman ym. (2000, ) mukaan mallissa määritellään yksi abstrakti luokka, joka esittää sekä primitiiviolioita että toisista oliosta muodostuvia koosteolioita, ja tämän luokan aliluokat, jotka toteuttavat varsinaiset kooste- ja primitiivioliot (kuvio 6). Asiakas Komponentti +Operaatio() +Lisää(olio: Komponentti) +Poista(olio: Komponentti) +HaeLapsi(id: int) Lehti +Operaatio() Rekursiokooste +Operaatio() +Lisää(olio: Komponentti) +Poista(olio: Komponentti) +HaeLapsi(id: int) KUVIO 6. Abstrakti luokka (Komponentti) esittää sekä primitiiviolioita (Lehti) että oliokoosteita (Rekursiokooste) (mukaillen Gamma ym. 2000, 164) Komponentti-luokan tarkoituksena on määritellä hierarkisen rakenteen yhteinen rajapinta, antaa mahdollinen oletustoteutus yhteisille operaatioille sekä määritellä operaatiot, joilla lapsisolmuihin päästään käsiksi. Tarvittaessa se määrittelee ja mahdollisesti myös toteuttaa operaation, joka tarjoaa pääsyn

29 29 vanhempisolmuun. Lehti-luokka kuvaa primitiiviolion ja toteuttaa sen operaatiot. Rekursiokooste puolestaan kuvaa koosteolion, jolla on lapsia. Sen tehtävänä on tallentaa viitteet lapsisolmuihin ja toteuttaa Komponentti-rajapinnan lapsisolmuja koskevat operaatiot. (Gamma ym. 2000, 165.) Rekursiokooste-mallia on Gamman ym. (2000, 164) mukaan hyvä käyttää silloin, kun halutaan esittää hierarkisia rekursiivisia oliorakenteita ja/tai kun primitiiviolioiden ja koosteolioiden käsittelytapa halutaan pitää samanlaisena niitä kutsuvan Asiakkaan näkökulmasta katsottuna. Tällöin Asiakas (sovellus) käsittelee koosterakennetta vain Komponentti-luokan rajapinnan kautta. Esimerkiksi olion lisäyksessä voidaan käyttää kutsua olio->lisää(this) riippumatta siitä, onko kyseessä primitiivi- vai koosteolio. Mikäli pyyntö kohdistuu koosteolioon, se useimmiten delegoi pyynnön lapsilleen ja mahdollisesti tekee jotain toimenpiteitä joko ennen tai jälkeen delegointia. Jos taas kyseessä on primitiiviolio, pyyntö käsitellään suoraan. (Gamma ym. 2000, 165.) Kehittämässäni järjestelmässä käytin Rekursiokooste-mallia Model-kerroksella. Päädyin Rekursiokoosteen käyttöön, sillä huomasin järjestelmässä rekursiivisen rakenteen, jossa koosteolio voi sisältää samasta luokasta luodun olion. Primitiivi- ja koosteolioiden toteutuksen piti myös näkyä samanlaisena ulospäin, jotta niiden käsittely sujuisi dynaamisesti ja mahdollisimman vaivattomasti kutsuvan koodin kannalta. Järjestelmän Model-kerroksella on yksi abstrakti yläluokka, AbstractComponent, joka toteuttaa rajapinnan ja edustaa sekä primitiiviolioita että koosteolioita (kuvio 7).

30 30 AbstractComponent Content +save() #dosave() +displayinhtmlmode() #dodisplayinhtml() +displayineditmode() #dodisplayineditmode() Text #dosave() #dodisplayinhtml() #dodisplayineditmode() Paragraph #dosave() #dodisplayinhtml() #dodisplayineditmode() -displaydatainhtml() -displaydataineditmode() Column #dosave() #dodisplayinhtml() #dodisplayineditmode() -displaydatainhtml() -displaydataineditmode() KUVIO 7. Esimerkki Rekursiokoosteen toteutuksesta Futurable Oy:n järjestelmässä AbstractComponent-luokka tarjoaa rajapinnan, jonka avulla voi tallentaa olion (save) sekä näyttää sen html- (displayinhtml) ja muokkaustiloissa (displayineditmode). Tallentaminen sisältää uuden olion tallentamisen, olemassa olevan olion muuttuneiden tietojen tallentamisen sekä olion poistamisen. Tallennushaara päätetään alemmassa kerroksessa sen mukaan, millaisia ominaisuuksia oliolla on (lisää luvussa Data Mapper). Html-tilassa olio esitetään html-koodimuotoisena niin, että selain voi tulkata HTML-koodin oikeaan esitysmuotoonsa. Muokkaustilassa olio puolestaan esitetään HTML-lomakkeessa niin, että admin-käyttäjä voi joko luoda uuden olion tai muuttaa olemassa olevan olion muokattavia ominaisuuksia. Content edustaa kutsuvaa koodia eli Asiakasta. Koosteoliot voivat sisältää toisia AbstractComponent-luokasta perittyjä olioita. Esimerkiksi toimeksiantajani järjestelmässä Paragraph-olio voi sisältää Textolioita (katso kuvio 7) tai Column-olio voi sisältää toisia Column-olioita sekä vaikkapa Paragraph-olioita. Järjestelmän perusversiossa primitiivioliota edustavat Text, TextTitle, Photo, Link ja HtmlCode. Koosteolioita ovat puolestaan Column, Paragraph ja UnorderedList. Kooste- ja primitiivioliota käsitellään

31 31 samalla tavalla AbstractComponent-luokan tarjoaman rajapinnan kautta, kutsuva koodi ei koskaan tiedä millainen olio on kyseessä. Content täyttää oliotaulunsa AbstractComponent-olioilla tietämättä ovatko ne primitiivi- vai koosteolioita. Sitten se käy oliotaulunsa läpi ja kutsuu joka kierroksella sen hetkisen olion metodia (esimerkiksi object->displayinhtml() ). Jos kyseessä on koosteolio, se puolestaan käy oman oliotaulunsa läpi ja delegoi displayinhtml-komennon taulusta löytyville olioille. Näin edetään rekursiivisesti, kunnes kaikki oliot on käyty läpi. Rekursiokooste-malli helpottaa olioiden käsittelyä silloin, kun ohjelmassa on sekä primitiivi- että koosteoliota. Ilman mallin käyttöä toteutus olisi monimutkainen ja ohjelmakoodista tulisi sekavaa ja vaikeasti ylläpidettävää. Rekursiokoosteen hienous on siinä, että kutsuvan koodin ei koskaan tarvitse tietää, millaisesta oliosta on kyse, vaan kaikki oliot käsitellään samalla tavalla Data Mapper Data Mapper mallista ei ole vakiintunutta suomennosta, joten käytän opinnäytetyössäni siitä englanninkielistä nimeä. Data Mapper on ohjelmiston kerros, joka erottaa muistissa olevat oliot tietokannasta, kirjoittaa Fowler (2002, 165). Sen toimintaperiaatteena on yhdistää kaksi erillistä resurssia toisiinsa, mutta pitää ne kuitenkin itsenäisinä toimijoina. Relaatiotietokannat on suunniteltu säilyttämään suuria määriä taulukkomuotoista dataa. (Zandstra 2010, 276.) Oliot puolestaan eivät useinkaan ole rakenteeltaan samanlaisia kuin relaatiotietokannat, vaan ne saattavat esimerkiksi koostua toisista olioista, jolloin ne eivät vastaa tietokannan rakennetta lainkaan. Data Mapper -mallissa yksi tai useampi luokka kääntää sovelluskerroksen olioiden attribuutit ja/tai metodit tietokannan taulujen kentiksi ja toisin päin (Sweat 2005, 260). Sovelluskerroksen ei tällöin tarvitse tietää tietokannan läsnäolosta, sen käyttämiseen liittyvästä koodista eikä kannan rakenteesta (Fowler 2002, 165).

32 32 Yksinkertaistettuna Data Mapper -mallin tarkoituksena on toimia sovelluskerroksen ja tietokannan välisen kommunikaation tulkkina (kuvio 8). Sen tehtävänä on ymmärtää sille annetun datan ja tietokannan välinen yhteys sekä reitittää tietoa kantaan ja sieltä poispäin. Uusien olioiden luonti tietokannan tietojen perusteella sekä olemassa olevien olioiden tietojen päivitys sekä poisto sovelluskerroksen olioilta tulevien tietojen perusteella ovat sen perustoimintoja. (Sweat 2005, 262.) KUVIO 8. Data Mapper (HenkilöMapper) toimii sovelluskerroksen ja tietokannan välissä (mukaillen Fowler 2002, 165) Fowlerin (2002, 167) mukaan Data Mapperin tehtävänä on tallennuksen yhteydessä tietää, millaisessa tilassa olio on (uusi/päivitettävä/poistettava) ja miten sen tallentamisen pitäisi tapahtua (insert/update/delete). Data Mapper toimii myös toisinpäin: sovelluskerros voi pyytää siltä tiettyä oliota (Fowler 2002, 166). Silloin Data Mapper hakee olion tiedot kannasta, muodostaa olion ja palauttaa olion sovelluskerrokselle. Data Mappereita voi olla sovelluksessa yksi tai useampi (Fowler 2002, 167). Data Mapper -mallia suositellaan käytettäväksi Fowlerin (2002, 168) mukaan muun muassa silloin, kun tietokannan rakenne ja oliomalli halutaan kehittää erillään. Data Mapperin etu on siinä, että sovelluskerrosta voidaan työstää välittämättä tietokannasta ja toisinpäin. Tämä toteutuu niin suunnittelu- ja toteutuskuin testausvaiheessakin. (Fowler 2002, 168.) Tällainen eriyttäminen voi olla erityisen hyödyllistä yritysmaailmassa, jossa eri tiimit paneutuvat ja erikoistuvat eri kerrosten toteuttamiseen. Data Mapper on hyödyllinen myös silloin, kun sovelluksen logiikka on monimutkainen eikä tiedon tallentamisella haluta lisätä monimutkaisuutta (Fowler 2002, 169). Data Mapper antaa järjestelmälle joustavuutta, olio ja tietokanta eivät ole tiukasti sidoksissa toisiinsa, jolloin muutosten

33 33 tekeminen jompaan kumpaan ei aiheuta muutostarpeita toiseen. (Sweat 2005, 281.) Esimerkiksi tietokannan vaihtaminen toisenlaiseen vaatii vain Data Mapper -kerroksella olevien luokkien metodien toteutuksen muuttamisen eikä vaikuta lainkaan sovelluskerroksen toimintaan. Edellä mainittujen hyötyjen lisäksi on ilmeistä, että Data Mapperin hyödyn voi todeta myös ylläpidon helppoudessa. Kehittämässäni järjestelmässä käytin Data Mapperia luonnollisesti sovelluskerroksen (Model-kerros) ja tietokannan (MySQL) välissä. Data Mapper -malli soveltuu hyvin järjestelmän monimutkaisen rekursiivisen oliorakenteen tallentamiseen. Halusin myös, että tietokannan vaihtaminen olisi riittävän vaivatonta eikä vaikuttaisi sovelluskerroksen toimintaan tai rakenteeseen lainkaan. Kehittämässäni järjestelmässä Data Mappereita on useita. Niillä on yksi abstrakti yläluokka (DataMapper), joka tarjoaa rajapinnan muiden Data Mapper -luokkien käyttämiseen (kuvio 9). KUVIO 9. Futurable Oy:n järjestelmässä Data Mapper -malli on toteutettu usean Data Mapper -luokan avulla Abstrakti yläluokka DataMapper tarjoaa rajapinnat findbyid, jonka avulla olio haetaan tietokannasta, ja save, jonka avulla olion voi tallentaa. Jokaisella Model-kerroksen luokalla on Data-kerroksessa luokkaa vastaava Data Mapper

34 34 -luokka, joka vastaa kyseisen luokan ilmentymien hakemisesta ja tallentamisesta. Jokainen Data Mapper -lapsiluokka toteuttaa yläluokan määrittämät abstraktit metodit (dofindbyid, doinsert, doupdate ja dodelete), jotka sisältävät metodien varsinaiset implementaatiot. FindById delegoi kutsun aliluokan dofindbyid-metodille, joka hakee olion tiedot tietokannasta yksilöllisen id-numeron (id) perusteella. Data Mapper kokoaa olion näiden tietojen perusteella ja palauttaa täytetyn olion kutsujalle. Savemetodissa olion tallennustapa päätetään sen mukaan, millaisia ominaisuuksia oliolla on. Mikäli olion ominaisuus isnew on tosi, kyseessä on uusi olio, joka tallennetaan metodilla insert. Mikäli ominaisuus dodelete on tosi, on kyseessä poistettava olio, joka poistetaan delete-metodilla. Muissa tapauksissa olion tiedot päivitetään update-metodilla. Kuviossa 10 on kuvattu findbyid-metodin toiminta Futurable Oy:n järjestelmässä. Toiminta lähtee liikkeelle, kun käyttäjä navigoi sivustolle tai painaa navigaatiolinkkiä ja ylin kerros pyytää sisältöä alemmalta kerrokselta. Tällöin Content-olio kutsuu oman Data Mapperinsa (ContentDataMapper) findbyidmetodia. Tämä puolestaan siirtää kutsun dofindbyid-metodilleen, jossa haetaan tietokannasta niiden olioiden id-numerot, jotka on linkitetty kyseiseen Content-olioon. Esimerkissä on kuvattuna tilanne, jossa Content-oliolla on vain yksi sisältöelementti, TextTitle. Tietokantakyselyn jälkeen kyselyn vastaus käydään läpi ja jokaisella kierroksella kutsutaan DataMapper-luokan rajapintametodia findbyid. FindById ohjaa kutsun abstraktin dofindbyid-metodinsa kautta Data Mapper -aliluokalleen (TextTitleDataMapper), joka hakee olion tiedot id-numeron perusteella tietokannasta. TextTitleDataMapper muodostaa tietojen perusteella TextTitle-olion, joka palautetaan lopulta Content-oliolle, joka lisää sen komponenttitauluunsa.

35 35 KUVIO 10. Olioiden hakeminen tietokannasta Data Mapper -mallin avulla Data Mapper -malli on mielestäni erittäin käyttökelpoinen malli, joka pilkkoo tietokantahakuja pienempään ja yksinkertaisempaan muotoon ja näin helpottaa hakujen tekemistä. Kun yhden Data Mapperin vastuulla on vain yhden olion tietojen hakeminen ja olion muodostaminen, on sovelluksen ymmärtäminen ja laajentaminen helpompaa. Ohjelmakoodista muodostuu selkeämpää ja helpommin ylläpidettävää Data Mapper -mallin avulla. Data Mapperin heikkoutena voi olla se, että tietokantakyselyjä joudutaan tekemään melko paljon, mikä voi jossain tapauksissa hidastaa ohjelman toimintaa Operaatiorunko (Template Method) Operaatiorunko-mallissa yläluokka määrittelee algoritmin rungon operaatiossa ja jättää jotkin sen osat aliluokkien toteutettavaksi (Gamma ym. 2000, 325). Kun metodien yhteinen toteutus on yläluokassa, voivat lapsioliot keskittyä puh-

36 36 taisiin ja tarkemmin rajattuihin tehtäviin (Zandstra 2010, 195). Operaatiorunko erottaa luokkien yhtäläisyydet ja eroavaisuudet ja tehostaa näin konkreettisten luokkien kehitystä (Fowler 2000, 259; Zandstra 2010, 195). Gamman ym. (2000, 327) mukaan Operaatiorunko on koodin uudelleenkäytön perustekniikka. Sen käyttö johtaa käänteiseen kontrollirakenteeseen ( Hollywood-periaate ), sillä siinä yläluokka kutsuu aliluokkien operaatioita, toisin kuin perinteisessä kontrollin kulussa (Gamma ym. 2000, 327). Gamma ym. (2000, 327) mukaan abstraktilla yläluokalla on kaksi perustehtävää. Sen on määriteltävä abstraktit primitiivioperaatiot sekä runko, josta niitä kutsutaan. Kuviossa 11 abstrakti yläluokka (AbstractClass) määrittelee rajapinnan (TemplateMethod), jolla lapsiluokkia käytetään, sekä abstraktit primitiivioperaatiot (PrimitiveOperation1, PrimitiveOperation2), jotka konkreettiset lapsiluokat toteuttavat (Gamma ym. 2000, 327). Aliluokkien (Concrete- Class) tehtävänä on toteuttaa primitiivioperaatiot kunkin luokan vaatimalla tavalla. AbstractClass +TemplateMethod() #PrimitiveOperation1() #PrimitiveOperation2() ConcreteClass #PrimitiveOperation1() #PrimitiveOperation2() KUVIO 11. Operaatiorunko-mallin toimintaperiaate (Gamma ym. 2000, 327) Operaatiorunkoa suositellaan käytettäväksi tilanteissa, joissa kahdella tai useammalla luokalla on samanrakenteiset metodit, mutta joiden toteutus poikkeaa hieman toisistaan (Fowler 2000, 280). Tällöin yhteiset osat voidaan siirtää yläluokan metodiin ja monimuotoisuus (polymorphism) voi hoitaa luokkien välisen dynaamisen sidonnan (Fowler 2000, 281; Gamma ym. 2000, 326). Operaatiorunko-malli vähentää koodin monistamista, kun aliluokkien yhteinen käyttäy-

37 37 tyminen paikallistetaan yhteiseen luokkaan (Gamma ym. 2000, 326). Operaatiorunkoa voidaan käyttää Gamman ym. (2000, 326) mukaan myös sellaisissa tilanteissa, joissa aliluokkien laajennuksia halutaan kontrolloida. Runko voidaan tällöin toteuttaa siten, että se sallii laajennuksia vain tietyissä kohdissa (nk. koukku-operaatiot, hooks). Tällöin on tärkeää, että määritellään, mitkä operaatiot ovat valinnaisia koukkuja ja mitkä puolestaan ovat pakollisia abstrakteja operaatioita, jotta abstraktia luokkaa voitaisiin uudelleenkäyttää mahdollisimman tehokkaasti. (Gamma ym. 2000, 328.) Kehittämässäni järjestelmässä käytetään Operaatiorunkoa sekä Model- että Data-kerroksilla. Päädyin käyttämään Operaatiorunko-mallia, sillä huomasin kahdella eri kerroksella samanlaisen tarpeen: yläluokalla pitää olla rajapinta, jonka kautta aliluokkia käytetään, vaikka aliluokkien toteutukset poikkeavatkin toisistaan. Lisäksi aliluokilla on selkeästi myös yhteinen osuus toteutuksessa. Model-kerroksella abstrakti yläluokka (AbstractComponent) toteuttaa kolme Operaatiorunkoa save, displayinhtml ja displayineditmode (kuvio 12). Save-metodissa yhteisessä operaatiorungossa reagoidaan tietokantakyselyn onnistumiseen/epäonnistumiseen sekä kutsutaan abstraktia dosave-metodia. Rungossa on myös virheiden etsimiseen liittyvää ohjelmakoodia. AbstractComponent +save() #dosave() +displayinhtml() #dodisplayinhtml() +displayineditmode() #dodisplayineditmode() HtmlClass +displayinhtml() +displayineditmode() TextTitle #dosave() #dodisplayinhtml() #dodisplayineditmode() Paragraph #dosave() #dodisplayinhtml() #dodisplayineditmode() KUVIO 12. AbstractComponent toteuttaa kolme Operaatiorunkoa sekä niihin liittyvät primitiivioperaatiot, jotka aliluokat toteuttavat.

38 38 DisplayInHtml- sekä DisplayInEditMode-metodien rungot toteuttavat aliluokille yhteisen HtmlClass-luokan käsittelyn sekä virheiden etsimisen ja kutsuvat luonnollisesti vastaavia abstrakteja metodeita. Aliluokat toteuttavat abstraktit metodit kukin omalla tavallaan. Kummassakin metodissa metodit palauttavat lopulta Content-oliolle sen sisältämät oliot tekstimuotoisena HTML-datana, jonka selain kääntää ihmiselle ymmärrettävään muotoon. Kuviossa 13 on esitetty sekvenssikaaviossa yksinkertaistettu displayinhtml-metodin toiminta, kun Content koostuu yhdestä Paragraph-oliosta, jonka sisällä on yksi Text-olio. Content AbstractComponent HtmlClass Paragraph Text displayinhtml() displayinhtml() return: String dodisplayinhtml dodisplayinhtml dodisplayinhtml return: String return: String return: String KUVIO 13. Sekvenssikaavio displayinhtml-metodin toimminasta Model-kerroksella Operaatiorunko toteutuu abstraktin DataMapper-luokan metodeissa findbyid sekä save (kuvio 14). FindById-metodin runko koostuu parametrin tarkistamisesta, olion alustamisesta, primitiivioperaation (dofindbyid) kutsumisesta sekä olion palauttamisesta. DoFindById on toteutettu kussakin aliluokassa luokan vaatimalla tavalla. Aliluokan primitiivioperaatio tekee olion tiedot kysyvän kyselyn tietokantaan, muodostaa olion näistä tiedoista ja palauttaa olion metodia kutsuneelle oliolle. Save-metodin Operaatiorungossa tarkistetaan parametrina tulevan olion muuttujat, reagoidaan tietokantakyselyn onnistumiseen/epäonnistumiseen sekä päätetään, mikä on olion tila ja kuinka se tulisi tallentaa. Olion tila määrää, mitä yksityistä (private) Operaatiorunko-metodia save kutsuu. Näissä metodeissa runkona on toistaiseksi vain tietokantakyselyn

39 39 onnistumisen/epäonnistumisen välitys sekä abstraktien operaatioiden kutsu, mutta tulevaisuudessa niihin voidaan liittää myös muita toimintoja. Aliluokat toteuttavat primitiivioperaation kukin tavallaan. DataMapper +findbyid(id: int) #dofindbyid(id: int) +save(object: AbstractComponent) -insert(object: AbstractComponent) -update(object: AbstractComponent) -delete(object: AbstractComponent) #doinsert(object: AbstractComponent) #doupdate(object: AbstractComponent) #dodelete(object: AbstractComponent) DatabaseConnect TextTitleDataMapper #dofindbyid(id: int) #doinsert(object: AbstractComponent) #doupdate(object: AbstractComponent) #dodelete(object: AbstractComponent) ParagraphDataMapper #dofindbyid(id: int) #doinsert(object: AbstractComponent) #doupdate(object: AbstractComponent) #dodelete(object: AbstractComponent) KUVIO 14. Operaatiorunko toteutuu myös Futurable Oy:n järjestelmän Modelkerroksella Kuviossa 15 kuvataan yksinkertaistetusti save-metodin toiminta sekvenssikaaviossa tilanteessa, jossa sisältönä on yksi Paragraph-olio. Sekvenssi alkaa, kun Content-olio kutsuu ContentDataMapperin save-metodia, jossa aloitetaan transaktio (begin) ja käydään läpi parametrina tulevan Content-olion komponenttitaulu. Olio tallennetaan kutsumalla abstraktin yläluokan (DataMapper) rajapintametodia save. Sen Operaatiorungossa muun muassa varmistetaan parametrina tulevan olion muuttujien sopivuus tietokantaan (mysql_real_escape_string-metodin avulla). Olion tilan perusteella päätetään, millainen tallennus oliolle tehdään. Kuviossa 15 on kuvattu tilanne, jossa olio on uusi ja tallennukseen käytetään insert-metodia. Insert toimii jälleen Operaatiorunkona, joka kutsuu abstraktia doinsert-metodia. Tämä on puolestaan toteutettu kussakin lapsiluokassa luokan vaatimalla tavalla. DoInsert tallentaa olion tietokantaan ja antaa paluuarvona tiedon siitä, onnistuiko tallennus. Lopulta paluuarvo palautuu ContentDataMapper-oliolle, joka päättää transaktion joko onnistuneesti (commit) tai peruuttaa sen (rollback).

40 40 Content ContentDataMapper DataMapper ParagraphDataMapper save(content: object) save(abstractcomponent: object) insert(abstractcomponent: object) doinsert(abstractcomponent: object) doinsert(astractcomponent: object) tallennus tietokantaan return(boolean: success) return(boolean: success) return(boolea: success) return(boolean: success) KUVIO 15. Save-metodin toimintaperiaate, kun uusi olio tallennetaan Operaatiorunko on mielestäni tehokas ja selkeä tapa toteuttaa toimintoja, jotka ovat osittain samanlaisia, mutta osittain poikkeavia. Mallin käytön lopputuloksena syntyy uudelleenkäytettävää, helposti ylläpidettävää ja virheet nopeasti paljastavaa ohjelmakoodia, jota käytetään aina rajapinnan metodien kautta samalla tavalla riippumatta siitä, millainen konkreettinen luokka on kyseessä. 5.5 Kehitysideat Opinnäytetyöni käytännön osuus on perustoiminnot sisältävä kevyt järjestelmä, jonka parhaat puolet tulevat esiin melko suppean sisällön web-sivustoissa. Järjestelmän arkkitehtuuri antaa kuitenkin mahdollisuuden järjestelmän monipuoliseen laajentamiseen ja erikoistamiseen. Yksi sen hienoimpia piirteitä onkin järjestelmän soveltuminen erilaisiin projekteihin, sillä komponenttilähtöisyys antaa mahdollisuuden toteuttaa erikoiskomponentteja kunkin projektin tarpeisiin. Vaikka lopputulos on tavoitteiden mukainen, on sen perusversiossakin muutamia kehitystä vaativia kokonaisuuksia, joita aion parantaa mahdollisuuksien mukaan tulevaisuudessa. Yksi kehitettävistä kohteista on hallintapaneelin käyttöliittymä. Käyttöliittymä nykyiselläänkin on toimiva, mutta sen käytettävyys päivittäjän näkökulmasta ei

41 41 ehkä ole paras mahdollinen. Nykyisellään käyttöliittymä on hieman kömpelö ja vaatii sisällön järjestyksen suunnittelua ennen sen lisäämistä. Sisällön lisääminen on helpompaa, jos on jo etukäteen käsitys siitä, minkälaista sisältöä ja missä järjestyksessä sitä aikoo sivustolle laittaa. Komponenttien järjestys perustuu numeroihin, joita päivittämällä järjestys päivittyy esikatselunäkymään. Toisin sanoen järjestyksen muutosta ei näe heti, vaan se on katsottava esikatselunäkymästä. Käyttämällä esimerkiksi jquery-tekniikan raahattavuutta ( drag and drop ), komponenttien liikuttamisesta saisi tehtyä käyttäjäystävällisemmän ja nykyaikaisemman. Sivuston monikielisyys voitaisiin myös toteuttaa joustavammin. Nykyisessä versiossa sivuston monikielisyys määräytyy sen mukaan mitä navigaation muokkaustiedostoon on määritelty. Ohjelman konfiguroinnin yhteydessä voidaan siis määritellä esimerkiksi suomen- ja englanninkelinen navigaatio. Hallintapaneelissa päivittäjä näkee nämä navigaatiot kahtena erillisenä ja pystyy vaihtamaan niitä kielivalikon avulla. Ongelmaksi muodostuu se, jos esimerkiksi samojen kuvien halutaan näkyvän sekä suomen- että englanninkielisellä puolella. Tällöin päivittäjän on lisättävä kuvat molemmille puolille erikseen, mikä hankaloittaa sivuston päivittämistä melkoisesti. Olisi kätevämpää, jos kuvan voisi linkittää sekä suomen- että englanninkieliseen sivuun niin, että kuva pysyisi aina samana, mutta tekstien muokkaus olisi silti mahdollista. Nykyisellään järjestelmä sisältää vain peruskomponentteja, joiden avulla käyttäjä voi lisätä sivustolleen pääasiassa tekstiä ja kuvia. Oman kokemukseni mukaan kuitenkin melkein jokaisella web-sivulla on nykyisin jonkinlainen kuvagalleria ja yhteydenottolomake. Olisikin hyvä, jos järjestelmän perusversiosta löytyisi niiden lisäämisen mahdollistavat komponentit. Nykyisellään komponenteista löytyy kyllä vapaamuotoisen ohjelmakoodin lisäämisen tarkoitettu htmlcodekomponentti, mutta sen käyttäminen suurempien kokonaisuuksien lisäämiseen on melko haastavaa ja siinä tarvitaan jo html-koodin ymmärtämistä, mitä peruskäyttäjän ei oleteta osaavan. Tulevaisuudessa aionkin toteuttaa järjestelmän perusversion vakio-ominaisuudeksi sekä lomakkeen lisäyksen mahdollistavan komponentin että komponentin, jolla yksinkertaisen kuvagallerian lisääminen onnistuu.

42 42 6 ESIMERKIT FUTURABLE OY:N JÄRJESTELMÄN KÄYTÖSTÄ 6.1 Tampereen akateemisen sinfoniaorkesterin web-sivusto Tampereen akateeminen sinfoniaorkesteri (TASO) on tamperelainen pääasiassa harrastelijamuusikoista koostuva sinfoniaorkesteri, joka toimii aktiivisesti ja konsertoi vähintään kaksi kertaa vuodessa. TASO halusi uudistaa ja yhtenäistää markkinointi-ilmettään, jonka seurauksena oli tarvetta myös uusille websivuille. Selvitettyäni uudistuksen taustaa ja tarkoitusta, suosittelin, että uusi sivusto voitaisiin rakentaa suunnittelemallani järjestelmällä. Uusien web-sivujen toteutus on opinnäytetyötä kirjoittaessa vielä hieman kesken, mutta sivusto on tarkoitus julkaista marraskuun 2011 loppuun mennessä. Sivusto toteutetaan tässä vaiheessa Futurable Oy:lle kehitetyn järjestelmän perusversion avulla. Tulevaisuudessa sinne tullaan kuitenkin lisäämään ainakin kuvagalleria sekä muutamia lomakkeita. Hallintapaneelin oikeasta sivusta löytyvät painikkeet erilaisten sisältökomponenttien lisäämiseen. Perusversiossa sivuille on mahdollista lisätä otsikoita, tekstiä, kuvia, linkkejä ja asialistoja (kuva 1). Kuvien ja tekstin lisääminen tapahtuu Kappale-komponentin avulla. Järjestelmässä on myös html-koodin lisäykseen tarkoitettu Lisää html-koodia -nappi, jolla html-ohjelmointia osaava päivittäjä voi lisätä sellaista sisältöä, jolle ei vielä toteutettu omaa komponenttia. Kuten kuvasta 1 näkee, sivun vasemmasta laidasta löytyy navigaatiovalikko, josta voi valita muokattavan sivun. Navigaatiovalikko on täysin samanlainen kuin sivuston julkisella puolella ja se rakennetaan conf-navi.xml-tiedoston avulla. Jos sivustosta haluaa monikielisen, tiedostoon voi määritellä useammankin erikielisen navigaationvalikon xml-puun avulla. Esimerkiksi englanninkielinen navigaatio rakennetaan <navigationen> -nimisen XML-elementin ja sen lapsielementtien avulla. Navigaation piirtämisestä vastaava Navigationkomponentti huolehtii siitä, että tarvittavat kielenvalintanapit tulevat näkyviin käyttöliittymään. TASO:n tapauksessa sivustosta tehdään tässä vaiheessa kaksikielinen (suomi ja englanti), mutta myöhemmin kielisyyksiä saatetaan lisätä.

43 43 KUVA 1. Hallintapaneelin näkymä TASO:n sivuilla Sivuston julkinen puoli rakennetaan sen mukaan, millaisia komponentteja kullekin sivulle on linkitetty. Esimerkiksi Orkesterin esittely -sivulle on linkitetty yksi pääotsikko (TextTitle), yksi väliotsikko (TextTitle) sekä kolme tekstikappaletta (Paragraph + Text) (kuva 2). Kun päivittäjä lisää sisältöä hallintapaneelin kautta, kaikki päätason komponentit saavat parentid-tiedokseen kyseisen sivun yksilöllisen id:n. Kun käyttäjä navigoi sivulle, Content-olio hakee kyseisen sivun sisällön findbyid-metodin avulla. Sivuston sisältökomponentit päätyvät tällöin Content-olion komponenttitauluun, joka tulostetaan selaimen tulkattavaksi html-muotoon displayinhtml-metodin avulla. Sama pätee hallintapaneelin puolella, jossa komponentit tulostetaan muokkaustilaan käyttämällä displayineditmode-metodia.

44 44 KUVA 2. TASO:n web-sivuston julkinen puoli rakentuu sisältökomponenteista Futurable Oy:n järjestelmän perusversiossa ei ole mahdollisuutta ajastuksiin, mutta TASO:n tapauksessa olisi hyvä, jos tiettyjä ilmoituksia ja uutisia pystyttäisiin ajastamaan siten, että ne siirtyisivät tietyn päivän jälkeen eri sivulle. Esimerkiksi konsertin mainos olisi Konsertit-sivulla konserttipäivään saakka ja sen jälkeen siirtyisi Historia > Menneet konsertit -sivulle. Tällainen toiminto vähentäisi käsin tehtävää päivitystä huomattavasti. Tulevaisuudessa onkin tavoitteena viedä päivittämistä eteenpäin ja mahdollistaa myös tällaiset pienet ajastettavat toiminnot. 6.2 Kuullos Orchestran web-sivusto Kuullos Orchestra on Helsingin seudulla toimivien nuorten musiikin ammattiopiskelijoiden muodostama big band, jonka perusideana on kantaesittää nuorten suomalaisten säveltäjien uutta tuotantoa. Vaikka orkesteri on perustettu vuonna 2008, ei sillä ole ollut web-sivuja vielä lainkaan. Opinnäytetyön kirjoitushetkellä projekti on vielä alkutekijöissä, mutta sivuston vaatimusten perusteella olemme sopineet, että sivusto tullaan toteuttamaan Futurable Oy:n järjestelmällä. Sivusto on tarkoitus julkaista vuoden 2011 loppuun mennessä.