Prosessdokumentasjon

HOVEDPROSJEKT 2010 - HØGSKOLEN I OSLO Prosessdokumentasjon Gruppe 18

ISMAIL SABANI ATLE IDSØ BJORÅ CHRISTIAN DOKKEN Side 2 av 29

1 Forord Denne rapporten forteller om hvordan arbeidet med prosjektet har foregått. Før man skal lese rapporten bør man lese igjennom brukermanualen, slik at man kan bli kjent med applikasjonen. Hvis man vil ha mer detaljert teknisk informasjon om applikasjonen mens man leser dette, kan man slå opp i produktdokumentasjonen, som går mer i detalj om hvordan produktet er bygget opp. Dette dokumentet vil forklare hvordan vi har gått frem nå vi har laget applikasjonen. Det beste er å begynne med kapittel 3, som går igjennom bakgrunnen for prosjektet, og forklarer noen begreper om oppdragsgivers arbeid med salmer. Det forklarer også hvordan det gamle programmet oppdragsgiver arbeidet med virket. Kapittel 4 går så igjennom hvordan det nye produktet fungerer. Det går raskt igjennom de forskjellige delene av programmet. Hvis man er interessert i å vite mer om programmet, anbefales det at man leser brukermanualen og/eller produktdokumentasjonen. Kapittel 5 går så igjennom planleggingsfasen og hvordan vi startet opp arbeidet. Kapittel 6 forklarer hvordan vi gikk fram når vi skulle overføre data fra det gamle programmet til det nye. Kapittel 7 forteller så om kravspesifikasjonen og den rollen den har hatt for produktet. Den forteller om kravspesifikasjonen og hvilken rolle den har hatt under utviklingen. Kapittel 8 forteller om resultatet og hvilken betydning det har hatt for oppdragsgiver å få det nye produktet. Kapittel 9 avslutter så rapporten med en konklusjon. Side 3 av 29

2 Innholdsfortegnelse 1 Forord... 3 2 Innholdsfortegnelse... 4 3 Innledning... 6 3.1 Bakgrunn for oppgaven... 6 3.1.1 Oppdragsgivers arbeid... 6 3.1.2 Et forsøk på å gjøre jobben lettere... 6 3.1.3 Oppdragsiverens egne ord... 6 3.2 Ønsker... 7 3.3 Det opprinnelige programmet... 8 4 Det ferdige produktet... 11 4.1 Organisten... 11 4.1.1 Programmets Inngangsparti... 11 4.1.2 Søking... 12 4.1.3 Salmer... 12 4.1.4 Notehefter... 14 4.1.5 Kirkeår... 14 5 Planlegging og metode... 16 5.1 Valg av verktøy... 16 5.2 Databasen... 16 5.2.1 ER-diagram... 17 5.3 Brukergrensesnittet... 18 5.3.1 Kommunikasjon med databasen... 18 5.3.2 Innhold... 18 5.3.3 Implementering av funksjonalitet... 18 5.4 Kommunikasjon med oppdragsgiver... 18 6 Om utviklingsprosessen... 19 6.1 Overføring av gamle salmer... 19 6.1.1 Det gamle salmeformatet... 19 6.1.2 Verktøy for overføring... 20 6.1.3 Scriptene... 22 Side 4 av 29

6.1.4 Omgjøring til SQL INSERTS... 24 6.2 Overføring av kirkeåret... 26 7 Kravspesifikasjon og dens rolle... 27 7.1 Hovedkrav... 27 7.2 Innfrielse av kravene... 27 7.3 Andre krav... 28 8 Resultatet... 29 8.1 Oppdragsiverens egne ord... 29 Side 5 av 29

3 Innledning Prosjektet Organisten er ment å erstatte et 15 år gammelt QBasic program laget av en bekjent av oppdragsgiveren. Det gamle programmet lagret alle data som tekstfiler, og viser dataene fram. 3.1 Bakgrunn for oppgaven Dette kapittelet vil fortelle om hvorfor oppdragsgiver trengte et nytt program og hvordan han tidligere arbeidet. 3.1.1 Oppdragsgivers arbeid Oppdragsgiveren vår er organist i Søgne menighet. Jobben hans er blant annet å spille salmer på gudstjenester og kirkelige handlinger. Salmer som blir spilt står i tre forskjellige typer bøker: Salmebøkene er de som blir brukt av menigheten, og inneholder teksten og en melodi til å synge etter. Det er hovedsakelig to salmebøker som blir brukt i Den Norske Kirke; Norsk salmebok og Salmer 1997. Melodibøkene inneholder noter med satser for organister som skal spille salmene. Det finnes hovedsakelig to melodibøker, en til hver salmebok; Norsk koralbok tilhører Norsk salmebok og Salmer 1997 for Orgel og Klaver hører til Salmer 1997. I tillegg finnes det et utall notehefter, som fungerer som tillegg til melodibøkene, med ekstra forspill, etterspill og andre variasjoner av notene i melodibøkene. Med alle disse detaljene krever er det mye arbeid i å holde oversikt over hva som står hvor og hva som passer bra å bruke til forskjellige anledninger. 3.1.2 Et forsøk på å gjøre jobben lettere Det gamle programmet vil bli sett på mer nøye i kapittel 3.3, men her kommer en kort oppsummering. Det var skrevet i QBasic for ca 15 år siden. Det var et databaseprogram opprinnelig ment for å oppføre fotballresultater. Dette ble klart for oss da vi leste igjennom koden. Programmet var en forbedring i forhold til hvordan oppdragsgiver hadde det tidligere, men det var likevel primitivt og vanskelig å bruke. Det hadde begrenset plass til oppføringene, så oppdragsgiver måtte omgå begrensningene på kreative måter. Det var for eksempel et par oppføringer han ikke hadde, som han allikevel trengte. Det var også ofte at han trengte flere linjer til oppføring av notehefter, siden salmer ofte var i ganske mange av dem. Begge disse problemene løste han ved å føre opp flere ting på samme linje. For eksempel ble antall vers en salme hadde oppført på samme linje som salmenummeret, og han skrev flere notehefter på samme linje slik at han hadde plass til alt han skrev. Dessverre førte disse løsningene til at alle dataene ble unødvendig komplisert og uoversiktelig. I tillegg til dette trengte han å kunne bruke programmet flere steder samtidig. Programmet var laget for å ha bare et sted. Dette førte til at oppdragsgiver måtte kopiere programmet med seg hver gang han skulle et annet sted der han skulle bruke programmet. Disse tingene sammen gjorde at oppdragsgiver hadde bruk for en mer moderne versjon av programmet, som ville gjøre arbeidet hans lettere. 3.2 er en kort oppsummering om oppdragsgivers ønsker. Kapittel 6 forteller mer inngående om oppdragsgiverens krav. 3.1.3 Oppdragsiverens egne ord I 1992 begynte jeg i fast stilling som organist. Og da begynte jeg også å anskaffe meg en del notehefter med stoff som passet til forskjellige salmer. Notesamlinga mi har hatt en jevn økning siden 1992 og fram til nå. Det gikk ikke lang tid før jeg fant ut at det ble veldig tungvint å lete i alle noteheftene for hver salme som skulle spilles. Så jeg begynte med å notere salmenumrene i Side 6 av 29

rekkefølge i 3 linjerte skrivebøker med to linjer til disposisjon til hvert nummer. Da kunne jeg registrere noter som passet til de forskjellige salmene. Dette fungerte greit en liten stund. men så viste det seg jo snart at 2 linjer ikke var nok på mange av salmene. Så ble neste skritt at en bekjent av meg laget et databaseprogram der jeg kunne legge inn informasjon til de forskjellige salmene. Dette var et stort fremskritt for meg. Etter hvert som jeg anskaffet nye noter, ble de registrert på sidene til de salmene som var representert i notehefte. Totalt har jeg brukt et veldig stort antall timer på dette. Men det er jo gjort over ca. 15 år. Etter hvert har også databaseprogrammet blitt for lite for mange av salmenumrene. Jeg har løst dette med å bruke forkortelser og legge flere noter inn på samme linje. Det er også åpenbart seg en del svakheter. Likevel har programmet absolutt gjort nytte for seg. Og jeg hadde forstått det slik at ved å bytte til nytt program, måtte all informasjonen legges inn på nytt. Dette ville være så enormt tidkrevende at jeg utelukket det. 3.2 Ønsker Oppdragsgiverens hovedønske var at han kunne forstette med de samme dataene han hadde jobbet med i 15 år. Dette var viktig siden det var ganske mye data og han brukte den hver dag. Programmet skulle også beholde den viktigste funksjonaliteten til det gamle programmet slik at oppdragsgiver ikke skulle få så stor omstilling når han skifter til det nye programmet. Side 7 av 29

3.3 Det opprinnelige programmet Tidligere hadde oppdragsgiver jobbet med et meget gammelt program. Det følgende kapittel vi gi en innføring i det gamle programmet slik at det skal bli lettere å forstå prosessen som følger. Programmet var skrevet i QBasic. En av tingene vi prøvde på var å se igjennom koden for å se om vi kunne skjønne hvordan det virket, og mens QBasic ikke er veldig komplisert, var koden skrevet på en slik måte at det var vanskelig å følge den, såkalt spaghetti-kode. 1 2 250 REM HOVEDMENY 251 KEY OFF: A = 2: C = 7: GOSUB 13250: GOSUB 14250 3 IF K$ = CHR$(27) THEN 260 4 5 ON K GOTO 600, 300, 900, 250, 250, 250, 250, 260 GOTO 251 6 260 CLOSE : ERASE A$: GOTO 1 7 300 REM * REGISTRERING AV DATA * 8 GOSUB 2: KEY ON 9 PRINT "LEGG INN NYE DATA, TRYKK 'F1' VED SP RSM L 1, FOR TILBAKE TIL MENY" 10 F = VAL(A$(0, 0)): F%(2) = VAL(A$(0, 1)) 11 310 A = 1: A$(F, 1) = "" 12 320 PRINT A$(A, 0); : INPUT A$(A, 1) 13 IF A$(1, 1) = "MENY" THEN 330 14 IF A$(1, 1) = "" THEN MS$ = "M ALLTID FYLLES UT": GOSUB 8000: PRINT CHR$(30); : GOTO 320 15 IF A$(A, 1) = "MENY" THEN MS$ = "F1 VIRKER BARE VED 1.SP RSM.": GOSUB 8000: PRINT CHR$(30); : GOTO 320 16 IF A$(A, 1) = "SIDE" AND A = F - 1 THEN F% = F%(2): GOSUB 20610: GOSUB 2: GOTO 325 17 IF A <> F - 1 THEN A = A + 1: GOTO 320 18 325 F%(2) = F%(2) + 1: GOSUB 350: GOTO 310 19 330 A$(0, 1) = STR$(F%(2)): GOSUB 3000 20 340 GOTO 250 21 350 OPEN I$ FOR APPEND AS 1 22 FOR A = 1 TO F 23 WRITE #1, A$(A, 1) 24 NEXT A 25 CLOSE 1 26 RETURN Figuren ovenfor viser et utsnitt av koden. Tallene i starten av noen linjer merker et avsnitt i koden, som skal gjøre det lett å hoppe mellom avsnitt. GOTO kommandoen brukes for å hoppe mellom avsnitt. Variablene er dessverre bare enkeltbokstaver, sannsynligvis for å spare plass, tross alt var ikke maskinene veldig kraftige på den tiden. Etter å ha lest koden en stund fant vi også ut at dette programmet var konvertert fra et annet program som den opprinnelige forfatteren sannsynligvis hadde brukt for å lagre fotballresultater. En masse henvisninger til Mål, Lag osv. gjorde det enda vanskeligere til å forstå hva som var hva. Etter å ha prøvd å forstå koden en stund, fant vi ut at det var ufruktbart, så vi valgte heller å bare hente inn dataene og lage noe helt nytt. Side 8 av 29

La oss likevel ta en titt på hvordan det gamle programmet så ut. Dette er et eksempel på en oppføring av en salme. Hver rad representerer mye data. Til venstre står det hva slags data det er snakk om og til høyre står selve dataene. Dessverre var det ikke plass nok for oppdragsgiveren å lagre all data han trengte, så han var nødt til å lagre flere felter på samme rad. I dette eksempelet for eksempel inneholder første linje, som egentlig bare skal inneholde salmenummeret, også hvor mange vers salmen har. De ti linjene FS1-FS10 inneholder notene denne salmen står i. Det er disse som er den data det var viktigst for oppdragsgiver å lagre. Dessverre hadde han bare ti linjer til rådighet, selv om en salme kan stå i langt over ti notehefter. Derfor måtte oppdragsgiver improvisere. Han begynte å skrive flere oppføringer på samme linje. Første FS linje for eksempel, inneholder fire oppføringer. Disse oppføringene består av en forkortelse av enten navnet på heftet eller forfatteren. Hvor mangle linjer det står over i dette heftet. Det kan stå hvilken side den finnes på, hvilken karakter og vanskelighetsgrad oppdragsgiver har gitt den og eventuelle andre kommentarer. Og bare den første linjen inneholder fire slike oppføringer. Så det er godt mulig å si at det var på tide med en oppgradering. Side 9 av 29

I tillegg til dettebrukte han samme sett til å lagre en helt annen type data, nemmelig data om hvilke salmer han kunne bruke på forskjellige kirkelige handlinger. Dette skjermbildet viser hvilke salmer som passer til Juledag for eksempel. Den inneholder informasjon om hvilke bibeltekster som skal brukes under prekenen og at antall salmer som passer bra. Hver linje med salmeoppføringer forteller i tillegg når på gudstjenesten salmen kan spilles. Side 10 av 29

4 Det ferdige produktet Dette kapittelet beskriver det ferdige produktet og vil gi en forståelse av hvordan applikasjonen fungerer. For at leseren skal ha utbytte av å lese om prosessen som ledet frem til det endelige produktet (kapittel 5 og 6), er det viktig å vite hva som er utviklet. Vi går ikke inn på alle detaljer i dette kapittelet, så hvis man vil sette seg grundigere inn i hvordan applikasjonen fungerer fra brukerens og utviklerens ståsted, så anbefaler vi å lese brukermanualen og/eller produktdokumentasjonen. 4.1 Organisten Programmet er en database som kan brukes av organister og andre som jobber med kirkemusikk. Det viktigste innholdet i databasen er salmer, notehefter og koblinger mellom disse. Når brukeren går inn på en salme kan han se hvilke notehefter som inneholder noter til denne salmen og lese informasjon om disse notene. Dette gjør det enklere å finne fram i det havet av noter som de fleste organister har på kontoret sitt. Det finnes også en oversikt over dager i kirkeåret og forslag til hvilke salmer som kan passe til disse dagene. 4.1.1 Programmets Inngangsparti Når du åpner programmet møter du dette skjermbildet: Du blir her bedt om å logge inn for å få tilgang til applikasjonen. Dette må du gjøre for å få tilgang til noe som helst informasjon. For å logge inn må du ha en bruker, det finnes ingen gjeste-brukere. Når du så har logget inn med ditt personlige brukernavn og passord vil du se denne skjermen: Side 11 av 29

Herfra har du tilgang til alle dataene i resten av programmet. På venstre side er menyen, det er her du kan nå spesifikk data du leter etter. 4.1.2 Søking Søking blir gjort ved at man skriver inn begrepet man vil søke på og trykker søk knappen. I dette eksempelet har vi brukt søkebegrepet ter å søke med, simpelthen fordi det gir oss resultat på alle kategoriene. Som man kan se så deles søket opp i de forskjellige kategoriene, og gir et tall som forteller hvor mange treff det er på hver kategori. Dette gjør det enkelt å finne frem til det du skal, uten å måtte lure på hvilken kategori det faller inn under 4.1.3 Salmer Når du går trykker på menyvalget Salmer, så får du opp en liste med alle salmer som er lagret. La oss se på hvordan en salme ser ut når man går inn på den. Side 12 av 29

Her kan man se detaljert informasjon om salmen. Den første fanen forteller spesifikk informasjon om salmen. De to blå firkantene forteller om hvilke melodibøker denne salmen står i. Vi ser også på fanen som viser hvilke notehefter salmen står i. Den ser slik ut: Hver blå ramme representerer et notehefte og inneholder data om salmen spesifikk til hvert enkelt notehefte. Dette gjør det lett å finne frem til akkurat den versjonen du vil ha. Navnene på noteheftene er i tillegg linker til det noteheftet det gjelder. På høyre side kan du også redigere eller slette en oppføring. Side 13 av 29

4.1.4 Notehefter Hvis man trykker på Notehefter på menyen får man opp en liste over notehefter. Går man inn på et spesifikt notehefte får man se mer detaljert blikk på informasjonen om notehefte, man får se noe som kan likne på dette skjermbildet: Her kan man se navnet på notehefte, i tillegg til informasjon om antall sider, hvilket forlag den er utgitt på og utgivelsesår. På venstre side er det knapper for å redigere eller slette dette notehefte, og nederst kan man legge til bildet av forsiden til noteheftet. 4.1.5 Kirkeår Den neste informasjonen du kan komme til er informasjon om kirkeåret. Dette er informasjon om dagene i kirkeåret, helligdager som feires og som organisten skal spille til. Her får du en liste over alle de viktigste dagene i kirkeåret. Du kan også trykke på dem for å få mer informasjon om hver enkelt dag. Her har vi valgt Påskedag. Det er tre faner på hver dag. Kirkeår, Tekstrekke 1 og Tekstrekke 2. Her er det nok en fordel å forklare om tekstrekkene. Samme dag, ta for eksempel påskedagen over, har forskjellige tekstrekker annethvert år. Her kan man se at den har noen bibeltekster som hører til tekstrekke 1. Neste år vil man bruke bibeltekstene fra tekstrekke 2. Side 14 av 29

Tekstrekke 1 og Tekstrekke 2 kan derfor ha forskjellige salmer også. Dette kan være salmer som omhandler de samme temaer som vi finner i bibeltekstene. Det er det de to neste fanene beskriver. Disse fanene beskriver altså hvilke salmer som passer til en helligdag. Forskjellige salmer kan passe til forskjellige tider i gudstjenesten, og dette blir vist med overskrifter i fet type. Side 15 av 29

5 Planlegging og metode Utgangspunktet for planleggingen var de allerede eksisterende dataene som til fordel lå på en tekstfil. Dataene skulle bevares på best mulig måte og ga oss et utgangspunkt for å begynne planleggingen vår. Vi begynte derfor planleggingen ved å gå nøye igjennom dataene. Dette gjorde oss i stand til å lage en database som inneholdt alle de felter vi trengte for å beholde dataenes integritet. 5.1 Valg av verktøy Da vi valgte hvilke verktøy som skulle brukes på applikasjonen var det to ting som var viktige for oss. For det første skulle vi levere et best mulig resultat, for det andre skulle det være så billig som mulig. Vi visste vi ikke om programmet bare skulle brukes av oppdragsgiver eller om det skulle ha flere brukere og vi ville ikke påføre oppdragsgiveren flere kostnader enn absolutt nødvendig. Derfor har vi valgt å bruke PHP og MySQL som er gratis og likevel gir mange muligheter til å lage den beste mulige applikasjonen for våres oppdragsgiver. Vi valgte å legge programmet ut på en virtuell maskin som Atle hadde tilgang til. Der hadde vi full kontroll på hvilke programmer vi ville installere, mappestruktur og lignende. 5.2 Databasen Planleggingen av databasen begynte ved at vi så på hvilke felter vi trengte for at alle dataene vi overførte fra det gamle programmet skulle bli inkludert i databasen. I det gamle programmet var alle dataene lagret som salmer. Derimot var det ingen relasjoner i den gamle databasen, slik at mye var dobbeltlagret. Det var lett å dele opp dataene i flere tabeller. Det ble en tabell om salmer, og en om notehefter, det ble også tabeller om dager i kirkeåret og mange flere tabeller. Det viste seg at det var data om ganske mye i det gamle programmet. I tillegg til alle dataene skulle vi også ha en del metadata slik at vi kunne ha implementert historikk i databasen. Dette gjorde vi fordi det skulle være mulig å rette opp sine egne feil, og hvis det eventuelt var andre brukere, rette opp andres feil. Dette førte til at det var nødvendig å ha ekstra tabeller som gjorde dette mulig. Dataene om salmer for eksempel består av tabellen salme som bare består av identifikasjon av salmen. Så er det salmedata, hvor de faktiske dataene om salmen er lagret. Der blir det lagret hvordan salmen ser ut nå, og alle tidligere versjoner av den, slik at det er mulig å gjenopprette en gammel salme. Så finnes det også en salmehistorie tabell, som inneholder data om redigeringer av salmen, her blir det lagret redigeringsdato, brukeren som gjorde redigeringen og noen identifikatorer som gjør det mulig å finne tilbake til tidligere versjoner av salmen. Alle dataene det gir mening at flere brukere kan redigere er bygd opp på denne måten. Data som dager i kirkeåret er ikke dette implementert på fordi det der ikke gir noen mening at andre brukere enn administrator skal kunne redigere helligdager. Databasen er grundig forklart i Produktdokumentasjonen kapittel 7. Side 16 av 29

5.2.1 ER-diagram Under følger et bilde av ER-diagrammet for applikasjonen. Side 17 av 29

5.3 Brukergrensesnittet Vi begynte designet av brukergrensesnittet med å tegne noen prøvedesigner for hånd. Vi ville ha en oversiktelig design, så vi laget designen med en meny på venstre side, med et søkefelt og noen linker. Øverst i høyre hjørne ville vi ha en innloggingsform man skulle bruke for å få tilgang til programmet. Når vi begynte å lage layouten fikk vi problemer med å få brukergrensesnittet til å se likt ut på forskjellige nettlesere. Spesielt Internet Explorer skulle vise seg å være meget vanskelig, men også Opera behandlet brukergrensesnittet rart. Vi måtte gjøre en del css koding for å få grensesnittet til å bli likt. I et tilfelle måtte vi også bruke et javascript for å holde brukergrensesnittet slik vi ville det skulle se ut på de viktigste plattformene. Vi bestemte oss for å bruke en løsning med faner for å holde oversiktelig og gjøre programmet lett å navigere. Alle sidene er delt opp med faner, med forskjellig innhold avhengig av hvilken side man er på. Når vi hadde designen på brukergrensesnittet noenlunde klar begynte vi å kode applikasjonen grundigere. 5.3.1 Kommunikasjon med databasen Kodingen av programmet begynte med at vi skrev php funksjoner som skulle hente ut data fra databasen, og lage class filer med objekter som skulle fylles med data fra databasen. Vi lagde alle funksjoner vi tenkte vi kom til å trenge for å hente ut og endre data i de forskjellige tabellene. Alle funksjonene ble testet i etterkant. 5.3.2 Innhold Når vi var ferdige med å lage funksjonene for å kommunisere med databasen brukte vi disse for å hente ut innhold til de forskjellige sidene. Det gjorde jobben vår lettere å kun forholde seg til metoder og objekter i de filene som skulle presentere innholdet til brukeren. 5.3.3 Implementering av funksjonalitet Etter at vi hadde laget brukergrensesnittet og fått presentert innhold fra databasen til brukeren begynte vi å implementere funksjonalitet vi mente applikasjonen burde ha. Dette var ting som redigering av data og innlogging. 5.4 Kommunikasjon med oppdragsgiver Vi hadde kontinuerlig kontakt med oppdragsgiveren vår via telefon og e-post. I begynnelsen gikk dette mest på å få forklaringer på hvordan de forskjellige tingene i det gamle programmet virket. Under utviklingsprosessen rådførte vi oss mange ganger med oppdragsgiver når vi var i tvil om hvordan noe skulle gjøres for å høre hva som var de faktiske ønskene og behov. Oppdragsgiver fikk også teste programmet etter hvert når vi hadde noe å vise og kom med tilbakemeldinger på hva som var bra og hva som kunne gjøres annerledes. Side 18 av 29

6 Om utviklingsprosessen Dette kapittelet beskriver hvordan vi gikk frem når vi startet prosjektet. Denne delen inneholder teknisk informasjon om hvordan vi hentet ut data fra det gamle programmet og konverterte den til SQL script. 6.1 Overføring av gamle salmer Det første arbeidet vi gjorde var å overføre salmene fra det gamle formatet (se nedenfor) til et format som sorterte dataene, som vi kunne bruke for å overføre den til SQL INSERT script. 6.1.1 Det gamle salmeformatet Størstedelen av det gamle programmet besto av allerede lagret data. Disse var lagret i en fil med endelsen.dat, men var egentlig bare ren tekst. Hver salme var på 18 linjer, se figuren nedenfor. Salmene var alle på samme format, hver linje var omgitt av hermetegn. De 18 linjene var alt oppdragsgiver hadde per salme, men det ble nødvendig for ham å legge til mer data om salmene enn det var plass til. På de fleste linjene er forskjellige data skilt med dobbelt mellomrom mellom dem, dessverre var det et par andre steder som også hadde to mellomrom, som trengte spesiell behandling. 1 "S128 4V" 2 "SE VI GÅR OPP TIL JERUSALEM" 3 4 "128 KP 3/4" "F MOLL" 5 "" 6 7 "" "" 8 "SWH 3L 3/ S TRIO RJs7 1S 4/3 OFL 3L 3/3 S OFL 2L 3/3 L" 9 "MO2/39 1S 3/3 MO2/40 1S 2/3 FEST5/3 4S 3/4" 10 "KFRa 4L 3/ S KFRb 1S 3/3 TH 2L 2/3 G" 11 "HG90a 1S 3/3 TRIO HG90b 3L 3/3 L JLLEDSIII" 12 "AFR44 2S 3/3 OS41 2L 2/3 RCs10 2S 4/3 S" 13 "KMKs110 2S 3/4 S OS50s45 2L 2/3" 14 "TTSs11 2L 3/3 L OS50s42 2S 4/3" 15 "LNI 1S 3/ S OS50s44 1S 4/4 P" 16 "PI 2S 4/ S PII 3L 2/3 PIII 1S 2/3 PV 2S 3/4 S" 17 "OTE1 2S 2/3 PIV 1S 4/3" 18 "7" Linje 1 består av to ting, det første tallet er salmenummeret, i figuren over er salme nummer 128, S en foran forteller at denne salmen står i Norsk salmebok. Alternativet hadde vært en T foran i stedet. Da hadde den stått i boka Salmer 1997. Den andre informasjonen på linje 1 er antall vers den består av. Denne salmen har 4 vers. Den neste linjen, linje 2, er navnet på salmen. Det gikk ikke an å skrive komma i den gamle databasen. Derfor betyr to mellomrom etter hverandre i salmetittelen at det skal være et komma. Side 19 av 29

Linje 3 er hvilke bøker hovedmelodien står i. I dette tilfellet står den i to bøker. Det første tallet er melodinummeret i en bok som heter Norsk koralbok, som er den største av melodibøkene. I dette tilfellet er salmenummeret det samme som melodinummeret, men dette er ikke alltid tilfellet. Så står det KP 3/4. Dette betyr at melodien også står i boken Koralpermen. 3/4 er noe oppdragsgiver Håkon Bjorå skriver selv, og er en nummerering han har gitt noten, 3 betyr vanskelighetsgraden han har gitt noten fra Koralpermen, fra 1 til 5, mens 4 er karakteren han har gitt den. Denne noten er midt på treet vanskelig, og litt bedre enn middels. Den neste linjen er hvilken toneart salmens melodi går i. Denne salmen går i F Moll. Den neste linjen, som er tom i denne salmen, ville sagt om salmen hadde en alternativ toneart. For eksempel kunne det stått KP A ; det ville da betydd at den også sto i Koralpermen med tonearten A. Den neste linjen er også tom, men her ville det stått et nummer hvis salmen hadde hatt en alternativ melodi som kunne spilles til den i tillegg. Den siste av de tomme linjene på denne salmen, blir kalt anvendelse. Linjen blir sjeldent brukt, men hvis den blir det ville det vært en slags kommentar til salmen om hvilke omstendigheter den kan bli brukt i, for eksempel begravelse eller bryllup. De neste ti linjene består av andre notehefter melodien står i. Dette er da samme melodi, men med variasjoner, som for eksempel solostemmer, pedalsoloer eller forspill og etterspill til salmen. Et typisk eksempel er OS50s45 2L 2/3 på linje 13. Dette betyr at det står i noteheftet 50 Orgelkoraler og koralforspill av Oddbjørn Sæbø, på side 45. 2L betyr at det er to linjer, det vil si at det er ikke langt, sannsynligvis et forspill, og har vanskelighetsgrad 2 og karakter 3. I stedet for 2L kunne det stått 2S, dette ville betydd 2 sider. I tillegg kunne det også stått andre stikkord, som for eksempel post, pre eller prost, som står for henholdsvis postludium, preludium eller begge deler. Hvis det er to eller flere notehefter på samme linje, så er disse avskilt med to mellomrom. På den siste linjen står det her 7. Dette er noe spesielt som hører til programmet. Hvis denne siste linjen er utfylt, betyr det at salmen også har ekstra data som står i en egen fil. Det er ikke mange salmer som har det men det er noen. Hvordan programmet finner ut hvor disse ekstra dataene ligger var såpass vanskelig å finne ut av at vi valgte å ikke bruke tid på det. De få salmene som har en ekstra side kan fikses manuelt i ettertid. 6.1.2 Verktøy for overføring For å overføre dataene fra det gamle formatet til et format vi kunne bruke, skrev vi script i perl. Disse scriptene inneholder mye bruk av regulære uttrykk for å trekke ut riktig informasjon og putte det tilbake igjen i en annen form. De gamle dataene er på formatet som er vist ovenfor. Fra dette forandret vi det til et mellomformat fordelt på mange tekstfiler. Salme ovenfor vil for eksempel se slik ut: I salmer.txt vil denne linjen stå 224:128:1:4:Se, vi går opp til Jerusalem:20:NULL Det første tallet, 224, er id-nummeret salmen får, det er viktig for databasen, men brukes kun der. Det andre nummeret er salmenummeret, 128. Så kommer et tall som sier hvilken salmebok den står i Side 20 av 29

hvis det står 1 er den i Norsk Salmebok, og hvis det står 2 er den i Salmer 1997. Tallet som følger er antall vers salmen har, denne har 4 vers. Det neste er navnet på salmen, å midt i det tredje order er html for bokstaven Å. Det følgende tallet, 20, er id til tonearten salmen går i. 20 er en id som peker til F MOLL i toneart tabellen. Det siste som står er det som ville stått på anvendelse hvis det hadde vært aktuelt, men i dette tilfellet er det ingenting, derfor står det bare NULL. Men dette er ikke all informasjon om salmen, her mangler hvilke notehefter salmen står i. Dette blir lagt i en annen fil: notesalme.txt, som lager linker mellom salmer og notehefter. Denne filen er på over 7500 linjer, og salme nummer 128 tar 29. Men la oss ta for oss en linje og se hvordan den er oppbygd: 3047:224:19:10:NULL:2:NULL:4:3:1:0:0:NULL:NULL:NULL:0:NULL:RCs10 2S 4/3 S Ganske kryptisk. Heldigvis er det ikke meningen at dette skal leses og tolkes av mennesker, det er allikevel et viktig steg for å overføre det til databasen. Denne linjen starter med id til denne forbindelsen fra salme til notehefte. Det er i dette tilfellet 3047. Det andre tallet er enkelt og greit id på salmen, og det neste tallet, 19 er id til notheftet. Det neste tallet er hvilken side det står på i dette noteheftet. I noen notehefter er det nummer i stedet for sider, dersom dette hadde vært tilfellet ville det stått noe i det neste, i stedet står det her NULL. Det neste tallet er hvor mange sider salmen går over i dette noteheftet, i dette tilfellet 2 sider. Ikke alle salmer er på over en side, noen er på under en side, på bare et par linjer. Da ville det stått hvor mange linjer i det neste. Så kommer karakter og vanskelighetsgrad, her henholdsvis 4 og 3. De tre neste tallene er flagg, dvs. enten 0 eller 1 som sier om salmen har henholdsvis Solostemme, Ledsagersats og Pedalsolo. Denne salmen har 1 i det første av de tre, det betyr at denne har solostemme. Hvis salmen hadde hatt en annen toneart i dette noteheftet ville det stått id til en toneart som det neste tallet. De to neste innleggene ville sagt om salmen hadde postludium og preludium. Disse blir ikke brukt i den ferdige applikasjonen siden oppdragsgiver mente det ikke var nødvendig. Det neste tallet, her 0, er et datafelt vi har kalt plassering. Det kan være 0, 1 eller 2 og forteller oss om denne raden er et notehefte, melodi eller alternativ melodi. Etter dette kommer et felt hvor det ville stått noe hvis det var noe ekstra som ikke passer inn i de andre feltene. Det siste er det gamle feltet, hvordan raden så ut i den gamle databasen Side 21 av 29

6.1.3 Scriptene Vi brukte perl script med regulære uttrykk for å hente ut de gamle dataene og splitte den opp i de filene vi trengte. Scriptet går igjennom tekstfilen med salmer linje for linje, og bruker mod % 18 for å sjekke hvilken linje den er på. Som et eksempel kan vi se på koden som brukes på den første linjen 1 2 if ($mod == 0) { 3 @slm; 4 5 $line =~ /^\"([ST]?)(\d{1,4}[ab]?)(\s*)/; # henter ut hvilken bok det er og salmenummer 6 7 8 9 $slm[1] = $2; 10 if($1 eq "T") 11 { 12 $slm[2] = 2; 13 } 14 15 else { 16 $slm[2] = 1; 17 18 } 19 chomp($line); 20 21 $slm[1] =~ s/^0+//g; 22 23 24 $line =~ /(\d{1,2})([l V])/; # henter ut antall vers/linjer 25 $slm[3]="null"; 26 27 if ($1) { 28 if($2 eq "L") 29 30 { $slm[3] = 1; 31 } 32 33 elsif($2 eq "V") { 34 $slm[3] = $1; 35 36 } } 37 } Denne koden tar kun for seg den første linjen i en salme. I eksempelet ovenfor er det linjen S128 4V Det er mye informasjon i denne linjen, den sier hvilken bok den står i, salmenummeret og hvor lang den er. Denne salmen er nr 128, står i Norsk Salmebok (som gitt av S helt først) og er på fire linjer. Den første linjen i scriptet er if($mod = 0). Dette er enkelt og greit en sjekk om mod % 18 er lik null. Hvis den er er den på første linje og den kan gjøre det den skal. @slm oppretter en array for å putte informasjonen i. Linje 5 er $line =~ /^\"([ST]?)(\d{1,4}[ab]?)(\s*)/; Side 22 av 29

Dette er den linjen som faktisk henter ut informasjonen. Dette er det regulære uttrykket som henter ut det vi vil ha på den måten vi vil. /^\"([ST]?)(\d{1,4}[ab]?)(\s*)/; La oss ta denne linjen litt nøyere for oss. /^\" Den første slashen (/) starter det regulære uttrykket. ^ forteller at vi skal begynne helt fra starten av linjen. sier at her kommer det hermetegn. Så kommer første parantes. Det som står inne i denne parantesen blir lagret i variabelen $1. [ST] sier her finner vi en S eller en T, mens spørsmålstegnet sier at det er enten 0 eller 1 av dem. Dette betyr at variabelen $1 nå inneholder data om hvilken bok den står i. Den andre parantesen blir lagret i $2, og tar for seg salmenummeret. \d betyr at det følger en rekke med tall, og {1,4} betyr at det er fra en til fire siffer. [ab]? betyr som ovenfor at det så følger enten en a, en b eller ingenting. Grunnen til at vi har med dette er at noen av salmenumrene hadde a eller b på slutten. Den siste parentesen inneholder \s*, som betyr at det kan komme blanke tegn, det vil si mellomrom. 8 $slm[1] = $2; 9 10 if($1 eq "T") 11 { 12 $slm[2] = 2; 13 } 14 else 15 { 16 $slm[2] = 1; 17 } I linje 8 ser vi at $2 settes inn i $slm[1]. Dette er salmenummeret. Koden setter så salmenummeret inn i arrayet slm sin andre posisjon ( den første posisjonen $slm[0] inneholder iden til salmen. Så sjekker den om det står en T foran salmenummeret. Hvis det gjør det setter den slm sin tredje posisjon til 2, ellers blir den satt til 1. Den neste linjen er chomp($line), denne funksjonen fjerner linjeskift på slutten av linjen. Så kommer en linje hvor det står $slm[1] =~ s/^0+//g;. Denne linjen er en regex som bytter ut ut nuller i starten av salmenummer med ingenting; altså, den fjerner 0 er hvis de står først i et salmenummer, slik at 002 blir lagret som 2. $line =~ /(\d{1,2})([l V])/; Linjen over henter ut antall vers. Først ser den etter ett eller to siffer, så om det står L (linjer) eller V (vers) etter det. I et tilfelle står det L, ellers så står det alltid V. Den ene gangen det var antall linjer valgte vi å lagre dette som et vers. Side 23 av 29

Så utføres følgende kode: 25 $slm[3]="null"; 26 27 if ($1) { 28 if($2 eq "L") 29 30 { $slm[3] = 1; 31 } 32 33 elsif($2 eq "V") { 34 $slm[3] = $1; 35 } } Først settes slm sin fjerde posisjon til NULL, dette gjøres i tilfelle det ikke står om det er noen vers eller linjer. Så blir det sjekket om $1 inneholder noe, og hvis den gjør det, så blir det satt inn noe i $slm den fjerde posisjonen avhengig av om det står V eller L. Dette er kun det som skjer på første linje av salmen. Scriptet går gjennom alle de 18 linjene og gjør forskjellige operasjoner på de forskjellige linjene. Når scriptet er ferdig med de 18 linjene, så er det ferdig med en salme og det begynner på nytt. 6.1.4 Omgjøring til SQL INSERTS Da alle script som gjorde data om til kolonseparerte lister var ferdig kjørte vi et script som gjorde disse listene om til SQL INSERTS slik at dataene kunne importeres i databasen. Vi ser på et lite kodeeksempel. Koden for å lagre SQL INSERTS for bibelvers er ganske enkel. Her er det en fil inn og en fil ut. Hvis vi hadde sett på koden for salmer, så hadde vi hatt en fil inn og 6 filer ut. Det koden vi skal se på skal gjøre dette: 1:1:Jes 62,10-12:1 1:1:Rom 13,11-14:1 1:1:Matt 21,1-9:1 1:2:Jes 12,2-6:1 1:2:Jes 61,1-4:1 Om til dette: INSERT INTO bibeltekst (kirkedag_id, tekstrekke, linje, navn) VALUES (1, 1, 1, "Jes 62,10-12"), (1, 1, 1, "Rom 13,11-14"), (1, 1, 1, "Matt 21,1-9"), (1, 1, 2, "Jes 12,2-6"), (1, 1, 2, "Jes 61,1-4"); Det er selvfølgelig mer enn 5 bibelvers som er lagret, men vi tar bare et utsnitt for dette eksempelet skyld. Side 24 av 29

1 open (INN,"out/bibelversny.txt"); 2 open (UT,">sql/bibelvers.txt"); 3 4 $komma = ""; 5 6 print UT "INSERT INTO bibeltekst (kirkedag_id, tekstrekke, linje, navn) VALUES \n"; 7 8 while($line = <INN>) 9 { 10 chomp($line); 11 12 @array = split /:/, $line; 13 14 $ut = $komma. "(". $array[0]. ", ". $array[3]. ", ". $array[1]. ", \"". $array[2]. "\")"; 15 16 print UT $ut; 17 18 $komma = ",\n"; 19 } 20 21 print UT ";\n\n"; 22 23 close(inn); 24 close(ut); I den første linjen åpner vi dokumentet med den kommaseparerte listen. I linjen etter oppretter vi filen vi skal skrive til. Variabelen $komma brukes for å legge et komma og et linjeskift der hvor det kommer en ny rad under. I linje 6 skriver vi ut den linjen som skal stå øverst og bestemmer hvilken tabell vi skriver til og hvilke kolonner de forskjellige verdiene skal legges i. Så kommer en while-løkke som skal skrive ut verdiene som kommer i parentes i linjene under. I dette eksempelet er det fem linjer. Kommandoen chomp($line) fjerner linjeskiftet på slutten av linjen. Kommandoen på linje 12 deler opp de kommaseparerte verdiene inn i en array slik at vi kan bruke en verdi omgangen. Så lages linjen som skal skrives ut i linje 14. Noen verdier er integer mens noen ande er string. En string-verdi må settes inn i hermetegn. I linje 16 skrives linjen til UT-filen. Og $komma får en ny verdi på linje 18. I linje 21 blir SQL INSERT setningen avsluttet med et semikolon. Og filene vi jobber med blir lukket i linje 23 og 24. Etter at scriptene som lager SQL INSERTS er kjørt legger et bash-script alle disse linjene inn i en fil som heter daba.sql. Denne er på nesten 60.000 linjer og kan importeres i den ferdige MySQLdatabasen. Side 25 av 29

6.2 Overføring av kirkeåret Som du kan lese i kapittel 3 er det også lagret informasjon om kirkeåret i databasen. Det ble laget lignende perl-script for å omgjøre disse til kolonseparerte lister og så til SQL INSERTS. Siden disse er veldig like scriptene som blir brukt på salmer gir vi ikke noe eksempel på dette i denne rapporten. Side 26 av 29

7 Kravspesifikasjon og dens rolle Oppdragsgiver har hatt noen krav til programmet, og gruppen har også satt noen egne krav slik at programmet skal holde en standard som gjør oppdragsgiver fornøyd. Kravspesifikasjonen finnes som vedlegg 2. 7.1 Hovedkrav Oppdragsgiver hadde noen få minimumskrav til applikasjonen. Det første var at det nye programmet beholdt den funksjonaliteten det gamle programmet hadde. Det andre var at han enkelt skulle kunne nå programmet både hjemmefra og fra arbeidsplassen, og det tredje var at han beholdt all de originale dataene han hadde fra det gamle programmet. Etter disse viktigste kravene kom kravet om at programmet skulle være lett å bruke. Dette var ikke det viktigste kravet, men det var allikevel et krav som hadde en høy prioritet. 7.2 Innfrielse av kravene For å oppfylle kravet om at oppdragsgiver skulle kunne bruke programmet både hjemmefra og fra arbeidsplassen, tok vi valget å lage en webapplikasjon. Dette gjorde at det var mulig å nå programmet, ikke bare fra hjemmet og arbeidsplassen, men også fra andre eventuelle steder han måtte være. Overføringen av de gamle dataene er nøye forklart ovenfor i kapittel 5. En kort oppsummering: å overføre de gamle dataene til en database var det første arbeidet vi utførte på siden. Dette ble gjort med perl scripting. Vi designet databasen og brukte perl scripting til å hente ut de gamle dataene til det formatet vi ville ha og til å overføre det til SQL script. Det tredje kravet, opprettholdelse av gammel funksjonalitet, var ikke så vanskelig å utføre fordi det gamle programmet ikke var spesielt avansert og hadde derfor ikke mye avansert funksjonalitet. Det gamle programmet kunne søke på salmer, det kunne legge til nye salmer og det kunne redigere allerede eksisterende salmer. Alt dette er implementert i programmet i forbedret versjon. Søk i det gamle programmet ga deg bare mulighet til å se treffene en etter en, og hvis det da var mange treff måtte du gå igjennom alle for å finne den du var ute etter. Søket i den nye versjonen gir deg lister over treff, og gjør det derfor lettere å finne frem til det man er ute etter. Å legge til salmer er også mye mer intuitivt. I det gamle programmet måtte man legge til en linje om gangen, og hvis man gjorde en feil måtte man redigere salmen senere. I den nye versjonen har du mye bedre oversikt over salmen du legger inn og du kan hele tiden forandre på alle felter. Redigering av salmer i det gamle programmet er det mest klønete. Du kan bare redigere en linje av gangen, og i tillegg kan du ikke fjerne tegn, bare bytte dem ut. Det betyr at hvis du skal skrive 233, men skriver ved en feil 2033, og prøver å fjerne 0 ender du opp med 2 33 i stedet. Dette betyr at hvis du skriver feil i starten av en linje, må du sannsynligvis skrive hele linjen på nytt igjen. Dette er da selvfølgelig mye bedre i det nye programmet, hvor du hele tiden har oversikt over alle feltene og kan forandre hvert enkelt datafelt individuelt. Disse tre implementeringene gjør at programmet opprettholder de krav oppdragsgiver har gitt, slik at han skal kunne bruke programmet på samme måte som han har brukt det gamle programmet, på en mer tidsparende måte. Side 27 av 29

7.3 Andre krav I kravspesifikasjonen står beskrevet flere funksjonelle krav som er spesifikke til implementeringen. Der er beskrevet krav som at brukeren skal kunne søke, at han skal kunne logge seg inn i programmet og at databasen skal støtte historikk. Ingen av disse kravene var påkrevd av oppdragsgiver. Disse ble i stedet gitt av oss selv som mål om hva vi skulle lage. Alle disse målene ble implementert i det ferdige produktet. Side 28 av 29

8 Resultatet Vi er fornøyd med resultatet av prosjektet. Arbeidet har resultert i en tidsmessig effektiv applikasjon for arbeidsgiver. Med denne nye versjonen vil det være mulig for ham å finne informasjonen han leter etter fortere, og det vil også ta mindre tid å redigere det han trenger og å legge til ny data. I tillegg kan han nå dataene sine fra alle steder som har internettoppkobling, noe som gjør det lettere for ham å arbeide både hjemme og fra arbeidsplassen. Programmet er mye raskere å arbeide med enn det programmet oppdragsgiveren brukte tidligere. Dette skyldes først og fremst brukervennligheten. Selv om applikasjonen hovedsakelig ble laget for vår oppdragsgiver, så er programdesignen åpen for at det er mulig å implementere flere brukere. Vi er fornøyd med at vi tok valget med å designe applikasjonen slik fra bunnen av, fordi dette åpner for flere muligheter for bruk av programmet. At programmet kan brukes av flere brukere gjør at det vil være i stand til å hjelpe flere enn bare oppdragsgiveren med å få organisert arbeidet sitt. Det er store muligheter for at også andre organister kunne være interessert i programmet. Oppdragsgiveren har fått fire-fem andre organister med seg, som skal være med å teste programmet for å se om det er andre ting som kan gjøres for å få det bedre for flere brukere. Vi vet allerede at det er et program oppdragsgiveren er fornøyd med, men med denne testingen vil vi kunne se om også andre organister vil være interessert i å bruke programmet. Vi var også i kontakt med Cantando musikkforlag, et forlag som utgir notehefter og musikk, om de var interessert i å ha linker i programmet vårt til hjemmesidene deres. De brukte allerede et program kalt LabOra Cantor som er et administrasjonsverktøy for kirkemusikere, men siden dette programmet ikke lenger ble videreutviklet, så var de interessert i å høre mer om programmet vårt. Vi fikk gjort applikasjonen til det produktet vi hadde planlagt. Programmet ble akkurat det oppdragsgiver trengte. Oppdragsgiver er veldig fornøyd med resultatet, og det er det viktigste målet med oppgaven. Prosjektet har resultert i økt kompetanse for gruppen. Vi måtte sette oss godt inn i regulære uttykk for å få overført dataene trygt, og vi måtte sette oss dypere inn i databasedesign. Vi har fått mye innsikt i prosessen det tar å utvikle et produkt, i tillegg til mer teknisk kunnskap om programmering av databaser og webapplikasjoner. Vi fikk større kunnskap om php og SQL, og hvordan å bygge en webapplikasjon. Dette er for oss nyttig erfaring å ta med seg videre. 8.1 Oppdragsiverens egne ord [Jeg] fikk tilbud fra skolen om å få laget et nytt program der gammel informasjon ble lagt inn i det nye programmet. Dette var veldig interessant. Så jeg engasjerte gruppen til å lage dette nye programmet. Med mine begrensede datakunnskaper så jeg ikke for meg hvilke muligheter som kunne legges inn i det nye programmet. Men vi har hatt en god dialog underveis, og jeg er stadig mer begeistret for de mulighetene dette nye programmet åpner for. Og det gamle programmet hadde med sine mange forkortelser bare anvendelse for meg. Nå ser jeg for meg at flere organister kan ha nytte av dette programmet. Side 29 av 29