Kategoria: sovelluskehitys

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 2

Kesälomat ovat jo kaukana takana ja paluu arkeen on todellisuutta sekä töiden että osaamisen kehittämisen osalta. Hieman lomien jälkeen jatkui myös Tieturin ”Tietojärjestelmäarkkitehdin valmennusohjelma” -kurssi, jonka ensimmäinen osa pidettiin alkukesästä. Keinoja ja ratkaisuja erinomaiseen arkkitehtuuriratkaisuun pääsemiseksi esittelevän kurssin ensimmäinen osio käsitteli tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja, laatuatribuutteja, arkkitehtuurikehyksiä ja 4+1 -mallia. Toinen osio jatkoi aihepiirin käsittelyä muun muassa suunnittelumalleilla, integraatioilla, SOA:lla, tietoturvalla ja arkkitehtuurin arvioinnilla ja dokumentoinnilla. Kuuden päivän kokonaisuus oli aikamoinen annos aiheeseen liittyviä otsikoita ja ajateltavaa ja tarjosikin lähinnä paljon lähtökohtia lisäopiskelulle, eikä niinkään käsitellyt miten asioita pitäisi tehdä. Eli hyvä yleiskatsaus aihepiiriin ja ajattelemisen aihetta tarjoava.

4+1 -mallin kaavioita tilanvarausjärjestelmästä

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 2

Tietojärjestelmäarkkitehdin valmennusohjelman ensimmäisen osion jälkeen tunnelmat kurssista olivat aika teoriapainotteiset, mutta laajan aihepiirin käsittely konkreettisemmin olisi vaatinut vähintään pari päivää per aihepiiri, joten sinällään kurssin yleiskatsauksen omainen lähestyminen aiheeseen oli toimiva. Mutta silti odotukset kurssin jälkimmäiseltä osiolta olivat hieman enemmän. Lupasihan kurssikuvaus, että ”valmennusohjelman suoritettuaan osallistuja osaa tietojärjestelmäarkkitehdin työn kannalta systemaattiset toimintatavat ja merkittävät välineet.”.

Erinomaisen arkkitehtuuriratkaisun saavuttamiseksi keinoja ja ratkaisuja esittelevän kurssin toinen osio jatkoi aihepiirin käsittelyä muun muassa suunnittelumalleilla, integraatioilla, SOA:lla, tietoturvalla ja arkkitehtuurin arvioinnilla, valvonnalla ja dokumentoinnilla. Suurilta osin aihepiirit olivat tuttuja, mutta uusia keinoja parhaiden käytäntöjen metodeihin, arkkitehtuurin arviointiin ja sen testaukseen kyllä ilmeni.

Osa 2, päivä 1:

  • Parhaita käytäntöjä arkkitehtuurisuunnitteluun
    • Attribute Driven Development method (ADD), ketterän arkkitehtuurin suunnittelu, ketterän tiimin suunnittelukäytännöt

Kurssin neljäs päivä alkoi ryhmien saamien kotitehtävien läpikäynnillä, jonka harmillisesti oli tehnyt vain kaksi viidestä ryhmästä. Tehtävänä oli hyödyntää 4+1 -mallia jonkin järjestelmän, keksityn tai olemassa olevan, kuvaamiseen. Ryhmäni suunnitteli kuvitteellisen ”neuvottelutilojen tilanvarauksen ja käytönseurannan integraatio” -sovelluksen, jonka idea oli tehostaa neuvotteluhuoneiden käyttöä. Olimme kuvanneet konteksti-, prosessi-, komponentti- ja sijoittelukaaviot, joista keskustelimme lyhyesti. Olisi ollut kiva nähdä useampienkin ryhmien ratkaisuja, mutta muuten harjoitus oli mielenkiintoinen ideointihetki.

Loppuaika neljännestä päivästä käytiin läpi arkkitehtuurisuunnittelun parhaita käytäntöjä muun muassa toiminnallisten vaatimusten hyödyntämisessä, arkkitehtuurin oikeellisuuden ja suorituskyvyn aikaisessa testauksessa ja käsiteltiin anti-patterneja. Monta maalaisjärjellä perusteltavaa asiaa, mutta todellisuudessa kuitenkin yllättävän hankalia käytännössä viedä läpi, kuten arkkitehtuurin muuttaminen sen osoittautuessa huonoksi, prototyyppien tekeminen tai aloittaminen liian isosti. Harjoituksena käytiin läpi ADD:tä elokuvateatterin lipunvarausjärjestelmän laatuattribuuttien osalta, joista esille nostettiin monikanavaisuus, skaalautuvuus, tietoturva, laajennettavuus, avoimuus, saatavuus, muunneltavuus ja jäljitettävyys. Nykytrendien mukaisesti keskusteltiin myös ketterästä kehityksestä ja sen suhteesta arkkitehtuurisuunnittelun. Vaikka Scrum-projektissa arkkitehtuuri tehdään ”just in time”, on sprint 0 ja ennakkosuunnittelu tärkeää ja projektin alkuvaiheessa painottuu arkkitehtuurin osuus väheten loppua kohden.

Osa 2, päivä 2:

  • Arkkitehtuurin testaaminen
    • Testaamisen ajoittaminen, testaamisessa huomioitavia seikkoja, suorituskyvyn testaaminen
  • Järjestelmien yhteensovittaminen
    • Tietojärjestelmäintegraation haasteet, löyhä kytkeytyvyys, tyypilliset integraatioratkaisut, integraatioarkkitehtuuri, palveluväylät (ESB)
  • Palveluarkkitehtuurin luominen (SOA)
    • Mitä SOA tarkoittaa?, avoin arkkitehtuuri, SOA arkkitehtuurin luominen, arkkitehtuurin toteuttaminen ja haasteet

Viidennen koulutuspäivän aluksi keskustelimme teknisestä velasta, jota tulee sekä tietoisesti että suunnittelun myötä. Jos velkaa on paljon, on sovellusta myöhemmin hankala tai mahdoton refaktoroida kuntoon. Päivän pääteemat olivat kuitenkin arkkitehtuurin testaaminen, järjestelmien integrointi ja palveluarkkitehtuuri.

Sovelluskehitysprojekteissa testauksen rooli usein aliarvioidaan. Testauksenkin osalta pätee 80/20 sääntö, eli 80 prosenttia ongelmista korjataan testaamalla avainvaatimuksia säännöllisesti ja 20 prosenttia ongelmista on haastavia ja hankalia löytää. Ongelmana usein on myös laadukas testiaineisto ja sen määrä. Testaukseen liittyy myös suorituskyvyn arviointi ja nyrkkisääntönä voidaan pitää, että kannattaa varata 3,14 kertaa enemmän kapasiteettia kuin vaadittu. Toiminnallisen testauksen lisäksi pitää huolehtia suorituskyvyn testauksesta, jota käsiteltiin komponenttien ja koodin osalta. Tarjolla on useita avoimen lähdekoodin testausvälineitä, joista mainittiin muun muassa jMechanic ja JProfiler . Lisäksi lyhyesti esiteltiin kaupallista Compuwaren Application Monitoring -tuotetta (entinen dynaTrace). Testauksessa on hyvä muistaa Heisenbergin epämääräisyysperiaate, joka soveltaen on: ”Et voi suorittaa mittausta vaikuttamatta mitattavaan kohteeseen”.

Päivän muut aiheet olivat palvelusuuntautuneisuutta tukeva arkkitehtuurityyli eli SOA ja sovellusten integraatio. Tässä palvelu on looginen esitystapa toistuville liiketoiminnan aktiviteeteille, joilla on määritelty lopputulos, eli se on itsenäinen (itseriittoinen), voi koostua muista palveluista ja on musta laatikko kuluttajilleen. SOA:n rakentaminen pitäisi lähteä liiketoiminnan prosessien tietojärjestelmien tarpeista ja tuottaa aina liiketoiminta-arvoa. Ei kannata myöskään unohtaa, että SOA on kuin koiranpentu, joka vaatii jatkuvaa valvontaa, hoitoa, selkeitä rajoja ja vastuuhenkilöä, eli johtamista. Lisäksi sivuttiin REST-palvelun versiointia ja kuvaamista, kun käytössä ei ole WSDL:ää kuten SOAP-palveluissa. Sovellusten integraatioista käsiteltiin muun muassa erilaisia suunnittelumalleja kuten julkaise-tilaa (Twitter, RSS), sanomaväylät (SETI), vastaavuustunniste (laskun viitenumero), prosessimanageri, sanomakeskus (SMS) ja sääntöjen mukainen tietomalli.

Osa 2, päivä 3:

  • Teknologia-arkkitehtuuri
    • Teknologia-arkkitehtuuri mahdollistajana, liiketoimintalähtöinen teknologia-arkkitehtuuri, teknologioiden hallinta sekä valinta, teknologia-arkkitehtuurin suunnittelu
  • Lisensointimallit
    • Arkkitehtuuri ja lisenssit, Open Source -tuotteet sekä sovelluskehykset, näkökulmia lakiasioihin
  • Tietoturva-arkkitehtuuri
    • Tietoturvan näkökulmat ja tasot, vyöhykkeinen tietoturva, tietoturvan perustekniikat, tietoturvasuunnittelun peruspilarit
  • Arkkitehtuurin käytön valvonta
    • arkkitehtuurin käytön ohjeistus, arkkitehtuurin käytön katselmointi
  • Arkkitehtuurin arvioiminen
    • Arkkitehtuurin laatukriteerit, arkkitehtuurin arvioiminen, Architecture Tradeoff Analysis Method (ATAM) -metodi, Cost Benefit Analysis Method (CBAM)
  • Arkkitehtuurin dokumentoiminen
    • Arkkitehdin rooli dokumentoijana, arkkitehtuurin dokumentoiminen UML-kielellä, muita dokumentoinnin välineitä
  • Arkkitehtuurin hallinnointi
    • Arkkitehtuurin toteutus, arkkitehtuurin muutoshallinta, arkkitehtuuriorganisaatio, vaaditut prosessit

Kurssin viimeinen eli kuudes päivä sisälsi paljon eri aihepiirejä ja alkoi harjoituksella, jossa käytiin läpi sovellus- ja teknologia-arkkitehtuurin yhteyttä ja miten teknologia-arkkitehtuuri täyttää järjestelmän laatuvaatimukset. Teknologia-arkkitehtuurin rooli on mennä syvemmälle ja tarkemmalle tasolle, sekä se voi olla jo olemassa ja sanella asioita sovellusarkkitehtuurille. Tarkoituksena on taata järjestelmän rakennuspalikoiden yhteensopivuus ja dokumentoida valitut teknologiastandardit. Teknologia-arkkitehtuurin suunnittelusta käsiteltiin siihen liittyvät eri vaiheet: lähtötason kuvaaminen, näkökulmien ja työvälineiden valinta, tavoitearkkitehtuurin luominen, liiketoiminnan tarpeiden täyttymisen varmistaminen ja nyky- ja tavoitetilan kuilun analyysi. Teknologiasta olikin hyvä siirtyä lisensseihin ja avoimen lähdekoodin sovelluksiin, joista lähinnä mainittiin, että niitä on moneen lähtöön. Parempi olla tarkkana.

Tietoturva-arkkitehtuuria käsiteltiin sentään hieman laajemmin ja siitä on hyvä muistaa seuraavat kirjaimet: C = Confidentiality, I = Integrity, A = Availability. Arkkitehti valitsee miten tietoturvateknologioita ja työvälineitä käytetään tietoturvan toteuttamiseksi ja tietoturva-arkkitehtuurin rakennuspalikoita ovat: henkilöstön tietoturva tietoisuus ja koulutus, käyttäjähallinta, autorisointi ja autentikointi, toimien vahvistaminen, kriittisten osien eristäminen, tunkeutumisen havaitseminen ja estäminen, salaustekniikoiden käyttäminen ja virustorjunta. Lisäksi kerrottiin OWASP Top 10 -ongelmakohtien listauksesta (pdf) ja ettei kannata jäädä kymmeneen, sillä maailma muuttuu jatkuvasti. Aiheeseen liittyen tehtiin harjoitus elokuvateatterin lippujärjestelmän potentiaalisista tietoturvariskeistä ja niiden hallinnasta.

Tietojärjestelmän arkkitehtuurin voi suunnitella monella eri tavalla, eikä yhtä oikeaa ratkaisua ole, joten arkkitehtuuriratkaisun arviointi on tärkeää. Parasta se olisi suorittaa jo etukäteen, eikä vasta jälkeenpäin, vaikka se tällöin onkin helpompaa. Arvioida voi muun muassa ylläpidettävyyttä ja uusien ominaisuuksien ja bugien korjaamisen helppoutta ja nopeutta. Yksi keino tähän on käyttää ATAM:ia (Architecture Tradeoff Analysis Method) ja CBAM:ia (Cost Benefit Analysis Method), joita voidaan soveltaa arkkitehtuuria luodessa, kun projekti on ongelmissa ja jo olemassa olevaan arkkitehtuuriin.

Yhteenveto

Tietojärjestelmän arkkitehtuurin suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Tieturin tietojärjestelmäarkkitehdin valmennusohjelma antaa hyvän yleiskuvan laajasta aihealueesta ja on kokonaisuutena aikamoinen annos aiheeseen liittyviä otsikoita ja ajateltavaa. Kurssi tarjosikin lähinnä paljon lähtökohtia lisäopiskelulle, eikä tarkemmin käsitellyt miten asioita pitäisi tehdä, joka olisikin ollut kurssin aikataulun ja aihepiirin laajuuden osalta mahdotonta.

Olisin itse kuitenkin kaivannut ehkä enemmän konkreettisempaa lähestymistä, jota kurssin neljäntenä ja viidentenä päivänä olikin hieman enemmän. Jos kurssista pitäisi mainita yksi mieleen jäänyt asia, on se 4+1 -malli, jonka käyttämistä arkkitehtuurin suunnittelussa käytiin läpi enemmän ja muita aihealueita sipaistaan siihen verrattuna suhteellisen pintapuolisesti.

Kurssi antaa pohjatiedot myös Open Groupin Certified Architect (Open CA) (aikaisemmin ITAC) sertifikaatin ykköstason suorittamiseen (edulliseen 1250 dollarin hintaan), jota pitää harkita.

Yksi sovellus, kolme Java EE -käyttöliittymäkehystä

Sovelluskehityksessä käyttöliittymän rakentaminen ja käyttäjille näkyvien toimintojen toteuttaminen on yksi tärkeimmistä osuuksista, sillä hyväkin sovellus voi kaatua heikkoon käyttöliittymään. Java EE -sovelluskehityksessä on tarjolla useita erilaisia käyttöliittymäkehyksiä, jotka tarjoavat työkalut toimivan käyttöliittymän rakentamiseen, mutta käyttötarkoitukseen sopivan välineen valinta ei ole aina yksiselitteistä. Oli siis aika päivittää hieman tietoja erilaisten Java EE -käyttöliittymäkehysten osalta ja tutustua Vaadin 7:aan, Java Server Faces (JSF) 2:een PrimeFacesin kanssa ja Apache Wicket 6:een toteuttamalla yksinkertainen imgur-kuvaselaussovellus. Aikaisemmin olen kehittänyt sovelluksia käyttäen muun muassa Strutsia, JSF 1.2:sta ja Wicket 1.5:sta.

Java EE 6 -sovelluksia voi toteutta monella eri tekniikoilla ja tällä kertaa toteutin käyttöliittymäkerroksen usealla eri tavalla (Vaadin 7, JSF2, Wicket 6) ja pitäen taustapalvelut vakiona. Imgurin REST-APIn käsittelyyn käytin jokaisessa sovelluksessa Apache CXF:ää rajapinnan lukemiseen ja GSONia JSON-sanoman muuntamiseen Java-olioiksi. Vaikka kaikki kolme kehystä tukevat Java EE 6:n JSR 299 CDI:tä, tein Java Beanien injektoinnin Spring 3:lla, joka toimi varmasti myös vanhemman WebLogic 11g -sovelluspalvelimen kanssa. Jettyllä tai TomEE:llä ajettaessa ei olisi ollut mitään ongelmaa.

Sovellusten koodit löytyvät GitHubista (https://github.com/walokra/fotorest.git), vaikkakaan ne eivät ole mitenkään viimeisteltyjä. Ehkä niistä kuitenkin on jollekin hyötyä.

Sovellus 1: Vaadin 7

Vaadin on avoimen lähdekoodin Java-sovelluskehys Web-sovellusten rakentamiseen ja muistuttaa enemmän työpöytäsovellusten tekemistä esimerkiksi Java Swing -kehyksellä kuin perinteistä Web-sovelluskehitystä HTML:n ja JavaScriptin kanssa. Vaadin rakentuu Google Web Toolkitin päälle ja käyttää GWT:tä sivujen renderöintiin. Vaadin on suomalaisen Turussa pääkonttoriaan pitävän Vaadin Oy:n kehittämä. Vaadin 7 julkaistiin pari kuukautta sitten.

Vaadin tarjoaa perinteiselle Java-kehittäjälle helpomman lähestymisen Web-sovellusten kehittämiseen, kun käyttöliittymän rakentaminen onnistuu ilman HTML:n ja JavaScriptin kanssa askartelua. Vastaavasti HTML:ää osaavalle kehittäjälle Swing-tyylinen käyttöliittymän rakentaminen voi olla tuskastuttavaa. Vaadin tarjoaa itsessään kattavan valikoiman erilaisia käyttöliittymäkomponentteja ja erilaiset demot antavat hyvän kuvan mitä Vaatimella saa aikaan.

Yksinkertaisen imgur-selaajan toteutus Vaadin 7:lla luonnistui nopeasti, kun olin ensin sisäistänyt Swing-tyylisen käyttöliittymän idean. Toimivan ulkoasun ja muutamat toiminnot sai rakennettua suhteellisen helposti ja lopputuloksesta tuli siisti. Koska Vaadin-sovellus on käytännössä kasa Javascriptiä, on sen debuggaaminen hieman hankalampaa, mutta kehys tarjoaa avuksi kohtalaiset työvälineet (?debug-parametri). Käytin Vaatimen oletusteemaa, koska muut teemat eivät vielä uusinta versiota tukeneet. Uuteen kehykseen tutustumisessa auttoi myös Vaatimen laadukas dokumentaatio ja keskustelufoorumi, vaikkakin moni keskustelu ja netistä löytyvä esimerkki käsitteli aikaisempaa 6 versiota.

Fotorest-sovellus toteutettuna Vaadin 7:lla:
Fotorest Vaadin 7

Sovellus 2: JavaServer Faces 2 + PrimeFaces

JSF 2 eli Java Server Faces on Javan spesifikaatio Web-sovellusten komponenttipohjaisten käyttöliittymien rakentamiseen ja osa Java Enterprise Editionia. Sovellus koostuu HTML:ää ja Facelet-tageja sisältävistä -XML-tiedostoista, jotka kehys prosessoi ja tarjoilee käyttäjälle. JSF:n 2 -versio julkaistiin 2009 ja tuorein 2.2. versio huhtikuussa 2013.

Sovelluksen ulkoasun rakentaminen ei juurikaan eroa normaalista Web-kehityksestä, joten HTML ja CSS -osaaminen ovat tarpeen siistin käyttöliittymän aikaansaamiseksi. JSF:n tarjoamia ominaisuuksia ja komponentteja voi laajentaa muun muassa PrimeFaces tai RichFaces -komponenttikirjastoilla, joilla käyttöliittymään saa enemmän kilkettä ja parempaa käytettävyyttä.

JSF 2:n oli sovelluskehitysalustana suhteellisen tuttu, sillä olin käyttänyt sitä pienen prototyypin tekemiseen pari vuotta sitten, eikä vuosien aikana mikään ollut juuri muuttunut. Täten uutena asiana oli enemmänkin PrimeFaces -käyttöliittymäkomponenttien käyttäminen. Yksinkertainen kuvaselaaja syntyi lähes yhtä helposti kuin Vaadinta käytettäessä, vaikka osa toiminnoista piti koodata sivupohjiin ja osa Javan puolelle ja käyttöliittymän dynaamisessa päivittämisessä oli alkuun pieniä ongelmia. PrimeFaces tarjosi kattavan listan erilaisia käyttöliittymäkomponentteja ja niiden ulkoasua oli helppo muokata jQuery UIn ThemeRollerin avulla.

Fotorest-sovellus toteutettuna JSF 2 + PrimeFacesilla:
Fotorest JSF 2 + PrimeFaces

Sovellus 3: Apache Wicket 6

Apache Wicket on avoimen lähdekoodin komponenttipohjainen Web-sovelluskehys Javalle. Lyhyesti kuvattuna Wicket on kuin yhdistelmä Vaadin ja JSF -kehyksiä, sillä käyttöliittymä rakentuu HTML-sivupohjista ja tapahtumiin reakoivista komponenteista. Sovelluksen ulkoasun voi täten rakentaa HTML:llä ja lisätä toiminnot Javan puolelta juurikaan koskematta sivupohjiin. Wicket 6 julkaistiin syksyllä 2009.

Wicket ei JSF:n tavoin tarjoa peruskomponentteja enempää, mutta käyttöliittymän toiminnallisuuksien laajentamiseen voi käyttää useita jQuery-pohjaisia komponenttikirjastoja kuten Wicket – jQuery UI, jqwicket ja wiquery. Vaikka komponenttikirjastoja on useita, ovat niiden heikkous ajantasaisuus (esim. jqwicket vain 1.5 versiolle), eivätkä ne eivät ole aivan yhtä kattavia kuin mitä Vaadin tai JSF:n kirjastot tarjoavat.

Ideana HTML-sivupohjat ja työpöytäsovellusmaisen tapahtumapohjaisuuden yhdistelmä on hyvä, mutta jotenkin kokonaisuus ei ole yhtä miellyttävä kuin JSF 2 tai Vaadin. Kehittäjän kannalta Wicketissä on monia hyviä puolia, kuten toimintojen liittäminen komponentteihin ja niiden uudelleenkäyttö on kätevämpää kuin JSF 2:ssa ja sovelluksen kehittäminen on kohtalaisen selkeää, kun toiminnot ovat yhdessä paikassa eikä sekä sivupohjassa että Java-luokassa kuten JSF 2:ssa. Itseäni eniten Wicketin osalta harmittaa kuitenkin kattavien komponenttikirjastojen puute, joka tekee käyttöliittymän toiminnallisuuksien rakentamisesta hieman työlästä, kun asiat joutuu toteuttamaan itse. Yksinkertaista kuvaselaajaakin varten piti tehdä muutamia lisäluokkia, eikä valmista loputtomasti skrollaavaa taulukkokomponenttia ollut saatavilla.

Fotorest-sovellus toteutettuna Wicket 6:lla:
Fotorest Wicket 6

Yhteenveto

Kolme Java EE -käyttöliittymäkehystä ja kolme erilaista tapaa lähestyä käyttöliittymän rakentamista. Vaadin 7 tarjosi nopeasti siistiä Swing-tyylisesti komponenttien kera, JSF 2 + PrimeFaces luotti perinteisempään komponenttipohjaiseen HTML:ään ja tageihin ja Wicket 6 oli joukosta hieman työläämpi komponenttipohjainen ratkaisu. Kokonaisuutena Vaadin on selkeästi yhtenäisin paketti ja sekä JSF:n että Wicketin kanssa on hieman enemmän askarreltavaa, joka toki myös tarjoaa vapauksia.

Jokaisella kehyksellä sai aikaan suhteellisen pienellä vaivalla yksinkertaisen imgur-kuvaselaajan haun kera. Jos pitäisi saada nopeasti valmista, niin kenties toteuttaisin sen Vaatimella, jolloin aikaa ei mene niin paljoa käyttöliittymän kanssa taisteluun. Valmiiden sivupohjien kanssa JSF 2:llakin syntyy koodia nopeasti. Kaikissa kolmessa on kyllä omat jekkunsa ja ”ongelmansa” muun muassa sessioiden koon ja selaimen kuormittavuuden osalta.

Seuraavaksi tutustumislistalla JVM:ssä toimivien kehysten osalta on ehkä Spring MVC, Play Framework, Grails ja puhdas GWT. Lisäksi Node.js:llä toteutettu kuvaselain on jo osittain tehty.

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1

Tietojärjestelmät eivät rakennu itsestään, vaan niiden kehitys vaatii monia askelia vaatimusmäärittelystä, suunnitteluun, toteutukseen, testaukseen ja toimittamiseen. Yksi tärkeä askel on järjestelmän arkkitehtuurin suunnittelu, joka luo perustan onnistuneelle ratkaisulle. Tietojärjestelmän arkkitehtuurin suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Tieturi on useamman vuoden ajan järjestänyt 3+3 -päiväistä ”Tietojärjestelmäarkkitehdin valmennusohjelma” -kurssia, jossa käsitellään tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja ja keinoja erinomaiseen ratkaisuun pääsemiseksi. Osallistuin kurssin ensimmäiselle kolmipäiväiselle teoria- ja alustuspainotteiselle osiolle alkuviikosta ja tietämystä kertyi suurilta osin avainteemoista ja 4+1 -mallin hyödyntämisestä. Kurssin toinen osa on edessä syksyllä.

Jatka lukemista ”Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1”

Pitäisikö Web-sovelluksilla olla yhtenäinen tyyli ja logiikka?

Nykyään suuri osa sovelluksista toimii Web-selaimissa ja sovellusten osalta on havaittavissa siirtymää työpöydältä Web-sovelluksiksi, jolloin aikaisemmin suhteellisen samanlailla toimivat ja näyttävät käyttöliittymät muuttuvat monimuotoisiksi. Web-maailmassa ei ole yhtenäistä tapaa toteuttaa asioita, vaan jokainen suunnittelija tekee kuten parhaimmakseen näkee ja sovellusten ulkoasut vaihtelevat suuresti. Perinteisten työpöytäsovellusten osalta eri sovellukset toimivat suurin piirtein samoilla periaatteilla ja toimintopainikkeet sekä näyttävät samoilta että löytyvät tutuista paikoista.

Usability Post kysyykin, pitäisikö Web-sovelluksilla olla yhtenäinen käyttöliittymä, eli ulkoasu näyttäisi ja toimisi visuaalisesti samoilla periaatteilla, kuten työpöytäsovelluksissakin eri käyttöjärjestelmissä sovellukset ovat usein yhtenäisiä keskenään. Tutut toiminnot näyttäisivät samoilta eri Web-sovellusten välillä, kun nyt painikkeiden ja komponenttien ulkoasut vaihtelevat enemmän tai vähemmän eri sovellusten välillä.

On totta, että sitä toivoisi sovellusten toimivan edes suurin piirtein samoilla periaatteilla, ettei aina tarvitsisi arpoa miten asiat nyt tässä toimivatkaan, mutta yleisesti ottaen on vaikea nähdä, että eri Web-sovellukset näyttäisivät peruspiirteiltään samanlaisilta, toimisivat samalla tavalla tai käyttäisivät samoja komponentteja. Web on visuaalisesti toinen maailma verrattuna työpöytäsovelluksiin, joka myös heijastuu sovellusten toimintoihin. Webin osalta ei oikeastaan odoteta, että eri sovellukset näyttäisivät yhtenäisiltä, vaan ollaan jo totuttu, että jokaisen sovelluksen kohdalla pitää aina oppia uudestaan perustoiminnot ja logiikka. Onneksi suunnittelijat tekevät sovellukset usein helposti opittaviksi ja joissa asiat toimivat kuten niiden olettaa toimivan. Tai ainakin näin haluaisi uskoa, sillä todellisuus on välillä aivan jotain muuta.

Kun asiaa ajatellaan pienemmällä skaalalla, olisi sovelluskehittäjällä hyvä olla karkealla tasolla välineet yhtenäisen käyttöliittymän toteuttamiseksi, ainakin saman asiakkaan sovellusten osalta. Toki usein saman kehittäjän sovelluksissa toistuvat samat ratkaisut ja uudestaan käytettävät palikat, joilla yhtenäisyyttä syntyy kuin itsestään. Miksi keksiä asioita uudestaan, kun ne ovat jo kerran toteutettu, ellei asiaa keksi ”paremmin”. Suunnittelun ja ratkaisujen avuksi löytyy myös apuvälineitä, joilla visuaalista ilmettä ja sovellusmaista toimintaa voidaan tukea.

Webissä ei ole yhtä ja oikeaa tapaa toteuttaa asioita, vaan monet ratkaisut ovat yhtä hyviä. Mallia voi ottaa esimerkiksi useilta suunnittelumalli-sivustoilta kuten UI Patterns, YPatterns ja UI Pattern Factory. Lisäksi erilaiset komponenttikehykset kuten JQuery UI ja Java EE -maailmassa RichFaces ja PrimeFaces tarjoavat omia ehdotuksiaan toiminnoille. Vaihtoehtoja on monia ja lopputulos on usein eri ratkaisujen yhdistelemistä, jolloin sovellus koostuu useista erilaisista käyttöliittymäratkaisuista. Harvoin eri valmiiden ratkaisujen mallit toimivat suoraan omiin tarpeisiin nähden ja niitä joudutaan vähintäänkin visuaalisen ilmeen osalta virittelemään.

Koska Web perustuu pohjimmiltaan HTML:ään ja CSS:ään, voidaan valmiita komponentteja yleensä muokata ulkoasultaan tarpeiden mukaan ja soveltaa toisaalla havaittuja hyviä asioita. Esimerkiksi Web-sovelluksen käyttöliittymää varten voidaan soveltaa Cappucino tai Sproutcore -kehysten Creative Commons Attribution Share-alike -lisenssin alaisuudessa olevia Ace- ja Aristo-teemoja, jotka näyttävät siisteiltä ja tarjoavat yhtenäisen ulkoasun eri komponenttien välille.

Molemmat teemat näyttävät nykyaikaisilta ja niillä on enemmän yhteistä kuin eroa, jonka voi todeta lyhyestä vertailusta. Enemmän teemojen toiminnasta saa selville, kun vierailee teemojen demosivuilla. Sproutcoren Ace-teemasta on havaittavissa yhtäläisyyksiä OS X:n Aqua-teemaan ja SproutCoren kehitys onkin Applen sponsoroimaa. Cappucinon Aristo-teema ei ole niin silmiinpistävä kuin Ace, keskittyy näyttämään hyvältä sekä Windowsissa että OS X:ssä ja sopii paremmin vakavampiin sovelluksiin.

Molempien teemojen soveltuvuus omaan käyttötarkoitukseen riippuu toteutettavasta sovelluksesta, mutta niistä voi ainakin ottaa hieman mallia, miltä peruskomponentit voisivat näyttää. Cappucinon Aristo-teema on hieman helpommin otettavissa testiin ja se on saatavissa PSD -kuvina ja kolmannen osapuolen CSS 3 toteutuksena. Sproutcoren Ace-teema löytyy vastaavasti vain sprite-kuvina, joten teemaus pitää hoitaa itse loppuun, mutta se tarjoaa kattavamman valikoiman eri komponentteja ja malleja.

Ikävä tosiasia valitettavasti on, että sovelluksen ulkoasun eteen joudutaan aina askartelemaan enemmän tai vähemmän. Esimerkiksi jos sovelluksessa otetaan käyttöön jokin valmis komponentti, pitää sen ulkoasua joko muokata vastaamaan muuta sovellusta, tai käyttää valittua kirjastoa kaikilta osin jokaisen komponentin kanssa, jolloin eroavaisuuksia on mahdollisimman vähän. Valituista ratkaisuista riippuen tämä on enemmän tai vähemmän helppoa. Esimerkiksi JQuery UI:n komponenteille voi määritellä haluamansa ulkoasun kätevästi Theme Rollerin avulla, mutta vastaavasti samanlainen teemanrakentaja tarvittaisiin myös RichFaces-komponenteille, joiden teemaus on suhteellisen työlästä ja osittain arpapeliä. Muutenkin aina tuntuu, että useat valmiit ratkaisut eivät toimi kuten niiden haluaisi toimivan, eikä niitä usein voi myöskään helposti muokata riittävällä tasolla.

Kaikenkaikkiaan Web-käyttöliittymä voi näyttää upealta, jos siihen viitsii panostaa, mutta Web-sovelluksilla ei mielestäni tarvitse olla yhtenäisiä periaatteita. Web on monimuotoinen ja asiat saavat toimia, kuten ne parhaimmikseen näkee, kunhan ne silti toimivat loogisesti ja ymmärrettävästi. Toki yhtenäiset ratkaisut helpottavat käyttäjän elämää. Toisaalta Webin käyttöliittymät eivät helposti vertaudu perinteisiin työpöytäsovelluksiin, ainakaan nykyisillä teknologioilla ennen HTML5:n ja CSS 3:n yleistymistä, joten sallittakoon niille myös omat tyylinsä, kunhan ne ovat hyvällä maulla toteutettuja.

Pitääkin tässä edistää työlistalle hautautunutta tehtävää jalostaa omaa visuaalisesti yksinkertaista komponettiteemaa eteenpäin ja rakentaa vastaava teemaus myös RichFaces-komponenteille, jolloin asiakkaan sovellus saisi vielä nykyistä yhtenäisemmän ulkoasun.

Vaadin tarjoaa Swingiä Web-sovellusten kehitykseen

Web-sovellusten kehitys Javalla on täynnä erilaisten frameworkkien kuten Strutsin, Springin ja JSF:n hyödyntämistä, joista jokaisessa on hyvät ja huonot puolensa ja varsinainen toteutus on usein sekoitus HTML-merkkausta ja koodia. Java EE -sovelluskehitystä voi kuitenkin katsella myös hieman erilaisesta näkökulmasta: Suomalainen IT Mill on rakentanut kokonaisuuden nimeltä Vaadin, joka tuo Javan Swing -maailman Web-sovelluksiin. Lopputuloksena on sovelluskehys, jossa HTML:n koodaaminen unohdetaan lähes täysin ja sovellusta toteutetaan samalla periaatteilla kuin työpöytäsovelluksia, joka on kätevää, jos tykkää Java Swing -tyylisestä sovelluskehityksestä.

Vaadinta voi lyhyesti kuvata sanomalla sen olevan Swing-koodausta sekä hyvässä että pahassa. Web-sovelluksen toteutus Vaatimella on suhteellisen helppoa, mutta toisaalta se myös Swingin tapaan rajoittaa käyttöliittymäsuunnittelua. Toteutuksessa HTML:n ja komponenttien säätäminen jää pois, jolloin toteuttajat voivat keskittyä varsinaiseen toimintaan kuuntelijoiden ja tapahtumien parissa. Kokonaisuutena kehitys on tavallaan selkeämpää kuin esimerkiksi JSF:llä, jossa toiminnot hajoavat sekä sivuille että Java-luokkiin ja erilaisia säädettäviä XML:iä on useita. Totuus ei tietenkään ole aivan näin yksinkertaista, mutta melkein.

Sovelluskehityksen osalta Eclipselle on saatavilla WYSIWYG-editori ja sovelluksen debuggaus onnistuu normaalisti debug-moodissa ja käyttöliittymän osalta Firefoxin Firebug-lisäosalla, eli sen osalta ei ole mitään ihmeellistä. Käytettävissä on useita erilaisia komponentteja ja hyvä dokumentointi, joilla toimintoja rakentaa. Tutoriaalien avulla pääsee helposti alkuun ja näkee mistä asiassa on kyse. Vaadin on lisensoitu avoimen lähdekoodin Apache License versio 2.0 -lisenssillä, joten tarvittaessa sen laajentaminen ja bugien korjaaminen on mahdollista. Saatavilla on myös maksullista tukea ja palveluita.

Vaadin perustuu Google Web Toolkitin päälle, jota käytetään selaimelle piirtämiseen ja GWT:hen verrattuna Vaadin-sovellukset pyörivät palvelinpuolella, kun GWT on selainpuolen sovellus. Vaadin-sovellus on paljolti sidottu JavaScriptiin ja siinä on mielestäni myös sen heikoin lenkki, sillä suorituskyvyllisesti käytetty lähestymistapa ei ole kovin tehokas. Etenkin monimutkaisilla käyttöliittymäkomponenteilla ja ulkoasuilla selaimen JavaScript-suorituskyky tulee äkkiä vastaan, vaikkakin tällä saralla on etenkin Googlen Chrome ja Safari kunnostautuneet. Muuten komponentit toimivat hyvin riippumatta käytettävästä selaimesta.

Vaikka Vaadin tavallaan yksinkertaistaa rikkaiden Internet sovellusten (RIA) tekemistä, pidän itse enemmän perinteisestä Java Server Facesiin (JSF) pohjautuvasta Web-kehityksestä. JSF:n kanssa käyttöliittymän koodi on erikseen HTML:ssä, johon on lisätty tarvittavat sidokset ja dynaamisuutta. Tietenkin tässäkin tavassa on omat ongelmansa, etenkin kun JSF 1.2 ja käyttöliittymäkomponentit ovat mitä ovat. Ehkä taustani Web-koodaajana vaikuttaa siihen, että pidän enemmän siitä, että pääsen helpommin näkemään ja säätämään käyttöliittymää HTML-tasolta, eli tekemään juuri sitä, mistä ”perinteiset” Java-koodarit eivät tykkää. Ainakin saan tarkalleen mitä haluan, jos osaan sen HTML:llä, CSS:llä ja käytössä olevilla komponenteilla toteuttaa.

Vaadin on kuitenkin kätevä tapa toteuttaa Web-sovelluksia ja sillä saa kohtalaisen nopeasti aikaan hyvän näköistä jälkeä helposti. Toisaalta kuten kaikissa sovelluskehyksissä, on myös Vaatimessa asioita, jotka aiheuttavat kehittäjälle harmaita hiuksia. Nimi Vaadin tarkoittaa myös naaraspuolista poroa ja sanaa voidaan käyttää esimerkiksi lauseessa ”Vaadin parempia käyttöliittymiä!”.

Näköjään seuraava Vaadin Developer Meetup pidetään 3.12.2009 Pitäjänmäellä Helsingissä Logican tiloissa (ilmoittautuminen 26.11.2009 mennessä).

Esimerkkinä silloin vielä IT Mill Toolkit -nimellä tunnetulla Vaadin-kehyksellä hahmoteltu sähköpostisovellus:

iMail iMail

Käyttöliittymän hahmottelua luonnostelemalla

Käyttöliittymien suunnittelussa ideoiden hahmottelu ja visualisointi käsiteltävään muotoon on yksi ensimmäisiä vaiheita ennen koodiin sukeltamista. Visualisointia voi suorittaa monella tapaa ja yksi kätevä keino on luonnostelu, eli piirtämällä kynällä karkea malli halutusta lopputuloksesta paperille. Yksinkertaista, helppoa ja nopeaa prototypointia, vaikka paperimallit eivät ole kovin joustavia ja muutokset ovat työläitä.

Luonnostelu on yksi yleisimmistä tekniikoista matalan tarkkuuden prototyyppien luomiseen. Menetelmässä käytetty ”kynä ja paperi-menetelmä on luonnollinen ja vähän vaivaa vaativa tekniikka, joka mahdollistaa abstraktien ideoiden siirtämisen konseptista nopeasti kiinteämmälle pohjalle. Erityisen hyödyllisen menetelmän tekee sen luovuuteen ja ajatteluun rohkaiseva luonne. Lisäksi luonnostelu rohkaisee useamman eri tekijän osallistumisen mallin luontiin, kun visuaalinen malli ja tekniikka on kaikille tuttua. Asiat jäävät myös riittävän epätarkoiksi, joka sallii tarkennusten tekemisen myöhemmin, estämättä luovuutta mallin kehittämisen aikana.

Luonnostelua voi suorittaa myös tietokoneella, hyödyntämällä Washingtonin yliopistossa kehitettyä avoimen lähdekoodin BSD-lisenssillä julkaistua DENIM-ohjelmistoa. Ohjelma tarjoaa käytännössä paperintapaisen käyttöliittymän mallien luontiin. DENIM on tarkoitettu tukemaan Web-kehittäjien alkuvaiheen suunnittelua informatiivisen luonnostelun kautta, ja tarjoaa suunnittelun tueksi kynällä luonnostelua, eri tarkkuuksille kohdentamista (sivukartta, kuvakäsikirjoitus, sivu), sivujen linkittämistä kuvakäsikirjoitusta varten, mallin ajamista esittämistä ja vuorovaikutusta varten ja mahdollisuuden luoda uudelleenkäytettäviä komponentteja. Lopputuloksen voi myös viedä linkitetyiksi HTML-sivuiksi. Javalla toteutettu DENIM on saatavilla Windowsille, Unixille ja Mac OS X:lle.

Denim Denim

DENIMillä luodut prototyypit muistuttavat kynällä ja paperilla luonnosteltuja malleja sekä hyvässä että pahassa, ja koska nyt piirtovälineenä toimii hiiri, on piirtojälki kynääkin karkeampaa. Paperimalleihin verrattuna sähköinen media tarjoaa mahdollisuuden elementtien siirtelyyn ja muokkaamiseen ja lopputuloksen dokumentointi ja säilöminen myöhempää käyttöä varten on helpompaa. Tietenkin kuten kynällä ja paperilla luonnostellessa, jää käyttöliittymän vuorovaikutuksen esittäminen ja mallin myöhempi hyödyntäminen vähäiseksi. DENIMin käyttö on suhteellisen yksinkertaista ja opasteen avulla hieman erikoinen käyttöliittymä ja sen tarjoamat toiminnot selviävät nopeasti, mutta tämänkin jälkeen työskentely on hieman hidasta ja monimutkaisen tuntuista.

DENIM tarjoaa mahdollisuuden sähköiseen luonnosteluun, mutta käyttö on hieman kömpelöä, joka tosin johtunee suurilta osin piirtovälineenä käytettävästä hiirestä. Piirtopöydällä käytettynä DENIM voisi olla pätevä apuväline, mutta nyt osa sovelluksen kätevyydestä menee hiiren epätarkkuuden kanssa hukkaan, vaikka ohjelmisto suoristeleekin piirrettyjä viivoja. Myös isolla kosketusnäytöllä, jolloin useampi henkilö voisi yhtä aikaa ilmaista ideoitaan, voisi ohjelman käyttö olla kätevää. Toisaalta, kynällä ja paperilla saa edelleen luotua nopeammin ja helpommin luonnoksia ja piirrosjälki on tarkempaa ja mahdollistaa pienempien ja tarkempien elementtien hahmottelun.