Kalle Korpijoki
Tilannetietojen julkaisujärjestelmän tekninen parantaminen ja dokumentointi.
Työn valvoja Prof. Tomi Männistö
Työn ohjaaja FK Ari Rosenberg
r ^
HANTI .UNEN KORK*'ARO"' M TIHTOlfcKN IIKAN TAI-ON k::.:»V>10 K!)NhMIFIIliNTlB ?
U2O0 LiHOO
Tekijä
Kalle Korpijoki
Päiväys
23.1.2006
Sivumäärä
61+5
Työn nimi
Tilannetietojen julkaisujärjestelmän tekninen parantaminen ja dokumentointi
Professuuri
Ohjelmistotuotanto ja liiketoiminta
Koodi
T-76
Työn valvoja
Prof. Tomi Männistö
Työn ohjaaja
FK Ari Rosenberg
Työn tarkoituksena oli parantaa olemassa olevan tilannetietojen julkaisujärjestelmän si
säistä rakennetta siten, että järjestelmän WWW-käyttöliittymä pysyy mahdollisimman samanlaisena kuin ennen. Lisäksi haluttiin järjestelmälle dokumentaatio, koska nykyisestä järjestelmästä ei ollut dokumentaatiota.
Työn alussa kuvattiin nykyisen järjestelmän rakenne ja päätettiin mitä parannuksia järjes
telmään tehtäisiin. Tämän jälkeen suunniteltiin ja toteutettiin uusi järjestelmä. Toteutuksen jälkeen tutkittiin järjestelmän huonoja rakenteita menetelmällä, jossa etsitään lähdekoodis
ta huonoja hajuja eli yleisiä huonoja ohjelmointikäytäntöjä. Lopuksi huonoksi havaitut kohdat korjattiin ja kuvattiin järjestelmän suunnitelmaan tehdyt muutokset.
Muutokset sisälsivät siirtymisen oliopohjaiseen ohjelmointiin sekä tietokantarakenteen muuttamisen joustavammaksi. Nämä muutokset todettiin tarpeellisiksi ja hyviksi valin
noiksi. Parannetun järjestelmän lähdekoodista löydettiin joitakin huonoja hajuja ja nämä kohdat korjattiin siinä määrin kuin nähtiin tarpeelliseksi.
Avainsanat
refaktorointi, WWW-ohjelmointi, PHP, julkaisujärjestelmä, UML, koodin haju
Department of Computer Science and Engineering
THESIS
Author Date
Kalle Korpijoki January 23,2006
Pages
61+5
Title of thesis
Improving and Documenting the Emergency Information Publishing System
Professorship Professorship Code
Software Engineering and Business T-76
Supervisor
Prof. Tomi Männistö
Instructor
FK Ari Rosenberg
The purpose of this master’s thesis was to improve the functionality of an existing emer
gency information publishing system without changing the user interface drastically. Also the new documentation was seen important since the current system is not documented.
First the structure of the current system was described and it was decided which improve
ments were to be implemented. According to the improvements the new system was then designed. After the implementation phase the system was checked for bad code smells.
Finding bad code smells is a method used to find bad programming practices in the source code. Then these problem points were fixed and the changes made to the design were documented.
The implemented improvements include changing to object oriented programming and more flexible database structure. These improvements were found necessary and that they were the right choices. Some bad smells were found in the source code after implementing the improvements. These problems found were fixed if they were seen to be severe
enough.
Keywords
refactoring, web programming, PHP, publishing system, UML, code smell
julkaisujärjestelmän kehitystä. Kehitys alkoi vuonna 2002 ja jatkuu edelleen. Tarkoitukse
na on, että Säteilyturvakeskus voisi tarjota yhteistyökumppaneilleen mahdollisimman hy
vää palvelua.
Kiitokset tämän työn valvojille Casper Lasseniukselle ja Tomi Männistölle sekä ohjaajal
leni Ari Rosenbergille. Heiltä sain työhöni tarvittua opastusta ja apua. Kiitos myös työni aikana eläkkeelle jääneelle Säteilyturvakeskuksen ATK-päällikölle Kalevi Hokkiselle, sekä kaikille muille, jotka ovat työtäni tavalla tai toisella auttaneet.
Lopuksi vielä kiitos vanhemmilleni, jotka ovat avustaneet minua opintojeni aikana. Ilman heidän apuaan olisi lähtö pääkaupunkiseudulle opiskelemaan jäänyt tekemättä.
Vantaalla 23.1.2006
Kalle Korpijoki
1 JOHDANTO... 1
1.1 Taustaa...1
1.2 Tavoitteet ja rajoitukset...3
1.3 Menetelmät... 5
2 JÄRJESTELMÄN NYKYTILAN KUVAUS... 7
2.1 Yleistä... 7
2.2 Tärkeimmät käyttötapaukset... 7
2.3 Tarkempi kuvaus...9
2.3.1 Palvelinohjelmistot... 9
2.3.2 Tiedostojärjestelmä...10
2.3.3 Toiminnallisuus... 11
2.3.4 Tietokanta... 19
3 TEORIATAUSTAA PARANNUKSILLE... 21
3.1 Yleistä... 21
3.2 WWW-ohjelmointi...21
3.3 Lähdekoodin parantaminen... 23
4 JÄRJESTELMÄÄN TEHTÄVÄT PARANNUKSET...24
4.1 Yleistä... 24
4.2 Tärkeimmät parannusten kohteet...24
4.3 Parannukset... 25
4.3.1 Tietokantarakenne... 25
4.3.2 Olio-ohjelmointi ja järjestelmän rakenne...28
4.3.3 Luokkien tarkempi kuvaus...31
4.3.4 Tiedostojärjestelmän muutokset ja ulkoasun muokattavuus...37
4.4 Testauksesta... 38
5 PARANNETUN JÄRJESTELMÄN KUVAUS... 39
5.1 Yleistä... 39
5.2 Parannuksien tarkempi kuvaus...39
5.2.1 Tietokanta...39
5.2.2 Toiminnallisuus... 42
6 MUUTOSTEN TARKASTELU... 53
6.1 Yleistä...53
6.2 Lähdekoodi ja tietokannanrakenne...53
6.3 Ulkonäön muokattavuus ja kieliversiot... 53
6.4 Uuden järjestelmän dokumentaatio...54
6.5 Muutokset käyttäj ien näkökulmasta... 55
6.6 Väärinkäytön estäminen... 55
6.7 Tulevaisuuden kehityskohteita... 57
7 YHTEENVETO... 58
LÄHDELUETTELO... 60
LIITTEET:
LIITE 1: Ruudunkaappauksia uudesta ja vanhasta järjestelmästä
LIITE 2: SLOCCount-ohjelman tulokset vanhalle ja uudelle järjestelmälle LIITE 3: Ruudunkaappaus NOTE-projektin järjestelmästä
1 JOHDANTO
1.1 Taustaa
Säteilyturvakeskus (STUK) on turvallisuutta valvova viranomainen, tutkimuslaitos ja asi
antuntijaorganisaatio [www.stuk.fi 2004], STUK:lla on oma valmiusyksikkö, joka valvoo mahdollisia säteilyyn liittyviä vaara- ja onnettomuustilanteita. Valmiustilanteessa valmius- yksikkö muun toimintansa ohella julkaisee tilannetietoja yhteistyökumppaneilleen Interne
tissä olevan tilannetietojen julkaisujärjestelmän kautta. Tästä julkaisujärjestelmästä käyte
tään nimeä FINRI, joka rakentuu englanninkielisistä sanoista ”Finnish Emergency Respon
se Information”. Vastaavia järjestelmiä on käytössä tai suunnitteilla myös muiden maiden säteilyä valvovilla viranomaisilla mm. Ruotsissa ja Norjassa sekä kansainvälisellä ato
mienergiajärjestöllä IAEA:lla.
FINRI
Tilannetiedot poikkeavista tapahtumistaFinnish Emergency Response Information
9>STUK
In English Haku otsikoista Etusivu Aikajärjestys Tapahtumajärjestys
♦ Tilannekuva ja suositukset
♦ Säätiedot ja leviämlsennusteet
♦ Säteilytilanne Suomessa
♦ Säteilytilanne ulkomailla
♦ Lehdistötiedote
♦ Pressmeddelande Taustatietoja
(yleista, karttoja..,)
Tapahtuma-arkisto Palaute
Usein kysyttyjä kysymyksiä
Tapahtuma-arkisto
Tapahtuma: Kaikki tapahtumat ▼ Näytä: Kaikki ▼ j Päivitänäkymäi~|
Tapahtuma Otsikko Alaotsikko/Tiedostot Julkaistu
Suomen aikaa Loviisa2003 Tilannekuva ja
suositukset
Harjoitus on päättynyt, täytä palautelomake 2003-11-25 15:57 Lovilsa2003 Tilannekuva ja
suositukset
Kotieläintuotannon ja juomaveden suojaaminen
2003-11-25 15:52 Loviisa2003 Tilannekuva ja
suositukset
Slsällesuojautumis- ja jodinottosuositukset (kartta)
2003-11-25 15:33 Loviisa2003 Pressmeddelande Läget vid Lovisa kärnkraftverk är allvarligt 2003-11-25
15:30 Loviisa2003 Lehdistötiedote Loviisan ydinvoimalaitoksen päästön suunta
muuttuu 2003-11-25
15:29 Loviisa2003 Tilannekuva ja
suositukset
Joditabletit Kymenlaakson, Etelä-Karjalan ja Päijät-Hämeen maakunnissa
2003-11-25 15:24 Lovlisa2003 Säätiedot ja
leviämlsennusteet
Päivitetty leviämisanlmaatio 25.-27.11. (gif, 2 MB)
2003-11-25 15:20
Lovilsa2003 Pressmeddelande Vindens riktning 2003-11-25
14:44 Loviisa2003 Säteilytilanne Suomessa Mittauspartioiden tuloksia 12:15 UTC (kuva) 2003-11-25
14:36 Loviisa2003 Pressmeddelande Utsläppet från Lovisa har inte kunnat
stoppas, INES 6
2003-11-25 14:28
<< Edelliset 10 Seuraavat 10 >>
Copyright STUKi FINRI - Säteilyturvakeskuksen tilannetiedot poikkeavista tapahtumista
Kuva 1 Ruudunkaappaus yhteistyökumppaneiden FINRI-näkymästä. Näkymässä olevat tilannetiedot liittyvät valmiushaijoitukseen.
dottamisessa. Se on WWW-selaimella käytettävä sivusto, jonka päätavoite on mahdollistaa nopea tiedon jakaminen STUK:n yhteistyökumppaneille. Sisäänpääsy on rajoitettu käyttä
jätunnuksella ja salasanalla. Tämä mahdollistaa julkaistujen tilannetietojen lukemisen miltä tahansa Intemet-yhteydellä, WWW-selaimella ja dokumenttien lukemiseen sopivilla oh
jelmilla varustetulta laitteelta, kunhan käyttäjällä on palvelun vaatima käyttäjätunnus ja salasana.
Tilannetietojen julkaisuun tarvitaan myös PDF-dokumenttien tekemiseen vaadittava oh
jelmisto. Tämä ei ole järjestelmän asettama vaatimus vaan STUK:ssa sovittu tapa, jotta dokumenttien avaus onnistuisi mahdollisimman useassa paikassa ja dokumenttien ulkoasu pysyisi samana. Julkaisemispuolelle pääsemiseen vaaditaan käyttäjätunnuksen ja salasanan lisäksi myös työasemakohtaiset erillisoikeudet, eli pääsyä on rajoitettu myös työasemien IP-osoitteen mukaan. Sivusto on sijoitettu ulkoisen palveluntarjoajan palvelimelle, jotta sen aiheuttama tietoliikennekuorma ei hidasta STUK:in käyttäjien toimintaa valmiustilan- teissa.
Ylläpitäjä:
- VWWV-selain - PDF-dokumenttien
valmistamiseen sopiva ohjelmisto
Yhteistyökumppani:
- VWWV-selain - PDF-dokumenttien
lukuohjelma
Luku:
- käyttäjätunnus - salasana
Kaavio 1 FINRI:n toiminta yksinkertaistettuna.
FINRI kehitettiin vuonna 2002. Osittain lyhyestä kehitysajasta johtuen järjestelmän raken
teesta ei ole olemassa dokumentointia. Järjestelmään on tämän jälkeen tehty myös lisäyksiä ja muutoksia, jotka ovat tehneet sen rakenteesta hyvin epäselvän. Dokumentoinnin puute vaikeuttaa ylläpitoa huomattavasti, eikä alkuperäinen rakenne ole suunniteltu muutostar
peita huomioon ottaen.
Järjestelmässä on kaksi kieliversiota: suomi ja englanti. Käyttäjän näkymät (Kuva 1) sivus- tolla ovat suurimmaksi osaksi taulukkoja, joissa on lueteltu tapahtuman nimi, siihen liitty
vä otsikko, alaotsikko ja julkaisuaika. Tapahtuman nimellä ryhmitellään samaan tapahtu
maan liittyvät tilannetiedot ja otsikolla kerrotaan tarkempi kategoria. Alaotsikkoja voi olla useampi ja ne ovat hyperlinkkejä dokumentteihin.
Viime aikoina on ilmennyt joitakin tarpeita saada vastaava järjestelmä hieman erilaiseen tarkoitukseen, kuten tiettyyn projektiin liittyvien dokumenttien jakamiseen. Tästä on he
rännyt ajatus, voitaisiinko FINRLssä käytettävää järjestelmää saada muokattua näihinkin tarpeisiin sopivaa. Tämä on luultavasti hyvin työlästä juuri sen takia, ettei järjestelmää suunniteltaessa ole otettu huomioon mahdollista rakenteen suurempaa muokkausta.
1.2 Tavoitteet ja rajoitukset
Tämän diplomityön tärkein tavoite on helpottaa nykyisen järjestelmän lähdekoodin ylläpi
dettävyyttä. Samalla on tarkoitus parantaa järjestelmän muokattavuutta toiminnallisuuden lisäksi myös ulkonäöllisesti. Työssä keskitytään lähinnä järjestelmän sisäiseen toimintaan.
Lähdekoodin ylläpidettävyyden helpottamiseksi järjestelmästä tehdään dokumentaatio ja järjestelmän osien rakennetta parannetaan mm. siirtymällä olio-ohjelmointiin ja uusimalla tietokantarakenne. Olio-ohjelmointiin siirryttäessä on tarkoituksena kerätä samaan asiaan liittyvät toiminnallisuudet luokiksi, jolloin rakenteen hahmottaminen helpottuu. Samalla muutosten tekeminen yksinkertaistuu, koska nykyisen järjestelmän useassa eri paikassa olevat samat toiminnallisuudet kerätään yhteen.
Nykyisessä tietokantarakenteessa on redundanssia eli turhaa toistoa, sillä molemmilla kie
liversioilla on omat taulunsa tietojen tallentamiseen ja jokainen julkaistu tilannetieto varaa aina tietyn määrä tilaa liitetiedostojen tiedoille. Edellä mainituista syistä johtuen mm. sa
mojen funktioiden käyttäminen tietokannan muokkaamiseen eri kieliversioissa on moni
ta tulisi normalisoida, eli poistaa ylimääräinen toisto ja jakaa taulu loogisiin kokonaisuuk
siin [Ullman & Widom 2002], Rakenteen jakaminen pienempiin loogisiin kokonaisuuksiin helpottaa tietokannan muuttamista, koska tällöin mahdolliset myöhemmät muutokset vai
kuttavat pienempään osaan järjestelmän toiminnallisuuksista.
Järjestelmän ulkonäöllisen muokkauksen helpottamiseksi on tarkoitus erottaa toiminnalli
suus ja kieliversiot ns. sivupohjista. Tällä hetkellä jokainen toiminnon osa on oma sivunsa, joka sisältää sekä toiminnallisuuden että ulkonäön määrittelyt. Tämän lisäksi on myös kak
si kieliversiota jokaisesta sivusta. Jos jotakin ulkonäköön liittyvää seikkaa haluttaisiin muuttaa, jouduttaisiin käymään jokainen sivu läpi ja tekemään halutut muutokset niihin.
Uudessa järjestelmässä tulisi olla sivupohja, johon staattinen teksti lisätään käytössä olevan kielen mukaan ja toiminnallisuus tuottaa muuttuvan sisällön. Näin voidaan muuttaa ulko
näköä muokkaamalla sivupohjaa, kieliversioita muokkaamalla kielitiedostoja ja toiminnal
lisuutta muokkaamalla järjestelmän lähdekoodia.
Tapahtumien ja otsikoiden muokkaaminen on lisättävä uuteen järjestelmään siten, että jul
kaisija voi tehdä kyseiset toiminnot itse. Vanhassa järjestelmässä julkaisija voi lisätä ja poistaa tapahtumia, mutta etenkin tapahtuman nimen vaihtaminen on monimutkaista. Otsi
koiden käsittelyn joutuu tekemään järjestelmän ylläpitäjä, koska käsittely vaatii tietokan
nan suoraa muokkausta. Nämä toiminnot nopeutuisivat huomattavasti jos julkaisijalla olisi mahdollisuus tehdä ne itse käyttöliittymän kautta.
Koska järjestelmä sijaitsee julkisessa verkossa, tulee järjestelmän toteutuksessa ottaa huo
mioon mahdolliset väärinkäyttöyritykset. Vaikka yhteys FINRIm ja käyttäjän välillä on suojattu salasanalla ja salauksella, voi salasanat jotenkin päästä ulkopuolisten tietoon. Jos ulkopuolinen käyttäjä pääsee järjestelmään, hänen ei pitäisi päästä häiritsemään muita jär
jestelmän käyttäjiä.
Diplomityössä ei keskitytä järjestelmän käyttöliittymään tai käytettävyyteen. Nykyisen järjestelmän käytettävyydestä saatu palaute on ollut suurimmaksi osaksi positiivista, joten käytettävyystutkimus voidaan rajata tämän työn ulkopuolelle. Uuden järjestelmän oletus- käyttöliittymä on tarkoitus toteuttaa mahdollisimman samankaltaiseksi nykyisen järjestel
män kanssa. Myös tarkempi testaussuunnitelma tehdään erikseen, eikä näin ollen sisälly tähän työhön.
Tämän diplomityön tärkeimmät tavoitteet yhteenvetona:
• järjestelmän sisäisten rakenteiden parantaminen ja lähdekoodin ylläpidon helpotta
minen käyttämällä olio-ohjelmointia ja selventämällä tietokantarakennetta
• järjestelmän muokattavuuden parantaminen erottamalla sivujen ulkonäkö, kieliver
siot ja toiminnallisuus toisistaan
• ajan tasalla olevan dokumentaation laatiminen järjestelmälle
• julkaisijan työn nopeuttaminen mahdollistamalla tapahtumien ja otsikoiden muok
kaaminen käyttöliittymän kautta
• sivuston väärinkäytön estäminen
Tavoitteiden toteutumiseen palataan työn loppuosassa (kappaleessa 6).
1.3 Menetelmät
Diplomityön tärkein tutkimusaineisto on nykyisen järjestelmän lähdekoodi, jota työn edis
tyessä parannetaan. Järjestelmä on ohjelmoitu PHP-kielellä, jota voidaan käyttää suoraan HTML-sivuihin upotettuna, kunhan palvelinohjelmisto tukee tätä. Lisäksi valmista aineis
toa ovat kahden vuoden aikana pidetyistä valmiusharjoituksista saatu palaute.
Järjestelmän kuvauksessa käytetään tarkoitukseen sopivilta osin UML-kuvauskieltä [OMG 2003; Booch et ai. 1999], Ainakin alkuvaiheessa tulee kuitenkin ottaa huomioon kuvaus
kielen olio-ohjelmointikeskeisyys, sillä nykyisessä lähdekoodissa ei ole käytetty olioita.
Työn aikana on tarkoitus kuitenkin siirtyä olio-ohjelmointiin, koska PHP tukee sitä. Tieto
kantarakenne on myös yksi parannus- ja dokumentointikohde. Rakenteen kuvaukseen ja suunnitteluun käytetään E/R-kaavioita.
Tarvittavien kaavioiden tekemiseen käytetään vapaasti saatavilla olevaa Dia-ohjelmaa, joka on tarkoitettu juuri kaavioiden piirtämiseen. Kaavioiden piirtämisessä noudatetaan mahdollisimman pitkälle aineistossa määriteltyjä UML- ja E/R-kaavioiden merkintätapoja [Booch et ai. 1999; Ullman & Widom 2002], mutta käytetyt ohjelmistot saattavat asettaa joitakin rajoituksia. Mahdolliset merkintätapoihin liittyvät eroavaisuudet, määritellään
erikseen kyseisessä kappaleessa.
tiedot lähdekoodiin [java.sun.com 2005], Javadoc-kommentointi käytetään Java- lähdekoodissa ja sille on työkalu, jolla luokkien toiminnallisuuden dokumentointi voidaan tehdä automaattisesti kommenttien pohjalta. Tämä työkalu ei toimi PHP-kielellä kirjoitet
tujen luokkien kanssa, mutta kommentointitapa on käytännöllinen ja tunnettu. Kommen
teissa kuvataan luokan, muuttujien ja funktioiden toiminnallisuudet sekä funktioiden mah
dolliset parametrit ja palautusarvot.
Lisäksi apuna käytetään juuri PHP-kieltä ja WWW-ohjelmointia koskevia artikkeleja, jotka käsittelevät lähdekoodia tietoturvan näkökulmasta. Vaikka järjestelmään pääsy on käyttäjä
tunnuksella ja salasanalla suojattu, on sivuston tietoturvaan kiinnitettävä huomiota.
2 JÄRJESTELMÄN NYKYTILAN KUVAUS
2.1 Yleistä
Tässä kappaleessa käydään läpi järjestelmän nykytila, eli FINRIin tämänhetkinen toiminta.
Ensin käydään läpi nykyisen järjestelmän tärkeimmät käyttötapaukset, joiden pohjalta teh
dään kuvaukset, kuinka järjestelmä toimii näissä tapauksissa. Kuvaukset ovat niin sanottuja dynaamisia kuvauksia, eli niissä tarkastellaan järjestelmän eri osien yhteistoimintaa tietyis
sä tapauksissa. Näiden kuvausten pohjalta voidaan myöhemmässä vaiheessa suunnitella järjestelmän parannuksia ja lähdekoodin muuntamista olio-ohjelmointimalliin.
Lopuksi tehdään kuvaus myös järjestelmän käyttämästä tietokantarakenteesta. Näihin ku
vauksiin käytetään staattisia malleja, sillä tietokannan rakenne ei muutu käytön aikana, tietokantaan vain tallennetaan tietoa.
2.2 Tärkeimmät käyttötapaukset
Tärkeimpien käyttötapausten ja niiden välisten riippuvuuksien kuvaamiseen käytetään UML-kielessä määriteltyä käyttötapauskaaviota. Kaaviossa (Kaavio 2) on kuvattu eri käyt
täjien kannalta kaikkein yleisimmät ja tärkeimmät käyttötapaukset, jotka järjestelmällä on.
Tilannetietojen suodatus
Tilannetietojen haku sanalla
«include»
«include»
Käyttäjä
Tilannetietojen listaus
«include»
Tilannetiedon poisto
Julkaisija
«include»
Tilannetiedon muokkaus
«include»
Tilannetiedon lisäys
«include»
Tapahtuman siirto arkistoon
Tapahtumien listaus
«include»
Tapahtuman palautus arkistosta
Kaavio 2 Järjestelmän tärkeimmät käyttötapaukset.
Ensimmäinen käyttötapaus jokaisella järjestelmän käyttäjällä on järjestelmään kirjautumi
nen. Nykyisessä järjestelmässä kirjautuminen suoritetaan HTTP-palvelimen omalla käyttä
jän tunnistusmenetelmällä, jossa tiettyjen hakemistojen alla oleviin sivuihin ja niiden tar
joamaan toiminnallisuuteen vaaditaan toimiva käyttäjätunnus ja salasana.
Järjestelmällä on kahdenlaisia käyttäjiä eli käyttäjän ilmentymiä, lukijat ja julkaisijat. Luki
jat ovat käyttäjiä, jotka voivat seurata millaista tietoa järjestelmän kautta julkaistaan eli FINRLn tapauksessa he ovat Säteilyturvakeskuksen valmiustilanteen aikaisia yhteistyö
kumppaneita. Julkaisijat ovat niitä käyttäjiä, jotka voivat lukijan käyttötapausten lisäksi myös julkaista uusia tietoja järjestelmään, eli FINRl:ssä he ovat Säteilyturvakeskuksen valmiusorganisaation työntekijöitä. Lukijoille on kaksi kieliversiota: suomi ja englanti, mutta julkaisijoille on tällä hetkellä vain yksi, koska kaikki julkaisijat osaavat suomea.
Kaaviossa (Kaavio 2) keskeisin käyttötapaus on tilannetietojen listaus, jota suurin osa muista käyttötapauksista tarvitsee. Tilannetietojen haku sekä suodatus näyttävät siis tulok
sensa samanlaisena listana. Lisäksi julkaisija käyttää muokatessa tai poistaessa tilannetieto
ja suodatettua listaa, josta voidaan valita haluttu tilannetieto.
Julkaisija voi lisätä järjestelmään tapahtumia vain tilannetiedon lisäyksen yhteydessä, eli kyseistä toimintoa ei voi käyttää suoraan. Tapahtumien listausta voidaan pitää erillisenä käyttötapauksena, sillä listausta käytetään kaaviossa mainittujen käyttötapausten lisäksi myös mm. sivustolla olevassa valikossa.
2.3 Tarkempi kuvaus
2.3.1 Palvelinohjelmistot
FINRI koostuu PHP-ohjelmointikielellä kirjoitetuista sivuista, joiden esittämiseen käyte
tään HTTP-palvelinohjelmistoa jossa on tuki PHP-kielelle. Tietovarastoina järjestelmä käyttää MySQL-palvelinohjelmistoa sekä käyttöjärjestelmän tarjoamaa tiedostojärjestel
mää.
Ohjelmoinnin aikana testausjärjestelmänä käytettiin PC-tekniikkaan perustuvaa palvelinta, Linux-käyttöjärjestelmää ja Apache HTTP-palvelinohjelmistoa. Tuotantokäyttöön siirryt
täessä järjestelmä asennettiin palveluntarjoajan palvelimelle, jossa on Netscape-Enterprise
olla mikä tahansa, kunhan MySQL toimii ja PHP-kielelle löytyy tuki.
2.3.2 Tiedostojärjestelmä
Järjestelmän käyttämän tiedostojärjestelmän rakenne on päätasoltaan melko yksinkertai
nen. Rakenteessa on jaettu dokumentin julkaisijoiden ja lukijoiden käyttämät toiminnalli
suudet omiin hakemistoihin sekä yhteiset kuvat omaan hakemistoon. Tämä päätason ra
kenne johtuu täysin käytetystä käyttäjätunnistuksesta. Tunnistus perustuu hakemistokohtai
siin oikeuksiin, kuten edellä (kappaleessa 2.2) mainittiin. Lukijoiden hakemiston alla oleva hakemistorakenne on monimutkaisempi.
Ö www-root
—Ö admin
—Pit pics
-HÖI users
•—tip en
—tp) data
—(p 2004 --£p 12_24
—G 12_36_21
“0 1 -Q 2
•Hp fi
—tp data
—Ip 2004
—tp 12_24
—tp 12_30_59
—£5 i
^2 HÖ 3
—Q pda
Kaavio 3 Tiedostojärjestelmän rakenne
Kuten yllä olevasta kaaviosta (Kaavio 3) näkyy, on lukijat jaettu kolmeen pääryhmään:
englanninkieliset, suomenkieliset ja pieninäyttöisten laitteiden esim. kämmentietokoneiden ja WWW-selaimella varustettujen puhelimien käyttäjät. Pieninäyttöisten laitteiden käyttä
jät on yksi muutos, joka on tehty alkuperäiseen järjestelmään ja on erikoistapaus, joten tässä vaiheessa keskitymme enemmän suomen-ja englanninkielisten lukijoiden hakemisto
jen rakenteisiin.
Molempien kieliversioiden hakemistot sisältävät samat toiminnallisuudet ja molemmissa on oma alihakemisto, johon järjestelmään lisätyt aineistot tallennetaan. Tämän aineistoha- kemiston alla olevat tiedostot jaetaan vielä omaan hakemistorakenteeseensa, jossa käyte
tään kaavion (Kaavio 3) mukaista nimeämistä. Ylimmällä tasolla hakemiston nimi raken
tuu julkaisuvuodesta, jonka jälkeen tulee kuukausi sekä päivä, kellonaika ja viimeisellä tasolla on järjestelmän sisäinen järjestysluku kyseiselle tiedostolle. Pieninäyttöisten laittei
den hakemisto ei sisällä liitetiedostoja, vaan sieltä viitataan suoraan kieliversioiden alla oleviin tiedostoihin.
2.3.3 Toiminnallisuus
Seuraavaksi käydään läpi järjestelmän toiminnallisuutta tärkeimpien käyttötapausten kan
nalta (kuvattu kappaleessa 2.2). Kuvauksessa käytetään UML-kielen sekvenssikaavioita, jotka kuvaavat järjestelmän ajon aikaista toimintaa [Booch et ai. 1999]. Toiminnallisuudet on jaettu moneen pieneen osaan, joista jokainen toteuttaa vain tietyn pienen osan koko jär
jestelmän toiminnallisuudesta. Vaikka käyttötapauskaaviossa (Kaavio 2) on kuvattu, että tilannetiedon muokkaus ja poisto käyttävät tilannetietojen suodatusta, lähdekoodin tasolla tämä suodatustoiminnallisuus on toteutettu jokaiseen paikkaan erikseen. Tästä johtuen staattisen rakenteen kuvaaminen ei ole mielestäni tarkoituksenmukaista, vaan dynaaminen kuvaus selventää rakennetta paremmin.
Kaavioissa on käytetty olioiden nimien tilalla ko. toiminnallisuuden toteuttavien PHP- sivujen nimiä sekä järjestelmän osien yleisnimiä, kuten tietokanta ja tiedostojärjestelmä.
Lisäksi lähetettyjen ja vastaanotettujen viestien nimet on tehty selventämään mitä kyseises
sä kohdassa tapahtuu. Tässä joudutaan hieman soveltamaan UML-kieltä kuvausten selven
tämiseksi, koska järjestelmän rakenne ei koostu olioista.
Lukijan käyttötapauksista ei ole omia sekvenssikaavioita, koska kirjautuminen on toteutet
tu HTTP-palvelinohjelmiston avulla ja tilannetietojen listaus sekä suodatus (tilannetietojen haku on suodatuksen erikoistapaus) sisältyvät muihin käyttötapauksiin. Loput tärkeimmistä käyttötapauksista, eli julkaisijan osuus, on kuvattu.
Kappaleen lopussa on lisäksi yhteenveto PHP-sivujen toiminnallisuuksista. Se koostuu taulukoista, joissa on lueteltu PHP-sivujen nimet sekä lyhyt kuvaus sivun sisältämästä toi
minnallisuudesta.
Julkaisija linsert.php : tietokanta
haal kävql nm^l p __ lisäysLoraaLe _ _ _
lisäaTisdat
haeTnnahti imat
^ tap ah tn raa Lista
ra
lisätty____________
lisääTiatol antaan.
- onnistui_____
tallennjiTieciastot
-QDflistui
itiedostojärjestelmä
Kaavio 4 Tilannetiedon lisäys sekvenssikaavio
Kaaviossa (Kaavio 4) on kuvattu uuden tilannetiedon lisäys järjestelmään. Ensin julkaisija hakee lisäyslomakkeen, joka sisältää mahdollisuuden liittää tilannetieto jo olemassa ole
vaan tapahtumaan. Tämä lomake sisältää mahdollisuuden tallentaa tilannetietoon liittyen seitsemän tiedostoa. Tämä seitsemän tiedostoa on järjestelmän sisältämä rajoitus.
Seuraavaksi lisäyslomakkeen tiedot ja siihen liittyvät tiedostot lähetetään palvelimelle.
Järjestelmä tallentaa syötetyt tiedot tietokantaan ja tallentaa tietoihin liittyvät tiedostot tie
dostojärjestelmään. Lopuksi julkaisija saa näytölleen ilmoituksen tietojen tallennuksen onnistumisesta.
tietokanta
:selectmodify.php :modify.php
haeRaiausLomal.e
tapahtum dLisla El
haeTapahtiumatFN
___rajaus Le make_____ haeValintalomake
on tilannetietojen lisäys ja suodatus käyttötapauksia vastaava
haaBatati itPedot
_rmatua;ia£iQt _
Kaavio 5 Tilannetiedon muokkaus sekvenssikaavio osa 1
Tilannetiedon muokkauksen kuvaus on jaettu kahteen osaan (Kaavio 5 ja Kaavio 6). En
simmäisessä osassa (Kaavio 5) rajataan tapahtumien ja otsikkojen avulla tilannetietolistaa, josta muokattava tilannetieto valitaan, ja näytetään julkaisijalle tämä lista. Rajauksessa näytetään molemmat kieliversiot, joten järjestelmä joutuu hakemaan eri kieliversiot eri tietokantatauluista. Tietokannan rakenteeseen palataan tarkemmin myöhemmin (kappa
leessa 2.3.4).
Valintalomakkeessa haetaan ensin otsikko, jotta voidaan hakea tietokannasta rajausten mu
kainen lista tapahtumia. Otsikon haku tarvitaan, koska otsikko lähetetään kutsussa nume
rona (otsikon tunniste) ja hakemisessa tarvitaan otsikkoa. Tämä toiminnan epäloogisuus johtuu osittain juuri alkuperäiseen järjestelmään tehdyistä muutoksista. Kaavion osa, jossa rakennetaan valintalomake, kuvaa myös tilannetietojen näyttö-ja suodatuskäyttötapauksia.
:changefile.php : tietokanta
: modif y2.php :tiedostojärjestelmä
Julkaisija
baaMuoLLausi omaka
munii outoinako. -
hapJiftrinsrarjvaihfcfll m
hapTipdo«:fnnTiiadof ^
li od ostoni] edot _ .tiedosto ny4ihtc> lorulle
waihdaliadQsla.
nnisra\/anhaTiednsrn
tallfinnaUjisiTiPiInstii
___ onnistui____
haftMuinl.l.ansI n m ai .e.
jjiupLI ausLomai.o___
rallftnnaMmirnLsftt
näuitahaiU.iTiotlot
___ tallon ne ttu___
Kaavio 6 Tilannetiedon muokkaus sekvenssikaavio osa 2
Sekvenssikaavion toisessa osassa (Kaavio 6) kuvataan toiminta, kun muokattava tilannetie
to on jo valittu ja siihen tehdään muutoksia tietoihin sekä vaihdetaan yksi siihen liittyvä tiedosto. Ensin julkaisija valitsee muokkauslomakkeesta tiedoston, jonka haluaa vaihtaa ja
saa lomakkeen, jolla tiedoston voi vaihtaa. Liitettyään lomakkeeseen uuden tiedoston, jul
kaisija lähettää sen järjestelmään, joka poistaa vanhan tiedoston tiedostojärjestelmästä, tallentaa uuden ja päivittää tietokannassa olevan viittauksen tiedostoon.
Tämän jälkeen julkaisija saa ilmoituksen tiedoston onnistuneesta vaihdosta ja tämän ilmoi
tuksen alla on painike, josta päästään takaisin tilannetiedon muokkauslomakkeeseen.
Muokkauslomakkeeseen voi vielä tehdä loput tarvittavat muutokset ja lähettää ne. Lopuksi järjestelmä päivittää muokatut tiedot tietokantaan ja näyttää julkaisijalle sivun, jolla kerro
taan muokkauksen onnistuneen.
Kaavio 7 Tapahtuman siirto arkistoon sekvenssikaavio
Kaaviossa (Kaavio 7) kuvataan tapahtuman siirto arkistoon, mutta sama sekvenssikaavio sopii myös tapahtuman siirtoon takaisin arkistosta. Tällöin arkistointitila muutetaan tieto
kannassa pois päältä.
Julkaisija hakee aluksi lomakkeen, josta voi valita joko suomen- tai englanninkielisen ta
pahtuman. Tämä siirretään kokonaisuudessaan arkistoon eli siihen ei voi enää lisätä tilan
netietoja. Kun tapahtuma on valittu ja tieto lähetetty, järjestelmä muuttaa kaikkien tapah
tumaan liittyvien tilannetietojen arkistointitilan päälle tai pois.
iselectdelete.php :delete.php Julkaisija
h^oR.siAi Kl nm^il p
ta p^ hlu m £U,i 5taD
IwTanahrlimatFN
tapahtumalijs^aEN,
__ raja lis Up maLe____
haoRaiaP itTiprlnt-
_rajatutJia.doJ: _
hap\/ahvkki|isl omål
__ q£sikkfi___
hapRaiafi itTiprlnt-
_rajatutjispiQj; _ xabyistuskcmal^e
Kaavio 8 Tilannetiedon poisto sekvenssikaavio osa 1
Myös tilannetiedon poisto on jaettu kahteen sekvenssikaavioon (Kaavio 8 ja Kaavio 9).
Poistaminen aloitetaan samalla tavalla kuin tilannetiedon muokkaus, mutta valintalomak- keen jälkeen näytetään samanlainen lomake uudestaan, jossa valinta tulee vahvistaa.
:tietokanta tiedostojärjestelmä Julkaisija
nniskakaiU-iTipHnt-
nnkfafriprioqfn 1
Toistetaan tiedoston ja hakemiston poisto liitteille 1-7 nnistaKIhHal emistn
QJJOislui.
orioistui.
_ tiStbtEoist£ttu__
Kaavio 9 Tilannetiedon poisto sekvenssikaavio osa 2
Toisessa osassa (Kaavio 9) julkaisija on vahvistanut poiston, jolloin järjestelmä hakee en
sin tietokannasta tilannetietoon liittyvien tiedostojen nimet muistiin, jonka jälkeen kyseisen tilannetiedon voi poistaa tietokannasta. Tämän jälkeen järjestelmä käy läpi kaikki liitetie
dostot ja poistaa ne sekä niihin liittyvän hakemiston. Lopuksi poistetaan liitteiden hakemis- torakenne, joka on kuvattu aiemmin (kappaleessa 2.3.2), ja näytetään julkaisijalle ilmoitus poiston onnistumisesta.
Taulukko 1 Lukijan käyttämien PHP-sivujen toiminnallisuudet
display.php Näyttää kaikki tilannetiedot tai niistä suodatetun listan käyttäjäl
le.
menu.php Näyttää valikon, jolla voidaan suodattaa tilannetietoja otsikoiden mukaan.
displayold.php Näyttää arkistoidut tilannetiedot tai niistä suodatetun listan käyt
täjälle.
search.php Tilannetietojen hakulomake.
Taulukko 2 Julkaisijan käyttämien PHP-sivujen toiminnallisuudet
insert.php Uuden suomenkielisen tilannetiedon tallennuslomake.
inserten.php Uuden englanninkielisen tilannetiedon tallennuslomake.
selectmodify.php Muokattavan tilannetiedon valintalistan suodatuslomake.
modify.php Muokattavan tilannetiedon valintalista.
modify2.php Tilannetiedon muokkauslomake.
changefile.php Tilannetietoon liittyvän tiedoston valintalomake.
selectdelete.php Poistettavan tilannetiedon valintalistan suodatuslomake.
delete.php Poistettavan tilannetiedon valintalista.
delete2.php Tilannetiedon poisto.
makeold.php Tapahtuman siirto arkistoon.
makenew.php Tapahtuman siirto takaisin arkistosta.
Vanhan järjestelmän lähdekoodin koko on 1950 koodiriviä laskettuna David A. Wheelerin SLOCCount-ohjelmalla (ohjelman tulokset liitteessä 1). Koodista hieman yli puolet eli 1031 koodiriviä on lukijan toiminnallisuutta ja loput 919 koodiriviä toteuttaa julkaisijan tarvitseman toiminnallisuuden. Koodirivien määrää lisää kieliversiot, koska samat toimin
nallisuudet ovat sekä suomenkielisissä että englanninkielisissä sivuissa.
2.3.4 Tietokanta
Tilannetietoihin liittyviä tiedostoja lukuun ottamatta kaikki julkaisijan tallentamat tiedot ovat tietokannassa. Tietokannassa oli aluksi vain yksi taulu kieliversiota kohti, mutta jär
jestelmän oltua käytössä jonkin aikaa huomattiin, että tarvittiin otsikkojen muokkaamista.
Tämä vaati järjestelmän eri osien muokkaamista, sillä otsikoiden nimet oli kirjoitettu suo
raan lähdekoodiin. Tämän takia päätettiin, että olisi parempi, jos otsikoita pystyttäisiin muokkaamaan hieman helpommin. Näin ollen tehtiin tietokantaan uusi taulu, joka sisälsi otsikoiden nimet. Otsikoita ei kuitenkaan voi muokata suoraan käyttöliittymän kautta.
luokat
otsikko-on
aika
otsikko nimi?
tiedl
tapahtumat
tied:
tiedé
nimi 5
nimi 3
Kaavio 10 E/R-kaavio järjestelmän käyttämästä tietokantarakenteesta
tumat ja luokat. Englanninkielisille tilannetiedoille on omat vastaavat taulut, joiden nimet ovat events ja classes.
Järjestelmässä oleva tapahtumat-tanhx sisältää kaikki tilannetietoihin liittyvät tiedot. Jo tämän taulun nimi on epälooginen sillä se sisältää tilannetietoja, jotka liittyvät johonkin tapahtumaan. Jokaisella tilannetiedolla on yksilöllinen avain (id), jolla tilannetietoon voi viitata. Muut tiedot ovat tapahtuman nimi (tapahtuma), mihin luokkaan kyseinen tilanne- tieto liittyy (otsikko), julkaisuaika (aika) ja tieto siitä, onko kyseinen tieto arkistoitu (van
ha). Lisäksi taulussa on paikka seitsemälle tiedostonimelle (tiedl-tiedT) ja viitatun tiedos
ton kuvauksille (nimil-nimiT). Tämä menettely asettaa rajoitteen yhteen tilannetietoon liit
tyvien tiedostoiden maksimimäärälle.
Luokat-ia\i\u sisältää tilannetietojen eri luokat (nimi) ja niiden yksilölliset avaimet (id).
Tapahtumat-taulussa ei kuitenkaan viitata luokkiin niiden yksilöllisellä avaimella vaan nimellä. Tämä on epäloogista, mutta näin säästyttiin muokkaamasta kaikkia järjestelmän osia, kun luokat-iauhx jouduttiin lisäämään.
3 TEORIATAUSTAA PARANNUKSILLE
3.1 Yleistä
Tässä kappaleessa käydään läpi aineistoa, jota käytetään parannuksien suunnittelussa ja toteutuksessa. Ensin käydään läpi WWW-ohjelmoinnin kehitystä, erikoispiirteitä ja mihin pitää erityisesti kiinnittää huomiota. Lopuksi käydään läpi myös perinteiseen ohjelmointiin liittyviä asioita ja keskitytään etenkin tarkastelemaan juuri olemassa olevan järjestelmän parantamista sekä suunnittelumalleja.
3.2 WWW-ohjelmointi
Ensimmäinen toteutus WWW:stä (World Wide Web) tehtiin vuonna 1990 ja toteuttajana oli Tim Bemers-Lee [www.w3.org 2005]. Seuraavan 15 vuoden aikana sen tekniikka on kehittynyt paljon ja käsite WWW-ohjelmointi on muuttunut samalla. Aluksi sivuilla oleva tieto oli staattista ja käyttäjiä vähän, eli WWW-ohjelmointi oli lähinnä HTML-kielellä ole
vien dokumenttien kirjoittamista. Ajan kuluessa käyttäjämäärät ja samalla tiedon määrä on kasvanut, jonka takia on tarvittu monipuolisempia tapoja toteuttaa sivustoja. Dynaamisten sivustojen toteuttamiseen on useita tapoja, joita on tutkittu sekä vertailtu toisiinsa [Vajda
1998; Malinowski & Wilamowski 2001].
Viimeisen viiden vuoden aikana WWW-ohjelmoinnissa on keskitytty mm. parempaan yh
teensopivuuteen, monikielisyyteen, uudelleenkäyttöön ja tietoturvaan [Tilley 2003]. Myös oliopohjaisuutta ja siihen liittyviä eri menetelmiä pidetään hyvinä toimintatapoina [Coda et ai. 1998; Gellersen & Gaedke 1999], Näihin keskitytään myös FINRI-järjestelmään tehtä
vissä parannuksissa.
Toiminnallisuutta voidaan toteuttaa sekä palvelin- että asiakasohjelmistossa riippuen oh
jelmiston tarpeista. FINRI-järjestelmän toteutukseen valittu PHP-kieli on palvelinohjelmis
toon sisällytetty kieli, joka suoritetaan palvelimella. Tällä päätöksellä on haettu mahdolli
simman hyvää yhteensopivuutta eri asiakasohjelmistojen kanssa. Jos käytettäisiin toista, asiakkaan ympäristössä suoritettavaa kieltä, olisi toiminnallisuuksien toteuttaminen vaike
ampaa. WWW-selaimilla ja käyttöjärjestelmillä on eroavaisuuksia näiden kielien kohdalla,
mowski 2001],
Monikielisyys sekä uudelleenkäyttö liittyvät osittain toisiinsa, koska eri kieliversiot ovat saman toiminnallisuuden uudelleenkäyttämistä eri kielillä. Kuitenkin uudelleenkäytöllä on myös laajempi tarkoitus, kuten FINRI-järjestelmän tapauksessa järjestelmän käyttö muiden dokumenttien julkaisemiseen. Tarkoituksena on, että ulkonäön ja sivuilla olevan staattisen tiedon muokkaus olisi mahdollisimman helppoa.
PHP-kieli sisältää piirteitä, joilla olio-ohjelmointia voidaan toteuttaa. Tämän hetkisen pal
veluntarjoajan palvelinohjelmisto sisältää PHP-kielestä version 4 (PHP4), jolla olio- ohjelmointi onnistuu, mutta tuki ei ole täydellinen. Uudempi versio 5 (PHP5) sisältää pa
remman tuen olioille. Suurin puute vanhemmassa versiossa on muuttujien ja metodien nä
kyvyyden rajoittaminen. PHP4:ssä näkyvyys on sama eli kaikki ovat julkisia ja näin ollen olioiden muuttujia voidaan muokata myös suoraan [Zandstra 2004], Tämä on vastoin yhtä keskeistä olio-ohjelmoinnin periaatetta, mutta johtuen nykyisen palveluntarjoajan rajoit
teesta FINRI-järjestelmän parannukset tehdään yhteensopiviksi PHP4 kanssa.
Koska WWW-järjestelmien tiedetään olevan yleisesti turvattomia [Rubin & Geer 1998;
Joshi et ai. 2001], tulee tietoturvaan keskittyä jo suunnitteluvaiheessa. Myös juuri PHP- kielelle tarkoitettuja tietoturvaan liittyviä artikkeleja on runsaasti tarjolla [Dimov 2001;
Coggeshall 2003; Malcolm 2003] ja niissä mainitut yleiset virheet käydään läpi toteutus
vaiheessa. Tärkeimpiä asioita artikkeleiden perusteella on varmistaa, ettei käyttäjä pääse lukemaan lähdekoodia tai syöttämään sellaisia arvoja, jotka saavat järjestelmän toimimaan väärin, esim. tyhjentämään koko tietokannan.
Selvin ominaispiirre WWW-ohjelmoinnille on sen tilattomuus eli sivua avatessa ympäristö on aina alkutilassa. Jokainen sivu on periaatteessa ohjelma, joka palauttaa joitakin arvoja, jotka sitten annetaan seuraavalle ohjelmalle parametreinä. Tästä johtuen sivut joutuvat en
simmäisenä lukemaan koko järjestelmää koskevat asetukset, tämän jälkeen edellisen sivun palauttamat arvot ja näiden perusteella päättelemään, mitä edellisellä sivulla tehtiin sekä mitä seuraavaksi pitäisi tehdä.
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.
+shovLanguageList() +shovEventList() +shovClassList() +shovInformationList() -mseLanguage(id:int): boolean -language: int
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 +selectQuery(query:string): boolean 4-fetchNextRovO: array
+updateQuery(query:string): boolean +deleteQuery(query:string): boolean +disconnect()
-link: resource -results: resource
DatabaseAccess
+showAddInformationForm(): boolean +shovModifyInformationForm(): boolean +showDeleteInformationForm(): boolean +shovAddEventForm(): boolean +shovModifyEventForm(): boolean +shovDeleteEventForm(): boolean +shovAddFileForm(): boolean +shovModifyFileForm(): boolean +shovDeleteFileForffi(): boolean
AdminUI +create(attributes:array): int +select(id:int): boolean
+getAttribute(name:string): string
+setAttribute(name:string,value:string): boolean -♦-update (): boolean
♦delete(): boolean
♦qetArrayOfAll(filter:string): array -attributes: array
-attributeTypes: array -table: string
Databaseitem
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.
