GRAILS JA LIFT OHJELMISTOKEHYSTEN VERTAILU WEB-SOVELLUSTEN EVOLUTIIVI- SESSA PROTOILUSSA

Koko: px
Aloita esitys sivulta:

Download "GRAILS JA LIFT OHJELMISTOKEHYSTEN VERTAILU WEB-SOVELLUSTEN EVOLUTIIVI- SESSA PROTOILUSSA"

Transkriptio

1 GRAILS JA LIFT OHJELMISTOKEHYSTEN VERTAILU WEB-SOVELLUSTEN EVOLUTIIVI- SESSA PROTOILUSSA Aki Heikkinen Itä-Suomen yliopisto Tietojenkäsittelytiede Pro gradu -tutkielma

2 TIIVISTELMÄ Evolutiivisen protoilun ja ohjelmistokehyksien hyödyntäminen web-sovellusprojekteissa on osoittautunut tehokkaaksi valinnaksi useampiin projekteihin. Evolutiivinen protoilu tarjoaa nopeaan ohjelmistokehitykseen perustuvan inkrementaalisen kehitysmallin. Tätä mallia hyödyntäen kussakin kehitysvaiheessa kehitettävästä web-sovelluksesta tuotetaan prototyyppi, jonka avulla asiakkaalta kerätään palautetta parantaakseen lopullisen toimitustuotteen laatua. Grails ja Lift ovat ohjelmistokehyksiä, joilla voi tuottaa tehokkaasti nykypäivän web-standardien ja teknologioiden vaatimukset täyttäviä web-sovelluksia. Molemmilla ohjelmistokehyksillä on kuitenkin toisistaan hyvin erilainen lähestymistapa. Grails-ohjelmistokehys pohjautuu dynaamiseen Groovy-ohjelmointikieleen ja Liftohjelmistokehys pohjautuu funktionaaliseen Scala-ohjelmointikieleen. Molemmat ohjelmointikielet ovat olio-ohjelmointikieliä, jotka tuottavat puhdasta Java-virtuaalikoneeseen soveltuvaa tavukoodia. ACM-luokat (ACM Computing Classification System, 1998 version): D.2.2, D.2.3, D.3.3 Avainsanat: Groovy, Grails, Lift, ohjelmistokehys, evolutiivinen protoilu, prototyyppi, Scala, web-sovellus SISÄLLYSLUETTELO 1 JOHDANTO Taustaa Rakenne EVOLUTIIVINEN PROTOILU Yleistä Liiketoiminnan näkökulma evolutiiviseen protoiluun Evolutiivisen protoilun edut ja heikkoudet Käyttöliittymän evolutiivinen protoilu OHJELMISTOKEHYS Ohjelmistokehyksien taustaa Ohjelmistokehyksien rakenne Web-sovellusohjelmistokehys GRAILS Groovy-ohjelmointikieli Rakenne ja arkkitehtuuri Grails web-sovelluksien rakenne Grails kehitysalustana... 21

3 5 LIFT Scala-ohjelmointikieli Rakenne ja arkkitehtuuri Snippet-komponentit Toimijamalli AJAX- ja Comet-ohjelmointi VERTAILU Yleiskuva kehitettävästä web-sovelluksesta Ensimmäinen vaihe Projektin alustaminen Verkkosivupohjan toteuttaminen Sivujen ja linkitysten toteuttaminen Toinen vaihe Monikielisyystuen toteuttaminen Palaute ominaisuus Sisäänkirjautuminen ja käyttäjän tunnistaminen Palautteen selailuominaisuus ylläpitäjälle Kolmas vaihe Dynaamiset sivut Grails-projektissa Dynaamiset sivut Lift-projektissa Vertailu dynaamisten sivujen toteuttamisessa Toimitusvaihe Yleinen vertailu YHTEENVETO VIITTEET LIITE Y1: Java-toteutus esimerkkitehtävästä LIITE Y2: Groovy-toteutus esimerkkitehtävästä LIITE Y3: Scala-toteutus esimerkkitehtävästä LIITE G1: Grails web-sovelluksen banneri-komponentin toteutus LIITE G2: Grails web-sovelluksen pääsivun toteutus LIITE G3: Grails web-sovelluksen etusivukomponentin toteutus LIITE G4: Yhden hallintaluokan toteutus LIITE G5: Palautteen antamistoimintoa vastaava GSP-sivu LIITE G6: Ylävalikon GSP-sivutoteutus LIITE G7: Kielivalikko hallintaluokan toteutus LIITE G8: Palautteen toimintoalueluokka LIITE G9: Palautteen hallintaluokka LIITE G10: Type-toimintoalueluokan toteutus LIITE G11: Category-toimintoalueluokan toteutus LIITE G12: Languages-toimintoalueluokan toteutus

4 LIITE G13: Page-toimintoalueluokan toteutus LIITE G14: Pagecontent-toimintoalueluokan toteutus LIITE G15: Dynaamisen luonteen mahdollistava yleinen GSP-sivu LIITE G16: Dynaamisen hahmottamisen mahdollistava hallintaluokka. LIITE G17: Apuluokka dynaamisen hahmotuksen toteuttamiseen LIITE G18: Pagecontent-instanssin muokkaussivu LIITE G19: Tietokantamääritys DataSource.groovy tiedostossa LIITE L1: Lift web-sovelluksen staattisen banneri-sivupohjan toteutus LIITE L2: Lift web-sovelluksen frontpage-sivupohjan toteutus LIITE L3: Lift web-sovelluksen pääsivun toteutus LIITE L4: Main pääkategoriaan sisältyvien alakategorialinkkien hahmottaminen LIITE L5: SiteMap-komponentin toteutus ensimmäisessä vaiheessa. LIITE L6: Lokalisoinnin määritysfunktio LIITE L7: Käytettävän lokaalin valintatoiminnallisuus LIITE L8: Palautetta vastaava toimintoaluemalli LIITE L9: Tietokantayhteys olion toteutus LIITE L10: Palautteenantolomake LIITE L11: Palautteenantolomakkeen käsitelevä Snippet-luokka LIITE L12: Käyttäjää mallintava toimintoalue luokkatoteutus LIITE L13: Sivupohja-apuluokan Snippet-komponentti toteutus LIITE L14: Palautteiden selailuominaisuuden sivupohjatoteutus LIITE L15: Palautteiden selailuominaisuuden Snippet-komponentti LIITE L16: Yksittäisten palautteiden näkymä-sivupohja LIITE L17: Yksittäisten palautteiden näkymän Snippet-komponentti LIITE L18: Type-toimintoalueluokan toteutus LIITE L19: Category-toimintoalueluokan toteutus LIITE L20: Languages-toimintoalueluokan toteutus LIITE L21: Page-toimintoalueluokan toteutus LIITE L22: Pagecontent-toimintoalueluokan toteutus LIITE L23: Dynaamisen sivuluonteen mahdollistava sivupohja LIITE L24: Pagecontent-instanssin muokkaussivupohja LIITE L25: Dynaamisen sivupohjaluokan Snippet-komponentti LIITE L26: Yleinen apuluokka sivujenkäsittelyyn

5

6 1 JOHDANTO Nykypäivän web-sovelluksilta odotetaan paljon ja web-kehitykseen liittyy yleensä useita eri standardeja ja teknologioita, joiden toteuttaminen alusta alkaen olisi hyvin työlästä ja hidasta. Samaan aikaan nykypäivän teollisuuden ja kaupallisuuden liiketoimintamallit vaativat nopeita ratkaisuja ja toteutuksia. Kaisler (2005) ja Sommerville (2007) mukaan ohjelmistotuotannon vastaus nykypäivän vaatimuksiin on nopean ohjelmistokehityksen (rapid software development) ja ohjelmistokehysten (software frameworks) hyödyntäminen ohjelmistoprojekteissa. Sommerville (2007) mukaan nopeasta ohjelmistokehityksestä on tullut yksi tärkeimmistä nykypäivän ohjelmistoprojektien vaatimuksista, koska se voi reagoida ja vastata nopeasti muuttuvaan liiketoimintaympäristöön. Yksi lähestymistapa nopeaan ohjelmistokehitykseen on hyödyntää evolutiivista protoilua, jossa kehitettävä sovellus on alusta pitäen elävä ja muuttuva prototyyppi kunnes se saavuttaa valmiuden lopullista julkaisua varten. Kaisler (2005) mukaan ohjelmistokehykset taas tarjoavat hyviksi todettujen standardien ja teknologioiden toteutukset sekä laajennettavan pohjan erilaisille ohjelmistoprojekteille. Ohjelmistokehyksiä on hyvin monenlaisia ja ne on tavallisesti tarkoitettu tietynlaisia projekteja varten. Tässä Pro Gradu-tutkielmassa tutkitaan ja verrataan kahta erilaisella lähestymistavalla toteutettua web-sovellusohjelmistokehystä keskenään evolutiivisen protoilun näkökulmasta. Tutkittavat web-sovellusohjelmistokehykset ovat Groovy-ohjelmointikieleen pohjautuva Grails ja Scala-ohjelmointikieleen pohjautuva Lift. Molemmat ohjelmointikielet ovat vaihtoehtoisia Java-virtuaalikone (JVM) kieliä, jotka kääntyvät lähdekoodista puhtaaksi JVM- tavukoodiksi ja niitä voi ajaa samanlaisessa ympäristössä. Grails on kokonaisvaltainen ohjelmistokehys, joka tarjoaa työkaluja projektien luomisesta toimitukseen. Lift on vastaavasti joustava ja erityisen skaalatutuva ohjelmistokehys, joka tarjoaa kehittäjille suuren vapauden valita erilaiset ratkaisumallit erilaisiin ongelmiin ja rohkaisee kehittäjiä suunnittelemaan web-sovellukset funktionaalista ohjelmointiparadigmaa käyttäen (WorldWide Conferencing, LLC., 2010). 1

7 1.1 Taustaa Sommerville (2007) mukaan ohjelmistokehittäjille on tarjolla useita eri lähestymistapoja prosessimalleja projektien läpivetämiseksi. Osa prosessimalleista pohjautuu kiinteisiin peräkkäisiin vaiheisiin, joissa vaatimusmäärittely, suunnittelu, implementaatio ja testaaminen ovat omia itsenäisiä kehitysvaiheita. Tällaiset mallit hyödyntävät kiinteitä vaatimusmäärittelyjä ja ne soveltuvat erityisen hyvin suuriin ohjelmistoprojekteihin, jossa järjestelmän arkkitehtuuri tulee suunnitella alusta pitäen tietynoloiseksi. Näiden mallien suurin heikkous on siinä, ettei niitä ole suunniteltu huomioimaan projektien aikana ilmeneviä mahdollisia muutoksia. Muutokset ovat tyypillisiä erityisesti tilanteissa joissa kehittäjien ja asiakkaiden ymmärrykset ei täysin kohtaa tai esimerkiksi kun asiakkaalla on visio, mutta ei täysin tiedä miten se tulisi toteuttaa, jotta se vastaisi tehokkaasti tarkoitustaan. Sommerville (2007) mukaan uudemmat ketterät ohjelmistoprosessit ottavat kantaa muutosten huomioimiseen ja mahdollistamiseen ohjelmistoprojektin aikana. Yksi tällainen ketterä lähestymistapa on evolutiivinen protoilu, jossa kehitettävä sovellus toteutetaan pienissä osissa. Stephens, et al. (2002) mukaan tarkoitus kussakin pienemmässä osassa on löytää kehittäjän ja asiakkaan välinen yhteisymmärrys siitä mitä asiakas todella haluaa ja tarvitsee visionsa toteuttamiseen. Asiakkaan ja kehittäjän välinen yhteisymmärrys helpottaa lopullisten vaatimusmäärittelyn tuottamista ja rajausta, jonka johdosta projektin resurssit voidaan pitää helpommin hallittavissa. Erityisesti web-sovelluskehityksessä evolutiivinen protoilu on havaittu tehokkaaksi lähestymistavaksi. Ohjelmistoprosessimallien lisäksi ohjelmistokehitystä on pyritty helpottamaan ja standardisoimaan erilaisilla tekniikka- ja teknologiapohjaisilla lähestymistavoilla. Kaisler (2005) mukaan yksi nykypäivän merkittävimmistä lähestymistavoista on hyödyntää uudelleenkäytettäviä ohjelmistokehyksiä. Ohjelmistokehyksiä on useita erilaisia ja ne yleensä keskittyvät tuottamaan teknillisen ratkaisumallin tietynoloista ohjelmistoa varten. Web-sovellusohjelmistokehykset ovat yksi ohjelmistokehyksien tyyppi ja näiden päätavoite on tyypillisesti keventää kehittäjien taakkaa tarjoamalla valmiita de factostandarditoteutuksia ja joustavasti muokattavia ohjelmistokomponentteja web-pohjaisiin sovelluksiin. Tällainen lähestymismalli keventää kehittäjien tarvetta tutustua lukuisiin matalantason www-tekniikkatoteutuksiin, jolloin kehittäjillä on enemmän resursseja käytettävissä itse liiketoimintamallien suunnitteluun ja toteuttamiseen. 2

8 1.2 Rakenne Tutkielma rakentuu kahdesta pääosasta: luvussa 2-5 esitetään aiheen teoreettiset osuudet ja kuvataan käytössä olevat tekniikat. Luvussa 6 suoritetaan tutkielman empiirinen osuus. Aiheen käsittely aloitetaan evolutiivisen protoilun teoriasta ja sen hyödyistä ohjelmistokehityksessä. Luvussa kolme esitellään yleisesti mitä ohjelmistokehykset ovat ja luvuissa neljä ja viisi perehdytään yksityiskohtaisemmin kahteen verrattavaan Grailsja Lift web-sovellusohjelmistokehykseen. Tarkasteltavia asioita ovat erityisesti molempien ohjelmistokehysten konseptit ja vahvuudet. Luvussa kuusi suoritetaan tutkielman menetelmävertailu, jossa toteutetaan yksinkertainen, mutta ominaisuustäytteinen websovellus sekä Grails- että Lift-ohjelmistokehyksillä. Web-sovellus toteutetaan vaiheittain, jolla pyritään mallintamaan evolutiivista protoilua. Samassa luvussa keskitytään löytämään myös web-sovellusohjelmistokehyksen eroja ja kartoittamaan kummankin vahvuuksia ja heikkouksia. Viimeinen luku sisältää tutkielman yhteenvedon. 2 EVOLUTIIVINEN PROTOILU Sommerville (2007) mukaan prototyypillä tarkoitetaan alustavaa ohjelman versiota, jonka tarkoitus on demonstroida ohjelman konseptia, kokeilla erilaisia suunnitteluvaihtoehtoja ja yleisesti tarkentaa vaatimusmäärittelyjä. McConnel (2002) mukaan on olemassa kahdenlaisia prototyyppejä: pois-heitettäviä ja evolutiivisia. Kumpikin prototyyppimalli tarjoaa samat edut, mutta niiden tehokkuus voi vaihdella eri projekteissa. Pois-heitettävän prototyypin tarkoitus on palvella projektia vain sen alkuvaiheissa, jonka jälkeen se heitetään pois ja virallinen tuote kehitetään alusta alkaen hyödyntäen tietoa, jota saatiin protoilulla. Evolutiivisella prototyypillä taas tarkoitetaan vaiheittain kehittyvää ohjelmaa, josta lopuksi saadaan toimitettava tuote. Evolutiivista protoilua voidaan täten pitää synonyymina inkrementaaliselle ohjelmistokehitykselle. Sommerville (2007) mukaan evolutiivinen protoilu on osa nykypäivän nopeaa ohjelmistokehitystä ja siitä on tullut yksi merkittävimmistä ohjelmistokehitysmalleista tuottaa rikkaita web-sovelluksia. 3

9 2.1 Yleistä McConnel (2002) mukaan evolutiivinen protoilu on ohjelmistokehityksen elinkaarimalli, jossa kehitettävän järjestelmän konsepti ja kokonaisuus tarkentuu projektin edetessä. Erityisesti web-sovelluskehityksessä evolutiivinen protoilu aloitetaan kehittämällä järjestelmän näkyvimmät osat, esimerkiksi käyttöliittymä. Kehitteillä olevaa, mutta osittain valmista ja näkyvää web-sovellusta esitellään ja demotaan asiakkaalle, jonka on tarkoitus antaa palautetta sovellusta koskien. Palautatte hyödyntäen prototyyppiä kehitetään vaiheittain eteenpäin kunnes sekä kehittäjät että asiakkaat toteavat prototyypin olevan riittävän hyvä. Tämän jälkeen sovellukseen toteutetaan loput puuttuvat osat ja prototyyppi toimitetaan lopullisena tuotteena. McConnel (2002) mukaan evolutiivisen protoilunmalli tuottaa tasaisia ja näkyviä edistyksen merkkejä, joiden avulla asiakkaat pysyvät tietoisina projektin etenemisestä. Kuva 1 esittää tyypillisen evolutiivisen protoiluprosessin. Kuva 1. Evolutiivinen protoiluprosessi McConnel (2002) toteaa evolutiivisen protoilumallin olevan tehokas erityisesti projekteissa, joissa vaatimukset voivat muuttua nopeasti eikä asiakas halua sitoutua tiettyyn spesifiseen vaatimusmäärittelyyn tai jos asiakas ja kehittäjät eivät kumpikaan tunne kehitettävää sovellusaluetta kunnolla. Evolutiivinen protoilumalli voi olla hyödyllinen myös tapauksissa, joissa kehittäjät ovat epävarmoja parhaan arkkitehtuurin ja algoritmien suhteen. McConnel (2002) mukaan onnistuneen evolutiivisen protoilun tulee kuitenkin sisältää todellinen vaatimusmäärittely, suunnitelma ja ylläpidettävää lähdekoodia. Ilman näitä tekijöitä evolutiivinen protoilu voi olla pahimmillaan pelkkää resurssien tuhlaamista ilman päämäärää. 4

10 2.2 Liiketoiminnan näkökulma evolutiiviseen protoiluun Sommerville (2007) mukaan tietokoneohjelmisto on osa lähes kaikkea nykypäivän liiketoimintaa, joka toimii globaalissa, nopeasti muuttuvassa ympäristössä. Nykypäivän liiketoiminnalla on uusia haasteita kyetä vastaamaan uusiin tilaisuuksiin, markkinoihin sekä muuttuviin ekonomisiin asemiin ja ylläpitää kilpailukykyisiä tuotteita ja palveluita. Tästä syystä myös ohjelmistojen kehityksen tulee kyetä edistymään nopeasti, jotta se voisi vastata liiketoiminnan nopeasti muuttuvaa maailmaa. Näiden tekijöiden tähden nopeasta ohjelmistokehityksestä ja toimituksesta on tullut yksi kriittisimmistä vaatimuksista valtaosaan ohjelmistoprojekteja. Sommerville (2007) mukaan vaatimusmäärittelyjen muutokset ovat väistämättömiä nykymaailman muuttuvassa ympäristössä. Vaatimusmäärittelyjen muutokset yleensä johtuvat siitä, ettei asiakas pysty etukäteen ennustamaan kuinka kehitettävä järjestelmä tulee vaikuttamaan työkäytöntöihin, kuinka järjestelmän tulee olla vuorovaikutuksessa muiden järjestelmien kanssa ja mitä käyttäjätoimintoja tulisi automatisoida. Joissain tilanteissa todelliset vaatimukset tulevat ilmi vasta järjestelmän toimituksen jälkeen kun käyttäjät ovat saaneet kokemusta sen käytöstä. Muutoksien väistämättömyyden takia ohjelmistokehitysprosessit, jotka pohjautuvat tiukkoihin vaatimusmäärittelyihin ja joustamattomiin kehitysvaiheisiin, eivät sovellu Sommerville (2007) mukaan nopeaan ohjelmistokehitykseen, eivätkä siten nopeasti muuttuvaan liiketoimintaympäristöön. Evolutiivinen protoilu pystyy tarjoamaan joustavan, iteratiivisen ja muutokset mahdollistavan kehitysmallin ohjelmistojen kehitykseen. 2.3 Evolutiivisen protoilun edut ja heikkoudet Sommerville (2007) mukaan evolutiivisen protoilun soveltuminen nykypäivän ohjelmistokehityksen kriteereihin perustuu siihen, että se pohjautuu sekä inkrementaalisen ohjelmistokehityksen että nopean ohjelmistokehityksen ideaan. Evolutiivisen protoilun suurimmat edut ovat Sommerville (2007) mukaan seuraavat: 1. Kehitysprosessin määrittely, suunnittelu ja toteutusvaiheet voidaan hoitaa samanaikaisesti. Tämä mahdollistaa muun muassa mahdollisten muutoksien toteuttamisen siinä vaiheessa kun ne ilmenevät. 5

11 2. Järjestelmä kehitetään pienissä osissa, eli inkrementeissä, jotka yhdessä muodostavat lopullisen tuotteen. Tällöin kaikki projektiin liittyvät tahot, esimerkiksi loppukäyttäjät, voidaan ottaa mukaan arvioimaan ja määrittämään kukin inkrementti. Etuna on se, että tahot pystyvät esittämään muutospyynnöt ja uudet vaatimukset aikaisessa vaiheessa, jolloin niihin voidaan ottaa kantaa nopeammin. 3. Nopeampien järjestelmän välitoimitusten ansiosta asiakkaat voivat saada järjestelmästä osittain käytännöllistä hyötyä jo sen aikaisessa kehitysvaiheessa. 4. Asiakkaiden ja loppukäyttäjien osallistuminen projektiin palautteen antajina parantaa todellisten vaatimusten löytämistä projektin aikaisessa vaiheessa. Tämän ansiosta lopullinen tuote vastaa paremmin asiaakaan todellista tarvetta, joka parantaa tuotteen hyväksymisastetta. 5. Käyttöliittymäsuunnittelussa ja toteutuksessa on yleensä käytössä kehitystyökaluja joiden avulla voi tuottaa nopeasti interaktiivisia käyttöliittymä prototyyppejä. Tällaisten työkalujen käyttäminen vähentää kehityskuluja ja resursseja. Osa kehitystyökaluilla tuotetuista prototyypeistä voidaan jopa liittää mukaan viralliseen tuotteeseen. Esimerkiksi web-sovellukseen prototyyppinä tuotettua HMTLsivupohjaa ja CSS-tyylitiedostoja on mahdollista hyödyntää virallisessa tuotteessa. Evolutiivisen protoilu on Sommerville (2007) mukaan vesiputousmallia tehokkaampi lähestymistapa erityisesti sen inkrementaalisen luonteen ansiosta. Sillä on kuitenkin kaksi merkittävää heikkoutta projektihallinnan ja ohjelmistosuunnittelun näkökulmasta (Sommerville, 2007): 1. Projektin edistymistä on vaikea hahmottaa, joka johtuu siitä, ettei projektin elinkaaressa ole tiettyjä luukoonlyötyjä vaiheita. Ainut tapa projektinjohdolle hahmottaa mihin vaiheeseen projekti on edennyt, on muodostaa erilaisia dokumentteja ja julkaisuversiota kehitettävästä järjestelmästä. Tämä lähestymistapa ei kuitenkaan ole kustannustehokas mikäli kehitystä tapahtuu nopeasti. 2. Inkrementaalisella kehityksellä tuotetut järjestelmät voivat olla heikosti rakennettuja kokonaisuudessaan. Syy tähän on se, että eri inkrementeissä toteutetut toiminnallisuudet voivat muuttua kehityksen eri vaiheissa, joka voi korruptoida järjestelmän alkuperäistä kiinteää rakennetta. Tämän lisäksi järjestelmän rakenteiden muutokset voivat olla vaikeita ja kalliita toteuttaa. 6

12 Sommerville (2007) mukaan evolutiivinen protoilu soveltuu parhaiten pieniin ja keskikokoisiin ohjelmistoprojekteihin, joissa lähdekoodin määrä on enintään riviä. Suuremmissa projekteissa, joissa tähdätään erityisesti pitkäikäisiin järjestelmiin, voi olla suuria haasteita hyödyntää evolutiivista protoilua. Tämä johtuu siitä että suurissa projekteissa työ yleensä jaetaan pienempiin irrallisiin osiin joihin eri kehitysryhmät ottavat kantaa. Kun irralliset osat ovat valmiita, ne yhdistetään toisiinsa. Tällaisessa lähestymistavassa muutosten toteutettavuus on hyvin hankalaa ja pahimmillaan se on este tuottaa vakaita järjestelmäarkkitehtuureja. Sommerville (2007) kuitenkin toteaa, että evolutiivista protoilua pystyy hyödyntämään osittain suuremmissakin projekteissa. Esimerkiksi järjestelmän muuttumattomin arkkitehtuurirakenne voitaisiin toteuttaa kiinteämpiä ohjelmistoprosesseja hyödyntäen, ja vain muutosarimmat osat, kuten esimerkiksi käyttöliittymä toteutettaisiin evolutiivista protoilua hyödyntäen. 2.4 Käyttöliittymän evolutiivinen protoilu McConnel (2002) mukaan ohjelmistojen käyttöliittymä on yleensä kaikista riskialtein osa, jonka kehitys kannattaa aloittaa yleensä mahdollisimman aikaisessa vaiheessa. Käyttöliittymä on yleensä ainoa ohjelmiston näkyvä osa, jonka perusteella loppukäyttäjät arvioivat ohjelman kokonaisuutta ja tekevät päätökset sen käytettävyydestä ja hyväksyttävyydestä (Sommerville, 2007). Sommerville (2007) mukaan ohjelmistojen käyttöliittymien dynaamisen luonteen takia niitä ei tavallisesti voida määritellä vaatimusmäärittelyssä, vaan ainut käytännöllinen tapa käyttöliittymän suunnitteluun ja toteuttamiseen on protoilu. Mahdollisten loppukäyttäjien mukaan ottaminen käyttöliittymän suunnittelu- ja kehitysprosessiin on yksi onnistumisen välttämättömimmistä tekijöistä käyttäjäkeskeisessä suunnittelussa, kun kyseessä on interaktiivinen järjestelmä. McConnel (2002) mukaan evolutiivisen käyttöliittymä protoilun suurin etu on se, että se pienentää käyttöliittymän kehittämisen riskejä ja kehittämismenoja. Käyttöliittymä protoilu voidaan jakaa kahteen vaiheeseen (Sommerville, 2007): 1. Kehitysprosessin alkuvaiheessa käyttöliittymä voidaan esittää paperiversiona. Tällöin kukin sovelluksen näyttö on oma paperiprototyyppi ja näyttöjen välinen vuorovaikutus voidaan kuvata asiakkaalle visuaalisesti. 7

13 2. Myöhemmässä kehitysvaiheessa käyttöliittymä määritellään uudelleen käyttäen hyödyksi aikaisemmassa vaiheessa saatua palautetta ja niiden pohjalta kehitetään interaktiivinen ja automatisoitu käyttöliittymä prototyyppi. Tällaista prototyyppiä voidaan jälleen testauttaa ja simuloida käyttäjillä. Paperiprototyypin tuottaminen on edullista ja nopeaa, mutta McConnel (2002) mukaan käyttöliittymän esittäminen interaktiivisena toteutuksena on kaikista tehokkain tapa saada käyttäjiltä palautetta. Interaktiivisen käyttöliittymän prototyyppikäyttöön tuottamisessa on kuitenkin omat haasteensa (Sommerville, 2007). Esimerkiksi sovelluksella tulee olla jonkinlaista toiminnallisuutta, mutta yleensä aikaisessa kehitysvaiheessa sovelluskohtaista toiminnallisuutta tai logiikkaa ei ole mahdollista toteuttaa. Tämän lisäksi interaktiivisen käyttöliittymän toteuttaminen ja toimittaminen voi olla hidasta. Sommerville (2007) mukaan evolutiivinen käyttöliittymäprotoilu soveltuu hyvin web-sovellusten käyttöliittymä protoiluun, sillä kehittäjät voivat helposti hyödyntää valmiita WWW-selaimia web-sovellusten näyttöpohjina. WWW-selaimia hyödyntäen kehittäjät voivat tehokkaasti tuottaa alustavat käyttöliittymäprototyypit yksinkertaisina HTMLsivuina tai esimerkiksi Java-ohjelmointikielen tarjoamilla valmiilla käyttöliittymäkomponenteilla. McConnel (2002) mukaan käyttöliittymän evolutiivinen protoilu soveltuu luultavasti parhaiten erilaisten liiketoimintasovellusten kehittämisprojekteihin, joissa kehittäjillä voi olla jatkuva, epävirallinen yhteys loppukäyttäjiin. Valtaosa web-sovellusprojekteista ovat yleensä tämäntapaisia projekteja. Käyttöliittymän evolutiivinen protoilu tukee nopeaa ohjelmistokehitystä erityisesti seuraavilla tavoilla (McConnel, 2002): 1. Se vähentää käyttöliittymän hyväksyttävyyden riskiä, sillä epätyydyttävät käyttöliittymät ja niiden suunnittelumallit voidaan havaita hyvin aikaisessa vaiheessa ja korjaustoimenpiteet ovat todennäköisesti halvemmat. 2. Kehitettävistä sovelluksista tulee pienempiä, sillä asiakkaat ja loppukäyttäjät pystyvät itse vaikuttamaan siihen mitä ominaisuuksia järjestelmään halutaan mukaan ja mitä ei. Tavallisesti ohjelmistokehittäjät kuvittelevat käyttäjien tarvitsevan tietynlaisia ominaisuuksia vaikka se ei pitäisi paikkaansa. Tällaisten epähaluttujen ominaisuuksien karsiminen projektin alkuvaiheessa vähentää kehittämisaikaa. 8

14 3. Kehitettävistä sovelluksista tulee yksinkertaisempia, sillä asiakkaat eivät yleensä ole kiinnostuneita ohjelmistokehittäjien tarjoamista monimutkaisista ominaisuuksista. Asiakkaat haluavat mieluummin yksinkertaisempi, mutta laadukkaampia ominaisuuksia. Protoilun avulla voi löytää vastaavat monimutkaiset ominaisuudet, joista käyttäjät eivät edes välitä. 4. Ryömivien vaatimusten määrä on myös havaittu vähentyvän, sillä asiakkailla on parempi käsitys järjestelmästä jo projektin alkuvaiheessa. Tällöin asiakkaat tekevät yleensä vähemmän lisäyksiä vaatimusmäärittelyyn. 5. Projektin näkyvyys on myös parempi ja asiakkaat pystyvät konkreettisemmin suhtautumaan kehitteillä olevaan projektiin. 3 OHJELMISTOKEHYS Ohjelmistokehys on Kaisler (2005) mukaan uudelleenkäytettävä arkkitehtuuri- ja komponenttipohjainen työkalu, joka tarjoaa yleismallisen rakenteen ja toimintatavan sekä kontekstin kuinka sitä voi hyödyntää. Näiden lisäksi ohjelmistokehykset pohjautuvat yleensä rajattuun toiminta-alueeseen, kuten esimerkiksi liiketoimintamallinnus (financial modeling) sovelluksiin ja päätöksentekotuki (decision support) järjestelmiin (Shan, et al., 2006). Sommerville (2007) mukaan ohjelmistokehykset eivät yleensä ole valmiita sovelluksia, vaan niitä on tarkoitus käyttää toteuttamaan sovelluskohtainen toiminnallisuus rajatussa toiminta-alueessa. Ohjelmistokehys voidaan siten nähdä arkkitehtuuriohjaksena, joka jakaa suunnittelun abstrakteihin luokkiin ja määrittää näiden abstraktien luokkien väliset velvollisuudet ja yhteistyötoiminnallisuudet (Kaisler, 2005). Ohjelmistokehyksen käyttö on täten sen tarjoamien abstraktien luokkien perimistä ja toteuttamista soveltumaan tiettyä toiminnallisuutta varten. Ohjelmistokehykset pohjautuvat ajatukseen, jossa niiden tarkoitus on tarjota ohjelmistokehitykselle helppo ja nopea tapa tuottaa joukko spesifisiä, mutta samankaltaisia järjestelmiä, joilla on tietynlainen toiminta-alue (Kaisler, 2005). 3.1 Ohjelmistokehyksien taustaa Kaisler (2005) mukaan ohjelmistokehittäjät ovat jo pitkään tienneet, että uusien ohjelmistojen kehittäminen aivan alusta alkaen on resursseja hukkaava menetelmä. Tämän 9

15 takia ohjelmien uudelleenkäyttäminen on pitkään ollut osana uusien sovellusten kehitystä. Kuitenkin ohjelmistokehittäjät ovat aina myös uskoneet virheestä oppimiseen ja siihen että samanlaisten ohjelmien toteuttaminen alusta alkaen lisäisi tietotaitoa merkittävästi. Vasta 1990-luvulla uudelleenkäytettävyyden tehokkuus yleistyi ohjelmistokehittäjien keskuudessa kun ymmärrettiin että samankaltaiset sovellukset pystyttiin kehittämään tehokkaasti ja nopeammin käyttäen hyödyksi aikaisemmin opittua tietotaitoa ja uudelleen käyttämällä aikaisempien sovellusten osia. Kaisler (2005) mukaan ohjelmistokehys perustuu uudelleenkäytettävyyden ideaan ja sen edeltäjänä toimi olio-ohjelmoinnin komponentti-paradigma. Tässä paradigmassa ohjelma jaettiin osiin eli komponentteihin ja näitä toteutettuja komponentteja pystyttiin jatkossa uudelleen käyttämään uusissa projekteissa. Tämän paradigman ongelma oli kuitenkin se, että vain kaikista pienimpiä ja yksinkertaisimpia yksittäisiä komponentteja voitiin uudelleenkäyttää tehokkaasti. Keskikokoisten ja suurempien komponenttien käyttäminen oli tehokasta vain harvoin. Kaisler (2005) toteaa, että viimeaikoina kiinostunus uudelleenkäytettävyydessä on siirtynyt yksittäiskomponenteista suurempiin laajuuksiin, kuten kokonaisiin sovellusrakenteisiin ja järjestelmiin, jotka voidaan käsittää ohjelmistokehyksinä. Toisinkuin komponentti-paradigmassa, Kaisler (2005) mukaan ohjelmistokehykset painottavat erityisesti suunnittelumallien uudelleen käyttämiseen, lähdekoodin uudelleenkäyttämisen sijasta, mutta käytännössä ohjelmistokehyksiä käyttäessä lähdekoodin uudelleenkäyttäminen korkeammalla abstraktitasolla on väistämätöntä. Vaikkakaan ohjelmistokehyksien käyttö ei ollut yleistä vasta kuin 1990-luvulla, oli sen käsitteestä maininta kirjallisuudessa jo aikaisemmin. Kaisler (2005) mukaan ohjelmistokehyksistä tehtiin ensimmäinen maininta kirjallisuudessa 1980-luvulla Smalltalk-80 ohjelmointikielen yhteydessä. Smalltalk oli suosittu MVC (Model-View-Controller) käyttöliittymäkeskeinen ohjelmistokehys, jolla pystyi tuottamaan graafisia käyttöliittymä-pohjaisia sovelluksia. Apple Computer oli yksi ensimmäisistä kaupallisista tuottajista, joka alkoi hyödyntää ohjelmistokehyksen ajatusta omassa MacApp-ohjelmointiympäristössä. Sen jälkeen erityisesti käyttöliittymä-pohjaisten ohjelmistokehysten yleisyys kasvoi nopeasti suurissa ohjelmistotaloissa ja yrityksissä. Myöhemmin ohjelmistokehyksien käsite yleistyi myös pienemmissä ohjelmistotaloissa, ja erityyppisten ohjelmistokehysten asema vakiintui. Kaisler (2005) mukaan ohjelmistokehyksiä on pyritty luokittelemaan ryhmiin erilaisten kriteerien mukaan. Luokitteluskeemoja on useita eri- 10

16 laista, joista eräät suosituimmista ovat Fayad, et al. (1997) tarjoamat skeemat. Alla esitetään kuitenkin vielä yksi erilainen lähtökohta ohjelmistokehyksien luokitteluun (Shan, et al., 2006): Käsitteelliset ohjelmistokehykset yhdistävät arkkitehtuurimallit, esimerkiksi Zachman Framework. Sovellusohjelmistokehykset tarjoaa runkorakenteen sovelluksille, esimerkiksi WebWork. Toimintoalue (domain) ohjelmistokehykset räätälöity tavallisesti tiettyä liiketoiminta osaa varten, esimerkiksi IBM Information Framework. Alusta (platform) ohjelmistokehykset ohjelmointimallit ja ajanaikaiset ympäristöt, esimerkiksi.net ja Java EE framework. Komponenttiohjelmistokehykset sovellusten rakenneosia varten, esimerkiksi Hibernate, ibatis ja Cayenne. Palveluohjelmistokehykset liiketoiminta ja tekniset palvelumallit palvelukeskeisille ohjelmistoille, esimerkiksi Semantic Web Service Framework. Kehitysohjelmistokehykset rakennuspohjia tuottaa kehitystyökaluja erityisesti integroituja kehitysympäristöjä varten. 3.2 Ohjelmistokehyksien rakenne Shan, et al. (2006) mukaan ohjelmistokehys on rajattu tukirakenne, jonka avulla muut ohjelmistosovellukset voidaan organisoida ja kehittää. Ohjelmistokehys rakentuu kahdesta elementistä: uudelleenkäytettävästä suunnittelumallista ja rakennusosista kuten esimerkiksi graafisten käyttöliittymien komponenteista. Ohjelmistokehys voi sisältää muun muassa apuohjelmia, koodikirjastoja, yleisiä palveluita, rajapintoja tai muita työkaluja kuten esimerkiksi komentosarjakieliä. Näiden hyötykomponenttien avulla kehitettävän sovelluksen osat ja komponentit voidaan toteuttaa ja yhdistää yhdeksi kokonaisvaltaiseksi ohjelmistosovellukseksi. Shan, et al. (2006) mukaan ohjelmistokehyksien rakenne jakautuu myös kahteen eri alueeseen: staattisiin ja dynaamisiin alueisiin. Staattiset alueet ovat ohjelmistokehyksissä järjestelmän yleisarkkitehtuuri eli peruskomponentit ja niiden väliset suhteet. Staattiset alueet pysyvät muuttumattomia kaikissa ilmentymissä, jotka on toteutettu samalla 11

17 ohjelmistokehyksellä. Vastaavasti dynaamiset alueet kuvaava ohjelmistokehyksen osia, jotka voivat olla yksilöllisiä eri ohjelmistokehyksen ilmentymissä. Dynaamiset alueet on tavallisesti suunniteltu yleismallisiksi, jotta ne voidaan mukauttaa sopimaan erilaisiin sovelluksen tarpeisiin. Kaisler (2005) mukaan ohjelmistokehysten arkkitehtuuri ja rakenne voi vaihdella merkittävästi, mutta pääpiirtein ne rakentuvat samanlaisen arkkitehtuuri idean pohjalta. Alla on esitetty viisi eri ohjelmistokehyksen mahdollista arkkitehtuurikerrosta ja kuvaus niiden yleisestä tarkoituksesta ja toiminnallisuudesta. Esitetyssä mallissa kukin kerros muodostaa kaikkien sitä alempien kerrosten tarjoamista ominaisuuksista. Kerrokset on esitetty järjestyksessä alimmasta ylimpään. Kuvassa 2 on esitetty kokonaiskuvaus kaikista arkkitehtuurin kerroksista ja niiden tärkeimmistä sisällöistä. Kernel-kerros Kernel-taso tarkoittaa sovelluksen, käyttöjärjestelmän ja fyysisen tietokoneen välistä rajapintaa. Kaisler (2005) mukaan Kernel-taso tarjoaa yleiset toiminnallisuudet ja palvelut, esimerkiksi metaolio protokollat, oliovaihdot (object trading), säiliökirjastot, asiakas-palvelin toteutustasot (client-server middleware), tietovarastoinnit ja käyttöjärjestelmätason toiminnallisuudet. Tässä kerroksessa ei ole yleensä lainkaan toimintoalue tai sovellus-spesifistä toiminnallisuutta, joten se on helposti uudelleenkäytettävä kerros. Työpöytäkerros Kaisler (2005) mukaan työpöytäkerroksessa määritellään sovelluksien yleinen toimintamalli, johon kuuluu muun muassa yleinen arkkitehtuuri sekä interaktiivisen sovelluksen ulkoasu ja tuntuma. Työpöytäkerros varmistaa sovelluksen toiminnallisen ja teknisen yhtenäisyyden ja sitä voidaan hyödyntää interaktiivisen käyttöliittymän suunnittelussa. Liiketoiminnan toimintoaluekerros Kaisler (2005) mukaan tässä kerroksessa määritellään ja toteutetaan tietyn toimintoaluemallin ydinkäsite ja toiminnallisuus. Liiketoimintakerros toteuttaa pohjan, jota voi hyödyntää missä tahansa saman toimintoaluemallin omaavassa sovelluksessa. Tähän kerrokseen kuuluu muun muassa toimintoalue-spesifiset luokat ja arvotyypit. 12

18 Liiketoimintalogiikan kerros Kaisler (2005) mukaan liiketoimintalogiikan kerroksessa laaditaan toteutukset eri liiketoimintayksiköihin. Toimintalogiikan toteuttaminen vaatii yleensä liiketoiminnan toimintoaluekerroksen ja työpöytäkerroksen luokkien laajentamista ja abstraktien metodien toteuttamista. Tässä kerroksessa toteutetut luokat ja työkalut ovat hyvin spesifisiä liiketoiminnan toimintoaluekohtaisia tehtäviä varten. Sovelluskerros Kaisler (2005) mukaan sovelluskerros on ylin arkkitehtuurikerroksista ja se määrittää itse konkreettisen sovelluksen ja sen konfiguraation. Tässä kerroksessa toteutetaan sovelluksen organisaatiotasoiset vaatimukset asentamalla ja konfiguroimalla organisaatioriippuvaiset tekijät. Kuva 2. Viisikerroksinen ohjelmistokehysarkkitehtuuri 3.3 Web-sovellusohjelmistokehys Shan, et al. (2006) mukaan web-sovellusohjelmistokehys on uudelleenkäytettävä, runkomainen, puoli-valmis, modulaarinen alusta. Web-sovellusohjelmistokehyksellä voi tuottaa erilaisia web-sovelluksia, joita tavallisesti ajetaan web-selainten kautta käyttäen HTTP-protokollaa. Web-sovellusohjelmistokehys koostuvat yleensä palveluosista ja 13

19 komponenteista, joista voidaan rakentaa monipuolisia ja toiminnallisia liiketoimintapalveluita ja järjestelmä. Shan, et al. (2006) mukaan web-sovellusohjelmistokehykset ovat kontekstiltaan sovellusohjelmistokehyksiä, mutta se integroi myös muita kerroksia. Web-sovellusohjelmistokehykset toteuttavat muun muassa yleensä MVC suunnittelumallin, joka tavallisesti pohjautuu Model 2 arkkitehtuuriin. Web-sovellusohjelmistokehykset toteuttavat yleensä myös joitain perustavanlaatuisia liiketoiminnan palveluita kuten haku, versiointi ja oikeuksienhallinta, joilla voi kohentaa sovelluksen luotettavuutta. Näiden lisäksi web-sovellusohjelmistokehykset toteuttavat myös toimintoaluekerroksen, joka yleensä mallintaa yleiskäyttöisiä käsitteitä kuten käyttäjiä, ryhmiä ja näille kuuluvia oikeuksia. Muita mahdollisia relevantteja kerroksia ovat olio-relaatiokerros ja käyttöliittymä, sekä käyttöliittymän komponenttikirjastot, jotka on suunniteltu nopeaa kehitystä varten. Shan, et al. (2006) mukaan web-sovellusohjelmistokehykset toteuttavat yleensä hyviksi havaittuja standardeja ja tekniikoita, jotka mahdollistavat nopean web-sovellus kehittämisen ilman jyrkkää oppimiskäyrää. Tämän lisäksi web-sovellusohjelmistokehysten käyttäminen vähentää työmäärää ja resursseja kehittää ja ylläpitää web-sovelluksia ja ohjelmistokehittäjät pystyvät keskittymään sovelluksen liiketoimintapuoleen infrastruktuurin muun teknologian sijasta. 4 GRAILS Grails on yksi web-sovellusohjelmistokehys, jonka tarkoituksen Rocher, et al. (2009) tiivistää seuraavasti: Sen tarkoitus on yksinkertaistaa yritystason Java-pohjaista webkehitystä, viedä web-kehitys seuraavalle abstraktiotasolle, hyödyntää muiden ohjelmointiympäristöjen parhaita ominaisuuksia ja mahdollistaa joustava pääsy ja muokkaamisvara pohjateknologioihin. Korkeammalla abstraktiotasolla Grails-ohjelmistokehys pohjautuu seuraaviin suunnittelumalleihin ja periaatteisiin (Rocher, et al., 2009): Ohjelmistokehittäjien tarvitsee tehdä merkittäviä päätöksiä ja rajoituksia vain sovelluksen yksilöivien tekijöiden suhteen (Convention over Configuration). Tiedon toistamisen vähentämiseen monikerroksisessa arkkitehtuurissa (Don t Repeat Yourself). 14

20 Toimintoalue-ominaiseen ohjelmointiin (Domain-specific languages). Groovy-ohjelmointikielen tarjoamiin ominaisuuksiin. 4.1 Groovy-ohjelmointikieli Grails-ohjelmistokehys pohjautuu Groovy-ohjelmointikieleen, joka on ketterä ja dynaaminen olio-ohjelmointikieli (Judd, et al., 2008). Groovy toimii Java-alustalla ja se on saanut inspiraationsa muista ohjelmointikielistä kuten: Python, Ruby, Pearl, Smalltalk ja Java. Judd, et al. (2008) mukaan Groovy-ohjelmointikielen vahvuuksia on sen yhteensopivuus Java-virtuaalikoneen kanssa. Groovy-ohjelmointikielellä toteutetut luokat kääntyvät sen omalla kääntäjällä puhtaaksi JVM- tavukoodiksi ja se helpottaa Javaohjelmointikielellä toteutettuja luokkia ja komponentteja integrointia Groovy-ohjelmointikieleen ja toisinpäin. Groovy-ohjelmointikielen kehityspaketti GDK (Groovy Development Kit) laajentaa Java-ohjelmointikielen ohjelmointirajapintaa ja Groovy on itsessään Java Community Process (JCP) ja Java Specification Request (JSR) 241:n hyväksymä standardi, jota isännöidään Codehaus-yhteistyö ympäristössä (Codehaus Foundation, 2008). Toinen vahvuus Groovy-ohjelmointikielessä on sen suuntautuminen moderneihin ohjelmointi-ominaisuuksiin kuten sulkeumiin (closures) ja arvotietotyyppeihin (properties). Kuten Java, myös Groovy on imperatiivipohjainen olio-ohjelmointikieli (Ghosh, et al., 2009). Imperatiivinen ohjelmointi on vanhin ja suosituin ohjelmointiparadigma ja sen pääajatus on käsitellä tietokoneohjelmissa tiloja ja hyödyntää erilaisia komentoja tilojen muuttamiseksi (Kaisler, 2005). Imperatiivinen ohjelmointi pohjautuu von Neumann arkkitehtuuriin ideaan, jossa tieto esitetään muuttuvana varastona. Tässä arkkitehtuurissa ohjelmien toiminta on hakea tietoa varastosta, suorittaa toimintoja ja tallentaa muuttunut tieto takaisin varastoon. Kaisler (2005) mukaan imperatiivinen ohjelmointi voidaan kuvata peräkkäisinä toimintokäskyinä jotka muokkaavat ohjelman tilaa tyypillisesti erilaisten sijoituslauseiden muodossa. Kukin toimintokäsky ja tila on yksilöllinen tietokoneen osa, jotka yhdistettynä muodostavat kokonaisen ohjelman. Groovy-ohjelmointikieli mahdollistaa sekä staattisen että dynaamisen tyypityksen (Rocher, et al., 2009). Staattisella tyypityksellä tarkoitetaan sitä, että kenttien ja muuttujien tyyppi on määritetty tietyksi, esimerkiksi kokonaisluvuksi, liukuluvuksi tai merkki- 15

21 jonoksi, kun taas dynaaminen tyypitys tarkoittaa sitä että vain itse muuttuja määritellään, mutta sillä ei anneta mitään yksilöivää tyyppiä. Köning, et al. (2007) mukaan staattisen tyypityksen etuina on se, että se tarjoaa enemmän tietoa optimointia varten. Staattisessa tyypityksessä kääntäjä pystyy paremmin tulkitsemaan muuttujien käyttöä, joka mahdollistaa paremman integroitujen kehitysympäristöjen (IDE) tuen ja metodien ylilataamisen (overloading). Dynaaminen tyypitys on Köning, et al. (2007) mukaan joustavampi malli, koska muuttujan tyyppi pystyy vaihtumaan aivan kokonaan sen eliniän aikana ja se mahdollistaa ankkatyypityksen (duck typing). Ankkatyypityksessä olion metodit ja sen arvotietotyypit määrittävät oliota koskevan semantiikan sen sijaan että se määräytyisi olion luokkaperimän tai rajapintatoteutuksen mukaan (Köning, et al., 2007). Mikäli oliolla on tarpeelliset metodit tai arvotyyppitiedot niin se voidaan laskea samankaltaiseksi olioksi. Groovy-ohjelmointikielen syntaksi pohjautuu Java-ohjelmointikieleen, mutta sen muodollisuutta on kevennetty merkittävästi ja uusia syntaksiominaisuuksia lisätty parantamaan työtehokkuutta (Judd, et al., 2008). Esimerkiksi tietorakenteiden käsittelystä on tehty helpompaa ja tehokkaampaa Java-ohjelmointikieleen verrattuna. Groovy- ja Javaohjelmointikielien syntaksierot voi havainnollistaa liitteiden Y1 ja Y2 avulla. Liitteissä on toteutettu sama ohjelma, jossa aluksi kahteen listatietorakenteisiin lisätään kymmenen satunnaista lukua ja listojen leikkauksesta muodostetaan avain-arvo parillinen karttatietorakenne. Karttatietorakenteessa avain kuvaa leikkauksesta löytynyttä leikkausnumeroa ja arvo kuvaa kuinka monta kertaa kyseinen numero löytyi molemmista listoista. Tämän jälkeen karttatietorakenteen sisältö tulostetaan konsoliin. Java-toteutus esimerkkitehtävästä on esitetty liitteessä Y1 ja Groovy-ohjelmointikielellä toteutettuna lähdekoodi on liitteen Y2 mukainen. Groovy-ohjelmointikielellä toteutusta versiota voi nähdä kevennetyn syntaksin, tietorakenteiden käsittelyn yksinkertaistamisen ja sulkeumien käytön. Syntaksi muutoksen lisäksi Groovy-ohjelmointikielen kehityskirjastossa on useita hyödyllisiä apuluokkia ja laajennettuja Java ohjelmarajapinnan luokkia (Judd, et al., 2008). Esimerkiksi JUnit-yksikkötestaus on kiinteä osa Groovy:n kehityskirjastoa laajennettuine luokkineen ja metodeineen. Myös XML-rakenteiden käsittelystä on tehty helpompaa ja tehokkaampaa Groovy:n tarjoamien luokkien ja rajapintojen avulla. Judd, et al. (2008) mukaan XML-rakenteiden käsittely Groovy-ohjelmointikielellä on yhtä selkeää ja inhimillisen luettavaa kuin itse XML-rakenteiden luonnekin. Groovy- 16

22 ohjelmointikielelessä on myös muun muassa GPath-ilmaisukieli, jonka avulla XMLrakenteita pystyy navigoimaan tehokkaasti ja saumattomasti XPath-ilmaisukielen tavoin. Groovy-ohjelmointikieli mahdollistaa myös Meta-olio Protokollan (Meta-Object Protocol), jonka avulla olemassaolevia luokkia voi laajentaa ja niihin voi lisätä uusia toiminnallisuuksia, vaikka ne olisivatkin viimeisteltyjä (final). Judd, et al. (2008) mukaan Meta-olio Protokolla yksi tärkeimmistä Groovy-ohjelmointikielen ja Grails-ohjelmistokehyksen käsitteistä, sillä se mahdollistaa Grails:in toimintoalueluokkien ominaisuudet ja joustavan olemassaolon. 4.2 Rakenne ja arkkitehtuuri Judd, et al. (2008) mukaan Grails-ohjelmistokehys voidaan esittää neljäkerroksisena arkkitehtuuritoteutuksena, joka on esitetty kuvassa 3. Arkkitehtuurin alin taso on Javavirtuaalikone ja sen yllä on Java- ja Groovy-ohjelmointikielien tuki, joihin Grailsohjelmistokehys perustuu. Näiden kerrosten yllä on itse Grails-ohjelmistokehys ja websovelluskerros, jotka muodostavat Grails web-sovelluksien sydämen. Arkkitehtuurikerrosten lisäksi Grails hyödyntää Gant-teknologiaa, johon muun muassa Grails komentorivi-rajapinta pohjautuu. Judd, et al. (2008) mukaan Gant-teknologia käyttää Groovyohjelmointikieltä Apache Ant-skriptien tuottamiseen. Teknologiatasolla Grails-ohjelmistokehys sisältää lukuisia avoimeen lähdekoodiin pohjautuvia teknologioita, joista tärkeimmät on listattu ja kuvattu lyhyesti alla (Rocher, et al., 2009): Hibernate, josta on tullut de facto standardi Java-ohjelmoinnin olio-relaatiotietokantakartoitukseen (object-relational mapping). Grails-ohjelmistokehyksen GORM (Grails Object-relational Mapping) laajentaa Hibernate teknologiaa ja tarjoaa kehittäjille lähes konfiguraatio-vapaan oliotallennusrajapinnan. HSQLDB, joka on täysin Javalla toteutettu relaatiotietokannan hallintajärjestelmän (Relational Database Management System) toteutus. HSQLDB on valmiiksi asennettu oletustietokanta Grails-ohjelmistokehysprojekteissa, mutta tarpeen mukaan kehittäjät voivat ottaa käyttöön toisen tietokantatoteutuksen. SiteMesh, joka on vankka ja vakaa sivustopohjan hahmottamiskehys (layoutrendering). 17

23 Spring, joka on käänteisohjaus (Inversion of Control) säiliö ja kääre Javaohjelmoinnissa. Spring-teknologian käyttö Grails-arkkitehtuurissa mahdollistaa myös Spring-teknologian muiden ominaisuuksien, kuten tietoturvan käytön erilaisten Grails-laajennuksien avulla. Jetty, joka on Grails-ohjelmistokehykseen upotettu servlet-säiliö (servlet container). Jetty-säiliö tarjoaa helpon ja nopean tavan ajaa ja testata Grails-ohjelmistokehyksellä tuotettuja web-sovelluksia. Vaikka Jetty-säiliö onkin upotettu Grails-ohjelmistokehykseen, pystyy Grails web-sovelluksia ajamaan myös muissa sovelluspalvelimissa ja säiliössä Kuva 3. Grails-ohjelmistokehyksen arkkitehtuuri 4.3 Grails web-sovelluksien rakenne Rocher, et al. (2009) mukaan Grails-ohjelmistokehyksellä toteutetut web-sovellukset rakentuvat erilaisista valmispohjaisista pääelementeistä kuten toimintoalueluokista (domain classes), hallintaluokista (controllers) ja GSP-näytöistä (Groovy Server Page). Näiden pääelementtien lisäksi sisältö voi rikastaa erilaisilla Web 2.0 ominaisuuksilla kuten AJAX-tekniikalla, lokalisoinnilla sekä muilla palveluilla, joihin Grails-ohjelmistokehys tarjoaa rajapinnat erilaisten laajennuksen kautta. Grails-ohjelmistokehystä käyttäen web-sovelluskehittäjien ei tarvitse aloittaa kehitystä aivan tyhjästä. Sen sijaan nykypäivän standardit toteuttavan web-sovelluksen voi toteuttaa tehokkaasti yhdistelemällä pääelementtejä ja rikastavia Web 2.0 ominaisuuksia. Kuvassa 4 on esitetty tyypillinen Grails web-sovelluksen ajonaikainen ympäristö. 18

24 Kuva 4. Grails web-sovellusten tyypillinen ajonaikainen ympäristö Toimintoalueluokat Rocher, et al. (2009) mukaan olio-ohjelmointikielillä toteutetuissa sovelluksissa on lähes aina jonkinlainen toimintoaluemalli (domain model), joka kuvaa sovellukseen liittyviä liiketoiminta yksiköitä (business entities). Tavallisesti liiketoiminta yksiköiden sisältämät tiedot tulee olla pysyviä, jonka johdosta ne tallennetaan oliorelaatiotietokantaan, joka mallintaa kyseistä toimintoaluemallia. Grails-ohjelmistokehyksessä kukin liiketoiminnan yksikkö voidaan esittää omana toimintoalueluokkana. Toimintoalueluokat ovat tavallisia Groovy-luokkia, jolla voi olla tietokenttiä kuvaamaan yksikön sisältöä, sekä liitoksia toisiin yksiköihin kuvastamaan yksiköiden välistä suhdetta. Grailsohjelmistokehys luo automaattisesti kutakin toimintoalueluokkaa varten oman tietokanta taulun ja yksiköiden sisäisiä tietoja voidaan tallentaa sovelluksissa käyttäen GORM tekniikkaa. Kehittäjän tarvitsee toteuttaa vain liiketoimintayksikköä vastaava Groovyluokat, määrittää mitä ja minkälaisia tietokenttiä kullakin on sekä mitkä ovat kyseisen toimintoalueluokan suhteet muihin toimintoalueluokkiin. Tämän jälkeen GORM osaa automaattisesti hoitaa loput tietokanta- ja olio-kartoitusasetukset ja toteutetut toimintoalueluokat ovat valmiita käyttöä varten. Hallintaluokat Rocher, et al. (2009) mukaan hallintaluokkien tarkoitus on toimia web-sovellukseen tulevien pyyntöjen käsittelijöinä. Kun hallintaluokka vastaanottaa pyynnön, se voi toteuttaa jotain pyyntöön liittyvää toiminnallisuutta, jonka jälkeen hallintaluokkaa päättää mitä web-sovelluksessa tulisi tapahtua seuraavana. Mahdollisia päätöksiä voisi olla esimerkiksi uudelleenohjata pyyntö toiselle hallintaluokalle, hahmottaa koko näyttö tai hahmottaa osa nykyisen näytön tiedoista. Hallintaluokkien elämänkaari on pyyntökohtainen, joka tarkoittaa sitä että kyseisestä hallintaluokasta luodaan uusi ilmentymä jo- 19

25 kaista tehtyä pyyntöä kohden. Rocher, et al. (2009) mukaan hallintaluokat ovat Grails web-sovellusten logiikan ydin, jotka muodostavat keskitetyn tiedonsidonta ja ohjauskoordinaation. Hallintaluokat ovat toimintoalueluokkien tapaan tavallisia Groovyluokkia, jotka sisältävät sille ominaiset tiedot, sulkeumat ja muut metodit, joita voi hyödyntää web-sovelluslogiikan toteuttamiseen. Kehittäjät voivat laatia useita eri hallintaluokkia ja jakaa täten web-sovelluksen logiikkaa eri osa-alueisiin helpomman ylläpidettävyyden nimessä. GSP-näytöt Rocher, et al. (2009) mukaan Java-pohjaisiin web-sovelluksia varten on olemassa lukuisia avoimen lähdekoodiin näyttöteknologioita. Yksi nykypäivän tunnetuimmista näyttöteknologioista on JSP (Java Server Pages), josta on tullut lähes standardi websovelluskehitykseen. JSP-teknologia mahdollistaa perinteisten merkkikieltä, kuten HTML:n ja Java-lähdekoodin sekoittamisen keskenään muodostaakseen dynaamisen näytön. JSP mahdollistaa myös erilaisten tag-kirjastojen käytön, joiden avulla logiikka voidaan erottaa JSP sivunäkymästä. JSP-teknologian yleisyydestä huolimatta Grailsohjelmistokehys tarjoaa Rocher, et al. (2009) mukaan oman GSP-näyttöteknologian seuraavista syistä: Grails web-sovellukset voivat saada täyden hyödyn irti käyttämällä omaa näyttöteknologiaa, joka on yhteensopiva Groovy-ohjelmointikielen ajonaikaiseen ympäristöön ja siihen liittyvään dynaamiseen metodikutsuntaan. Groovy-ohjelmointikielen GPath-ilmaisukieli, Groovy papunotaatiot sekä operaatioiden ylikirjoitusmahdollisuus tarjoaa tehokkaamman kehityspohjan. Groovy-ohjelmointikielen muut ominaisuudet kuten säännöllisten lausekkeiden (regular expression) tuki, GStrings-merkkijonot sekä tietorakenteiden käyttösyntaksi tukevat hyvin näyttöteknologioiden vaatimuksia. Rocher, et al. (2009) mukaan GSP-teknologia on hyvin samankaltainen JSP-teknologiaan verrattuna. GSP-teknologia mahdollistaa muun muassa JSP-teknologian tapaisen mekanismin luoda omia tag-kenttiä, joiden avulla logiikkaa ja dynaamista luonnetta voidaan tuoda näyttöihin. Tämän lisäksi merkkikielen ja Groovy-ohjelmintikielen yhdistäminen on mahdollista, mutta GSP-teknologia rohkaisee kehittäjiä käyttämään mieluummin tag-kirjastojen kenttiä. GSP-teknologia tukee JSP-teknologian tag-kenttiä, 20

26 mutta se myös tarjoaa lukuisia sisäänrakennettuja omia tag-kenttiä toteuttamaan monipuolista dynamiikkaa. Web 2.0 ominaisuudet Grails-ohjelmistokehys mahdollistaa lukuisten Web 2.0 ominaisuuksien hyödyntämisen web-sovelluksissa. Näitä ominaisuuksia ovat Rocher, et al. (2009) mukaan muun muassa AJAX-tekniikka (kuvattu tarkemmin luvussa 5.5), sivuston lokalisoiminen viestinippujen muodossa (message bundles) ja tilallisten palveluiden sekä prosessien tuottaminen Web Flow-tekniikalla. Myös lukuisia muita Web 2.0 ominaisuuksia on tarjolla Grails-ohjelmistokehykseen erilaisten laajennuksien kautta. 4.4 Grails kehitysalustana Rocher, et al. (2009) mukaan Grails ei ole vain web-sovellusohjelmistokehys, mutta myös kokonaisvaltainen kehitysympäristö tuottaa ja testata web-sovelluksia koko sen kehityselämänkaaren ajan. Grails tarjoaa komentorivi-rajapinnan ja joukon erilaisia komentorivi komentoja, joiden avulla voi suorittaa muun muassa kehitys-, kokoamis- ja testaamistehtäviä. Grails komentorivi-rajapinnan avulla voi muun muassa aloittaa uuden Grails web-sovellusprojektin, joka luo automaattisesti tarvittavan projektirakenteen ja pohjan. Tämän lisäksi Grails komentorivi-rajapinnan avulla voi luoda uusia toimintoalue- sekä hallintaluokkia, ajaa yksikkötestejä ja koota nykyisen projektin eri versioksi. Grails kehitysalustan avulla kehittäjien ei tarvitse opetella projektirakennetta, laatia alustavia perusasetuksia tai edes sisäisiä integraatioita eri komponenttien välille. Näiden sijasta kehittäjät voivat siirtyä suoraan toteuttamaan web-sovelluksia. Judd, et al. (2008) mukaan Grails komentorivi-rajapinta pohjautuu Gant-teknologiaan. Gant-teknologia taas pohjautuu Groovy-ohjelmointikieleen, jonka avulla tuotetaan Apache Ant-skriptejä projektin hallintatehtäviä varten. Tavallisesti Apache Ant-skriptit tuotetaan XML-rakennekielellä, mutta Judd, et al. (2008) mukaan Gant-teknologia on tehokkaampi ja helpommin lähestyttävä menetelmä. Gant-teknologian avulla projekteille voi asettaa erilaisia automaattisia tehtäviä kuten projektin käännös-, kokoamis- ja käyttöönottotehtäviä. Tällaisten tehtävien automatisointi lisää projektin ja sen julkaisujen yhdenmukaisuutta. Gant-teknologia on myös helposti laajennettavissa, joka mahdollistaa laajempienkin projektikohtaisten elämänkaaritoimintojen automatisoinnin. 21

27 Rocher, et al. (2009) mukaan Grails ei pyri sisällyttämään kaikkea web-sovelluksiin liittyviä ominaisuuksia ja tekniikoita itsessään. Sen sijaan Grails tarjoaa liitännäisjärjestelmän (plugin system), jonka avulla perusominaisuuksia ja tekniikoita pystyy laajentamaan tarpeen mukaan. Grails-ohjelmistokehyksen ydin onkin toimia liitännäisjärjestelmän ajoympäristönä ja kaikki tärkeimmät sisäänrakennetut ominaisuudet ydinominaisuuksia lukuun ottamatta ovat erilaisia valmiiksi asennettuja laajennuksia. Juuri asennettuun Grails-ohjelmistokehykseen on pakattu mukaan vain tärkeimmät laajennuksen, mutta mahdollisia muita asennettavia Grails-laajennuksia voivat olla Judd, et al. (2008) mukaan esimerkiksi tietoturva ja tunnistusominaisuudet, Ajax testaaminen, haku- tai raportointiominaisuudet ja web-palvelut. Rocher, et al. (2009) toteaa, että liitännäisjärjestelmä on Grails-ohjelmistokehyksen kulmakivi. Julkaistuja Grails-laajennuksia voi selata joko Grails komentorivi-rajapinnan kautta tai Grails-ohjelmistokehyksen virallisilla verkkosivuilla (SpringSource, 2009). 5 LIFT Lift-ohjelmistokehys on Chen-Becker, et al. (2009) mukaan vaihtoehtoinen ohjelmistokehys monien muiden vastaavien joukossa, mutta se tarjoaa muihin verrattuna uudenlaisen tehokkaan tavan ratkaista web-sovelluskehitykseen liittyviä tilanteita. Liftohjelmistokehys on toteutettu ja koottu tehokkaalle ja vakaalle pohjalle, ottaen parhaita ideoita muista ohjelmistokehyksistä ja lisäämällä joukkoon uudenlaisia ideoita. Chen- Becker, et al. (2009) toteaa myös, että Lift-ohjelmistokehyksen kehittäjät ovat suunnitteluvaiheessa pystyneet huomioon ja välttämään virheitä, jotka ovat vaivanneet aikaisempia ohjelmistokehyksiä. Ghosh, et al. (2009) mukaan Lift-ohjelmistokehyksen erityisiksi vahvuuksiksi voidaan laskea Scala-ohjelmointikielen kattava hyödyntäminen ja HTML-kaavarakenteiden prosessointi. Lift-ohjelmistokehys erottaa kaavarakenteiden esityslogiikan käsittelylogiikasta täysin estämällä HTML tag-kenttien suoran kartoituksen. Chen-Becker, et al. (2010) toteaa, että Lift-ohjelmistokehyksen luonnissa esitys- ja käsittelylogiikan erottaminen toisistaan oli yksi tärkeimmistä suunnitteluvisioista. Ghosh, et al. (2009) mukaan tag-kenttien kartoituksen sijasta Lift-ohjelmistokehys tarjoaa mahdollisuuden toteuttaa erilaisia hallinta- ja käsittelyosia, joita kutsutaan Lift-ohjelmistokehyksen ter- 22

28 meissä Snippet-komponenteiksi. Snippet-komponentit hyödyntävät Scala-ohjelmointikielen sulkeumia sitomaan kaavarakenteiden elementtejä ja tietosisältöjä sopiviin sijainteihin kullekin sivuilla. Kolmas tärkeä vahvuus Lift-ohjelmistokehyksessä on Chen- Becker, et al. (2010) mukaan AJAX- ja Comet-tekniikoiden tehokas hyödyntäminen. Näiden tekniikoiden avulla web-sovelluskehittäjät voivat tuottaa sivuille hyödyllisiä web 2.0 ominaisuuksia vähällä työvaivalla. Kuten Grails-ohjelmistokehys, myös Lift-ohjelmistokehys perustuu useampaan eri suunnittelumalliin ja periaatteeseen, joiden tarkoitus on tehostaa ja helpottaa ohjelmistokehitystä (Chen-Becker, et al., 2010): Ohjelmistokehittäjien tarvitsee konfiguroida vain hyvin vähän alustavia websovelluksen asetuksia, sillä Lift-ohjelmistokehys tarjoaa valmiit asetukset lähes kaikkeen. Asetusten muokkaaminen on kuitenkin tehty helpoksi, sillä se vaatii vain muutaman tiedon muokkaamista XML-pohjaiseen tiedostoon ja loppujen asetusten kirjoittamista selkeisiin Scala-luokkiin. Ohjelmistokehittäjiä rohkaistaan toteuttamaan sivut näyttö-ensin (View-First) mallia käyttäen, koska Lift-ohjelmistokehys erottaa esitys- ja käsittelylogiikan täysin toisistaan. Kehittäjillä on kuitenkin paljon valinnanvara toteuttaa eri näytöt. Lift-ohjelmistokehys ei pakota web-sovelluskehittäjiä käyttämään vain yhdenlaista tapaa toteuttaa toiminnallisuuksia, vaan useita se tarjoaa erilaisia menetelmätapoja eri toiminnallisuuksia web-sovelluksiin. Web-sovelluskehittäjät voivat valita parhaaksi kokemansa tavan toteuttaa eri asiat. 5.1 Scala-ohjelmointikieli Lift-ohjelmistokehys pohjautuu Scala-ohjelmointikieleen (Chen-Becker, et al., 2009). Scala-ohjelmointikieli on Groovy-ohjelmointikielen tapaan vielä hyvin nuori ohjelmointikieli, joka tuottaa Java-virtuaalikoneeseen soveltuvaa tavukoodia. Pollak (2009) mukaan Scala-ohjelmointikieli on funktionaalispainoteinen olio-ohjelmointikieli, joka mahdollistaa myös imperatiivipohjaisen lähestymistavan ohjelmointiin. Scala-ohjelmointikieli kuitenkin rohkaisee ohjelmoijia tuottamaan ratkaisut funktionaalispainotteisesti, joka on yksi merkittävä tekijä, joka on nostanut Scala-ohjelmointikielen suureen 23

29 suosioon (Ghosh, et al., 2009). Erityisesti web-sovelluskehityksessä funktionaalispainotteinen lähestymistapa pystyy tarjoamaan imperatiivipohjaista lähestymistapaa tehokkaamman ja turvallisemman tavan toteuttaa esimerkiksi palvelinpäätyjä. Ghosh, et al. (2009) mukaan funktionaalispainotteisen lähestymistavan tarjoama erilainen abstraktiotaso tukee paremmin web-sovelluskehityksen vaatimuksia. Esimerkiksi funkionaalinen abstraktiotaso tukee paremmin palvelin- ja asiakaspäätytoteutuksien välistä pyyntö/vastauselämänkaarien käsittelyä ja kuvausta, erilaisten kaavarakenteiden (form) sisältöjen kartoitusta lähdekoodissa sekä tiedonesitys- ja sovelluslogiikan erottamista toisistaan. Kaisler (2005) mukaan funktionaalisen ohjelmoinnin päätarkoitus on tarjota ohjelmoijalle joukko funktioita ja toiminnallisuuksia ja esittää kaikki tieto mahdollisimman muuttumattomana. Funktionaalisen ohjelmoinnin paradigmassa ohjelma saa syötteen, jonka se käsittelee ja palauttaa siitä muodostuneen vastauksen. Funktiot ovat yksittäisiä ohjelman osia, jotka eivät vaikuta muihin ohjelman osiin tai tiloihin, vaan ne ainoastaan ottavat vastaan syötteen ja palauttavat vastauksen. Funktionaalisen ohjelmoinnin paradigma voidaan täten nähdä imperatiiviseen ohjelmointiin nähden vähemmän virhealttiina. Kuitekin algoritmien kehittäminen funktionaalista paradigmaa käyttäen on haastavampaa (Odersky, et al., 2008). Ghosh, et al. (2009) mukaan Scala-ohjelmointikielellä on useita ominaisuuksia, joiden ansiosta se on yksi vahvimpia valintoja vaihtoehtoisten JVM-pohjaisten ohjelmointikielten joukossa. Scala-ohjelmointikielen vahvuudet Java-ohjelmointikieleen verrattuna ovat (Ghosh, et al., 2009): Laajennettavuus, esimerkiksi tuki tietorakenteiden rakentamiseen erilaisten sekoituksien (mixins) ja itsetyypitys-annotaatioiden (self-type annotations) avulla. Staattinen ankkatyypitys (statically checked duck typing) rakennetyypityksen avulla, joka toimii kuten dynaamisissa ohjelmointikielissä, mutta on tyyppisuojattu. Korkeammanasteiset funktiot (higher-order functions), joita voidaan syöttää toisille funktioille parametreina ja joita voidaan vastaanottaa palautustyyppeinä. Scala-ohjelmointikieli mahdollistaa sulkeumien käytön, mikä helpottaa abstraktien kontrollitoiminnallisuuksien toteuttamista ja toimintoalueominaista ohjelmointia. 24

30 Muuttumattomat tietorakenteet on sisällytetty osana pääkirjastoa, mikä rohkaisee kehittäjiä suunnittelemaan viittausläpinäkyviä abstrahointeja (referentially transparent abstractions). Kehittyneemmät generointirakenteet, esimerkiksi for-silmukkan sisäinen suodatusmekanismin joustava toteutus, mikä tekee koodista selkeämpää ja ytimekkäämpää. Abstraktien tietorakenteiden mallitäsmäys (pattern matching). Scala-ohjelmointikielessä mallit ovat funktioiden osia, joita ohjelmistokehittäjät voivat laatia erilaisten yhdistäjien (combinators) avulla ja rakentaa laajennettuja abstrahointeja. Tapausvetoinen (event-driven) ohjelmointi toimijamallia (actor model) käyttäen. Tällaisen kevyen abstraktion avulla voidaan mallintaa skaalatutuvia vuorovaikutteisia järjestelmiä ilman tarvetta käyttää monimutkaisia käänteisohjausmalleja (inversion of control model), esimerkiksi kuuntelijoita ja takaisinkutsujia (callback). Ghosh, et al. (2009) kuvaa Scala-ohjelmointikielen syntaksin kevyenä, ilmaisuvoimaisena ja ytimekkäänä sen erilaisten rajapintaratkaisujen ja sulkeumaominaisuuksien ansiosta. Kappaleessa 4.1 esitetty tehtävä olisi Scala-ohjelmointikielellä toteutettuna liitteen Y3 mukainen. Liitteestä Y3 voi havaita Scala-ohjelmointikielen funktionaalispainotteisen piirteen, esimerkiksi siitä, miten listojen satunnainen kokonaislukusisältö toteutetaan ja kuinka listojen läpikäyminen on toteutettu verrattuna Java- ja Groovyohjelmointikieliin. 5.2 Rakenne ja arkkitehtuuri Chen-Becker, et al. (2009) mukaan Lift-ohjelmistokehys voidaan esittää viisitasoisena arkkitehtuuritoteutuksena. Arkkitehtuurin kolme alinta tasoa ovat Java-virtuaalikone, Java Enterprise Edition-ohjelmistokehyksellä (JEE) toteutettu web-säiliö sekä Scalaohjelmointikielen alusta. Näiden tasojen päällä on itse Lift-ohjelmistokehys, jonka päällä toimii sillä toteutetut web-sovellukse kuvan 5 esittämällä tavalla. Lift-ohjelmistokehys sisältää lukuisia komponentteja ja apuluokkia, jotka yhdessä tarjoavat monipuolisen kokonaisuuden rakentaa ja käsitellä erilaisia web-sovelluskohtaisia toiminnalli- 25

31 suuksia. Lift-ohjelmistokehyksen tärkeimmät komponentit ja niiden lyhyet kuvaukset on esitetty seuraavana (Chen-Becker, et al., 2009): LiftCore-komponentti on Lift-ohjelmistokehyksen ydin ja sen tarkoitus on muun muassa käsitellä web-sovellusten pyyntöjen ja vastausten elinkaaret, hahmotuskanavointi (rendering pipeline) ja kutsua käyttäjäkohtaisia toimintoja. Kaikki muut Lift-ohjelmistokehyksen toiminnallisuudet toimivat LiftCorekomponentin kautta. SiteMap-komponentti sisältää web-sovellusten sivut, sekä valikkokartoituksen niiden välille. Tämän lisäksi komponentti tarjoaa sivutasoisen pääsyhallinta mekanismin, jonka avulla voi hallita mille sivuille kukin käyttäjä voi päästä. Mekanismi mahdollistaa myös pyynnön uudelleenkirjoittamisen (request rewrite) ja tilariippuvaisen (state-dependent) laskennan. LiftRules-komponentin avulla Lift:n yleiset asetukset voidaan määrittää. LiftSession-komponentin avulla hallitaan web-istuntojen tiloja. S-komponentti on tilallinen olio, joka kuvaa tilan kontekstia pyyntö/vastauselämänkaaressa. Web-istunnon tila tallennetaan S-olioon muuttujina. SHtml-komponentti sisältää hyödyllisiä XHTML-elementien käsittelytoimintoja ja apufunktioita. Views-komponentin luokilla näytöt voidaan kuvata XML-sisältönä. LiftResponse-komponentti kuvaa vastauksen abstraktiota, joka välitetään asiakkaalle. Comet-komponentti kuvaa Comet-toimijakerrosta, joka mahdollistaa asynkronisen sisällön lähettämisen web-palvelimelta asiakkaan selaimeen. Mapper/Record ORM Framework-komponentti on kevyt oliorelaatiokirjasto. Mapper-kehys on ollut käytössä Lift-ohjelmistokehyksen aikaisemmassa versiossa (1.0), mutta myöhemmin se on korvattu Recoard-kehyksellä. Tällä kirjastokomponenteilla web-sovellukset voivat hyödyntämään oliorelaatiotietokantoja. HTTP Authentication-komponentti tarjoaa tavan toteuttaa HTTP-tunnistuksen. JavaScript API-komponentti tarjoaa abstraktiokerroksen hyödyntää JavaScriptkieltä. Tämä komponentti sisältää Scala-luokkia ja olioita, jotka abstrahoivat JavaScript artefakteja. Utilities-komponentti sisältää lukuisia apufunktioita. 26

32 Kuva 5. Lift-ohjelmistokehyksen arkkitehtuuri 5.3 Snippet-komponentit Chen-Becker, et al. (2010) mukaan Lift-ohjelmistokehyksessä hyödynnetään Apache Wicket-sivupohjajärjestelmää (templating system), joka perustuu XML-rakenteiden käsittelyyn. Lift-ohjelmistokehyksen Wicket-sivupohjajärjestelmä hyödyntää kattavasti Scala-ohjelmointikielen XML-tukea ja mahdollistaa sisäisten sivupohjien sekä Snippetkomponenttien käytön. Snippet-komponentit ovat itsenäisiä logiikaosia, joita lisätään sivuille tuottamaan erilaisia sivuhahmotuksia ja jotka ovat Lift-ohjelmistokehyksen selkäranka näyttö-ensin hahmotusarkkitehtuurissa. Ne tuottavat sisään syötetystä XMLtiedoista ulostulevaa XML-dataa muuntamalla ja kartoittamalla tietosisällön. Snippetkomponentteja voidaan hyödyntää esimerkiksi web-sovellusten kaavarakenteiden käsittelyssä ja hahmotuksessa, ja niiden käyttäminen mahdollistaa myös web-sivujen tiedonesityksen ja käsittelylogiikan erottamisen toisistaan. Toteutukseltaan Snippetkomponentit ovat tavallisia Scala-luokkia, joiden sulkeumia voidaan kutsua sivupohjatoteutuksissa. 27

33 5.4 Toimijamalli Odersky, et al. (2008) mukaan Scala-ohjelmointikieli tarjoaa vaihtoehtoisen säieohjelmointimallin, joka pohjautuu toimijoihin (Actors) ja se on saanut vaikutteita muun muassa Erlang-nimisestä ohjelmointikielestä. Java-ohjelmointikielen sisäänrakennettuun säieohjelmointimalliin verrattuna Scala-ohjelmointikielen toimijamalli on Odersky, et al. (2008) mukaan kevyempi ja helpompi toteuttaa sekä ylläpitää. Java-ohjelmointikielessä monisäikeinen toiminnallisuus tarkoittaa sitä, että olioihin on liitetty looginen monitorointi tarkastelemaan niiden keskinäistä synkronista tilaa. Ajonaikana Javavirtuaalikone asettaa ja avaa lukkoja tietoihin siten, että vain yksi säie saa kerrallaan pääsyn synkronoituun tietoon. Tässä mallissa erityinen haaste ohjelmoijilla on ymmärtää, mitä tietoa mikin ohjelmankohta käyttää ja muokkaa, jotta tietojen yhtenäisyys ei rikkoontuisi eikä mahdollisilta kuolonlukkoja (dead lock) syntyisi. Näiden lisäksi testaaminen on epäluotettavaa, koska säikeiden toimintajärjestys on epädeterministinen (Odersky, et al., 2008). Odersky, et al. (2008) mukaan toimijamalli perustuu asynkroniseen viestinsiirtomalliin, jossa kukin toimija on säikeenoloinen elementti, jolla on oma tila. Kukin toimija toimii itsenäisenä tilallisena elementtinä, mutta ne voivat myös toimia keskenään lähettämällä toisilleen asynkronisia viestejä. Toimijoiden tilaa ei kuitenkaan jaeta muiden säikeiden kesken kuten Java-ohjelmointikielen säiemallissa, vaan toimijan tilaa pystyy muuttamaan vain lähettämällä viestejä sille. Kullakin toimijalla on myös oma viestilaatikko, jossa ne säilyttävät ja lukevat vastaanotettuja viestejä yksikerrallaan. Viestilaatikon avulla lähetettyjen viestin saapumisjärjestyksellä ei ole väliä, eikä vastaanotetut viesti keskeytä toimijaa millään tavalla. Kun toimija lukee viestilaatikostaan saapuneen viestin, se vertaa viestin rakennetta Scala-ohjelmointikielen mahdollistaman mallitäsmäyksen avulla. Mikäli viesti vastaa jotain mallitäsmäyksen tyyppiä, niin toimija käsittelee viestin ja välittää sen sopivalle funktiolle. Vaikka toimijamalli perustuukin asynkroniseen viestinvälitykseen, Ghosh, et al. (2009) mukaan se kykenee se myös toimimaan synkronisesti tarpeen mukaan. Scala-ohjelmointikielen toimijat ovat kevyitä tapausolioita (event objects), jotka soveltuvat web-sovelluskehitykseen paremmin kuin Javaohjelmointikielen sisäänrakennettu säiemalli erityisesti niiden keveyden ja skaalatutuvuuden ansiosta. Tästä syystä Lift-ohjelmistokehys hyödyntää Scala-ohjelmointikielen toimijamallia kattavasti, erityisesti Comet-ohjelmoinnissa. 28

34 5.5 AJAX- ja Comet-ohjelmointi Chen-Becker, et al. (2010) mukaan Lift-ohjelmistokehys mahdollistaa sekä AJAX- (Asynchronous JavaScript And XML) että Comet-tekniikoden käytön tuottamaan rikkaita Web 2.0 sovellusominaisuuksia. AJAX- ja Comet-tekniikoista on tullut viime vuosina hyvin suosittu lähestymistapa rikkaiden ja dynaamisten web-sovelluksien toteuttamiseen. AJAX- ja Comet-tekniikat ovat vaihtoehto perinteiselle web-sovellusten pyyntö/vastauselinkaarimallille. Perinteisessä mallissa web-sovelluksen käyttäjän toiminto, esimerkiksi hiiren klikkaaminen painikkeen päällä, luo pyynnön, joka lähetettään palvelimelle. Palvelin vastaanottaa pyynnön, käsittelee sen ja palauttaa sitä vastaavan vastauksen web-sovellukselle, joka hahmotetaan selaimelle. Tämän kierron jälkeen pyyntö/vastauselinkaari on päättynyt ja uusi vastaava elinkaari aloitetaan käyttäjän seuraavasta toiminnosta. Kuvassa 6 on esitetty perinteisen pyyntö/vastauselinkaaren sovellusmalli. AJAX- ja Comet-tekniikat laajentavat tätä perinteistä mallia tarjoamalla asynkronisen päivityksen jompaankumpaan suuntaan palvelin-asiakas linjassa. AJAXtekniikassa asynkroninen päivitys on asiakkaalta palvelimelle ja Comet-tekniikassa päivitys on palvelimelta asiakkaalle. Kummassakin tapauksessa päivitys ei ole sidottu palvelimelta saatuun vastaukseen, kuten perinteisessä mallissa vaan päivitys tapahtuu taustalla. Kuva 6. Perinteinen web-sovellusten pyyntö/vastaus sovellusmalli Chen-Becker, et al. (2010) mukaan AJAX-tekniikassa käyttäjän toiminto web-sovelluksessa lähetetään taustapyyntönä palvelimelle. Palvelin käsittelee taustapyynnön ja lähettää JavaScript-sirpaleen (fragment) päivittämään asiakaspäädyn sivuston DOMpuurakennetta (Document Object Model). Tämä saa aikaan web-sovelluksen päivitty- 29

35 misen nykyisen sivun yksittäisiin kohtiin ilman tarvetta päivittää koko sivua. Kuvassa 7 on esitetty AJAX-tekniikan sovellusmalli. Kuva 7. AJAX sovellusmalli Chen-Becker, et al. (2010) mukaan Comet-tekniikka lisää perinteiseen sovellusmalliin pitkäkestoisen HTTP-pyynnön ylläpitäjän (long-polling HTTP request). HTTP-pyynnön ylläpitäjä toimii taustalla ja sen avulla palvelin voi syöttää asiakaspäätyyn tietoa ilman, että asiakkaan tulisi erikseen pyytää sitä. Comet-tekniikan avulla palvelin pystyy syöttämään pävitykset kaikkien samalla sivulla olevien asiakkaiden näkymiin. Kuvassa 8 on esitetty Comet-tekniikan sovellusmalli. Suurin haaste Comet-ohjelmoinnissa on huomioida skaalautuvuus palvelimen päässä. Kuva 8. Comet sovellusmalli 30

36 Chen-Becker, et al. (2010) mukaan Lift-ohjelmistokehykseen sisäänrakennettu Comettekniikka pohjautuu Scala-ohjelmointikielen toimijamalliin. Toimijat pohjautuvat Erlang6-ohjelmointikielen toimijamalliin, jossa kukin toimija on asynkroninen komponentti, joka voi vastaanottaa tai lähettää viestejä vastatakseen vastaanotettuihin viesteihin. Scala-ohjelmointikielen toimijamalli kuitenkin eroaa Erlang6-ohjelmointikielen konseptista sillä, ettei se ole ohjelmointikieleen rakennettu ominaisuus, vaan kirjastokokonaisuus. Scala-ohjelmointikielen toimijamalli on myös paljon skaalatutuvampi, sillä toimijoilla ei ole yksi-yhteen suhdetta ohjelmasäikeiden kanssa. Chen-Becker, et al. (2010) mukaan tästä on hyötyä esimerkiksi siinä ettei säikeet jää lukkoon tilanteissa joissa toimijat odottavat jotain viestiä toiselta toimijalta. Yksi-yhteen suhteen sijasta kunkin toimijan runko ja laskenta sisällytetään sulkeumiin, jotka tallennetaan sovelluksen välimuistiin. Kun sopiva viesti ilmestyy toimijalle, se suorittaa sulkeumaan sisälletyn laskennan ja toiminnallisuuden. Tämän ansiosta Lift-ohjelmistokehykseen toteutettu Comet-tekniikka on hyvin skaalautuva. 6 VERTAILU Grails- ja Lift-ohjelmistokehyksillä on erilainen lähtökohta, mutta molemmat pyrkivät samaan päämäärään: Vähentämään kehittäjien taakkaa tuottaa rikkaita web-sovelluksia. Tavoite on myös tehostaa kehitysprosessia, nopeuttamalla eri vaiheita ja mahdollistaa joustavat muutokset salliva ohjelmistoprosessimalli. Empiirinen Grails- ja Liftohjelmistokehysten vertailu suoritetaan toteuttamalla vaiheittain kehitettävä websovellus molemmilla web-sovellusohjelmistokehyksillä. Molemmat websovellustoteutukset ovat omia toteutuksia, jotka valmistuttuaan tulee pystyä siirtämään kehitysympäristöstä viralliseen ajoympäristöön. Tällä lähestymistavalla halutaan mallintaa todellisen ohjelmistokehityksen loppuvaiheessa olevaa tuotantoympäristöön siirtymistä. Tutkielmassa luotava web-sovellusprojekti on nimeltään Luma. Tässä luvussa oletetaan että kaikki tarpeelliset teknologiat ja ohjelmistokehykset on asennettu käyttökuntoon. Käytössä on Grails-ohjelmistokehyksen versio 1.35 ja Liftohjelmistokehyksen versio 2.1. Web-sovelluskehysten lisäksi käytössä on useita muita teknologioita, kuten tietokanta ja servlet-säiliö, jotka on tarkoitus olla molemmilla toteutuksilla samat lopullisessa versiossa. Kuitenkin kehityksen aikana eri ohjelmistoke- 31

37 hyksillä voi olla käytössä omat kehitysajan teknologiat nopeuttaakseen evolutiivista protoilua. Molemmissa sovelluksissa lopullinen tietokanta on MySQL 5.1-pohjainen oliorelaatio-toteutus ja käytettävä servlet-säiliö on Apache Tomcat versio Yleiskuva kehitettävästä web-sovelluksesta Kehitettävän web-sovelluksen on tarkoitus olla dynaamisesti päivitettävä verkkosivu, jossa on lukuisia eri kategorioita ja alikategorioita kuvastamaan erilaista tietosisältöä. Vierailevien käyttäjien tulee pystyä selaaman ja lukemaan verkkosivun kaikkia julkisia sivuja, mutta sivustolla tulee olla myös sisäänkirjautumistoiminnallisuus. Sivustoa ylläpitävien käyttäjien tulee pystyä kirjautumaan järjestelmään sisään, jonka kautta he voivat muokata verkkosivun tietosisältöä. Verkkosivuston tulee myös mahdollistaa monikielisyystuki kahdelle eri kielelle, jotka ovat englanti ja suomi. Näiden perustoiminnallisuuksien lisäksi verkkosivulla tulee olla joitain interaktiivisia ja rikastavia Web 2.0 ominaisuuksia kuten WYSIWYG-editori (What You See Is What You Get), jonka avulla ylläpitävät käyttäjät laativat ja muokkaavat verkkosivujen tietosisältöjä. Tarkemmat kuvaukset halutuista ominaisuuksista esitetään niiden toteutuksien yhteydessä. Web-sovelluksen kehitys jaetaan kolmeen vaiheeseen, ja kukin vaihe voi sisältää oman tarvittavan määrän iteraatiota. Ensimmäisessä vaiheessa web-sovellusprojekti aloitetaan ja web-sovellukseen laaditaan sivuston pohjarakenne ja ulkoasu sekä jokunen linkki viemään toiselle sivulle. Tässä vaiheessa kukin sivu on staattinen HTML-sivu, jossa ainut interaktiivisuus on linkitykset sivujen välillä. Toisessa vaiheessa sivustolle laaditaan jokunen interaktiivinen toiminnallisuus, kuten sisäänkirjautuminen ja yksinkertainen palautteenanto- ja selaustoiminnallisuus. Tässä vaiheessa sivustolle laaditaan myös monikielisyystuki ja autentikaatiotoiminnallisuus, jonka tarkoitus on rajoittaa vierailevia käyttäjiä pääsemästä suljetuille sivuille. Projektin kolmannessa vaiheessa suunnitellaan ja toteutetaan verkkosivun dynaaminen luonne. Dynaamisuuteen liittyy toiminnallisuus, jossa sisäänkirjautunut käyttäjä voi muokata web-sovellukseen kuuluvien sivujen tietosisältöä. Ainoastaan verkkosivun päärakenne ja kategoriat ovat staattisia. Sivut ovat muokattavissa hyvin määriteltyjen sääntöjen ja pohjarakenteiden mahdollistamalla tavalla. Yksittäisten sivujen muokkaamisominaisuuden lisäksi sisäänkirjautuneen käyttäjän tulee pystyä myös dynaamisesti lisäämään kullekin sivulle alisivuja, joiden tietosisältö tulee myös olla muokattavissa. 32

38 6.2 Ensimmäinen vaihe Web-sovelluskehityksen ensimmäinen vaihe sisältää staattisen sivun pohjarakenteen ja ulkoasun toteuttamisen, mutta siihen liittyy myös yleiset projektin aloitustoimenpiteet. Näitä aloitustoimenpiteitä ovat projektin ja projektirakenteen luominen, sekä ajonaikaisten ympäristöjen käyttökuntoon laitto. Ensimmäisen vaiheen tarkoitus on saada toteutettu jotain näkyvää ja interaktiivista hyvin nopeasti. Tavallisesti projektin alustaminen on hyvin työlästä, mikäli projektit tulee aloittaa aivan tyhjästä. Edessä on monen eri teknologian, tekniikan ja kehitysympäristön yhdistäminen. Grails- ja Lift-ohjelmistokehykset tarjoavat yksinkertaisen tavan saada projektit kehitysvaiheeseen hyvin vähällä työmäärällä Projektin alustaminen Grails-ohjelmistokehystä käyttäen projekti ja sen rakenne voidaan alustaa käyttämällä sen tarjoamaa komentorivi-rajapintaa ja kirjoittamalla komento: grails create-app luma (Judd, et al., 2008). Tämä komento luo valmiin projektirakenteen ja sisällyttää mukaan oletusarvoiset asetukset, sekä alustaa ajonaikaisen ympäristön automaattisesti. Grails-projekteissa oletusarvoisesti kehitysaikaisena ajoympäristönä toimii jetty-säiliö ja luodun web-sovelluksen voi käynnistää käyttämällä komentoa: grails run-app projektin hakemistorakenteen sisällä. Lift-ohjelmistokehyksessä ei ole Grails:in tapaan sisäänrakennettua komentorivi-rajapintaa, mutta sen sijaan Lift hyödyntää suosittua Apache Maven-teknologiaa projektin hallintatoiminnoissa (Chen-Becker, et al., 2009). Apache Maven-teknologia tarjoaa komentorivi-rajapinnan ja lukuisia toimintoja sekä projekti- ja riippuvuushallintamekanismin. Apache Maven-teknologialla voi muun muassa luoda uuden käyttövalmiin Liftprojektipohjan seuraavanlaista komentoa käyttäen: mvn archetype:generate -U \ -DarchetypeGroupId=net.liftweb \ -DarchetypeArtifactId=lift-archetype-blank \ -DarchetypeVersion=2.0 \ -DarchetypeRepository=http://scala-tools.org/repo-releases \ -DgroupId=fi.luma \ -DartifactId=luma \ -Dversion=1.0-SNAPSHOT 33

39 Kyseinen Maven-komento suorittaa pitkän toimintosarjan, jossa Lift-ohjelmistokehyksen omasta www- tietosäiliöstä (repository) haetaan tarvittavat riippuvuudet ja muodostetaan ajokuntoinen web-sovellusprojekti, jossa lähes kaikki on oletusarvoisesti asennettu valmiiksi. Luodun projektin voi käynnistää kutsumalla Maven-komentoa: mvn jetty:run. Tämä komento alustaa web-sovelluksen käyttämään jetty-säiliötä ajonaikaisena ympäristönä. Molemmat ohjelmistokehykset tarjoavat nopean ja samanlaisen tavan aloittaa websovellusprojektit ja luodut projektirakenteet ovat hyvin järjesteltyjä ja nimettyjä, ja ne pohjautuvat yleisiin web-sovelluksen rakenne- ja nimeämismenetelmiin. Grailsprojektirakenne on kuitenkin kattavampi alusta lähtien, koska sen tarkoitus on tarjoa mahdollisimman paljon valmista. Grails-projektirakenne sisältää muun muassa valmiit kansiot ja konfiguraatiot lokalisointiin, CSS-tyylimäärityksiin, tietokantayhteyksiin ja testeihin. Lift taas pyrkii luomaan vain kaikista oleellisimmat kansiorakenteet ja konfiguraatiot ja antaa kehittäjien itse päättää miten muut konfiguraatiot ja resurssit järjestetään projektissa. Grails projekteja voidaan täten pitää enemmän yhdenmukaistettuina, joka on hyvä lähtökohta erityisesti aloittelijoiden kannalta sekä tilanteissa, jossa projektin kehittäjät voivat vaihtuvat sen kehityskaaren aikana. Molempien ohjelmistokehysten komentorivi-rajapintoja voi hyödyntää samalla tavalla projektinhallinta toimintoihin. Grails:in komentorivi-rajapinta on kuitenkin aloittelijaystävällisempi ja joustavampi koska sitä voi laajentaa omien tarpeiden mukaan. Vaikka Grails:in sisäänrakennettu komentorivi-rajapinta onkin helpompi omaksua ja käyttää, on sen käyttöaste rajoitetumpi, sillä se toimii vain ja ainoastaan Grails-ohjelmistokehysprojekteissa. Apache Maven komentorivi-rajapinta on yleiskäyttöisempi, sillä sitä voi hyödyntää lähes kaikenlaisissa muissa projekteissa ja kolmannen osapuolen kehittäjät voivat laatia uusia Lift-arkkityyppimäärityksiä erilaisten Lift-projektin aloittamisen helpottamiseksi Verkkosivupohjan toteuttaminen Toteutettava verkkosivun tulee olla mahdollisimman yksinkertainen ja helposti navigoitava loppukäyttäjälle. Verkkosivun pohjarakenteeksi on valittu kuvan 9 mukainen pohjamalli. Tässä mallissa verkkosivu koostuu kuudesta eri toiminnallisuuden alueesta, jotka keskitetään selainikkunan keskellä, siten että verkkosivun kummallakin sivulle jätetään tyhjää. Tärkeimmät verkkosivun osat on selitetty lyhyesti alla: 34

40 Ylävalikko on tarkoitettu sisältämään sisäänkirjautumistoiminnallisuudet, monikielisyystoiminnallisuudet sekä muut yleiset sivunhallinta ominaisuudet. Banneri-osio sisältää sivuston yleiskuvastavat tunnukset ja mahdolliset mainokset. Päävalikko sisältää linkit kaikkiin sivuston pääkategorianäkymiin. Kullakin pääkategorianäkymällä on joukko alikategorioita, jotka listataan navigaatiovalikossa. Navigaatiovalikko sisältää yksilölliset pääkategorianäkymän alikategoriat. Näiden linkkien kautta hallitaan verkkosivun tietosisältönäkymää. Sisältö-osio koostuu kunkin sivun tietosisällöstä. Alatunniste sisältää yleiset verkkosivun tiedot ja muutaman mahdollisen interaktiivisen toiminnallisuuden kuten palautteen antamisen ja selaamisen. tyhjää ylävalikko tyhjää banneri päävalikko navigaatiovalikko sisältö linkki 1 linkki 2 linkki 3 alatunniste Kuva 9. verkkosivun pohjamalli Valitun pohjamallin tapauksessa ylävalikko, banneri- ja alatunnisteosat ovat staattisia verkkosivukomponentteja, jotka näyttävä samalta missä tahansa verkkosivun tilassa. Grails-ohjelmistokehyksessä staattiset verkkosivukomponentit voi toteuttaa yksittäisinä GSP-sivuina, jotka hahmotetaan verkkosivulle haluttuihin kohtiin käyttämällä <g:render> GSP-tag kutsua (Judd, et al., 2008). Banneri-komponenti on toteutettu omaksi div-elementiksi, jonka sisällä on kaksi verkkosivun logoa, jotka toimivat linkkeinä. Liitteessä G1 on esitetty banneri-komponentin GSP-toteutus. Grails-ohjelmistokehyksessä sivuston pohjarakenne voidaan toteuttaa yhteen GSP-sivuun, jota nimitetään tässä projektissa main.gsp sivuksi. Pääsivuun voidaan liittää irralliset GSP-sivujen toteutukset sekä asettaa erilaisia dynaamisia GSP-tageja. Dynaamisia GSP-tageja ovat muun muassa <g:layoutbody/> ja <g:layouttitle/> ja niitä käytetään Judd, et al. (2008) mukaan fuusioimaan useita eri HTML-sivutoteutuksia yhdeksi kokonaisuudeksi. Liitteessä G2 on esitetty pääsivun toteutus, josta voi muun muassa nähdä miten eri staattisia verkkosivukomponentteja kutsutaan ja kuinka dynaamiset GSP-tagit on ase- 35

41 tettu. Verkkosivun sisältö osiosta löytyy vain <g:layoutbody/> kenttä, jonka tehtävä on fuusioida näytettävien HTML-sivurakenteiden <body> kentän sisältö kyseiseen kohtaan. Tämän avulla muuttuva tiedonsisältö esitetään aina samassa kohtaa verkkosivulla. Lift-ohjelmistokehyksessä web-sovellusten sivurakenteet ovat XHTML-sivutoteutuksia (Chen-Becker, et al., 2009). Tämän tekniikan avulla sivuston pohjarakenne on helppo toteuttaa irrallisina sivupohjina, jotka jälkeenpäin voidaan yhdistää pääsivurakenteeseen. Lift:in sivupohjamekanismi on hyvin samanlainen Grails:iin verrattuna, mutta se tarjoaa useamman eri lähestymis- ja toteutustavan, joka tekee siitä joustavamman kokonaisuuden. Esimerkiksi kehittäjät voivat laatia sivupohjia joko XML-pohjaisina rakenteina tai ohjelmateitse, jolloin sivupohjan XML-rakenne generoidaan dynaamisesti ajonaikana. Lift-ohjelmistokehys tarjoaa joukon valmiita tag-kenttiä, joiden avulla sivupohjarakenteen voi toteuttaa, mutta kehittäjät pystyvät myös helposti luomaan omia tag-kenttiä vastaavia Snippet-komponentteja. Tämän projektin verkkosivupohjan toteuttamisen kannata tärkeimmät Lift-ohjelmistokehyksen sisäänrakennetuista tagkentistä ovat <lift:surround/>, <lift:embed/> ja <lift:bind>. Chen-Becker, et al. (2009) mukaan <lift:surround/> on ylin sitojakenttä, joka upottaa kaikki sen sisällä olevat XML-rakenteet voidaan haluttuun kohtaan toista sivupohjarakennetta, jonne sen vastakenttä <lift:bind> on lisätty. Kolmas tag-kenttä <lift:embed/> mahdollistaa staattisten sivupohjien upottamisen toisiin sivupohjiin. Esimerkiksi ylävalikko, banneri- ja alatunnisteosat on toteutettu irrallisiksi sivupohjiksi ja ne liitetään pääsivutoteutukseen <lift:embed/> kenttää käyttäen. Kuvassa 10 on esitetty esimerkki Lift:in sivupohjamekanismin hyödyntämisestä kun käyttäjä navigoi URLosoitteeseen: /luma/main/frontpage. Esimerkissä syötetyn URL-osoitteen takana on vain itse tietosisältötoteutus, joka liitetään automaattisesti haluttuun kohtaan default.html nimistä pääsivurakennetta. Tämä lisäksi frontpage.html ja default.html pohjarakenteet sisältävät myös upotettuja staattisia sivupohjarakenteita banner, footer ja sidebar.html. Liitteissä L1 L3 on esitetty banner.html, frontpage.html ja default.html sivupohjarakenteiden toteutukset. 36

42 Kuva 10. Lift sivupohjamekanismi sisäänrakennetuilla tag-kentillä Molemmissa ohjelmistokehyksissä verkkosivupohja on hyvin helppo toteuttaa teknisesti. Perusidea on toteuttaa yksi tai useampi pohjamalli, johon upotetaan staattisia tai dynaamisia elementtejä haluttuihin kohtiin. Molemmissa ohjelmistokehyksissä sivupohjat toteutetaan tavallisesti HTML-tyylisinä rakenteina joissa voi hyödyntää kehittyneitä tag-kirjastoja luomaan dynaamista sisältöä. Ohjelmistokehyksissä sivupohjien hierarkkinen lähestymistapa on kuitenkin vastakkainen. Grails-ohjelmistokehyksessä sivuston pääelementti on itse pääsivupohja, johon upotetaan tietosisältösivu ja muut sivupohjat. Lift-ohjelmistokehyksessä sivuston pääelementti on taas tietosisältösivu, jonka ympärille rakennetaan pääsivupohja ja muut upotettavat elementit. Grailsohjelmistokehyksessä on täten luonnollisempi lähestymistapa sivuston hierarkian sisäistämisessä, mutta Lift-ohjelmistokehyksen vastakkainen lähestymistapa on joustavampi, mikäli sivustolla halutaan hyödyntää useita eri pääsivupohjia. Tämän lisäksi Liftohjelmistokehys tarjoaa suhteessa enemmän eri vaihtoehtoja sivupohjien toteuttamiseen. Kokeneille kehittäjillä tällainen joustavuus voi olla tärkeää optimoinnin kannalta, mutta aloittelijat voivat kokea sen sekoittavana tekijänä Sivujen ja linkitysten toteuttaminen Toteutettavassa verkkosivustossa tulee olla lukuisia itsenäisiä sivuja ja näiden välillä selailu tulee pystyä hoitamaan päävalikon ja navigaatiovalikon avulla. Päävalikkoon lisätään linkit pääkategorioihin, ja kukin pääkategoria sisältää omat linkit sen alle kuuluviin sivustoihin. Toiminnallisesti käyttäjän tulee ensin valita haluamansa pääkategoria päävalikosta, jonka jälkeen verkkosivun navigaatiovalikkoon hahmottuu linkit pääkate- 37

43 goriaan liittyvistä alikategorioista. Kukin sivu voi sisältää omaa tietosisältöä, joten ne tulee toteuttaa itsenäisinä sivuina. Grails-projekti Grails-ohjelmistokehyksessä sivut ja linkityksen voi toteuttaa helpoiten hallintaluokkien avulla. Hallintaluokkia voi luoda Grails komentorivi-rajapinnan avulla käyttämällä komentoa: grails create-controller (Judd, et al., 2008). Hallintaluokan luominen lisää projektiin kolme eri tekijää: itse hallintaluokan, hallintaluokkaa vastaavan testiluokan sekä hallintaluokan nimisen kansion views-kansion sisälle. Tämän jälkeen GSPsivut voidaan toteuttaa luodun hallintaluokkanimisen kansion sisälle, joka sijaitsee views-kansiossa. Kukin sivu tulee toteuttaa omana GSP-tiedostona, joista yksi esimerkki löytyy liitteestä G3. Toteutustasolla sivuston pohjarakenteen päävalikon linkit vastaavat omia yksittäisiä hallintaluokkia ja navigaatiovalikon linkit vastaavat hallintaluokkaan kuuluvia GSP-sivuja. Kun hallintaluokan sisään kuuluvat GSP-sivut on toteutettu, niin niitä vastaavat linkit tulee määrittää hallintaluokan sisälle omina sulkeumina, joiden nimet vastaavat GSP-sivujen nimiä. Hallintaluokkaan luodut sulkeumat voivat sisältää mahdollista käsittely- ja ohjauslogiikkaa, joiden avulla voidaan määrittää mitä missäkin linkin painalluksessa tapahtuu. Koska projekti on vielä ensimmäisessä vaiheessa, sulkeumien sisälle ei tarvitse vielä kirjoittaa logiikkaa, jolloin ne toimivat tavallisina linkkeinä GSP-sivujen välillä. Liitteessä G4 on esitetty esimerkki hallintaluokan toteutuksesta. Jotta linkkejä voitaisiin hyödyntää verkkosivulla, tulee ne lisätä jonnekin. Linkit voitaisiin toteuttaa irrallisina <g:link> tag-kenttinä GSP-sivuilla, mutta on olemassa myös valmiita Grails-laajennuksia, jotka mallintavat tarvittavaa selailu-ominaisuutta. Työn tehostamiseksi käyttöön on valittu valmis Grails Navigation-laajennus, jonka voi ottaa käyttöön mihin tahansa Grails-projektiin kutsumalla seuraavaa komentoa: grails install-plugin navigation. Komennon ajaminen asentaa tarvittavat navigaatiolaajennuksen riippuvuudet suoraan kehitteillä olevaan projektiin, jonka jälkeen ne ovat valmiita käyttö varten. Laajennus lisää automaattisen navigaatiototeutuksen, joka voidaan sijoittaa haluttuun paikkaan lisäämällä <nav:render/> tag-kenttä. Vastaavasti navigaation alavalikko voidaan sijoittaa haluttuun paikaan käyttämällä <nav:rendersubitems/> tag-kenttää. Liitteessä G4 on esitetty kuinka navigaatiolaajennus konfiguroidaan käyttökuntoon ja liitteessä G2 on esitetty miten navigaatio hahmotetaan sivulle. 38

44 Lift-projekti Lift-ohjelmistokehyksessä sivujen ja linkityksen toteuttamisen sydän on SiteMapkomponentissa (Chen-Becker, et al., 2009). Kaikki web-sovelluksen piiriin kuuluvat sivut joihin halutaan päästä käsiksi ajonaikana, tulee määrittää SiteMap-komponentissa. Liitteessä L5 on esitetty ensimmäisen vaiheen aikana toteutettu SiteMap-komponentti, jota kutsutaan Lift-ohjelmistokehyksen alustusluokan bootsrap.liftweb.boot metodissa boot(). Kukin irrallinen sivu esitetään yksilöllisenä komponenttina, jolla on uniikki tunnus ja muut taustatiedot kuten esimerkiksi linkin fyysinen osoite, nimi ja joukko johon linkki kuuluu. Liitteessä L5 on luotu linkit kutakin pääkategorian ja näiden alakategorian sivua varten ja ne on jaettu ryhmiin siten, että kukin pääkategorian linkki kuuluu samaan ryhmään ja eri pääkategorian alakategoriat kuuluvat samaan ryhmään. SiteMap-komponentin tarkoitus on keskitetysti määrittää web-sovelluksen sivut. Kullekin sivulle voi SiteMap-komponentin avulla määrittää tunnistetietojen lisäksi myös pääsy- ja näkyvyysrajoitteet käyttäjätunnistusmenettelyä varten. Sivujen Site- Map-määrityksen lisäksi sivut tulee toteuttaa fyysisesti HTML-rakenteina. Liitteessä L2 on esitetty etusivun HTML-rakenne. Chen-Becker, et al. (2009) mukaan Lift-ohjelmistokehys tarjoaa sisäänrakennetun tehokkaan tavan esittää sivuston linkit valmiina linkkijoukkoina. Käytössä on <lift:menu/> Snippet-komponentti, joka hoitaa linkkijoukkojen hahmotuksen XHTML-rakenteiksi. Kehittäjällä on käytössä lukuisia eri tapoja määrittää miten linkkijoukot hahmotetaan, mutta yksinkertaisimmillaan hahmotus tapahtuu lisäämällä <lift:menu.builder/> Snippet tag-kutsu haluttuun kohtaan sivua. Kyseinen tagkutsu hahmottaa linkkilistan web-sovelluksen kaikista sivuista, jotka ovat näkyviä. Koska Luma-projektissa pääkategoriat ja alakategoriat halutaan esittää irrallisina kokonaisuuksina, niin käyttöön on otettu <lift:menu.group/> Snippet-tag kutsu, joka muodostaa linkkilistan tietyllä joukkotunnuksella merkityistä linkeistä. Liitteissä L3 ja L4 on esitetty esimerkki kyseistä Snippet tag-kutsusta. Mikäli osa web-sovelluksen sivujen linkeistä on tarkoitus olla salaisia, ne voidaan määrittää SiteMapkomponentissa näkymättömiksi asettamalla niille Hidden parametri. Tällöin linkki ei hahmotu <lift:menu/> tag-kutsusta, mutta sivu on olemassa ja sinne johtavan linkin voi luoda liittämällä sivulle <lift:menu.item/> tag-kenttä. 39

45 Vertailu Grails-ohjelmistokehyksen yksi merkittävin vahvuus on sen liitännäisjärjestelmä, jonka avulla kehittäjät voivat helposti ottaa käyttöön kolmannen osapuolen toteuttamia laajennuksia. Navigation-laajennus on hyvä esimerkki siitä, ettei Grails-projekteissa tarvitse keksiä jokaista pyörää uudestaan, mutta ohjelmistokehyksen ei itse tarvitse sisällyttää mitään valmista työkalua yksinkertaisen toiminnallisuuden toteuttamiseen. Vaikka Lift-ohjelmistokehyksen sisäänrakennettu linkkijoukkojen hahmotustyökalu on tehokas ja joustava, niin se ei vedä vertoja Grails:in liitännäisjärjestelmän ideologialle. Sisäänrakennettujen työkalujen heikkoutena on se, etteivät ne sovellu välttämättä aivan kaikkiin tapauksiin. Tämän lisäksi kehittäjät voivat tulla nopeasti sokeiksi käyttämään tiettyä sisäänrakennettua toteutusmallia, mikä ei välttämättä ole hyvä kyseisessä tilanteessa. Grails-ohjelmistokehyksen liitännäisjärjestelmä mahdollistaa sen, että kolmannen osapuolen kehittäjät voivat toteuttaa tiettyyn tapaukseen soveltuvan toteutusmallin, jota muut kehittäjät voivat hyödyntää samanlaisissa projekteissa. Grails:in liitännäisjärjestelmän heikkous on kuitenkin se, etteivät kaikki laajennukset ole välttämättä kattavasti testattuja tai edes yhteensopivia kaikkien Grails versioiden kanssa. Sivustonhallinnassa Lift:in keskitetty lähestymismalli SiteMap-komponentin avulla on tehokas tapa havainnollistaa ja ylläpitää sivujen olemassaoloa, näkyvyyttä ja rajoituksia. Kuitenkin mikäli web-sovellus on erittäin massiivinen voi keskitetty lähestymistapa osoittautua tehottomaksi. Lift kuitenkin mahdollistaa SiteMap-komponentin käytön usealla eri tavalla jolloin erikokoiset web-sovellukset voidaan toteuttaa parhaaksi toteamalla tavalla. Grails-ohjelmistokehyksen hallintaluokat perivät myös keskitetyn sivustonhallintaidean, mutta vain tiedonkäsittelyn ja ohjauksen näkökulmasta. 6.3 Toinen vaihe Projektin toisessa vaiheessa web-sovellukseen toteutetaan sisäänkirjautumis- ja autentikaatiotoiminnallisuus, monikielisyystuki sekä yksinkertainen palautteenantamis- ja selailutoiminnallisuus. Palautetoiminnallisuudessa käyttäjä voi syöttää web-sovellukseen liittyvää vapaamuotoista palautetta ja sivuston ylläpitäjä voi selata ja lukea niitä. Syötetty palaute tallennetaan automaattisesti tietokanta ja ylläpitäjälle toteutettava selailurajapinta mahdollistaa tallennettujen palautteiden hakemisen, lukemisen ja tarpeen mukaan poistamisen. Monikielisyystuki ja palautteenantamistoiminnallisuus eivät vaadi 40

46 sivustolla käyttäjän tunnistamista, joten ne toteutetaan ensimmäisenä. Monikielisyystuki on rajoitettu kahteen tarvittavaan kieleen: suomeen ja englantiin. Näiden ominaisuuksien jälkeen toteutetaan sisäänkirjautuminen, käyttäjätunnistaminen sekä käyttöliittymä ylläpitäjille selata ja lukea annettua palautetta web-sovelluksen sisällä. Tässä vaiheessa web-sovellukseen liitetään tietokanta ja laaditaan tarpeelliset toimintoaluemallit Monikielisyystuen toteuttaminen Monikielisyystuen toteuttaminen vaatii kahden eri tekstityypin huomioimista: staattisten tekstien ja virallisen tietosisältötekstien. Staattiset tekstit ovat verkkosivulle upotettuja tekstejä, joihin voi luokitella esimerkiksi painikkeiden ja eri linkkien tekstit. Tietosisältötekstit ovat taas käyttäjien ja sivuston ylläpitäjien kirjoittamia tekstejä. Grails-projekti Judd, et al. (2008) mukaan Grails:in sisään on rakennettu i18n-teknologiatuki, joka mahdollistaa monikielisyyden toteuttamisen. Tässä teknologiassa verkkosivun kielivalintaa voidaan muuttaa lisäämällä verkkosivun URL-osoitteeseen lang-parametri, jonka arvona on joku haluttu kielilokaali, esimerkiksi fi (suomi) tai en (englanti). Kun langparametri on kerran syötetty URL-osoitteessa, niin Grails tallentaa sen automaattisesti evästeisiin jonka avulla sivusto on tietoinen millä kielellä sisältö tulee esittää. Staattisia tekstejä varten Grails kehittäjän tulee aluksi luoda lokaalitiedosto kutakin tuettua kieltä varten. Lokaalitiedostot sisältävät kielikäännökset kaikkiin tarvittaviin staattisiin teksteihin avain-arvo pareina. Lokaalitiedoston luomisen jälkeen kehittäjän tarvitsee vain korvata kaikki GSP-sivuihin upotetut tekstit <g:message/> tag-kentillä, jolle annetaan code-attribuuttina jokin lokaalitiedoston avainta vastaava tunnus. Liitteessä G5 on esitetty <g:message/> tag-kentän käyttöä. Koska toisessa vaiheessa verkkosivut ovat vielä staattisia luonteeltaan, voidaan tietosisältöjen monikielisyys toteuttaa staattisesti GSP-sivuihin. Kuvassa 11 on esitetty yksi mahdollinen lähestymistapa, jossa GSPsivulle on toteutettu ehdollisrakenne käyttäen <g:if> tag-kenttää. Mikäli URLosoitteessa on mukana lang-parametri ja sen arvo on en, niin käytetään ensimmäisen lohkon tietosisältö, muussa tapauksessa käytetään toisen lohkon tietosisältöä. 41

47 ... <g:if test="${params.lang == 'en'"> <h1>title</h1> english version of the text... </g:if> <g:else> <h1>otsikko</h1> suomenkielinen versio tekstistä... </g:else>... Kuva 11. Tietosisällön monikielisyystuen toteuttaminen staattisena GSP-sivuna Jotta kielivalintaa olisi helpompi käyttää, eikä sitä tarvitsisi kirjoittaa URL-osoitteeseen manuaalisesti, tulee web-sovellukseen laatia painike, joka syöttää kielivalinta-parametrin automaattisesti URL-osoitteeseen. Liitteessä G6 on esitetty web-sovelluksen staattisen ylävalikon toteutus, jossa on kielivalinta toiminnallisuus ja liitteessä G7 on esitetty toiminnallisuutta vastaava hallintaluokka. Lift-projekti Chen-Becker, et al. (2010) mukaan myös Lift-ohjelmistokehykseen on sisäänrakennettu i18n-teknologiatuki. Monikielisyystuki voidaan täten toteuttaa lähes samalla tavalla kuin Grails-ohjelmistokehyksessä. Ainut ero on se, että Lift-ohjelmistokehys ei tarjoa valmista sisäänrakennettua lokalisoinnin määritysmekanismia vaan ainoastaan resurssien käsittelymekanismin. Liitteessä L6 on esitetty yksi mahdollinen lokalisoinnin määritysmekanismitoteutus, jossa web-sovellus tarkastaa löytyykö URL-osoitteesta langnimistä parametria tai onko selaimen evästeisiin tallennettu aikaisemmin kyseinen parametri. Kyseinen parametri määrittää mitä lokalisointia web-sovelluksen tulee käyttää. Staattiset ja upotetut tekstit tulee ilmaista Lift-projektin sivupohjissa tag-kentällä: <lift:loc/>, jolle voi syöttää locid-attribuutin. Attribuutin arvo on jokin lokaalitiedoston avain-arvo, jolle on vastaava kielikäännös. Ohjelmakoodissa staattisia tekstejä voi kutsua S-komponentin funktiota? kuten esimerkiksi liitteessä L5 on tehty linkkien nimien määrityksessä. Chen-Becker, et al. (2010) mukaan Lift-ohjelmistokehyksessä lokalisointilaajuus ulottuu lokaalitiedostojen ohella myös sivupohjatiedostoihin. Tällöin kustakin sivupohjasta voi luoda oman kieliriippuvaisen version, joiden avulla tietosisältö tekstien lokalisoinnin voi toteuttaa. Kieliriippuvaiset sivupohjat tulee nimetä päättymään alaviivalla varustettuun kielilokaalin tunnukseen, esimerkiksi frontpage_fi.html tai frontpage_en.html. 42

48 Lokaalin valintatoiminnallisuus voidaan toteuttaa Lift-projektissa luomalla kaksi uutta piilotettua linkkiä SiteMap-komponenttiin kuvan 12 tavalla. Koska linkit ovat piilotettuja, ne eivät näy missään <lift:menu/> Snippet-tagin generoimassa linkkijoukossa, mutta niitä pystyy liittämään sivuille <lift:menu.item/> tag-kentän avulla. Liitteessä L7 on esitetty topbar.html sivupohjatoteutus, jossa kaksi kielivalinnan linkkiä esitetään. Kun käyttäjä painaa jompaakumpaa linkkiä, ohjautuu hän sivuston pääsivulle ja kielivalinta muuttuu halutuksi. Menu(Loc("inFinnish", List("luma", "main", "frontpage?lang=fi"), S? "in.finnish", Hidden)), Menu(Loc("inEnglish", List("luma", "main", "frontpage?lang=en"), S? "in.english", Hidden)) Kuva 12. Kielivalinta linkkien määritys SiteMap-komponentissa Vertailu Chen-Becker, et al. (2010) mukaan monikielisyystuen mahdollistaminen on yksi tärkeimpiä ominaisuuksia nykypäivän web-sovellusohjelmistokehyksissä. Kummankin ohjelmistokehyksen kohdalla monikielisyystuki oli helppo ja nopea toteuttaa standardisoitujen mallien avulla. Lift-ohjelmistokehys tarjosi enemmän valinnanvaraa kuinka monikielisyystuki toteutettaisiin, mutta se vaati myös enemmän työpanosta ja lähdekoodia Grails-ohjelmistokehykseen verrattuna. Lift-ohjelmistokehyksen monikielisyys toteutuksen merkittävin etu Grails-ohjelmistokehykseen verrattuna on se, että monikielisyystuen laajuus ulottuu oletusarvoisesti myös sivupohjiin. Grails-projektin toisen vaiheen tietosisältöjen monikielisyystukitoteutus voi osoittautua kömpelöksi ja virhealttiimmaksi, mikäli kielivalintamahdollisuuksia olisi useampia. Grails-ohjelmistokehyksen sisäänrakennettua monikielisyystukea voidaan pitää aloittelijaystävällisempänä, sillä se ei vaadi lainkaan konfigurointia tai lähdekoodintoteutusta, mutta sen hyödyntäminen on myös rajoitetumpaa Palaute ominaisuus Palautteen antamisominaisuuden tarkoitus on mahdollistaa helppo verkkosivua koskevan palautteen keräys ja ylläpito. Palautetta voi antaa kuka tahansa joko nimellisenä tai nimettömänä ja se tallennetaan tietokantaan. Tärkeimmät vaiheet palautteenkeräämisominaisuutta varten on luoda sitä vastaava toimintoaluemalli ja muuttaa se yhteen- 43

49 sopivaksi tietokantaa varten sekä asentaa web-sovellus kommunikoimaan tietokannan kanssa. Näiden lisäksi web-sovellukseen tulee laatia kaavarakennesivu, johon käyttäjä voi syöttää palautetta koskevat tiedot. Palautteen antamissivulle voi päästä käsiksi verkkosivun alatunnisteissa olevan linkin kautta. Grails-projekti Judd, et al. (2008) mukaan Grails tarjoaa helppokäyttöisen ja tehokkaan tavan tuottaa toimintoaluemalleja. Kehittäjä voi luoda toimintoalueluokkia käyttämällä seuraavaa komentoa: grails create-domain-class. Kyseinen komento luo toimintoalueluokan ja sitä vastaavan testausluokan. Toimintoalueluokka on tavallinen groovy-luokka, joka vastaa tietokantataulua ja luokkaan määritellyistä tietokentistä muodostuu tietokantataulun sarakkeet. Liitteessä G8 on esitetty palautetta vastaava toimintoalueluokan toteutus. Judd, et al. (2008) mukaan kun toimintoalueluokka on luotu niin sitä voi hyödyntää erilaisten apumetodien avulla suoraan tietokantaa vasten. Esimerkiksi luomalla luokasta uuden ilmentymän ja kutsumalla sen metodia save() tallentuu uusi luotu olio suoraan tietokantaan ja sen voi hakea toimintoalueluokan staattisten apumetodin avulla. Grails hyödyntää oletusarvoisesti HSQLDB-tietokantaa, joka tallentaa kaiken oletusarvoisesti ajonaikaiseen muistiin, mutta sen voi myös asettaa tallentamaan tiedot kovalevylle. Kehittäjille tämä on suuri apu sillä alkuvaiheen tietokantaintegraatio voi yleensä heikentää työtehoa estämällä projektia etenemästä muilta osin. Judd, et al. (2008) mukaan toimintoalueluokan voi halutessa asettaa dynaamiseen sivumuodostustilaan (scaffold) liittämällä sen johonkin hallintaluokkaan. Tällöin Grails luo ajonaikana toimintoalueluokkaa vastaavat CRUD (create-read-update-delete) GSP-sivut, joihin voi päästä käsiksi hallintaluokan kautta. Toimintoalueluokan jälkeen kehittäjien tarvitsee vielä toteuttaa palautetta vastaava hallintaluokka ja GSP-sivut. Liitteessä G5 on esitetty palautteen antamiseen rakennekaavasivu ja liitteessä G9 on esitetty palautetta varten luotu hallintaluokka. Liitteen G8 hallintaluokasta vain kolme ensimmäistä sulkeumaa on toteutettu itse ja loput sulkeumista on Grails:in automaattisesti generoimia. Automaattinen generointi on toteutettu kutsumalla Grails komentorivi-rajapinnan komentoa: grails generate-views (Judd, et al., 2008). Kyseinen komento generoi dynaamisen sivumuodostustilan tavalla CRUD-sivut ja kirjoittaa ne fyysisiksi hallintaluokan GSPsivuiksi Grails-projektiin, jonka jälkeen niitä voi halutessa muokata omien tarpeiden mukaan. Grails web-sovelluksissa tiedonsidonta kaavarakenteista hallintaluokkiin tapahtuu automaattisesti nimeämällä kukin kaavarakenteen kenttä yksilöivällä tunnuksel- 44

50 la, joka vastaa jotain toimintoalueluokan kenttää. Tiedonkäsittely tapahtuu keskitetysti hallintaluokassa, jossa määritetään myös jatkotoiminnot ja ohjaukset. Lift-projekti Lift-ohjelmistokehyksessä palautteenanto toiminnallisuuden tietokanta- ja toimintoaluepuolen toteutus tehdään laatimalla palautemallia vastaava luokka, MySQLtietokantayhteysolio sekä konfiguroimalla luodusta palautemalliluokasta tietokantaskeema. Tämän jälkeen voidaan toteuttaa palautelomakkeen sivupohjatoteutus ja rakennekaavan käsittelevä Snippet-luokka. Liitteessä L8 on esitetty palautemallia vastaava luokkatoteutus. Luokka hyödyntää Lift-ohjelmistokehyksen tarjoaa Mapper-komponenttia, jonka avulla luokka perii kaikki oleellisimmat funktiot tietokantahakuja ja tallennusta varten. Luokka tulee vastamaan yhtä tietokantataulua ja luokan sisältämät kentät vastaavat tietokantataulun sarakkeita. Mapper-komponentin hyödyntäminen mahdollistaa myös erilaisten metodien ylikirjoituksen, joiden avulla kehittäjät voivat tehokkaasti vaikuttaa siihen millainen tietokantamalli kustakin toimintoalueluokasta todellisuudessa syntyy. Toimintoaluemallin jälkeen kehittäjien tulee toteuttaa tietokantayhteyttä vastaava ainokaisolio (singleton), josta on esitetty esimerkki liitteessä L9. Ainokaisolion toteutuksen jälkeen se ja toteutettu toimintoalueluokka tulee konfiguroida toimimaan web-sovelluksessa. Konfiguraatio tulee toteuttaa Lift-ohjelmistokehyksen alustusluokan bootsrap.liftweb.boot metodissa boot() ja Lift tarjoaa valmiit apuluokat näiden toteuttamiseen, mutta mahdollistaa myös muokattujen ratkaisujen toteuttamisen. Käytettävät Lift-apuluokat ovat DB ja Schemifier. DB-apuluokka asentaa automaattisesti tietokantayhteyden aikaisemmin luodun tietokannan ainokaisolion perusteella ja Schemifier-apuluokka muodostaa käytössä olevaan tietokantaan tietokantaskeemat luoduista toimintoaluemallitoteutuksista. Kuvassa 13 on esitetty esimerkki molempien apuluokkien hyödyntäminen alustusluokassa. Näiden toteutuksien jälkeen toimintoaluemallin luokkan ilmentymiä voidaan käsitellä ja tallentaa tietokantaan kutsumalla sopivia CRUD-metodeja kuten create, save ja delete. Käytössä on myös hakumetodeja kuten findall, jonka avulla tietokannasta voi hakea haluttuja tietoja. 45

51 DB.defineConnectionManager(DefaultConnectionIdentifier, DBVendor)... def schemelogger (msg : => AnyRef) = { logger.info(msg) Schemifier.schemify(true, schemelogger _, User, Feedback)... Kuva 13. Tietokanta-apuluokkien hyödyntäminen Tallennuskerroksen jälkeen Lift-projektissa tulee vielä toteuttaa itse palautteenkeräyslomake ja sen käsittelevä Snippet-komponentti. Liitteessä L10 on esitetty palautteenkeräyslomakkeen kaavarakennetoteutus, joka ei sisällä HTML-pohjaisia kaavarakenteiden kenttiä suoranaisesti. Kaavarakenne on toteutettu hyödyntämällä Liftohjelmistokehyksen tiedonsidontaa ja itse luotua Snippet-komponenttia nimeltä <lift:givefeedback.add/>, jonka toteutus on esitetty liitteessä L11. Lomakkeen kaikki tietokentät on sidottu e-nimiseen sitojaan ja kullakin tietokentällä on oma yksilöivä tunnus, esimerkiksi e:name. Kun lomake syötetään lähetyspainiketta painamalla, niin Lift kutsuu automaattisesti kaavarakenteen Snippet-komponenttia, joka hoitaa tiedontiedonkäsittelyn ja ohjauksen. Snippet-komponentti vastaanottaa tietokenttien arvot, tarkastaa, ettei palaute ole tyhjä ja tallentaa sen ilmentymän tietokantaan. Tiedonkäsittelyn jälkeen käyttäjä ohjataan uudelle sopivalle sivulle. Vertailu Kahdesta ohjelmistokehyksestä Grails:n tapauksessa palautteenantotoiminnallisuus oli tehokkaampi toteuttaa ja testata. Tämä johtui siitä, ettei Grails vaatinut tietokantayhteyksien luomista ja kaikki sivupohjat ja tallennustoiminnallisuudet pystyi generoimaan suoraan toimintoalueluokan pohjalta. Grails-projektin tapauksessa ainut merkittävä asia oli luoda toimintoalueluokka, generoida valmiit pohjat ja hienosäätää sen ulkoasua. Lift-ohjelmistokehys vastaavasti antoi paljon joustavuutta ja erilaisia toteutustapoja optimoida toiminnallisuus, mutta vastapainoksi vaati kehittäjän toteuttavan enemmän lähdekoodia. Lift-projektin hyvä puoli on kuitenkin sen lähestymismalli, jossa tiedonesitys ja logiikka erotellaan toisistaan. Lift-projektissa lomakkeen kaavarakenteesta tuli hyvin yksinkertainen ja ymmärrettävä, koska mitään logiikkaa ei tarvinnut kirjoittaa itse kaavarakenteisiin, vaan kaikki käsittelyt ja logiikat hoidettiin Snippet-komponentin sisällä. 46

52 6.3.3 Sisäänkirjautuminen ja käyttäjän tunnistaminen Sisäänkirjautumis- ja käyttäjän tunnistusominaisuuden tarkoitus on rajoittaa joidenkin web-sovelluksen sivujen näkyvyyttä ja toiminnallisuutta vieraileville käyttäjille. Tietyt sivut ja toiminnallisuudet ovat käytettävissä vain valitulle käyttäjäjoukolle ja tämä rajaus tapahtuu web-sovelluksessa sisäänkirjautumisen avulla. Käyttäjällä tulee olla tiedossa yksilöivä käyttäjätunnus ja sitä vastaava salasana, jotka syöttämällä websovellukseen, pääsee käsiksi rajoitettuihin toiminnallisuuksiin ja sivuihin. Kehitettävässä web-sovelluksessa on tarve vain kahdenlaisille käyttäjille: vierailevilla ja ylläpitäjille. Vierailevien käyttäjien ei tarvitse kirjautua web-sovellukseen sisään, vaan voivat selata web-sovelluksen julkisia vapaasti. Ylläpitokäyttäjät voivat myös selata websovelluksen julkisia sivuja vapaasti, muta mikäli he haluavat päästä suljetuille hallintasivuille, tulee heidän kirjautua web-sovellukseen käyttäjätunnuksillaan. Grails-projekti Grails-projektissa käyttäjän tunnistautumisen voi hoitaa monella eri tavalla ja jaossa on lukuisia valmiita Grails-laajennuksia, jotka toteuttavat erilaisia tietoturvastandardeja ja hyviksi todettuja menettelytapoja. Tähän projektiin tietoturvalaajennukseksi on valittu Spring Security:n toteutus nimeltään Acegi. Laajennuksen voi asentaa käyttökuntoon kutsumalla komentoa: grails install-plugin acegi. Judd, et al. (2008) mukaan Acegi määrittää kolmenlaiset toimintoalueluokat, joiden avulla käyttäjän tunnistautumista hoidetaan: Person, Authority ja Requestmap. Person-luokka vastaa yksittäistä käyttäjää ja Authority-luokka vastaa olemassa olevia käyttäjätasoja. Kukin yksittäinen käyttäjä voi kuulu eri käyttäjätasoihin ja kullakin käyttäjätasolla voi olla omia, vain sille ominaisia toiminnallisuuksia ja sivunäkyvyyksiä. Käyttäjätasojen sivunäkyvyysrajoitukset tulee määrittää Requestmap-luokkaan osoite-käyttäjätaso avain-arvopareina. Kuvassa 14 on esitetty esimerkki Requestmap-luokan avain-arvo pareista, jossa tietyt sivunäkyvyydet rajoitetaan näkymään ROLE_ADMIN käyttäjätason omaaville käyttäjille new RequestMap(url:"/category/**",configAttribute:"ROLE_ADMIN").save() new RequestMap(url:"/pagecontent/**",configAttribute:"ROLE_ADMIN").save() new RequestMap(url:"/page/**",configAttribute:"ROLE_ADMIN").save() Kuva 14. Esimerkki Requestmap-luokan avain-arvo pareista Acegi-laajennuksen asentaminen projektiin luo myös hallintaluokkia ja GSP-sivut sisäänkirjautumista varten, sekä lisää lukuisia hyödyllisiä GSP tag-kenttiä, joilla voi määrittää käyttäjän tunnistautumisseen liittyviä toiminnallisuuksia. Liitteessä G6 on esitetty 47

53 esimerkki Acegi-laajennuksen hallintaluokkien ja GSP tag-kenttien hyödyntämisestä. Käytettävä tag-kentät ovat <g:isloggedin> ja <g:loggedinuserinfo> ja niiden tarkoitus on määrittää eri toiminnallisuutta riippuen siitä onko käyttäjä sisäänkirjautunut web-sovellukseen vai ei. Lift-projekti Lift-projektissa sisäänkirjautuminen ja käyttäjäntunnistus voidaan toteuttaa ottamalla käyttöön käyttäjää mallintava toimintoalueluokka, joka toteuttaa Lift-ohjelmistokehyksen tarjoaman MetaMegaProtoUser-ominaisuusluokan (trait). Chen-Becker, et al. (2009) mukaan MetaMegaProtoUser-ominaisuusluokka tarjoaa valmiit toiminnallisuudet sisään- ja uloskirjautumiseen, salasanan palauttamiseen ja uusien käyttäjien luomiseen. Ominaisuusluokka kattaa logiikkatoiminnallisuuden lisäksi myös sivupohjatoteutukset, jotka on upotettu ominaisuusluokan sisälle Template-ilmentymänä. Liitteessä L12 on esitetty käyttäjää mallintavan toimintoalueluokan toteutus. Jotta MetaMegaProtoUser-ominaisuusluokan tarjoamat sivut olisivat käytössä, tulee ne lisätä SiteMapkomponenttiin manuaalisesti. Helpoin tapa on lisätä sivut SiteMap-komponentin sivulistaan, on kutsumalla ominaisuusluokan tarjoamaa sitemap() metodia, joka palauttaa kaikki ominaisuusluokan toteuttamat sivut. Liitteen L5 lopussa on esimerkki miten kyseistä metodia voidaan hyödyntää. Koska web-sovelluksen pitää pystyä esittämään erilaisia toimintoja riippuen siitä onko käyttäjä sisäänkirjautunut järjestelmään vai ei, tulee Lift-projektiin laatia uusi Snippet-komponentti, joka tuottaa dynaamisesti sivupohjia. Esimerkki vastaavanlaisesta Snippet-komponentista on esitetty liitteessä L13 ja sivupohja, jossa kyseistä Snippet-komponenttia hyödynnetään liitteessä L7. Yllämainitulla menetelmällä voidaan rajoittaa toimintojen näkyvyyttä, mutta Chen-Becker, et al. (2009) mukaan tärkeää on myös rajoittaa toiminnallisuuksiin pääsy. Lift-ohjelmistokehyksessä sivuja voidaan rajoittaa vain tietylle käyttäjäkunnalle asettamalla SiteMapkomponentin sivuille suodatuksia ja parametreja. Kuvassa 15 on esitetty esimerkki SiteMap-komponenttiin lisättävästä browsefeedback-sivusta, jonne vain sisäänkirjautuneella käyttäjällä on pääsy. Sivulle asetetaan arvo-parametri nimeltään loggedin, jonka arvo on määritetty toiminnallisuus Aina kun browsefeedback-sivulle pyritään menemään, loggedin arvoparametrin toiminnallisuus käydään läpi ja mikäli käyttäjä ei ole sisäänkirjautunut, ohjataan hänet sivulle pääsyn sijasta sisäänkirjautmissivulle. 48

54 val loggedin = If(() => User.loggedIn_?, () => RedirectResponse("/user_mgt/login "))... Menu(Loc("browseFeedback", List("luma", "feedback", "browse"), S? "browse.feedback", loggedin)) Kuva 15. Esimerkki sivulle pääsyrajoituksesta SiteMap-komponentissa Vertailu Grails-ohjelmistokehyksen liitännäisjärjestelmän tarjoama etulyöntiasema Liftohjelmistokehykseen verrattuna on jälleen havaittavissa. Grails-projektin kehittäjät voivat helposti valita käyttöön haluamansa valmiiksi toteutetun autentikaatio-laajennuksen ja vain muutamalla konfiguraatiolla saada siitä kaiken hyödyn irti. Chen-Becker, et al. (2009) mukaan Lift-ohjelmistokehyksen tarjoama MetaMegaProtoUser-ominaisuusluokan tarkoitus on soveltua yksinkertaisten sivujen autentikaatiojärjestelmäksi ja tarjota näkökulmaa kehittäjille siitä miten laajemmille web-sovelluksille kannattaa kehittää oma autentikaatiojärjestelmä. Lift-ohjelmistokehys tarjoaa täten vain esimerkin mahdollisesta autentikaatiojärjestelmästä ja kehottaa kehittäjiä toteuttamaan oman websovellukseen paremmin soveltuvan autentikointijärjestelmän. Grails-ohjelmistokehystä voidaan täten pitää tehokkaampana valinta, mutta Lift-ohjelmistokehyksen lähestymistapaa voidaan pitää parempana, mikäli kehitettävän web-sovelluksen autentikaatiojärjestelmä vaatii uniikkia toiminnallisuutta jota valmiiksi toteutetut autentikaatiojärjestelmät eivät voi tarjota Palautteen selailuominaisuus ylläpitäjälle Web-sovellukseen toteutettu palautteen antamisominaisuus tallentaa kaikki annetut palautteet web-sovelluksen tietokantaan, joten niiden selailuun tarvitaan myös websovellukseen kuuluva käyttäjärajapinta. Ainoastaan web-sovellukseen sisäänkirjautunut ylläpitäjä voi selata ja lukea annettuja palautteita. Palautteiden tulee myös muistaa tilansa siitä onko palaute joskus luettu vai ei. Ylläpitäjän käyttäjän tulee pystyä muuttamaan luetun palautteen tila takaisin lukemattomaksi sekä tarpeentullen poistamaan annettuja palautteita tietokannasta. Ylläpitäjällä ei kuitenkaan saa olla toiminnallisuutta muuttaa annettun palautteen sisältöä. 49

55 Grails-projekti Grails-projektissa palautteen selailukäyttöliittymän toteuttaminen on hyvin suoraviivainen ja helppo prosessi, koska käytössä on jo kaikki tarvittavat resurssit vain pientä viilaamista vailla. Palautteen antamisominaisuutta toteutettaessa luotiin jo tarvittava toimintoalueluokka, hallintaluokka ja toimintoalueluokkaa vastaavat GSP-sivut CRUDtoiminnallisuutta varten. Tarve on enää rajoittaa palautteiden selailunäkymä ylläpitäjäkäyttäjälle, muokata generoituja GSP-sivuja ja hallintaluokan sulkeumia vastaamaan haluttua toiminnallisuutta. Selailunäkymän rajoittaminen pelkästään ylläpitäjälle tapahtuu hyödyntäen käyttöön otettua acegi-laajennusta, johon laaditaan uudet sivunäkyvyysrajoitukset kuvan 16 mukaisesti. new RequestMap(url:"/feedback/list/**, configattribute:"role_admin").save() new RequestMap(url:"/feedback/show/**", configattribute:"role_admin").save() new RequestMap(url:"/feedback/edit/**", configattribute:"role_admin").save() Kuva 16. Sivunäkyvyysrajoitukset palautteen selailua varten Seuraavaksi muokataan yleistä palautteiden listaussivua ja yksittäisten palautteiden näkymäsivua: list.gsp ja show.gsp. Palautteiden listaussivusta piilotetaan kaikki tarpeettomat kentät kuten tietokanta id-kenttä ja sarakkeet järjestetään uudelleen vastaamaan paremmin selailumallia. Tämän lisäksi lukemattomat ja luetut palautteet esitetään listassa ikoneina totuusarvojen sijasta. Yksittäisten palautteiden näkymäsivulta on myös poistettu kaikki turhat kentät ja painikkeet joiden avulla pystyy siirtymään palautteiden muokkaussivulle. Käyttöliittymäpainikkeista näkymäsivulle on jätetty vain palautteen poistopainike, sekä kaksi uutta painiketta: palaa takaisin ja merkitse palaute lukemattomaksi. Seuraava vaihe GSP-sivujen jälkeen on muokata hallintaluokassa tapahtuvaa ohjausta, jotta palautteiden selailu ja poistaminen ohjaisi ylläpitokäyttäjän oikeaan paikkaan suorittaessaan kyseisen toiminnon. Lift-projekti Lift-projektissa palautteen selailuominaisuuden toteuttaminen vaatii kahden sivupohjan ja Snippet-komponentin toteuttamisen. Toteutettavat sivupohjat ovat browse.html ja show.html, joista ensimmäisen tarkoitus on listata kaikki saadut palautteet listana ja toisen sivupohjan tarkoitus on hahmottaa yksi valittu palaute kokonaisuudessaan näytölle ja tarjota mahdollisia muokkausominaisuuksia. Koska selailuominaisuus on rajoitettu vain sisäänkirjautuneelle käyttäjälle, on toteutetut sivupohjat määritetty SiteMapkomponenttiin pääsyrajoituskriteerillä kuvan 17 mukaisesti. Liitteessä L14 on esitetty 50

56 selailuominaisuuden listaus-sivupohja ja liitteessä L15 on esitetty sitä vastaava Snippetkomponentti, joka hahmottaa listan kaikista annetuista palautteista. Kunkin listattu palaute sisältää linkin uuteen sivunäkymään, johon valittu palaute hahmotetaan kokonaisuutena. Tämän sivunäkymän toteutus löytyy liitteestä L16 ja sivua vastaava Snippetkomponentin toteutus löytyy liitteestä L17. Yksittäisellä sivunäkymällä kaikki palautteen oleelliset tiedot esitetään tauluna ja käyttäjälle tarjotaan myös kaksi toiminnallisuutta: palautteen poistaminen ja lukemattomaksi merkkaaminen. Kumpikin toiminnallisuus on toteutettu linkkinä, joka käsittelyvaiheessa suorittaa oman palautetta koskevan toiminnallisuuden ja uudelleenohjaa käyttäjän palautteiden listausnäkymään. val loggedin = If(() => User.loggedIn_?, () => RedirectResponse("/user_mgt/login"))... Menu(Loc("browseFeedback", List("luma", "feedback", "browse"), S? "browse.feedback", loggedin)) :: Menu(Loc("showFeedback", List("luma", "feedback", "show"), S? "show.feedback", loggedin)) :: Kuva 17. Palautteen selailuominaisuuden määritys SiteMap-komponentissa Vertailu Näiden kahden eri ohjelmistokehystoteutuksen välillä merkittävä ero on se, että Grailsohjelmistokehyksessä lähes kaikki toiminnallisuus ja näkymät tarjottiin valmiina, jonka johdosta kehitykseen kuluvan ajan pystyi helposti keskittämään toiminnallisuuden hienosäätämiseen ja ulkoasun koristamiseen. Lift-ohjelmistokehyksessä kaikki tuli laatia tyhjästä, joka hidasti vaiheen toteutusta merkittävästi, eikä toiminnallisuutta tullut hienosäädettyä Grails-projektin tavoin. Kyseessä on kuitenkin ollut vain hyvin yksinkertainen CRUD-toiminnallisuus palautetta koskien, ja mikäli ominaisuus olisi vaatinut uniikkia logiikkaa ja käsittelyä eivät Grails-ohjelmistokehyksen tarjoamat valmiit ratkaisut olisi riittäneet niiden toteuttamiseen. Lift-ohjelmistokehyksen lähestymistapa olisi myös parempi tilanteessa jossa kehittäjien tulisi laatia useampi erilainen näkymä ja käsittelytoteutus palautetta koskien. Tällöin kehittäjät voisivat helposti uudelleenkäyttää ja muokata toteutettua toiminnallisuutta kuhunkin tilanteeseen sopivaksi. Grailsprojektissa automaattisesti luodut sivut sisältävät hyvin paljon upotettua logiikkaa ja sidontaa, joka tekee sen generoidun lähdekoodin uudelleenkäyttämisen virhealttiimmaksi. 51

57 6.4 olmas vaihe Kolmannessa projektin vaiheessa staattiset web-sovelluksen sivut on tarkoitus muuttaa dynaamisiksi ja helposti muutettaviksi. Web-sovelluksen loppukäyttäjät eivät ole ITalan ammattilaisia, joten verkkosivujen kirjoittaminen ja muuttaminen tulee olla mahdollisimman vähän puhtaan HTML-kielen kirjoittamista. Oleellisia ominaisuuksia onkin toteuttaa verkkosivujen muokkaaminen WYSIWYG-mallisena ratkaisuna. Ylläpitävien käyttäjien tulee pystyä myös luomaan, muokkaamaan ja poistamaan alisivuja, kullekin pääsivulle. Luodut alisivut esitetään linkkilistoina sivuilla, jonne ne on luotu. Oleellinen rajoite sivujen muokkaamisessa on se, että vain web-sovellukseen sisäänkirjautunut käyttäjä voi muokata sivuja sekä luoda ja poistaa alisivuja. Dynaamisten sivujen tulee myös luonnollisesti tukea monikielisyysominaisuutta Dynaamiset sivut Grails-projektissa Grails-projektissa dynaamisten sivujen mahdollistaminen tarkoittaa uusien toimintoalueluokkien luomista. Toteutettu malli koostuu viidestä toimintoalueluokasta, jotka ovat Type, Category, Languages, Page ja Pagecontent. Type-luokka vastaa websovelluksen pääkategoriaa ja Category-luokka vastaa web-sovelluksen pääkategorian alakategorioita. Page-luokka kuvaa sivupohjaa joka yksilöidään pääkategosen rian ja alakategorian mukaan. Kun käyttäjä selailee web-sovelluksen sivuja ja valitsee pääkategorian sekä sitä vastaavan alikategorian voidaan sivusto hahmottamista hallitsevassa hallintaluokassa määrittää yksilöllisen Page-luokka. Kun Page-luokan ilmentymä on määritetty, voidaan määrittää kyseistä sivua vastaava sisältö Pagecontent-luokan avulla. Pagecontent-luokka sisältää fyysisen sivuston sisällön HTML-toteutuksena ja kullakin eri kielitoteutuksella sekä alisivulla on oma Pagecontent-luokan ilmentymä. Käytettävä Pagecontent-ilmentymä voidaan valita kielivalinnan ja URL-osoitteeseen liitettävän numeraalisen id-tunnuksen perusteella. Alla on esitetty yksi esimerkki mahdollisesti URL-osoitteessa, joka määrittää näytettävän Pagecontent-ilmentymän: Judd, et al. (2008) mukaan Grails määrittää käytettävän hallintaluokan ja toiminnon URL-osoitteesta. Ylläolevassa esimerkissä käytössä on young-hallintaluokka, joka vastaa web-sovelluksen yhtä pääkategoriaa sekä computerscience-toiminto, joka vastaa 52

58 pääkategorian yhtä alikategoriaa. Näiden lisäksi osoitteessa on myös id-tunnusta vastaava numeroarvo 1 ja kielivalintaa vastaava parametri arvolla fi. Tämän osoitteen perusteella hahmotuksesta vastaava hallintaluokka voi päätellä minkä sivun käyttäjä haluaa nähdä ja millä kielellä. Kuvassa 18 on esitetty Grails-projektiin toteutettu toimintoaluemalli ja liitteissä G10 G14 on esitetty toimintoalueluokkien groovy-kieliset toteutukset. Kuva 18. Dynaamisten sivujen toimintoaluemalli Koska alisivujen määrä ei ole kiinteä, on helpompaa tehdä sivujen hahmottamisesta oma dynaaminen kokonaisuus. Tätä varten kaikki aiemmin luodut staattiset pää- ja alikategorioiden hallintaluokkakohtaiset GSP-sivut on poistettu ja tilalle on luotu yksi yleinen GSP-sivu jolle hahmotetaan kaikkien sivujen sisällöt. Tälle GSP-sivulle toteutetaan tietosisällön ja muokkaamistoiminnallisuuksien esityksen lisäksi myös linkkilista alisivuista. Linkkilistan avulla käyttäjä voi selata kutakin sivua ilman tarvetta kirjoittaa sivun fyysistä osoitetta URL-osoitteeseen. Tämän GSP-sivun toteutus on esitetty liitteessä G15. GSP-sivun päivityksen lisäksi myös hallintaluokat on päivitettävä tunnistamaan haluttu sivukokonaisuus, jotta se osaisi ohjata dynaamista hahmotusta. Liitteessä G16 on esitetty päivitetty hallintaluokka ja G17 on esitetty oleellinen apuluokka, jossa määritetään hahmotettava sivukokonaisuus. Nyt sivujen lisäys, poistaminen, hahmotus ja ohjaus ovat valmiita ja jäljellä on vain sivujen muokkaustoiminnallisuuden toteuttaminen. Koska kehitettävä muokkaussivu on tarkoitettu Pagecontent-toimintoalueluokkaa varten, voidaan se luoda automaattisesti kutsumalla Grails komentorivirajapinnan komentoa: grails generate-views. Komento luo neljä GSP-sivua, josta vain edit.gsp sivua tarvitsee muokata. Luotu GSP-sivu sisältää muokkausmahdollisuuden kaikkiin toimintoalueen kenttiin, mutta koska muokkaamista halutaan yksinker- 53

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat Järjestelmäarkkitehtuuri (TK081702) SOA yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

www.solita.fi solita@solita.fi

www.solita.fi solita@solita.fi www.solita.fi solita@solita.fi JAVA-SOVELLUSTEN RAKENTAMINEN INTEGROITUUN YMPÄRISTÖÖN Jarno Peltoniemi Solita Oy 10.5.2005 Aiheet Johdanto Portaalit, portletit Oracle Portal Java-sovelluksen rakentaminen

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

SUOMEN KUNTALIITTO RY

SUOMEN KUNTALIITTO RY Karttaliittymä Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen tausta... 2 1.2 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Lyhenteet...

Lisätiedot

Avointen ohjelmistojen käyttö ohjelmistokehityksessä

Avointen ohjelmistojen käyttö ohjelmistokehityksessä Avointen ohjelmistojen käyttö ohjelmistokehityksessä 9.4.2008 Janne Kuha Manager, Java Services Descom Oy Janne Kuha Manager, Java Services janne.kuha@descom.fi Kuka? Descom Oy:llä, sitä ennen Wanadu Inc.,

Lisätiedot

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

ecome Markkinoiden kehittynein julkaisujärjestelmä

ecome Markkinoiden kehittynein julkaisujärjestelmä ecome Ecome Finland Oy Itämerenkatu 3 p. 020 7749 580 00180 Helsinki p. 020 7749 585 Suomi - Finland ecome@ecome.fi y. 2193874-3 www.ecome.fi Ecome-järjestelmä pähkinänkuoressa Ecome on suomalaisen yhtiön

Lisätiedot

ohjelman arkkitehtuurista.

ohjelman arkkitehtuurista. 1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä

Lisätiedot

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT KOULUTUKSEN KOHDERYHMÄ SISÄLTÖ Koulutuksen tavoitteena on antaa opiskelijalle valmiudet uusien tietoteknisten menetelmien ja välineiden hyödyntämiseen.

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Taltioni teknisen alustan arviointi

Taltioni teknisen alustan arviointi Taltioni teknisen alustan arviointi Taltioni sidosryhmätilaisuus, 10.1.2012 Jaakko Lähteenmäki, Niilo Saranummi 1/11/2012 2 Selvitystyön kohde Selvitystyö: VTT & Fujitsu Keskeiset vaatimukset Taltioni-palvelulle?

Lisätiedot

T-111.361 Hypermediadokumentin laatiminen. Sisältö. Tavoitteet. Mitä on www-ohjelmointi? Arkkitehtuuri (yleisesti) Interaktiivisuuden keinot

T-111.361 Hypermediadokumentin laatiminen. Sisältö. Tavoitteet. Mitä on www-ohjelmointi? Arkkitehtuuri (yleisesti) Interaktiivisuuden keinot T-111.361 Hypermediadokumentin laatiminen -Ohjelmointi Peruskäsitys www-ohjelmoinnin kentästä Tekniikat interaktiivisuuden toteuttamiseen tekniikat tekniikat Tietokannat Juha Laitinen TKK/TML juha.laitinen@hut.fi

Lisätiedot

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

Lisätiedot

LIITE 2: Jyväskylän Kankaan alueen palveluiden hallinta- ja toimintamallit

LIITE 2: Jyväskylän Kankaan alueen palveluiden hallinta- ja toimintamallit 1/7 LIITE 2: Jyväskylän Kankaan alueen palveluiden hallinta- ja toimintamallit 2/7 Sisällysluettelo Palveluiden hallinta- ja toimintamallit Aluepalveluyhtiö Jatkuva elinkaaren hallinta ja kehittäminen

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri Järjestelmäarkkitehtuuri (TK081702) ja Järjestelmäarkkitehtuuri Sovellukset ovat olemassa Järjestelmien uudistaminen vie yleensä arvioitua enemmän resursseja ja kestää arvioitua kauemmin Migration (Migraatio

Lisätiedot

Kansallinen digitaalinen kirjasto Käyttöliittymä Finna. 12.12.2012 Aki Lassila / Kehittämispäällikkö / Kirjastoverkkopalvelut

Kansallinen digitaalinen kirjasto Käyttöliittymä Finna. 12.12.2012 Aki Lassila / Kehittämispäällikkö / Kirjastoverkkopalvelut Kansallinen digitaalinen kirjasto Käyttöliittymä Finna 12.12.2012 Aki Lassila / Kehittämispäällikkö / Kirjastoverkkopalvelut Finna tehostaa ja mahdollistaa Finnan kehittämisen myötä KDK:sta tulee: Tiedon

Lisätiedot

582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus

582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus 582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus Sisältö Mikä on web-sovellus? Selaimen rooli web-sovelluksessa Palvelimen rooli web-sovelluksessa Aineistopyynnöt Tiedon välittäminen

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

Testausautomaation mahdollisuudet käyttöliittymän testauksessa. Anssi Pekkarinen 5.11.2015

Testausautomaation mahdollisuudet käyttöliittymän testauksessa. Anssi Pekkarinen 5.11.2015 Testausautomaation mahdollisuudet käyttöliittymän testauksessa Anssi Pekkarinen 5.11.2015 Agenda Kustannustehokkaan testausautomaation tekemiseen vaikuttavat tekijät Käyttöliittymätestauksen haasteet Uudet

Lisätiedot

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000 Case TUHTI 17.12.2002 1 TietoEnator 2002 Projektin tunnuslukuja! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999! Otettu tuotantokäyttöön syksyllä 2001! Proof of Concept (5 henkilöä 4 kk) ->

Lisätiedot

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari

Lisätiedot

Uuden sukupolven verkko-oppimisratkaisut 15.2.2012 Jussi Hurskainen

Uuden sukupolven verkko-oppimisratkaisut 15.2.2012 Jussi Hurskainen Uuden sukupolven verkko-oppimisratkaisut 15.2.2012 Jussi Hurskainen Arcusys Oy Toimivan johdon omistama tietotekniikan palveluyritys Perustettu vuonna 2003 Henkilöstö 48 ohjelmistoalan ammattilaista Asiakkaina

Lisätiedot

Yhteisöllisen tuotekehyksen avoin verkkolaboratorio. Asta Bäck

Yhteisöllisen tuotekehyksen avoin verkkolaboratorio. Asta Bäck Yhteisöllisen tuotekehyksen avoin verkkolaboratorio Asta Bäck Sosiaalisen median mahdollisuuksia Palvelu voi rakentua kokonaan käyttäjien tuottaman aineiston ja käyttäjien aktiviteetin ympärille Flickr

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia

Lisätiedot

Ohjelmistoteknologioiden koulutus: Web-sovelluskehitys, Java Server. Infotilaisuus 3.12.2014 klo 10:00

Ohjelmistoteknologioiden koulutus: Web-sovelluskehitys, Java Server. Infotilaisuus 3.12.2014 klo 10:00 Ohjelmistoteknologioiden koulutus: Web-sovelluskehitys, Java Server Infotilaisuus 3.12.2014 klo 10:00 Yleistä Ohjelmistoteknologioiden koulutukset 2014-2015 3: Internet sovellusten ohjelmointi Java Server

Lisätiedot

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta.

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Malli-näkym kymä-ohjain arkkitehtuurit (Model-View View-Controller, MVC) Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Lähtökohdat: Sovelluksen

Lisätiedot

Onnistunut ohjelmistoprojekti

Onnistunut ohjelmistoprojekti Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden

Lisätiedot

Soveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen

Soveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen Soveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen ohjelmointiin Jukka Talvitie Valvoja: Professori Jorma Jormakka Paikka: TietoEnator oyj Ongelma Ideologia Lifebelt

Lisätiedot

Tekninen suunnitelma - StatbeatMOBILE

Tekninen suunnitelma - StatbeatMOBILE Tekninen suunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 13.12.2013 Pöyry Alustava rakenne ja sisältö 1.1 22.12.2013 Pöyry Lisätty tekstiä ilmoituksiin, turvallisuuteen ja sisäiseen API:in

Lisätiedot

Software product lines

Software product lines Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product

Lisätiedot

KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma

KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma Strateginen selvityshanke Eila Niemelä 1 Lähtökohta Selvitys suomalaisen teolllisuuden komponenttipohjaisten ohjelmistojen kehittämisestä ja

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

Toteutusvaihe T2 Edistymisraportti

Toteutusvaihe T2 Edistymisraportti Toteutusvaihe T2 Edistymisraportti Sisällysluettelo 1. Projektin tila...3 1.1. Suoritetut tehtävät...4 1.2. Käytetyt menetelmät...5 1.3. Ongelmat...6 1.4. Jatkosuunnitelmat...6 Versio- ja muutoshistoria

Lisätiedot

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3 Tuotekonfigurointi ADE Oy lyhyesti Asiakkaiden tarpeisiin suunnattua innovatiivista ja toimivaa ohjelmisto- ja 3d animaatiopalvelua. Ade Oy on toteuttanut vuodesta 2000 alkaen haastavaa interaktiivista

Lisätiedot

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

Tietokantojen suunnittelu, relaatiokantojen perusteita

Tietokantojen suunnittelu, relaatiokantojen perusteita Tietokantojen suunnittelu, relaatiokantojen perusteita A277, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin

Lisätiedot

Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin

Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin TEKNILLINEN KORKEAKOULU / VAASAN YLIOPISTO Diplomityöesitelmä Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin Timo Ahola 2006 Web sovellus Web palvelut joiden avulla laite voidaan liittää

Lisätiedot

J2EE vs..net Olli Sakari

J2EE vs..net Olli Sakari TEEMA-ARTIKKELI J2EE vs..net Olli Sakari J2EE ja.net ovat tietojärjestelmäteknologioita, joiden varaan suuri osa tulevaisuuden tietojärjestelmistä tulee rakentumaan. Molemmat teknologioista tarjoavat välineitä

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet Järjestelmäarkkitehtuuri (TK081702) Ympäristö Muutostarpeet ja niihin vastaaminen Yritysarkkitehtuuri Liiketoiminta-arkkitehtuuri Tavoitteet, Palvelut, Prosessit Informaatioarkkitehtuuri Tietotarpeet,

Lisätiedot

Pedacode Pikaopas. Web-sovelluksen luominen

Pedacode Pikaopas. Web-sovelluksen luominen Pedacode Pikaopas Web-sovelluksen luominen Pikaoppaan sisältö Pikaoppaassa kuvataan, miten Netbeans-työkalulla luodaan uusi yksinkertainen web-sovellus ja testataan sen toiminta. Opas kattaa kaiken aiheeseen

Lisätiedot

Internet-pohjainen ryhmätyöympäristö

Internet-pohjainen ryhmätyöympäristö Menetelmäohje Internet-pohjainen ryhmätyöympäristö Riku Hurmalainen, 24.3.2002 Sisällysluettelo 1. Johdanto...3 2. Termit...4 3. Toteutus...5 3.1. Yleiskuvaus...5 3.2. Tekninen ratkaisu...5 3.3. Tietoturva...6

Lisätiedot

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Fiksumpi käyttöliittymä kuntaan Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Otso Kivekäs 20.8.2015 Otso Kivekäs+ Codento Kehittämispäällikkö, kunta-alan projektit

Lisätiedot

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op FT Ari Viinikainen Tietokoneen rakenne Keskusyksikkö, CPU Keskusmuisti Aritmeettislooginen yksikkö I/O-laitteet Kontrolliyksikkö Tyypillinen Von Neumann

Lisätiedot

AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin

AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin Raimo Nikkilä Aalto-yliopiston sähkötekniikan korkeakoulu - Automaation tietotekniikan tutkimusryhmä 17. tammikuuta 2013

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,

Lisätiedot

Amazon Web Services (AWS) on varmaankin maailman suosituin IaaS-tarjoaja. Lisäksi se tarjoaa erilaisia PaaS-kategoriaan kuuluvia palveluita.

Amazon Web Services (AWS) on varmaankin maailman suosituin IaaS-tarjoaja. Lisäksi se tarjoaa erilaisia PaaS-kategoriaan kuuluvia palveluita. 1 2 Amazon Web Services (AWS) on varmaankin maailman suosituin IaaS-tarjoaja. Lisäksi se tarjoaa erilaisia PaaS-kategoriaan kuuluvia palveluita. 3 4 Region vastaa palvelun fyysistä sijaintipaikkaa (AWS

Lisätiedot

Vuorekseen liittyvä tutkimusja kehitysprojekti. Langaton Vuores. Kotikatupalvelin

Vuorekseen liittyvä tutkimusja kehitysprojekti. Langaton Vuores. Kotikatupalvelin Vuorekseen liittyvä tutkimusja kehitysprojekti Langaton Vuores Kotikatupalvelin Tutkimuksen tausta Langaton tietoliikenne on arkipäivää Personoidut päätelaitteet (taskutietokone, matkapuhelin, kannettava

Lisätiedot

Pedacode Pikaopas. Java-kehitysympäristön pystyttäminen

Pedacode Pikaopas. Java-kehitysympäristön pystyttäminen Pedacode Pikaopas Java-kehitysympäristön pystyttäminen Pikaoppaan sisältö Pikaoppaassa kuvataan, miten Windowstyöasemalle asennetaan Java-ohjelmoinnissa tarvittavat työkalut, minkälaisia konfigurointeja

Lisätiedot

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure Automaattinen regressiotestaus ilman testitapauksia Pekka Aho, VTT Matias Suarez, F-Secure 2 Mitä on regressiotestaus ja miksi sitä tehdään? Kun ohjelmistoon tehdään muutoksia kehityksen tai ylläpidon

Lisätiedot

Juhani Gurney Teknologiajohtaja. Peppi-projekti ja ESP (Eduix SOA Platform)

Juhani Gurney Teknologiajohtaja. Peppi-projekti ja ESP (Eduix SOA Platform) Juhani Gurney Teknologiajohtaja Peppi-projekti ja ESP (Eduix SOA Platform) Peppi-projekti Projekti aloitettu keväällä 2010 Projektin tehtävänä on määritellä, suunnitella ja toteuttaa uusi koulutuksen suunnittelutyökalujen

Lisätiedot

Microsoft Dynamics CRM 4.0. Jani Liukkonen

Microsoft Dynamics CRM 4.0. Jani Liukkonen Microsoft Dynamics CRM 4.0 Jani Liukkonen Microsoft Dynamics CRM kokonaisuus Täysi CRM toiminnallisuus ja joustavuus Vuorovaikutukset -Markkinointi Myynti -Asiakaspalvelu xrm -Prosessituki SOA -Joustava

Lisätiedot

WEBINAARIN ISÄNNÄT. Jarno Wuorisalo Cuutio.fi. Petri Mertanen Superanalytics.fi. Tomi Grönfors Brandfors.com

WEBINAARIN ISÄNNÄT. Jarno Wuorisalo Cuutio.fi. Petri Mertanen Superanalytics.fi. Tomi Grönfors Brandfors.com WEBINAARI 3.11.2015 Mitä Tag Management on käytännössä ja miten se vaikuttaa analytiikkaan? Petri Mertanen, Super Analytics - @mertanen Jarno Wuorisalo, Cuutio - @jarnowu Tomi Grönfors, Brandfors - @groenforsmethod

Lisätiedot

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Arkkitehtuuriin vaikuttavat ympäristötekijät Jo kehittämisen alkuvaiheessa on tarpeellista hahmotella arkkitehtuurin perusratkaisu. Lähtökohdat

Lisätiedot

työryhmien SharePoint-yhteistyötä helpottava ratkaisu

työryhmien SharePoint-yhteistyötä helpottava ratkaisu työryhmien SharePoint-yhteistyötä helpottava ratkaisu LIIKKEENJOHDON SUURIN HAASTE Modernin yrityksen on muutoksen kyydissä pysyäkseen suunniteltava tehokas strategia ja seurattava sitä. Siinä piilee kuitenkin

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen Tietojärjestelmä tuotantoympäristössä Tausta ja tavoitteet Tausta Kurssilla on opiskeltu suunnittelemaan ja toteuttamaan tietokanta, joka on pieni perustuu selkeisiin vaatimuksiin on (yleensä) yhden samanaikaisen

Lisätiedot

- Jarjestelmaasiantuntija Markku Jaatinen

- Jarjestelmaasiantuntija Markku Jaatinen SUOMEN KUNTALIITTO Sairaalapalvelut Terveydenhuollon ATK-päivät 26. - 27.5.1 997 Lahti, Kauppahotelli Grand - Jarjestelmaasiantuntija Markku Jaatinen Telecom Finland Tietojenhallinta Intranetin ja Internetin

Lisätiedot

S11-09 Control System for an. Autonomous Household Robot Platform

S11-09 Control System for an. Autonomous Household Robot Platform S11-09 Control System for an Autonomous Household Robot Platform Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Quang Doan Lauri T. Mäkelä 1 Kuvaus Projektin tavoitteena on

Lisätiedot

Android ohjelmointi. Mobiiliohjelmointi 2-3T5245

Android ohjelmointi. Mobiiliohjelmointi 2-3T5245 Android ohjelmointi Mobiiliohjelmointi 2-3T5245 Mikä on Android? Linux kernelin päälle rakennettu, Googlen kehittämä sovelluspino mobiilisovelluksiin Erillinen versio puhelimelle ja taulutietokoneille

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy. 2005 Mermit Business Applications

Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy. 2005 Mermit Business Applications Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy Esityksen sisältö Mermit yrityksenä Perustiedot Toimintamalli Mermit työpaikkana ohjelmistoinsinöörille Esimerkkiprojekti

Lisätiedot

Microsoft Visual Studio 2005

Microsoft Visual Studio 2005 Microsoft Visual Studio 2005 on integroitu kehitysympäristö (Integrated Development Environment) eli (IDE). Kehitysympäristöön kuuluvat seuraavat keskeiset sovelluskehitysvälineet: Ohjelmointikielet C#.NET

Lisätiedot

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlin Systems Oy Kommunikaatiokartoitus päätöksenteon pohjaksi Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlinin palvelujen toimittaminen ja Asiakasratkaisuyksikön tehtäväkenttä Merlin Asiakasratkaisut

Lisätiedot

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit Viestinvälitysarkkitehtuurit

Lisätiedot

asapflow - Yksinkertaistetut työprosessit saumattomalla yhteydellä SharePointiin ja SAP-järjestelmään

asapflow - Yksinkertaistetut työprosessit saumattomalla yhteydellä SharePointiin ja SAP-järjestelmään asapflow - Yksinkertaistetut työprosessit saumattomalla yhteydellä SharePointiin ja SAP-järjestelmään 2 asapflow Saumaton yhteys SharePointista SAP-järjestelmään asapflow on ADSOTECHin kehittämä sovellusperhe,

Lisätiedot

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

Ohjelmistojen testaus ja hallinta. Gradle

Ohjelmistojen testaus ja hallinta. Gradle Ohjelmistojen testaus ja hallinta Gradle Perinteiset koontityökalut Ant Maven 2 Maven XML-pohjaiset koontitiedostot (pom.xml) Pohjautuu käytäntöihin (vain poikkeukset käytännöistä kirjoitetaan koontitiedostoon)

Lisätiedot

Automaatio mahdollistaa Software as a Service - arkkitehtuurin

Automaatio mahdollistaa Software as a Service - arkkitehtuurin Automaatio mahdollistaa Software as a Service - arkkitehtuurin Softatyön trendit 11.6.2015 käytännön kokemuksia kehittämistyöstä Jussi Haaja Senior Systems Specialist Twitter @jussihaaja Esityksen sisältö

Lisätiedot

Portaaliteknologiat mahdollistavat ajattelutavan muutoksen

Portaaliteknologiat mahdollistavat ajattelutavan muutoksen - 1 - Portaaliteknologiat mahdollistavat ajattelutavan muutoksen Petri Kanerva Fusion Middleware Architect, Oracle Finland Oy 29.04.2010 The following is intended to outline our general

Lisätiedot

Arkkitehtuuri muutosagenttina

Arkkitehtuuri muutosagenttina Arkkitehtuuri muutosagenttina Smarter Processes, Development & Integration Hannu Salminen CTO OP-Pohjola 2013 IBM Corporation Taustaa Nykyinen IT-arkkitehtuuri ja liiketoimintatarpeet eivät kohtaa OP-Pohjolan

Lisätiedot

Suunnittelumallien käyttö ohjelmistosuunnittelussa

Suunnittelumallien käyttö ohjelmistosuunnittelussa Suunnittelumallien käyttö ohjelmistosuunnittelussa Mika Rantakeisu Rovaniemen ammattikorkeakoulu Avoin ammattikorkeakoulu mika.rantakeisu@edu.ramk.fi Tiivistelmä Tämä on selvitys suunnittelumallien käytöstä

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (6) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

1. Olio-ohjelmointi 1.1

1. Olio-ohjelmointi 1.1 1. Olio-ohjelmointi 1.1 Sisällys Olio-ohjelmointi on eräs ohjelmointiparadigma. Olio-ohjelmoinnin muotoja. Ohjelmiston analyysi ja suunnittelu. Olioparadigman etuja ja kritiikkiä. 1.2 Ohjelmointiparadigmoja

Lisätiedot

TIETOTEKNIIKAN KOULUTUSOHJELMA

TIETOTEKNIIKAN KOULUTUSOHJELMA TIETOTEKNIIKAN KOULUTUSOHJELMA Tietotekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Tietotekniikan koulutusohjelmasta valmistuneet insinöörit sijoittuvat suunnittelu-, ohjelmointi-, esimies-,

Lisätiedot

Web-palveluiden alusta Axis2

Web-palveluiden alusta Axis2 Web-palveluiden alusta Axis2 Aki Heikkinen Ohjaaja: Raimo Rask Itä-Suomen yliopisto, Tietojenkäsittelytieteen laitos Suullisen esittämisen seminaarin kirjallinen tukimateriaali 15. helmikuuta 2010 Tiivistelmä

Lisätiedot

VALDA-tietojärjestelmän j versio 1

VALDA-tietojärjestelmän j versio 1 VALDA-tietojärjestelmän j versio 1 Mitä palveluita tarjotaan VALDA-tietojärjestelmän ensimmäisestä versiosta? Mitä hyötyä saat tästä organisaatiollesi? IBM, Helsinki 14.5.2009 Hankepäällikkö Toini Salmenkivi

Lisätiedot

Ohjelmiston testaus ja laatu. Testaustasot

Ohjelmiston testaus ja laatu. Testaustasot Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu

Lisätiedot

Palvelumuotoilu ja muotoiluajattelu bisneksessä

Palvelumuotoilu ja muotoiluajattelu bisneksessä Palvelumuotoilu ja muotoiluajattelu bisneksessä Hanna-Riina Vuontisjärvi Projektipäällikkö/ Palvelumuotoilija Lapin yliopisto, Taiteiden Tiedekunta hanna-riina.vuontisjarvi@ulapland.fi Mitä palvelumuotoilija

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi

Lisätiedot

AS-0.3200 Automaatio- ja systeemitekniikan projektityöt

AS-0.3200 Automaatio- ja systeemitekniikan projektityöt AS-0.3200 Automaatio- ja systeemitekniikan projektityöt A11-17 Ikäihmisten kotona asumista tukevien järjestelmien kehittäminen AikatauluValpas Salla Ojala Paula Laitio 1. Projektin tavoite Projektimme

Lisätiedot

17/20: Keittokirja IV

17/20: Keittokirja IV Ohjelmointi 1 / syksy 2007 17/20: Keittokirja IV Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/10 Tavoitteita

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013 Virtualisointi Pertti Pennanen DOKUMENTTI 1 (5) SISÄLLYSLUETTELO Virtualisointi... 2 Virtualisointiohjelmia... 2 Virtualisointitapoja... 2 Verkkovirtualisointi... 2 Pertti Pennanen DOKUMENTTI 2 (5) Virtualisointi

Lisätiedot

Ohjelmistokehykset ohjelmistorunkoja uudelleenkäyttö olioperustaisista ohjelmistorunko

Ohjelmistokehykset ohjelmistorunkoja uudelleenkäyttö olioperustaisista ohjelmistorunko Ohjelmistokehykset Määritelmä & tavoitteet, taustaa & peruskäsitteitä, kehykset vs. suunnittelumallit, erikoistamisrajapinnat & kontrollinkulku, kehystyypit, kehysten rakenne ja evoluutio, esimerkki: JHotDraw,

Lisätiedot

Verkkopalveluiden saavutettavuus

Verkkopalveluiden saavutettavuus Verkkopalveluiden saavutettavuus Puhuja: Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Paikka: Helsinki, Tieteiden talo, 24.3.2011 Johdanto Verkkopalvelun saavutettavuus

Lisätiedot

Paloilmoitusjärjestelmän laajennusratkaisu - Sinteso Move

Paloilmoitusjärjestelmän laajennusratkaisu - Sinteso Move www.siemens.fi/paloturvallisuus Paloilmoitusjärjestelmän laajennusratkaisu - Sinteso Move Yhdistä nykyinen paloilmoitusjärjestelmäsi Sintesoon. Se on palontorjunnan uusi ulottuvuus. Infrastructure & Cities

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) AJAX, Asynchronous JavaScript And XML. AJAX, Asynchronous JavaScript And XML

Järjestelmäarkkitehtuuri (TK081702) AJAX, Asynchronous JavaScript And XML. AJAX, Asynchronous JavaScript And XML Järjestelmäarkkitehtuuri (TK081702) Ajax 2000-luvun alkuvuosina selainsotien rauhoituttua ohjelmistotalot alkoivat kehittää selainten luoman uuden ohjelmointiympäristön käyttötapoja. Syntyi AJAX (Asynchronous

Lisätiedot

KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka. Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012

KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka. Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012 KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012 SISÄLLYS 1 JOHDANTO 3 2 WWW-PALVELIMEN TOIMINTA 4 3 OMINAISUUDET

Lisätiedot

Avoimet standardit ja integraatio

Avoimet standardit ja integraatio Avoimet standardit ja integraatio Avoimet standardit ja integraatio Trendin ainutlaatuinen lähestymistapa avoimiin standardeihin ja integraatioon tarjoaa odottamasi hyödyt, sekä markkinoiden johtavat innovaatiot

Lisätiedot