Hypermedian ohjelmointi, kevät 2009

Hypermedian ohjelmointi, kevät 2009 (http://hlab.ee.tut.fi/hmopetus/hmohj-2009) Luento 4. Verkkopalvelun toteuttaminen Jukka Huhtamäki, Hlab (http://tut.fi/hypermedia) Luento 4. Verkkopalvelun toteuttaminen Luentokerran aikana käydään läpi lisää verkkopalvelun toteuttamiseen liittyviä yleisiä tosiasioita Mitkä tekijät asettavat reunaehtoja verkkopalvelun toteutukselle? Mitä kaikkea verkkopalvelun toteutuksessa on otettava huomioon? Loppukäyttäjä: käytettävyys (käytön tehokkuus ja virheettömyys, subjektiivinen tyytyväisyys) & saavutettavuus,... Kehittäjä: ylläpidettävyys & päivitettävyys, muokattavuus, uudelleenkäyttö,... Perustaa yleistämiselle Miten verkkopalvelun tyypilliset toiminnot toteutetaan? Kertausta: Verkkopalvelun toiminnallisuus perustuu lomakkeisiin, joten yksittäisten toimintojen toteuttaminen on pääpiirteissään samanlaista sovelluksesta toiseen Toteutustyön tueksi on olemassa valmiita suunnittelumalleja ja sovelluskehyksiä: tyhjästä on yleensä turha aloittaa Tutustutaan ensin tarkemmin verkkopalvelun toteutustyön reunaehtoihin eri näkökulmista ja käydään sitten läpi esimerkkejä siitä, miten reunaehdot voidaan ottaa huomioon käytännön toteutustyössä

Näkökulmia verkkopalvelun toteutukseen Kertausta: Sovelluksen käytettävyyden kriteerejä loppukäyttäjän näkökulmasta (ISO 9241): käyttäminen helppo oppia, käyttäminen on tehokasta (noviisi vs. ekspertti), helposti muistettavissa, aiheuttaa vähän virheitä ja on mukava käyttää. Teknisiä reunaehdoja Teknisen toteutuksen kriteerejä: Kustannustehokkuus, luotettavuus ja yhdenmukaisuus (Welling & Thompson) Päivitettävyys, siirrettävyys, uudelleenkäyttö, yhteensopivuus, virhesietoisuus (ohjelmistotuotanto) Tutustutaan seuraavaksi hieman tarkemmin siihen, miten kriteerit voidaan ottaa huomioon verkkopalvelun teknisessä toteutuksessa.

Heuristiikan noudattaminen: muistilistaa (1/4) Nielsenin heuristisen listaan (http://www.useit.com/papers/heuristic/heuristic_list.html) nojautuva luettelo laadukkaan ohjelmallisen hypermediatoteutuksen piirteistä: Järjestelmän tila: Palveluun kirjautuneen käyttäjän tunnus/nimi näytetään sovelluksen käyttöliittymässä (+ mahdollisuus uloskirjautumiseen) Käyttäjän sijainti sovelluksessa: mukautuva valikko tai murupolku Portaali: kooste järjestelmän tilasta käyttäjän mieltymysten perusteella Järjestelmän käsitteet vs. käyttäjä: Human-Computer Interaction (HCI) ja käyttäjäkeskeinen suunnittelu Toiminnallisuuden ja teknisen suunnittelun erottaminen Käsitteiden testaaminen prototyyppien avulla Heuristiikan noudattaminen: muistilistaa (2/4) Toimintojen peruuttaminen: Esikatselu ja hyväksyminen Mahdollisuus syötetyn tiedon muokkaamiseen/poistamiseen Peruuta-toiminnon toteuttaminen hankalaa, etenkin jälkikäteen! Toimintojen systemaattisuus: Yhtenäisyys: sivupohjat ja kielitiedostot Kirjastojen toteuttaminen käyttöliittymien tuottamiseen, käyttöliittymän irrottaminen toimintalogiikasta Käyttövirheiden ennakointi ja ennaltaehkäisy Ohjeet ja opasteet, käyttöliittymäsuunnittelu,... Testaaminen (prototyypit)! Iteratiivinen ohjelmistokehitys

Heuristiikan noudattaminen: muistilistaa (3/4) Käyttö havaitsemista, ei ulkoa muistamista: Ohjeet ja opasteet, käyttöliittymäsuunnittelu,... Hakutoiminto: tiedon visualisointi vs. avainsanahaku Eksperteille tehokkaita menetelmiä: Käyttäjäroolit Mukautuva hypermedia Korkean vuorovaikutuksen käyttöliittymät Pieni on kaunista: Yksinkertainen asiakas, käyttöliittymäsuunnittelu Yksinkertaisen verkkopalvelun suunnitteleminen on huomattavasti työläämpää kuin monimutkaisen! Heuristiikan noudattaminen: muistilistaa (4/4) Selkeät virheviestit: Tieto siitä, missä virhe on ja ohjeet virheen korjaamiseksi Ohjeet ja dokumentaatio saatavilla: Verkkopalvelun käyttöliittymässä on riittävästi tilaa siihen, että suuri osa ohjeista voidaan upottaa suoraan sovellukseen Oletukset julkaisukontekstista (käyttäjä, päätelaite & verkkoyhteys, tuki skripteille tai evästeille, välttämättömät selainlaajennukset,...) on aina kerrottava käyttäjälle Sovellusten arviointiin tarkoitettuja heuristiikkoja voi vapaasti käyttää apuvälineenä myös sovelluksen suunnittelutyössä

Lomakkeet ja syötteen käsittely Verkkopalvelun toiminto sisältää tyypillisesti seuraavat vaiheet: 1. Käyttäjä syöttää toiminnon edellyttävät tiedot lomakkeeseen ja lähettää lomakkeen sovellukselle 2. Sovellus ottaa pyynnön vastaan ja tarkastaa (validoi) syötteen Syötteen ollessa laillinen: Syötteen perusteella valitaan osa sovelluksen tietosisällöstä (turvallinen toiminto, ~haku) tai muutetaan sovelluksen tilaa (ei-turvallinen toiminto, ~tilaus) Käyttäjä ohjataan uuteen näkymään, jossa kerrotaan toiminnon onnistumisesta ja näytetään haun tulos tai sovelluksen uusi tila Syötteen ollessa virheellinen: Käyttäjä ohjataan takaisin näkymään, jossa virhe on tapahtunut. Näkymään liitetään korjausehdotuksen sisältävä virheilmoitus ja korostetaan virheellisen syötteen sisältävä lomakkeen komponentti tai komponentit Syötteen tarkastaminen Reunaehtoja syötteen laillisuudelle: Tietokanta: syötteen pakollisuus (pääavain tai not null), sarakkeen sisällön maksimikoko tai yksikäsitteisyys (pääavain) Määrämuoto: sähköpostiosoite, henkilötunnus, päivämäärä, viitenumero, ISBN-tunnus, URI,... Laillinen syöte määritellään usein osana sovelluksen toiminnallista määrittelyä (vrt. HYTT)

Säännölliset lausekkeet Keino syötteen tarkastamiseen: säännölliset lausekkeet (regular expressions) Määritellään merkkijonon sallittu hahmo (pattern), jota verrataan tutkittavaan merkkijonoon Säännöllisiä lausekkeita voi käyttää myös merkkijonojen etsimiseen ja korvaamiseen Syötteen pakollisuuteen ja merkkijonon pituuteen liittyvät tarkastukset voidaan toteuttaa käytössä olevan ohjelmointikielen kirjastofunktioilla Syötteen oikeellisuus voidaan joskus varmistaa myös toiminnallisuuden kautta. Miten? Säännöllisten lausekkeiden perusteet (POSIX) Säännöllisen lausekkeen hahmo koostuu merkeistä ja metamerkeistä (metacharacters) (mukailtu lähteestä Rantala, A. Web-ohjelmointi (http://www.docendo.fi/?p=showproduct&product=951-846-264-x) ): vaihtoehto ^ seuraava lauseke merkkijonon alussa $ edeltävä lauseke merkkijonon lopussa. mikä tahansa merkki (yksi) * edellisen lausekkeen toisto 0 tai useamman kerran + edellisen lausekkeen toisto 1 tai useamman kerran? edellisen lausekkeen toisto 0 tai 1 kertaa () lausekkeen ryhmittely (ja varastointi) [] merkkijoukko {} edellisen lausekkeen toisto vähintään n ja enintään m kertaa {n,m} \ metamerkin merkityksen poisto

Esimerkki säännöllisestä lausekkeesta Päivämäärän sallituksi muodoksi voidaan määritellä esimerkiksi yyyy-mm-dd (Lähde: http://www.w3.org/tr/note-datetime): Esimerkki hahmosta: ^[0-9]{4}-[01][0-9]-[0-3][0-9]$ merkkijono alkaa (^) tasan neljällä merkillä ({4}) joukosta (0, 1, 2, 3,..., 9) viidentenä merkkinä on pakollinen väliviiva (-) kuukauden ensimmäinen numero on aina 0 tai 1 ([01]) ja toinen välillä 0-9 pakollinen väliviiva (-) päivämäärän ensimmäinen ([0-3]) ja toinen ([0-9]) numero lopussa ei muita merkkejä ($) Huomaa, että tavalliselta käyttäjältä (noviisi) ei voi vaatia päivämäärän kirjoittamista tietyssä muodossa (vaihtoehdot!). Tehokäyttäjä on asia erikseen (ohjeistus) Säännöllisten lausekkeiden ideat tulevat vastaan myös esimerkiksi formaalien kielten ja UNIX-tehokäytön yhteydessä (grep) Esimerkki: Syötteen tarkastaminen ja CakePHP CodeIgniter, CakePHP ja muut sovelluskehykset pyrkivät automatisoimaan myös syötteen tarkastamisen, vrt. CakePHP-esimerkki: <?php class User extends AppModel { var $name = 'User'; var $validate = array( 'login' => '/[a-z0-9\_\-]{3,}$/i', 'password' => VALID_NOT_EMPTY, 'email' => VALID_EMAIL, 'born' => VALID_NUMBER); }?> Esimerkiksi CodeIgniter toteuttaa vastaavan mekanismin (http://codeigniter.com/ user_guide/libraries/validation.html).

Huomioita esimerkistä Muutamia huomioita esimerkistä: CakePHP käyttää syötteen tarkastamiseen Perl-kielen säännöllisiä lausekkeita (Perl-Compatible Regular Expressions, PCRE) POSIXkieliopin sijaan. Syötteen validointi tapahtuu Malli (model)-tyyppisessä luokassa: Tieto syötteen virheellisyydestä välitetään Ohjain-tyyppiselle luokalle funktion paluuarvona. Vieläkin elegantimpi olisi vaihtoehto poikkeusmekanismin soveltaminen. Syöte, tietoturva ja PHP Vihamielinen käyttäjä voi horjuttaa sovelluksen tietoturvaa monella tavalla: Tietokanta: Syötteeseen voidaan lisätä merkkejä, jotka mahdollistavat SQL-komentojen välittämisen suoraan tietokantaan. Ratkaisu: addslashes()- ja stripslashes()-funktiot Komentotulkki: Syötteeseen voidaan lisätä merkkejä, jotka mahdollistavat käskyjen välittämisen komentotulkille (shell). Ongelma silloin, kun PHPohjelma välittää syötteen komentoriviohjelmalle. Ratkaisu: escapeshellcmd()-funktio HTML-käyttöliittymä: Syötteeseen voidaan lisätä merkkejä, jotka sotkevat sovelluksen käyttöliittymän. Ongelma syntyy silloin, kun käyttäjän syöte tulostetaan takaisin käyttöliittymään (esimerkiksi keskustelupalsta tai vieraskirja). Ratkaisu: strip_tags()- ja htmlspecialchars()-funktiot Verkkopalvelun tietoturvallisen toteutuksen perusteisiin kuuluu lisäksi HTTPSprotokollan käyttäminen kaiken arkaluontoisen tiedon välittämiseen asiakkaan ja palvelimen välillä. HTTPS-protokollan käyttö estää tietojen selvittämisen tietoliikennettä kuuntelemalla. HTTPS-protokollan yli välitettyjä tietoja ei myöskään säilytetä selaimen välimuistissa.

Merkistöt: taustaa Merkistöt aiheuttavat ongelmia sovelluksen toteuttajalle ja käyttäjälle. Taustaa: Web-sovellusta voi käyttää mistä tahansa maailman kolkasta Eri kielissä ja käyttöympäristöissä on käytössä erilaiset merkistöt Eri merkistöt esitetään eri tavalla tietokoneen muistissa Kolmikerrosarkkitehtuuri: merkistöt on otettava huomioon sekä merkkijonojen esittämisessä, käsittelyssä että tallentamisessa Merkistöjä Yleisiä merkistöjä: ASCII: merkkien esittämiseen käytössä 7 bittiä, käyttäjälle näytettäville merkeille (A-Z, a-z, 0-9) annettu arvot väliltä 32-127 ISO 8859-1: ASCII-laajennos, joka sisältää mm. skandinaaviset merkit ÅÄÖåäö. ISO 8859-15 sisältää myös euro-merkin ( ). Merkkien esittämiseen 8 bittiä Unicode: Standardi, joka mahdollistaa kaikkien maailman merkkien esittämisen yhdellä ja samalla merkistöllä. Useita tapoja merkkien koodaamiseen: UTF-8, UTF-16, UCS-2 Esimerkiksi UTF-8 käyttää yhden merkin esittämiseen joko yhden tai useampia tavuja. Tämä aiheuttaa ongelmia kun asiaa huomioida sovelluksen toteutuksessa. Esimerkkejä: yksi merkki vie useamman merkin tilan tietokannassa ja tietosisällön korkein sallittu pituus ylittyy liian aikaisin.

Ongelmia ja yleinen ratkaisu Merkistöongelmaan on olemassa ainakin periaatteellinen ratkaisu: 1. Valitaan sovelluksen sisäiseen toteutukseen merkistö, jonka avulla pystytään esittämään mahdollisimman suuri joukko yksittäisiä merkkejä (=Unicode, esim. UTF-8) 2. Muunnetaan käyttäjän syöte ja muu sovellukseen tuotava tietosisältö valittuun merkistöön ja oletetaan merkistön käyttö sovelluksen sisäisessä toteutuksessa (ohjelmakoodi & tietokanta) Huomaa, että sovelluksen näkymissä voidaan käyttää eri merkistöä kuin sovelluksen sisäisessä toteutuksessa. Joel Spolskyn The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) (http://www.joelonsoftware.com/articles/unicode.html) on ehdottoman suositeltavaa luettavaa! Merkkijonot ja PHP PHP-kieli on kehittynyt käytännön tarpeista. Tästä syystä kielen kehitys on ollut välillä enemmän suunnitelmallista, välillä taas vähemmän. Merkistöjen näkökulmasta tiedossa on ongelmia (lähde: php.net): A string is series of characters. In PHP, a character is the same as a byte, that is, there are exactly 256 different characters possible. This also implies that PHP has no native support of Unicode. See utf8_encode() and utf8_decode() for some Unicode support. Siis: paras mahdollinen vaihtoehto, Unicoden käyttäminen sovelluksen sisäisessä toteutuksessa, ei ole (suoraviivaisesti) mahdollista. Avuksi voidaan ottaa PHP-kielen mbstring-laajennus sisältää joukon funktioita, jotka mahdollistavat myös Unicode-merkistöä käyttävien merkkijonojen käsittelemisen Karvalakkiratkaisu: otetaan käyttöön PHP-funktiot utf8_encode() ja utf8_decode() ja HTML-kielen accept-charset attribuutti. Ongelmia: UTF-8 ei ole ainoa tapa merkistön koodaamiseen, ratkaisun selainriippuvuus. Teknologiakatsaus: Python-kieli (ja siten Django) tukee Unicodea. Ruby on Rails versio 1.2 esitteli kehyksen aikaisemmista versioista puuttuneen Unicode-tuen.

Tyytyväinen sovelluskehittäjä => Tyytyväinen loppukäyttäjä? Koodin uudelleenkäyttö Koodin uudelleenkäytöllä on useita lisäarvoja sovelluksen toteutustyössä: Kustannustehokkuus: Sovelluksen moduulin M ylläpitämiseen, testaamiseen ja dokumentointiin keskimäärin kuluva aika on toteuttamiseen verrattuna moninkertainen Ylläpidettävän koodin määrä on pyrittävä pitämään mahdollisimman pienenä Luotettavuus: Moduulin luotettavuuden varmistaminen edellyttää kattavaa testaamista Testaamisesta huolimatta koodiin voi jäädä ohjelmointivirheitä, jotka paljastuvat ajan myötä Yhdenmukaisuus: Sovelluksen käyttöliittymien (ja muiden rajapintojen) yhdenmukainen toteuttaminen esimerkiksi tyylioppaan perusteella on työlästä Modulaarinen toteutus mahdollistaa koodin uudelleenkäytön

Koodin uudelleenkäyttö ja PHP PHP-kieli mahdollistaa koodin uudelleenkäytön moduulien ja funktioiden tuella: include() ja require(): tiedoston sisällyttäminen toiseen PHP-tiedostoon. Ero: ensimmäinen aiheuttaa epäonnistuessaan varoituksen (warning), jälkimmäinen virheen (error) include_once() ja require_once(): vastaavia kuin edelliset, mutta sisällyttäminen tapahtuu ainoastaan kerran Käyttötapauksia: Omat funktiokirjastot: HTML-merkkauksen tulostaminen, tietokantayhteyden avaaminen, syötteen tarkastaminen,... => include_once() Sivupohjan (header.php ja footer.php) ja muiden yleisten HTMLrakenteiden irrottaminen omaksi kokonaisuudekseen => include() PHP5 mahdollistaa yksinkertaisen moduuliperiaatteen ohella myös täysiverisen olio-ohjelmoinnin (periytyminen, paketointi, poikkeukset,...) Yksityiskohta: tietoturvan parantamiseksi arkaluontoista tietoa sisältävät sisällytettävät tiedostot kannattaa aina nimetä php-tiedostopäätteellä (miksi?) Ohjelmistotuotannon kriteerit Yleisessä ohjelmistotuotannossa sovelluksen laadulle on määritelty mm. seuraavat kriteerit: Päivitettävyys: Yleisesti: mekaanisten työtehtävien siirtäminen ihmiseltä tietokoneelle Modulaarinen suunnittelu parantaa sovelluksen päivitettävyyttä merkittävästi: HTML-merkkauksen tulostaminen, sivupohjat,... Verkkopalvelussa myös sisällön päivittämisen helppous on tärkeää Siirrettävyys: Sovelluksen toteutustekniikoiden valinta siten, että tuki löytyy mahdollisimman monelta palvelimelta Esimerkkejä: ODBC-tietokantarajapinta ja SQL-standardi (tai tekstitiedostojen käyttäminen), yleisesti käytössä olevat versiot käytettävistä ohjelmistoista ja kielistä, erillistä asennusta vaativien kirjastojen käytön välttäminen

Ohjelmistotuotannon kriteerit Uudelleenkäyttö: Modulaarinen suunnittelu Verkkopalvelun yleisten osien irrottaminen sovelluskohtaisista ratkaisuista Dokumentointi! Yhteensopivuus: Standardiratkaisujen käyttäminen mahdollisuuksien mukaan: validi HTML ja CSS, kuvat JPEG/GIF/PNG-muodossa Sovelluksen toteuttaminen saavutettavuuden ja laiteriippumattomuuden periaatteiden mukaisesti Sovelluksen kansainvälistäminen & mahdollisuus kotoistukseen Virhesietoisuus: Sovelluksen on toivuttava erilaisista virheistä: virheelinen syöte, tiedoston lukemisen tai kirjoittamisen epäonnistuminen, tietokantayhteyden katkeaminen Käyttäjälle virheilmoitus selvällä kielellä ja esimerkiksi toimenpidesuositukset Sovelluksen toiminnallisuuden toteuttaminen periaatteella Toimii PC:llä, mun PC:llä ei useinkaan ole järkevää, ei ainakaan verkkopalveluiden tapauksessa

Yhteenveto Verkkopalvelun (yleisesti hypermediasovelluksen) toteutuksessa on otettava huomioon paljon erilaisia asioita Dokumentoidun suunnittelun merkitys korostuu Perinteisen vesiputousmallin mukaisen prosessin sijaan on usein perusteltua käyttää iteraviisia suunnittelu- ja toteutusmenetelmiä: prototypointi tai ketterä ohjelmistokehitys (agile software development) Suunnittelutyössä ja valmiin sovelluksen arvioinnissa kannattaa käyttää apuna erilaisia heuristiikkoja ja muistilistoja Avaintekijä sovelluksen toteutuksen laadun edistämisessä on modulaarinen suunnittelu. Asia kannattaa pyrkiä ottamaan huomioon jo harjoitustyön toteutuksessa Käyttäjän syötteeseen liittyvät asiat aiheuttaa paljon sovelluksen tekijälle. Valtaosa lomakkeeseen perustuvat toiminnallisuuden toteuttamiseen kuluvasta ajasta on käytettävä syötteen tarkastamis- ja käsittelyrutiineihin Suunnittelumallien (design patterns) ja sovelluskehysten (application framework) avulla voidaan entisestään tehostaa toteutustyötä. Molempiin palataan vielä luentojen kuluessa