3 TEORIATAUSTAA PARANNUKSILLE
3.3 Lähdekoodin parantaminen
Nykyisen FINRI-järjestelmän toiminnallisuutta parannetaan siten, että käyttäjät näkevät mahdollisimman vähän muutoksia nykytilaan verrattaessa. Tähän liittyy käsite refaktoroin- ti, joka on järjestelmän sisäisen toiminnallisuuden parantamista siten, ettei ulkoinen toi
minnallisuus muutu [Fowler et ai. 1999], Samaan aiheeseen liittyy myös koodin haju eli menetelmä, jolla etsitään lähdekoodista sellaisia kohtia, jotka ovat tunnetusti huonoa oh
jelmointitapaa. Koodin hajun toimivuus riippuu ihmisestä, joka tarkastaa lähdekoodin ja näin ollen ei ole täysin yksiselitteinen mittari lähdekoodin toimivuudelle [Mäntylä et ai.
2003; Mäntylä et ai. 2004], Näitä menetelmiä voidaan käyttää apuna uuden järjestelmän toteutuksessa.
On mahdollista, että järjestelmään tehtävät muutokset ovat kuitenkin niin suuria verrattuna järjestelmän kokoon, että on kannattavampaa aloittaa alusta. Nykyisen järjestelmän lähde
koodi on todella sekavaa, koska sen sisäinen rakenne ei ole jaettu edes funktioihin ja eri sivut sisältävät paljon paikasta toiseen kopioitua lähdekoodia. Alusta aloitettaessa voidaan kuitenkin käyttää nykyisen järjestelmän toiminnallisuuden kuvausta (kuvattu kappaleessa 2) apuna. Lisäksi huonoja hajuja [Fowler et ai. 1999] voidaan käyttää tarkistettaessa uuden järjestelmän rakennetta.
Suunnitteluvaiheessa perehdytään myös suunnittelumalleihin [Gamma et ai. 1995] ja eten
kin niiden käyttöön PHP-kielessä [Zandstra 2004], Suunnittelumallit ovat periaatteessa päinvastainen menetelmä kuin koodin haju, eli siinä yritetään soveltaa hyväksi todettuja suunnittelumalleja järjestelmän rakenteeseen.
4.1 Yleistä
Tässä kappaleessa keskitytään järjestelmään tehtävien parannusten suunnitteluun. Suunnit
telussa käytetään apuna järjestelmän nykytilan kuvausta (kuvattu kappaleessa 2), nykyisen järjestelmän ylläpidossa saatua asiantuntemusta sekä julkaisijoilta saatua palautetta. Lisäk
si suunnittelussa otetaan huomioon ilmennyt tarve saada järjestelmä helpommin muokattua muuhun vastaavanlaiseen käyttöön.
4.2 Tärkeimmät parannusten kohteet
Edellä tehdyn järjestelmän nykytilan kuvauksen perusteella selkein parannuskohde on tie
tokantarakenne. Alkuperäinen tietokantarakenne koostui ainoastaan yhdestä taulusta kieli
versiota kohden ja näin ollen rakenne on ollut hyvin rajoittunut ja sekava. Myöhemmin lisätyt Luokat- ja C/asses-taulut ovat sekoittaneet rakennetta entisestään. Näistä syistä joh
tuen koko tietokantarakenne vaihdetaan.
Toinen parannuskohde, joka toteutetaan, on siirtyminen lähdekoodissa oliopohjaisuuteen.
Tämä päätös johtuu osittain tietokantarakenteen täydellisestä vaihdosta, koska kyseisen muutoksen takia kaikki tietokantaa käyttävät järjestelmän osat joudutaan joka tapauksessa korjaamaan. Lisäksi tällä hetkellä järjestelmän toiminnallisuudet sijaitsevat erillään toisis
taan, eikä rakenteesta saa kunnon kokonaiskuvaa.
Kolmas parannuskohde on tiedostojärjestelmän rakenne ja ulkoasun muokattavuus. Tie
dostojärjestelmää muokataan yksinkertaisemmaksi ja tähän liittyvät myös kieliversiot ja ulkoasun muokkaus yleensä.
Kaikkiin näihin parannuskohteisiin liittyy myös lähdekoodin ja tietokannan muuttujien yms. nimeäminen. Tällä hetkellä lähdekoodissa ja tietokantarakenteessa on joitakin suo
menkielisiä nimityksiä, esim. Luokat-iauhx. Ymmärrettävyyden takia olisi parasta päästä niistä kokonaan eroon. Tästä johtuen uudessa rakenteessa ja lähdekoodissa käytetään aino
astaan englanninkielisiä nimityksiä.
4.3 Parannukset
4.3.1 Tietokantarakenne
Hyvien suunnitteluperiaatteiden mukaan [Ullman & Widom 2002]:
• tietokannan elementtien tulisi vastata todellisuutta
• pitäisi välttää toistoa
• rakenne tulisi pitää mahdollisimman yksinkertaisena
• valita juuri oikeat yhteydet
• valita oikean tyyppiset elementit
Vanhan rakenteen osat, kuten tapahtuma, otsikko, aika jne., vastaavat todellisuutta, vaik
kakin niiden nimeämisessä ja elementtien valinnassa on parantamista. Näin ollen vanhoja rakenteen elementtejä voidaan käyttää pohjana uuden suunnittelulle.
Ensin täytyy päättää, mitkä elementit toistuvat useasti eri paikoissa. Rakenteen selvyyden takia kannattaa eri kieliversiot laittaa samoihin tietokantatauluihin ja eritellä ne lisäämällä jokaiseen viittaus siitä, mihin kieliversioon kyseinen tieto kuuluu. Tämän perusteella en
simmäinen taulu olisi Language eli eri kieliversiot. Kielellä tarvitsee olla nimi (name) ja viittausta varten tunniste (id).
Kaavio 11 E/R-kaavio Zangwage-taulusta
Järjestelmän keskeinen käsite on tilannetieto, joiden jakelemista varten järjestelmä on kehi
tetty. Toinen taulu on siis Information, joka sisältää tilannetietoon liittyvät asiat: tunniste (id), julkaisuaika (time), tila (status), luokka (class), tapahtuma (event) sekä kieli (langu
age). Tilannetietojen tilaa (status) käytetään määrittämään, onko kyseinen tilannetieto jo julkaistu. Viittaukset tilannetietoon liittyviin tiedostoihin eivät kuulu tähän tauluun, vaan
toiminnallisuuden kannalta on helpompaa, jos tiedostoista viitataan tilannetietoon.
Information
language
Kaavio 12 E/R-kaavio Information-taulusta
Tilannetietoihin liittyvistä tiedoista toistuvia ovat luokka ja tapahtuma. Tämän perusteella tehdään kaksi taulua: Class ja Event. Molemmilla on tunniste (id), nimi (name) sekä kieli (language). Lisäksi tapahtumilla (Event) on myös tila (status), jota käytetään samalla taval
la kuin vanhassa järjestelmässä eli ilmoittamaan onko kyseinen tapahtuma arkistoitu.
language
Kaavio 13 E/R-kaavio Ctos-taulusta
language
Event
status
Kaavio 14 E/R-kaavio £Vezi/-taulusta
Jotta tilannetietokohtaisesta tiedostojen maksimimäärästä päästään eroon, tehdään tietokan
taan taulu File, joka sisältää tiedostonimen (filename), kuvauksen (description), tunnisteen (id) sekä viittauksen siitä, mihin tilannetietoon tiedosto liittyy (information). Kaikkien tiet
tyyn tilannetietoon liittyvien tiedostoiden haku on yksinkertaista, koska tämä tieto on tal
lennettu F//e-tauluun.
description
File
information
Kaavio 15 E/R-kaavio F/Ve-tauIusta
Lopuksi edellä mainitut kaaviot yhdistetään ja saadaan kuvaus uudesta tietokantarakentees
ta. Rakenne on edelleen yksinkertainen, mutta kuitenkin vanhaa rakennetta joustavampi.
Language
"Language
"Language
Has-Language
Class Event
status
Has-cLass Has-event
status
Information class
language event
Belongs-to
filename
description information
Kaavio 16 E/R-kaavio suunnitellusta tietokantarakenteesta
hyviin suunnitteluperiaatteisiin, vaikuttaa se sopivalta tähän tarkoitukseen. Se sisältää sa
mat tiedot kuin vanha rakenne, on yksinkertainen eikä sisällä turhaa toistoa. Taulujen väli
set yhteydet sekä elementtityypit on suunniteltu sen perusteella, mitä järjestelmän toimin
nallisuus vaatii. Samalla on myös varmistettu, että rakenteet ovat Boyce-Coddin normaa
limuodossa (BCNF), eli attribuuteilla ei ole riippuvuuksia muihin kuin avain attribuuttiin [Ullman & Widom 2002]. Palaamme myöhemmin (kappaleessa 5.2.1) siihen, tarvitseeko suunnitelman mukaiseen rakenteeseen tehdä muutoksia toteutusvaiheessa.
4.3.2 Olio-ohjelmointi ja järjestelmän rakenne
Siirryttäessä järjestelmässä oliopohjaisuuteen täytyy järjestelmän rakenne suunnitella uu
delleen. Tässä kappaleessa käydään läpi suunnitelma, jonka pohjalta järjestelmän rakenne toteutetaan. Järjestelmän toiminnot pysyvät pitkälti samoina kuin vanhassa järjestelmässä, mutta ne jaetaan olio-ohjelmointiparadigman mukaisesti siten, että samoihin asioihin liitty
vät toiminnallisuudet ja muuttujat ovat samoissa luokissa.
Järjestelmän jako eri osiin eli luokkiin perustuu osittain sen tietokantarakenteeseen (kuvat
tu kappaleessa 4.3.1). Tietokannassa tiedot on jaettu loogisiin osiin, joita voi käyttää myös luokkarakenteessa. Nämä osat ovat toiminnallisuudeltaan hyvin samankaltaisia, joten jotta vältyttäisiin toistolta, toteutetaan yhteiset toiminnallisuudet abstraktiin luokkaan. Kun tie
tokannan eri tauluissa olevat osat ovat tämän abstraktin luokan aliluokkia, ne perivät yhtei
sen toiminnallisuuden.
Yhteisiä toiminnallisuuksia ovat tietyn tietokantarivin lisäys, valinta, poisto sekä attribuut
tien arvojen luku ja muokkaus. Lisäksi kaikista tauluista täytyy saada lista, jota voidaan tarvittaessa myös suodattaa. Tätä listaustoimintoa tarvitaan useimmissa käyttöliittymän näkymissä.
Eroa aliluokkien toiminnallisuudessa aiheuttavat tiedon tallennukseen käytettävät taulut sekä se, mitä tietoa tauluissa on. Nämä eroavaisuudet toteutetaan asettamalla kyseiset tie
dot muuttujiin luokan konstruktorissa silloin, kun luokan ilmentymä luodaan. Lisäksi File- luokan täytyy toteuttaa omat lisäys-, muokkaus- ja poistometodit, koska nämä metodit käyttävät tietokannan lisäksi myös tiedostojärjestelmää tiedon tallentamiseen.
Jotta tietokantaliittymä voitaisiin tarvittaessa vaihtaa, toteutetaan tietokannan ja tietokantaa käyttävien luokkien väliin oma luokka, joka tarjoaa järjestelmälle pysyvän ja yksinkertai
sen liittymän tietokantaan. Tärkeimmät toiminnot, jotka tietokantaan tarvitaan, ovat rivin lisäys, haku, muokkaus ja poisto. Näistä muokkaus ja poisto palauttavat joko arvon tosi tai epätosi, riippuen siitä onnistuiko tietokantakysely vai ei. Lisäys palauttaa lisätyn rivin tun
nisteen ja hakulistan halutuista tietokantariveistä rivi kerrallaan.
Käyttöliittymään tarvittavat näkymät toteutetaan kahteen luokkaan, joista toinen on lukijaa varten ja toinen julkaisijaa varten. Käyttöliittymän näkymät on tarkoitus toteuttaa siten, että näkymien paikkaa sivulla on mahdollisimman helppo siirtää. Tarkoituksena olisi, että esim. tiedostojen listaus lukijaa varten voitaisiin sijoittaa sivulle lisäämällä seuraava lähde
koodi haluttuun paikkaan sivua:
<?php
$uicomponent = new UI();
$uicomponent->show!nformationList();
?>
Järjestelmän yhteiset asetukset, joita ei voi muokata käyttöliittymän läpi (esim. tietokannan käyttäjät ja salasanat yms.), sijoitetaan omaan luokkaansa. Tämä luokka sisältää vain suo
raan lähdekoodiin sijoitetut muuttujat sekä niiden arvon lukemiseen tarkoitetun metodin.
Muuttujien arvoa ei pysty muuttamaan muuttamatta lähdekoodia. Kirjan [Zandstra 2004]
mukaan asetusten käyttö pitäisi olla mahdollisimman yksinkertaista, koska selainkäyttöliit- tymällä toteutetut järjestelmät joutuvat lukemaan asetuksensa uudestaan joka kerta, kun niitä tarvitseva sivu ladataan. Tähän luokkaan tallennettuja asetuksia ei jouduta muokkaa
maan usein, mutta järjestelmä lukee ne usein.
+setAttribute(name:string,value:string): boolean
•fdeleteO s boolean
Configuration-luokka sisältää järjestelmän asetuksia, joita ei voida muutaa järjestelmän kautta. Muutokset tulee tehdä suoraan luokan lähdekoodiin.
File-luokka sisältää omat totetutukset create-, setAttribute- ja delete-funk- tioista, koska ne käyttävät tietokannan lisäksi myös tiedostojärjestelmää tie
don tallentamiseen.
AdminUI-luokka tarkistaa jokaisen funktion alussa, että kyseessä on sallittu IR-osoite. Jollei kyseistä IR- osoitetta ei ole sallittu, keskeytetään suoritus ja palautetaan epätosi.
•fqetValue(name:string): string -dbHost: string {frozen) -dbName: string {frozen}
-dbUser: string {frozen}
-dbPassvord: string {frozen}
-dbAdminUser: string {frozen) -dbAdminPassword: string {frozen}
-allowedAdminIPs: string {frozen}
Configuration -♦■connect 0: boolean
+insertQuery(query-.string): int -♦-update (): boolean
♦delete(): boolean
Kaavio 17 Luokkakaavio suunnitelman mukaisesta jäijestelmän rakenteesta
Luokkakaavio (Kaavio 17) kuvaa edellä suunniteltua rakennetta. Rakenne ei ole täydelli
nen ja sitä luultavimmin muutetaan toteutusvaiheessa. Kaaviossa on kuitenkin kuvattu tär
keimmät riippuvuudet ja toiminnallisuudet.
Toteutusvaiheessa täytyy kuitenkin huomioida myös nykyisen palveluntarjoajan asettamat vaatimukset (mainittu kappaleessa 3.1). Vanhempaa PHP4:ä käytettäessä kaikki muuttujat
ovat julkisia eli niitä voidaan käyttää suoraan metodien ohi. Tämä voisi aiheuttaa ongel
mia, jos kyseessä olisi suurempi järjestelmä ja toteutukseen osallistuisi monta tekijää. Nyt toteutettavan järjestelmän kannalta tämän ei pitäisi olla ongelma, koska toteuttajia on vain yksi. Ongelma on kuitenkin tiedostettava ja tutkittava, onnistuisiko uudemman version käyttö jollain muulla palveluntarjoajalla.
4.3.3 Luokkien tarkempi kuvaus
Tässä kappaleessa käydään läpi tarkemmin, miten toiminnallisuus on jaettu uusien luokki
en kesken. Tämä sanallinen kuvaus tarkentaa eri luokkien vastuunjakoa ja toimii rakennus
ohjeena sekä muistilistana toteutusvaiheessa.
Configuration-luokka sisältää järjestelmän asetuksia. Koska asetuksia muokataan harvoin, mutta käytetään usein, on asetukset laitettu suoraan lähdekoodiin. Luokan ainoa metodi on getValue(name), joka palauttaa parametrina annetun asetuksen arvon. Luokan sisältämät vakiot ovat:
• dbHost - Tietokantapalvelimen osoite
• database - Käytetyn tietokannan nimi
• dbUser ja dbPassword - Tietokannan lukemiseen tarkoitettu käyttäjätunnus ja sen salasana
• dbAdminöser ja dbAdminPassword - Tietokannan muokkaamiseen tarkoitettu käyttäjätunnus ja sen salasana
• allowedAdminIPs - IP-osoitteet, joista tietokannan muokkaus on sallittua
DatabaseAccess-luokka sisältää yksinkertaistetun liittymän tietokantaan. Tätä luokkaa voi
taisiin pitää adapteri (adapter) suunnittelumallin mukaisena. Luokka ei kuitenkaan suora
naisesti toimi adapterina kahden luokan välillä, vaan se tarjoaa oliopohjaisen yhteyden käytettyyn tietokantaan. Jos tietokanta vaihdetaan, tulee tämä luokka ohjelmoida uudes
taan. Luokka sisältää seuraavat metodit:
linkin sisäiseen muuttujaan link ja palauttaa true, jos yhteyden avaus onnistui.
• insertQuery(query) - Käytetään lisäämään rivejä tietokantaan. Ottaa parametrina li
säykseen käytettävän SQL-lausekkeen ja palauttaa lisätyn tietueen tunnistenume
ron.
• selectQuery(query) - Hakee tietokannasta parametrina annetun SQL-lausekkeen mukaiset rivit. Tallentaa vastaukset luokan sisäiseen muuttujaan results ja palauttaa true, jos haku onnistui.
• fetchNextRow() - Palauttaa selectQuery-melodiMa saadusta vastauksesta seuraavan rivin ja palauttaa sen joukkona (array). Jollei seuraavaa riviä ole, palauttaa tyhjän joukon.
• updateQuery(query) - Päivittää tietokantaa parametrina olevan SQL-lauseen mu
kaan. Palauttaa true, jos päivitys onnistuu.
• deleteQuery(query) - Poistaa tietokannasta rivejä parametrina olevan SQL-lauseen mukaan. Palauttaa true, jos poisto onnistuu.
• disconnectQ - Katkaisee yhteyden tietokantaan.
Abstrakti DatabaseltemAuokka sisältää tietokannassa olevien tietorakenteiden käsittelyyn tarvittavat metodit. Tätä luokkaa ei käytetä suoraan, vaan käytetään sen aliluokkia: Infor
mation, Event, Class Language ja File. Abstraktiluokka sisältää seuraavat metodit:
• Aliluokkien konstruktorit asettavat sisäiset muuttujat table ja attributeTypes, jotka ovat taulun nimi sekä taulun sisältämien attribuuttien tyypit. •
• create(attributes) - Ottaa parametrina attribuuttien arvot sisältävän joukon. Attri
buuttien tyypit tarkistetaan, arvot sisältävä joukko tallennetaan sisäiseen muuttu
jaan attributes ja tallennetaan tietokantaan. Palauttaa tehdyn tietokantarivin tunnis
tenumeron tai -1, jos tallennus epäonnistui.
• selected) - Hakee tietokantarivin sen tunnistenumeron perusteella ja asettaa saadun arvojoukon sisäiseen muuttujaan attributes.
• getAttribute(name) - Palauttaa parametrina annetun attribuutin arvon.
• setAttribute(name,value) - Ottaa parametrina attribuutin nimen ja sen uuden arvon.
Muutettavan attribuutin arvo tarkistetaan ennen asettamista sisäiseen muuttujaan.
Palauttaa true, jos tarkistus onnistui. Tietokantarivin tunnistenumeroa ei voi muo
kata. Tallentaminen tietokantaan ei tapahdu vielä.
• update() - Päivittää sisäiset arvot tietokantaa ja palauttaa true, jos päivitys onnistui.
• delete() - Poistaa valittuna olevan tietokantarivin tietokannasta.
• get Array Of All (filter) - Ottaa parametrina SQL-lausekkeeseen sopivan suodattimen (esim. ”WHERE id< 10 ORDER BY time”) ja palauttaa suodatetun joukon kyseisiä olioita.
Databaseitem-luokan aliluokka File toteuttaa omat versiot seuraavista metodeista:
• create(attributes) - Kuten Databaseitem, mutta tallentaa attribuuttina saadun tie
doston oikeaan paikkaa ja muuntaa tiedostonimen muotoon <id>_<filename>, esim. 31.1.2005 julkaistu, tunnistenumeron 323 saanut tilannetieto.pdf tallennetaan nimellä 2005/01 /31 Z323_tilannetieto.pdf. Tiedostojärjestelmän rakenne pysyy sel
vänä ja samaan hakemistoon voi tallentaa tiedostoja, joilla on alun perin sama nimi.
• setAttribute(name, value) - Kuten Databaseitem, paitsi silloin kun vaihdetaan attri
buuttia filename. Tällöin joudutaan tallentamaan uusi tiedostoja poistamaan vanha.
• deleteQ - Kuten Databaseitem, mutta poistaa myös tiedoston.
Käyttöliittymää varten toteutetaan luokka UI ja sen aliluokka AdminUI. Niiden sisältämät metodit toimivat käyttöliittymän rakennuspalikoina, jotka voidaan sijoittaa haluttuun koh
taan sivua. Ul-luokka sisältää seuraavat metodit:
sää sivulle kielen valintaan tarvittavan muuttujan.
• showEventList() - Näyttää listan, jolla voidaan rajata näytettävät tilannetiedot ta
pahtuman mukaan, ja lisää sivulle tähän suodatukseen liittyvän muuttujan.
• showClassList() - Näyttää listan, jolla voidaan rajata näytettävät tilannetiedot luo
kan mukaan, ja lisää sivulle tähän suodatukseen liittyvän muuttujan.
• showInformationList() - Näyttää tilannetietolistan, joka on suodatettu asetettujen suodattimien mukaan. Julkaisemattomassa tilassa olevia tilannetietoja ei näytetä lukijalle.
• useLanguage(id) - Asettaa luokan sisäisen muuttujan language, jota järjestelmä käyttää muiden metodien tuottamiin käyttöliittymän osiin. Lisäksi lataa erillisen tiedoston, jossa sijaitsevat sivuilla tarvittavien staattisten tietojen kieliversiot. Tä
hän asiaan palataan vielä myöhemmin (kappaleessa 4.3.4).
Ul-luokan AdminUI-aliluokka sisältää julkaisijalle näytettävien muokkaussivujen osat.
Kaikki AdminUI-luokan metodit tarkistavat jokaisen vaiheen alussa, onko käyttäjän IP- osoite sallittujen osoitteiden listalla (lista Configuration-luokassa). Jollei osoite ole sallittu, metodi lopettaa suorituksensa ja palauttaa false. Koska nämä muokkaukseen liittyvät toi
minnot ovat moniosaisia ja WWW-ohjelmistot eivät tiedä, missä vaiheessa kyseinen toi
minto aina on, joudutaan sivujen kutsuissa asettamaan tilamuuttuja. Tämä tilamuuttuja kertoo metodille, missä vaiheessa toimintoa ollaan, esim. ollaanko lisäämässä tilannetietoa tietokantaan vai liittämässä juuri lisättyyn tilannetietoon uutta tiedostoa. Jos toiminto on moniosainen, sen täytyy osien välissä asettaa sivuille tieto siitä, mihin vaiheeseen seuraa- vaksi siirrytään. AdminUI-luokka sisältää seuraavat metodit:
• showAddInformationForm() - Tilannetiedon lisäyslomake. Sisältää seuraavat vai
heet:
1. Näyttää lisäyslomakkeen. Käyttäjä täyttää lomakkeen tiedot ja siirtyy seuraa-vaan vaiheeseen.
2. Lisää tiedot tietokantaan (jättää tilannetiedon tilamuuttujan julkaisemattomaan tilaan) ja näyttää tilannetietoon liitettävän tiedoston lisäyslomakkeen. Käyttäjä lisää tiedoston sekä sen kuvauksen ja siirtyy seuraavaan vaiheeseen. Yksi tie
dosto on lisättävä.
3. Lisää tiedoston sekä sen tiedot tietokantaan ja näyttää uuden tiedoston lisäys- lomakkeen tai vaihtoehtona lisäämisen lopettamisen. Jos käyttäjä lisää tiedos
ton, palataan uudestaan vaiheeseen 3. Muuten siirrytään seuraavaan vaiheeseen.
4. Muutetaan tilannetiedon tilamuuttuja julkaistuun tilaan ja näytetään ilmoitus li
säyksen onnistumisesta.
• showModifyInformationForm() - Tilannetiedon muokkauslomake. Sisältää seuraa-vat vaiheet:
1. Näytetään tilannetietolista, josta käyttäjä valitsee muokkauksen kohteen. Siirry
tään seuraavaan vaiheeseen.
2. Näyttää muokkauslomakkeen. Käyttäjä muokkaa tietoja ja siirtyy vaiheeseen 5.
Vaihtoehtoisesti käyttäjä haluaa muokata tiedostoa, jolloin siirrytään seuraa
vaan vaiheeseen.
3. Näytetään tiedoston muokkauslomake. Muokkauksen jälkeen siirrytään seuraa
vaan vaiheeseen.
4. Muokataan tiedostoa tai sen tietoja. Palataan vaiheeseen 2.
5. Tallennetaan muutokset tietokantaan ja näytetään ilmoitus muokkauksen onnis
tumisesta.
• showDeleteInformationForm() - Tilannetiedon poistolomake. Sisältää seuraavat vaiheet:
1. Näytetään tilannetietolista, josta käyttäjä valitsee poiston kohteen. Siirrytään seuraavan vaiheeseen.
2. Näytetään tilannetietoon liittyvät tiedot ja varmistetaan poisto. Jos käyttäjä vah
vistaa poiston, siirrytään seuraavaan vaiheeseen, muuten vaiheeseen 4.
Näytetään käyttäjälle ilmoitus, jossa kerrotaan tilannetiedon poiston onnistumi
sesta. Suoritus loppuu.
4. Näytetään käyttäjälle ilmoitus poiston peruuntumisesta.
• shoxvAddEventForm() - Tapahtuman lisäyslomake. Sisältää seuraavat vaiheet:
1. Näytetään lisäyslomake. Käyttäjä täyttää kentät ja siirtyy seuraavaan vaihee
seen.
2. Tiedot tallennetaan tietokantaan. Näytetään ilmoitus tallennuksen onnistumises
ta.
• showModiJyEventForm() - Tapahtuman muokkauslomake. Sisältää seuraavat vai
heet:
1. Näytetään lista tapahtumista, josta käyttäjä valitsee muokkauksen kohteen. Siir
rytään seuraavan vaiheeseen.
2. Näytetään muokkauslomake (sisältää tapahtuman siirron arkistoon). Käyttäjä muokkaa tietoja ja siirtyy seuraavaan vaiheeseen.
3. Tallennetaan muutokset tietokantaan ja näytetään onnistumisilmoitus käyttäjäl
le.
• showDeleteEventForm() - Tapahtuman muokkauslomake. Sisältää seuraavat vai
heet:
1. Näytetään lista tapahtumista, josta käyttäjä valitsee poistettavan. Siirrytään seu
raavan vaiheeseen.
2. Näytetään tapahtuman tiedot ja varmistetaan poisto. Jos käyttäjä vahvistaa pois
ton siirrytään seuraavaan vaiheeseen, muuten vaiheeseen 4.
3. Poistetaan tapahtuman tiedot tietokannasta. Näytetään käyttäjälle ilmoitus, jossa kerrotaan poiston onnistumisesta. Suoritus loppuu.
4. Näytetään käyttäjälle ilmoitus poiston peruuntumisesta.
• showAddFileFormO - Tiedoston lisäyslomake, jota showAddInformationForm()- metodi kutsuu vaiheissa 2 ja 3. Huolehtii tiedoston käsittelystä.
• show ModifyFileForm() - Tiedoston poistolomake, jota showModifylnformation- Form()-metodi kutsuu vaiheissa 3 ja 4. Huolehtii tiedoston käsittelystä.
• showDeleteFileForm() - Tiedoston lisäyslomake, jota showDeletelnformation- FormQ-metodi kutsuu vaiheissa 3. Huolehtii tiedoston käsittelystä.
4.3.4 Tiedostojärjestelmän muutokset ja ulkoasun muokattavuus
Tiedostojärjestelmän rakenteeseen tehdään myös muutoksia. Suurin muutos on lukijoiden kieliversioiden mukaisen hakemistojaon poistaminen. Kaikki kieliversiot toteutetaan sa
moihin sivupohjiin, joiden käännökset tallennetaan erillisiin tiedostoihin. Sivustolla on melko vähän staattista tietoa, eli melkein kaikki sivulla näkyvä tieto tulee tietokannasta, johon kieliversioiden tuki on tulossa. Sivulla olevat staattiset ilmoitukset, kuten suomeksi
”Tilannetiedot poikkeavista tapahtumista” tai englanniksi ”Finnish Emergency Response Information”, tallennetaan omiin kielitiedostoihin saman nimisiin muuttujiin. Järjestelmä lataa näistä kieliversioista sillä hetkellä käytössä olevan ja korvaa sivupohjissa olevat muuttujat kyseiseen kieleen liittyvillä ilmoituksilla. Lisäksi näihin tiedostoihin voi laittaa esim. eri kieliversioihin liittyvien kuvien nimet. Yhtenäisen ulkonäön aikaansaamiseksi käytetään myös CSS-tyylisivuja, jotka eivät riipu kieliversiosta.
Ö www-root
—Ö admin
—Q classes
—Ö common - -Q users
-Hrp data 3-Q 2005
- o oi
Ö 31
Kaavio 18 Suunnitelma tiedostojärjestelmän rakenteen parantamiselle
taa käyttäjän tunnistus edelleen hakemistokohtaisilla oikeuksilla eli jako lukijoihin ja jul
kaisijoihin {users ja admin). Lisäksi on yhteiset tiedostot {common), esim. kuvat ja CSS- tyylisivut sekä luokille oma hakemisto {classes). Luokkien hakemistoon ei pääse suoraan selaimella, vaan sitä käytetään ainoastaan sivuston kautta.
Tilannetietoihin liittyvät tiedostot tallennetaan edelleen käyttäjähakemiston alla olevaan tifata-hakemistoon, mutta sen alla olevaa rakennetta muutetaan. Jotta kaikki tiedostot eivät edelleenkään olisi samassa hakemistossa, jaetaan tiedostot alihakemistoihin julkaisuvuo- den, -kuukauden ja -päivän mukaan. Lisäksi tiedostonimet rakennetaan edellä (kappaleessa 4.3.3) mainitun kaavan mukaan.
4.4 Testauksesta
Tarkempi testaussuunnitelma ei kuulu tämän työn sisältöön. Kuitenkin ohjelmoinnin aika
na tehdään komponenttitestausta, jotta todetaan järjestelmän eri osien toimivuus. Järjestel- mätestaus tapahtuu aluksi kehittäjän toimesta ja myöhemmin avuksi otetaan myös pieni testausryhmä, joka koostuu lähinnä vanhan järjestelmän julkaisijoista.
5 PARANNETUN JÄRJESTELMÄN KUVAUS
5.1 Yleistä
Tässä kappaleessa käydään läpi uuden järjestelmän rakenne uudistusten jälkeen. Edellä (kappaleessa 4) tehtyyn suunnitelmaan tehtiin toteutusvaiheessa tarkennuksia, jotka selite
tään tässä kappaleessa. Kuten suunnitelmassa mainittiin, PHP4:ssä ei ole tukea eri näky
vyyksille. Vaikka kuvauksessa on muuttujien ja metodien näkyvyydet määritelty, ovat ne vain ohjeellisia.
Lopuksi tehdään uusi kuvaus järjestelmän tärkeimmistä käyttötapauksista ja tutkitaan mi
ten ne ovat muuttuneet parannusten takia. Järjestelmään on parannusten myötä tullut joita
kin uusia toimintoja, joiden tarve on huomattu edellistä järjestelmää käytettäessä.
5.2 Parannuksien tarkempi kuvaus
5.2.1 Tietokanta
Järjestelmän toteutusvaiheessa ei tietokantarakenteeseen tullut muita muutoksia, kuin kah
den taulun nimen vaihtaminen. Nimet vaihdettiin, jotta niiden nimet eivät olisi päällekkäi
siä PHP-kielen olemassa olevien funktioiden kanssa. Vaihdetut taulujen nimet olivat Class ja File, jotka ovat molemmat liian lähellä funktioiden nimiä. C/ass-taulun uudeksi nimeksi
tuli Title ja F7/e-taulun uusi nimi on Attachment.
Language
Has-language Has-Language
Title
Event
Has-language
status name
Has-event status
Information class
language event
Belongs-to
filename Attachment
description information
Kaavio 19 Tietokantarakenne parannusten toteutuksen jälkeen.
Tämän rakenteen (Kaavio 19) epäselvät asiat, jotka ilmenivät toteutusvaiheessa, olivat seu- raavat:
1. Event- tai 7zY/e-taulusta poistetaan sellainen rivi johon Information-taulusta viita
taan.
2. Event- tai 77//e-taulun viittausta Language-tau\\i\m muutetaan, jolloin lnformation- taulu saattaa viitata eri kohtaan Language-taulussa.
3. 57a/w.s-kenttää muokataan £Ven/-taulussa, jolloin Information-taulun rivit, jotka viittaavat £w«/-tauluun, sisältävät eri Sto/z/s-kentän arvon.
Kohta 1. päätettiin pitää mahdollisena, mutta sellaiset Information-taulun rivit, jotka viit- taavat olemattomiin riveihin ko. kahdessa taulussa, eivät enää näy lukijoille. Julkaisijat voivat kuitenkin muokata myös näitä rivejä eli esim. liittää ne johonkin sellaiseen riviin, joka on vielä olemassa. Tämä toimintatapa ainakin vaikeuttaa käyttäjän vahingosta johtu
vaa tiedon häviämistä. Nyt vahingossa tapahtuneen poiston jälkeen vanhat tapahtumatiedot ovat edelleen olemassa.
Kohdan 2. takia päätettiin, ettei viittausta Language-tauluun voi luomisen jälkeen enää muuttaa. Tämä toiminto ei pitäisikään olla usein tarvittu, sillä on hyvin epätodennäköistä, että suurempia kokonaisuuksia siirrettäisiin kieliversiosta toiseen. Kuitenkin julkaistut ti
lannetiedot ovat kirjoitettu yhdellä kielellä.
lannetiedot ovat kirjoitettu yhdellä kielellä.