Hovedprosjekt våren 2007

Hovedprosjekt våren 2007 Bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo Dokument Prosessrapport Prosjekttittel: Telepower Prosjektnummer: 07-06 Oppgave: Redesign av Telepower - en GSM /GPRS/SMS strømstyringssentral Prosjektperiode: November 2006 mai 2007 Gruppemedlemmer: Siril Alexandra Bache, Line Haugen og Hallvard Welde Oppdragsgiver: Cronus Engineering AS Kontaktperson: Geir Sørum tlf: 23 17 71 55 Veileder: Eva Hadler Vihovde

1. Forord Prosessrapporten beskriver prosessen vi har vært igjennom med hovedprosjektet Telepower. Hovedprosjektet er avsluttende prosjekt for bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo. Rapporten er utformet slik at den skal kunne leses som et selvstendig dokument. Detaljert informasjon om selve produktet finnes i produktdokumentasjonen. Vi forutsetter at leseren har generelle datakunnskaper og har kjennskap til objektorientert systemutvikling. Faguttrykk og forkortelser er beskrevet i dataordboken. 2

2. Innholdsfortegnelse 1. Forord... 2 2. Innholdsfortegnelse... 3 3. Sammendrag... 5 4. Om bedriften... 5 5. Bakgrunn for prosjektet... 6 6. Dagens system Telepower... 6 6.1 Fjernstyring av hyttevarme... 7 6.2 WinTelepower... 7 6.3 Dagens tekniske løsning... 7 6.4 Erfaringer med dagens løsning... 8 7. Mål for prosjektet... 9 8. Rammebetingelser og teknologier... 9 9. Systembeskrivelse... 9 10. Idéfasen... 11 10.1 Prosjektstyring... 11 10.2 Arbeidet med å skaffe et prosjekt... 11 10.3 Telepowerprosjektet tar form - Prosjektskissen... 12 11. Utdypningsfasen... 13 11.1 Forprosjekt... 13 11.1.1 Forprosjektsrapport... 13 11.1.2 Arbeidsplan, arbeidsdiagram og fremdriftsplan... 14 11.1.3 Risikoanalyse... 14 12. Kravspesifikasjon... 15 12.1 UML-modellering... 15 12.1.1 Funksjonell modell... 15 12.1.2 Objektmodell... 16 12.1.3 Dynamisk modell... 18 12.2 Utfordringer i utdypningsfasen... 20 12.3 Prioriteringer... 22 3

13. Konstruksjonsfasen... 23 13.1 Konfigurering av utviklingsmiljø... 23 13.2 Telefonmenyen... 24 13.2.1 Funksjonalitet... 24 13.2.2 Menyoversikt... 25 13.2.3 Implementasjon... 25 13.3 Rammeverket... 26 13.3.1 Implementasjon... 26 13.3.2 Programflyt... 26 13.4 Utvidelsesmuligheter... 29 13.5 Nye brukergrensesnitt... 29 13.5.1 Nye type enheter... 30 13.6 Utfordringer i konstruksjonsfasen... 30 14. Overgangsfasen... 31 15. Konklusjon... 32 16. Litteratur... 34 4

3. Sammendrag Vår oppdragsgiver er Cronus Engineering AS. Cronus utvikler, prosjekterer og selger nøkkelferdige automatisering/industrielle IT løsninger til norsk industri og offshore. Et produkt de tilbyr er Telepower som er en strømstyringssentral. Strømstyringssentralen benyttes til å kontakte og kontrollere ulike strømstyringsenheter. På grunn av vanskeligheter med å drifte og videreutvikle Telepower, ønsket Cronus å redesigne hele telepowersystemet. Prosjektet vårt danner grunnlaget for utvikling av det nye Telepowersystemet. Vi har laget et rammeverk til strømstyringssentralen og en telefonmeny som et brukergrensesnitt til sentralen. Vi har implementert støtte for to ulike typer styringsenheter, en som kontaktes via GSM nettet og kontrolleres med tonesignalering (DTMF) og en som kontrolleres med SMSmeldinger. Strømstyringsenhetene har en temperatursensor og et relé som kan benyttes til å skru av eller på varme og belysning. 4. Om bedriften Cronus har tatt navnet sitt fra en av de tolv titanene i gresk mytologi, han var gud for tidens fremdrift. Cronus Engineering AS utvikler, prosjekterer og selger nøkkelferdige Automatisering / Industrielle IT løsninger til norsk industri og offshore. I tillegg tilbyr selskapet et bredt spekter av standardprodukter og ingeniør- / servicetjenester. (Cronus.no, u.å.) Cronus Engineering er en del av Cronus gruppen som er en norsk eid selskapsgruppering som igjen er en del av Goodtech ASA. I 2001 ble Umoe Intech AS kjøpt ut fra Umoe konsernet og endret navn til Cronus Engineering. Cronus Engineering har 60 høyt utdannede medarbeidere og har hovedkontor på Karihaugen i Oslo. Vi finner store selskaper som Hydro, Tine, Kraft, Viken, Telenor og Shell blant Cronus sine kunder. Figur 1. Cronus; gud for tiden. Illustrasjon: www.pantheon.org 5

5. Bakgrunn for prosjektet Cronus har opplevd problemer med å drifte og videreutvikle Telepower. De ønsker derfor et fullstendig redesign av Telepowersystemet. Cronus har en visjon for nye Telepower: En modulbasert løsning som bygger på kjente programmerings- og databasestandarder, hvor det er lagt stor vekt på skalerbarhet og enkel implementering av nye tjenester og funksjoner. Vårt prosjekt danner grunnlaget for det nye Telepowersystemet basert på Cronus sin visjon. 6. Dagens system Telepower Ett av produktene Cronus tilbyr er strømstyringssentralen Telepower. Telepowers kunder er alt fra private hytteeiere til større bedriftskunder som Hafslund. Telepower styrer blant annet fasadebelysningen på Karl Johan, lysløyper i marka og er brukt av hytteeiere til å fjernstyre varmen på hytta. Figur 2. S5011 Styringsenhet Telepower ble opprinnelig utviklet av firmaet Cresto. Cresto gikk konkurs i 2001. På forespørsel av flere kunder som brukte Telepower, kjøpte Cronus opp konkursboet til Cresto og tok over driften av Telepowersystemet.. Hyttevarme styres fra en telefonmeny som en blir presentert med når en ringer opp Telepowersentralen. De mer avanserte funksjonene som styring av gatelys og tekniske installasjoner styres fra et windowsprogram kalt WinTelepower. 6

6.1 Fjernstyring av hyttevarme Fjernstyring av hyttevarme skjer ved at en installerer en GSM basert styringsenhet, kalt Telepower 5011. Enheten består av en GSM-modul, et relé, en temperaturføler og en ekstern antenne. For å styre Telepower 5011, ringer brukeren Telepowersentralen og angir en kommando via telefonmenyen. Sentralen videreformidler kommandoen til riktig styringsenhet. 6.2 WinTelepower WinTelepower er et windowsprogram for styring av Telepowerenheter. Dette programmet gir mulighet for effektstyring, styring og overvåkning av utebelysning via GSM-nettet. Det er også mulighet for styring og overvåkning av tekniske installasjoner i næringsbygg som for eksempel sentralfyring. WinTelepower kommuniserer med Telepowersentralen via et analogt modem. Telepowersentralen kontakter styringsenheten via GSM-nettet. 6.3 Dagens tekniske løsning Dagens løsning benytter telefoniscriptspråket Rekoll for kommunikasjon mellom telefonkort og databasen. Databasen som ligger i bakgrunnen er Microsoft SQL 2000 server. Se figur 3 for skisse over dagens løsning. 7

Figur 3. Skisse over dagens løsning Illustrasjon: Cronus 6.4 Erfaringer med dagens løsning Rekoll er et telefoniscriptspråk utviklet av et fransk firma og det er få personer i Norge som har kompetanse på dette området. Cronus er nødt til å leie inn kompetanse på Rekoll ved behov. Det er også et problem for Cronus at Rekoll ikke lenger støttes av leverandør. Innholdet i databasen er importert fra en eldre dbase database. I følge Cronus preges databasen av dårlig databasedesign uten relasjoner, noe som har ført til problemer med inkonsekvente data. Kombinasjonen av scriptspråket og ugunstig databasedesign har gjort det svært vanskelig for Cronus å drifte og videreutvikle systemet. 8

7. Mål for prosjektet Telepower er et stort system og redesign av hele Telepowersystemet var av for stort omfang for et hovedprosjekt. Prosjektet vårt danner grunnlaget for videre utvikling av det Nye Telepowersystemet. Målet for hovedprosjektet er ikke et fullverdig system som skal settes i produksjon ved prosjektets utløp. Målet er derimot å bygge opp et helhetlig rammeverk for å implementere funksjoner og tjenester til systemet. Det må være enkelt å lage nye grensesnitt til rammeverket. Cronus ønsket at vi laget en telefonmeny som et grensesnitt til rammeverket. Telefonmenyen skal være ett av flere grensesnitt til systemet når det settes i drift. 8. Rammebetingelser og teknologier Cronus skal videreutvikle systemet vi har laget, derfor har de gjort vurderinger og lagt føringer på hvilke teknologier og verktøy vi skulle bruke i prosjektet. Systemet skulle utvikles i Java og bygges med Maven. Vi skulle benytte oss av Asterisk som telefonisystem og Fast AGI som grensesnitt mellom Javakode og Asterisk. Rammebetingelser er ytterligere definert i kravspesifikasjonen. Gitte teknologier er beskrevet i produktdokumentasjonen. 9. Systembeskrivelse Systemet vi har utviklet består av et rammeverk og en telefonmeny som er grensesnittet til rammeverket. Se figur 4. Telefon- nettet Asterisk server FAST AGI PhoneMenu.java Manager GSM- API Rammeverket nettet Styringsenhet S5011 Figur 4. Arkitekturskisse 9

Rammeverket er laget med tanke på at det skal være enkelt å lage nye grensesnitt til rammeverket som for eksempel applikasjons-, PDA- og webgrensesnitt. Rammeverket tar i mot en forespørsel om å utføre en oppgave på en styringsenhet, på et gitt tidspunkt. En oppgave kan være å skru av eller på en styringsenhet, lese av temperatur og hente ut bryterstatus. Støtte for flere oppgaver kan legges til senere. Alle forespørsler systemet mottar lagres. På det tidspunkt en forespørsel skal utføres legges den i en kø. Det er separate køer for styringsenheter som benytter forskjellige kommunikasjonsmetoder som for eksempel SMS eller tonesignalering (DTMF). Vi har laget køhåndterere for SMS-styringsenheter og DTMF-styringsenheter. Køhåndterene kjører parallelt og henter ut en oppgave fra riktig kø og utfører den. Hvordan en oppgave utføres er definert i et kommandoobjekt som er knyttet til en forespørsel. SMS-oppgaver utføres ved at en spesielt formatert SMS-melding sendes til styringsenheten. DTMF-oppgaver utføres ved at enheten ringes opp og oppgaven sendes via tonesignalering. Hvis en oppgave mislykkes vil systemet forsøke å utføre den på nytt etter en gitt tid, et gitt antall ganger. Tiden og antall ganger spesifiseres av Cronus i rammeverket. En kunde kan enten høre progresjonen for en oppgave over telefonmenyen eller få tilsendt en SMS-melding når oppgaven er fullført. 10

10. Idéfasen Idéfasen er tradisjonell og består først og fremst av lønnsomhetsvurderinger og beslutninger om prosjektets omfang, men også første modellering gjøres her. (Gurholt og Hasle, 2003) For vår del var arbeidet med å finne et aktuelt prosjekt en viktig del av idéfasen. Vi brukte også denne fasen til å gjøre en del avgjørelser i forhold til prosjektstyring og dokumenthåndtering. Arbeidet med prosjektskissen var også en viktig del av idéfasen. 10.1 Prosjektstyring Vi har jobbet sammen i tidligere prosjekter der vi har erfart at vi utfyller hverandre godt og oppnådd en god gruppedynamikk. Likevel satte vi opp en samarbeidsavtale for å forebygge eventuelle konflikter i gruppen. I samarbeidsavtalen definerte vi at vi skulle ha en flat demokratisk gruppestruktur og at vi ønsket å oppnå konsensus der det var mulig. Samarbeidsavtalen er vedlagt som nummer 5. Vi bestemte at prosjektdokumentene skulle optimaliseres for papir og legges ut på prosjektets hjemmeside i PDF-format. Vi bestemte oss for å bruke en online prosjektdagbok. 10.2 Arbeidet med å skaffe et prosjekt Det første vi gjorde for å skaffe oss et hovedprosjekt var å ta kontakt med Storebrand der ett av gruppemedlemmene jobber. De hadde ikke kapasitet til å følge opp et hovedprosjekt. Deretter laget vi en webside med presentasjon av gruppen som vi sendte til en rekke potensielle oppdragsgivere. I tillegg planla vi hvordan vi skulle presentere oss på intervjuer hos mulige oppdragsgivere. Vi ønsket oss et prosjekt som ikke var en ren webapplikasjon, men et prosjekt som ga oss stor variasjon og mulighet til å sette oss inn i nye teknologier. Vi var på møte med Instant Office og Ullevål universitetssykehus. Etter møtene fant vi ut at vi ikke ønsket noen av disse prosjektene. Instant Office hadde en webapplikasjonsoppgave med data 11

som skulle leses inn fra en webside, og senere presenteres. Oppdraget på Ullevål var å videreutvikle en eksisterende database i FileMaker. Vi fant ingen av disse oppdragene utfordrende nok. Vi fikk også tilbud om hovedprosjekt hos Forsvarets forskningsinstitutt. De ønsket at vi utviklet en Unmanned Arial Vehicle til deres kampsimulator. Vi fant dette prosjektet litt for smalt. Vi hadde et møte med Cronus Engineering som hadde et hovedprosjektsforslag kalt Telepower. Hovedprosjektet gikk ut på å lage et rammeverk for å utvikle en GSM/GPRS/SMS strømstyringssentral. Vi valgte dette prosjektet fordi det var annerledes og mer utfordrende enn en tradisjonell webapplikasjonsoppgave. Telepowerprosjektet gav oss den variasjonen de andre prosjektene manglet. Prosjektet gav oss muligheten til å sette oss inn i mange nye teknologier. I det hele tatt virket prosjektet meget seriøst og godt organisert. I tillegg antydet Cronus en mulighet for å jobbe videre med prosjektet etter prosjektets utløp. 10.3 Telepowerprosjektet tar form - Prosjektskissen Utarbeidelsen av prosjektskissen var en viktig prosess for å få en bedre forståelse av prosjektet. Forprosjektskissen ble utarbeidet på bakgrunn av informasjon fra vårt første møte med oppdragsgiver, en PowerPoint presentasjon og Cronus sine hjemmesider. 12

11. Utdypningsfasen Utdypningsfasen er en analysefase på systemnivå, dvs. ikke på detaljnivå for det enkelte delprodukt. I denne fasen gjøres alle modeller som innvirker på systemet som helhet (Gurholt og Hasle, 2003) Vi startet utdypningsfasen med forprosjektet som ga grunnlaget for videre spesifisering av systemet med kravspesifikasjonen og UML-modelleringen. 11.1 Forprosjekt I forprosjektet skal problemområdet ytterligere defineres. En skal bestemme så nøyaktig og presist som mulig hva problemområdet består av. Et viktig poeng er om problemet kan løses innenfor de rammene som er aktuelle, d.v.s. tids- og arbeidsmessige rammer og de gitte teknologiske rammene. (Iu.hio.no, u.å.) I forprosjektet vårt utarbeidet vi en forprosjektsrapport, arbeidsplan, arbeidsdiagram og fremdriftsplan. 11.1.1 Forprosjektsrapport På første veiledningsmøte ble vi oppfordret til å skrive så mye som mulig i forprosjektsrapporten. Vi skrev ned alt vi visste om prosjektet. Vi prioriterte å jobbe godt med forprosjektrapporten og brukte mye tid på å skrive og formulere rapporten. Vi brukte white board til brainstorming. Brainstormingen ble utgangspunktet til disposisjonen vår. Etter å ha fått tilbakemelding av både veileder og oppdragsgiver, reviderte vi rapporten. Denne prosessen gikk vi igjennom flere ganger. Med å skrive en grundig og omfattende rapport fikk vi en god forståelse for hva prosjektet innebar. Forprosjektrapporten ga oss et godt grunnlag for andre rapporter, det erfarte vi allerede i kravspesifikasjonen. Vi fikk svært god tilbakemelding fra veileder på forprosjektsrapporten. Det ga oss motivasjon og bekreftelse på at fremgangsmåten vår fungerte bra. 13

Teknologiene vi skulle benytte i prosjektet var gitt som rammebetingelser. Vi trengte derfor ikke vurdere ulike teknologier opp mot hverandre, men måtte skaffe oss en overordnet forståelse for de valgte teknologier. 11.1.2 Arbeidsplan, arbeidsdiagram og fremdriftsplan Etter vi hadde kommet godt i gang med forprosjektet startet vi med arbeidsplanen. Inspirert av RUP (Rational Unified Process) delte vi arbeidet inn i fire faser: idéfase, utdypningsfase, konstruksjonsfase og overgangsfase. Idéfasen var vi alt ferdig med, så arbeidsplanen ble da delt inn i de tre siste fasene. Vi brukte igjen white board til brainstorming som utgangspunkt for disposisjon for arbeidsplanen. Vi forsøkte å lage arbeidsplanen så konkret og detaljert som mulig. Vi satte deretter opp en skjematisk fremstilling av rekkefølgen av oppgavene i arbeidsplanen som resulterte i et arbeidsdiagram. Det ga oss en svært god oversikt over rekkefølgen oppgavene måtte utføres i. Arbeidsdiagrammet ble brukt som utgangspunkt for å sette opp fremdriftsplanen. Vi brukte Excel til å sette opp fremdriftsplanen som et Gantt-diagram. Arbeidet med disse dokumentene ga oss en bedre forståelse av de konkrete oppgaver som skulle utføres og rekkefølgen de måtte utføres i. Se vedlegg for arbeidsplan, arbeidsdiagram og fremdriftsplan, henholdsvis nummer 1, 2 og 3. 11.1.3 Risikoanalyse For å forsøke å redusere ulike risikoer bestemte vi oss for å sette opp en risikoanalyse. Risikoanalysen ga oss en oversikt over sannsynligheten for at et problem inntreffer og konsekvensen det eventuelt vil medføre. Sannsynlighet ganger konsekvens ga oss en verdi som vi brukte for å rangere risikoen. I risikoanalysen satt vi opp tiltak for å forebygge de ulike problemene. I tillegg satt vi opp tiltak vi skal sette i verk hvis et problem inntreffer. Risikoanalysen er vedlagt som nummer 7. 14

12. Kravspesifikasjon Arbeidet med forprosjektet gav oss en oversikt over hvilke ønsker Cronus hadde til systemet. Vi tok utgangspunkt i disse ønskene og laget et førsteutkast til kravspesifikasjonen. Kravspesifikasjonen ble ytterligere detaljert igjennom flere iterasjoner, basert på tilbakemeldinger fra flere møter med Cronus. Underveis i prosjektet kom Cronus med nye ønsker og omprioriteringer som medførte at kravspesifikasjonen ble oppdatert. Kravspesifikasjonen er et selvstendig dokument og er å finne som en del av sluttrapporten. 12.1 UML-modellering Kravene til systemets skalerbarhet og utvidelsesmuligheter var noe av det viktigste med prosjektet vårt. Dette stilte store krav til modelleringen av systemet. Etter vi hadde ferdigstilt kravspesifikasjonen, begynte vi med en overordnet UML-modellering av hele systemet. Under konstruksjonsfasen gjorde vi en mer detaljert modellering av hvert enkelt delsystem. Vi valgte å se på UML-modellen som tre deler: funksjonellmodell, objektmodell og dynamisk modell. 12.1.1 Funksjonell modell Den funksjonelle modellen viser systemets funksjonalitet fra en brukers perspektiv. Vi laget et brukstilfelle for å skru av og på et relé på en styringsenhet ved hjelp av telefonmenyen. Brukstilfelle er lagt ved som nummer 4. 15

12.1.2 Objektmodell Objektmodellen viser systemets struktur av objekter, attributter, operasjoner og relasjoner. Vi startet med et konseptuelt klassediagram som senere ble detaljert igjennom flere iterasjoner. Nedenfor er det forenklede klassediagrammer over de viktigste elementene i programmet. Mer detaljert informasjon finnes i produktdokumentasjonen. Figur 5. Forenklet klassediagram over programstruktur 16

Figur 6. Forenklet klassediagram over Unit-hierarkiet Figur 7. Forenklet klassediagram av kommandoobjekthierarkiet 17

12.1.3 Dynamisk modell Den dynamiske modellen beskriver systemets interne oppførsel. Vi laget sekvensdiagrammer for telefonmenyen og rammeverket. Vi brukte en top-down strategi hvor vi først satte opp en grov oversikt over aktivitetene som vi deretter detaljerte gjennom flere iterasjoner. bruker telefonmeny Grensesnitt: RequestService enhet: Unit Ringer opp Angir enhetsnr validateunitid(enhetsnr) getunit(enhetsnr) enhet supportsrelay supportsgetrelaystatus supportsgettemperature Meny Valg addrequest (unitid, commandnr) requestid loop [ status!= success Status!= failed ] status getstatus(requestid) status Figur 8. Prinsipielt sekvensdiagram for kommunikasjon mellom telefonmenyen og rammeverket 18

Figur 9. Prinsipielt sekvensdiagram for addrequest 19

Figur 10. Prinsipielt sekvensdiagram for DTMF-køhåndterer 12.2 Utfordringer i utdypningsfasen En av de største utfordringene i prosjektet var håndteringen av forespørsler til styringsenheter som kommuniserer på forskjellige måter. Styringsenheten S5011 styres med tonesignalering (DTMF), mens SMS5011 styres med spesielt formaterte SMS-meldinger. Vi trengte en måte å lagre informasjon om hvordan en oppgave utføres for hver type enhet. I tillegg trengte vi å ha separate køer for styringsenheter som benytter forskjellige kommunikasjonsmetoder. Systemet må støtte fremtidige enheter som benytter ny kommunikasjonsteknologi. Det var derfor nødvendig å kunne opprette nye køer dynamisk og ha en fleksibel måte å lagre informasjon om hvordan en oppgave utføres. 20

Vi fant ut at det var hensiktsmessig å lage et klassehierarki av kommandoobjekter som inneholder informasjon om hvordan en oppgave skal utføres på en type styringsenhet. For å støtte en ny type styringsenhet som kommuniserer på en ny måte, må det opprettes en ny subklasse av kommandoklassen (Command), se figur 7. For å kunne dynamisk opprette nye køer har laget vi en hashtabell kalt queues. Med kommandoklasse som nøkkel og en kø som holder objekter av kommandoklassen som verdi, se tabell 1. Nøkkel Verdi SmsCommand SmsQueue{ } DtmfCommand DtmfQueue{ } Tabell 1. Hashtabell illustrasjon Hvis det innføres en ny type kommandoklasse opprettes det automatisk en ny oppføring i queues med ny kø for den typen kommandoobjekter, se figur 11. /*gets the class of the command object assosiated with the unitrequest */ Class commandclass = unitrequest.getcommand().getsuperclass(); /* if there is not a queue of the correct command type create one */ if (! queues.containskey( commandclass ) ) { queues.put(commandclass, new LinkedBlockingQueue<UnitRequest>() ); } /*Get the correct queue from the hashtabel of queues */ Queue<UnitRequest> queue = queues.get( commandclass ); <...> /* Add the unitrequest to the correct Queue */ queue.add( unitrequest ); Figur 11. Kodeutsnitt fra RequestService.addToExecutionQueue En annen utfordring var håndtering av oppgaver som mislykkes. Hvis systemet ikke lykkes i å utføre en oppgave skal systemet forsøke å utføre oppgaven på nytt etter et gitt tidsintervall. Vi 21

fant en løsning på denne utfordringen som ikke bare løste problemet, men også ga ny ettertraktet funksjonalitet. Ved å lage funksjonalitet for å utføre oppgaver på et fremtidig tidspunkt, kan mislykkede oppgaver forsøkes på nytt etter en gitt tid. I tillegg gir det kunden mulighet til utføre en oppgave på et fremtidig tidspunkt. 12.3 Prioriteringer Utviklingen av køhåndteringsmekanismen var den største og viktigste oppgaven i prosjektet. Etter vi hadde gått igjennom første utkast av UML-modellen av systemet innså Cronus hvor omfattende køhåndteringsmekanismen kom til å bli. De ba oss prioritere å lage en fleksibel og robust køhåndteringsmekanisme fremfor bruker- og gruppehåndtering som hadde vært et ønske til å begynne med. Denne omprioriteringen førte til at vi måtte omarbeide kravspesifikasjonen og UML-modellen. 22

13. Konstruksjonsfasen Konstruksjonsfasen består av mange iterasjoner, hvor hver iterasjon inneholder alle de vanlige livssyklusfasene som detaljanalyse, design, implementering og testing dog på et detaljert nivå (Gurholt og Hasle 2003) Vi laget et rammeverk og en telefonmeny. Vi så på disse som separate delsystemer. På hvert enkelt av disse delsystemene har vi gått igjennom fasene analyse, design, implementering og testing. 13.1 Konfigurering av utviklingsmiljø Oppsett av utviklingsmiljøet har vært en tildels tidkrevende og utfordrende prosess. Teknologiene Maven, Asterisk, Manager API og Fast AGI var nye for oss og det krevde at vi brukte tid på å sette oss inn i disse. Vi benyttet oss av Maven 2 som er et prosjekt- og byggeverktøy for Javautvikling. Vi brukte mye tid på å sette oss inn i og konfigurere Maven korrekt. Når Maven var korrekt satt opp og vi hadde lært oss å bruke det, viste det seg å være et meget nyttig verktøy. Dette gjorde det enkelt å bygge Javaapplikasjonen vår og å legge til avhengigheter i prosjektet vårt som for eksempel Asterisk Fast AGI. Telefonmenyen implementerte vi med Asterisk som er et open source telefonisystem og Fast AGI som er et Javagrensesnitt til Asterisk. Det krevde også noe tid å konfigurere og sette seg inn i dette. Vi brukte også Asterisk til å ringe opp DTMF-enheter, det krevde riktig oppsett og bruk av Manager API. 23

13.2 Telefonmenyen Telefonmenyen er det grensesnittet ut mot kunden som vi implementerte i dette prosjektet. Det var flere grunner til at Cronus ønsket at telefonmenyen skulle være det første grensesnittet som skulle implementeres: - dagens Telepower kunder er vant til å bruke et telefongrensesnitt - det er viktig at systemet skal være tilgjengelig så lenge du har tilgang til en telefon - Asterisk er relativt ny og uprøvd teknologi for Cronus, de ønsket å undersøke om det var mulig å implementere telefonmenyen med Asterisk og Fast AGI 13.2.1 Funksjonalitet Vi implementerte følgende funksjonalitet i henhold til første kravspesifikasjon: - velge en av følgende oppgaver: skru av eller skru på en enhet - velge å utføre oppgaven umiddelbart eller på et framtidig tidspunkt - høre oppgavens progresjon over telefon eller få tilsendt en SMS-melding når oppgaven er fullført Når denne funksjonaliteten var ferdig kom Cronus med ytterlige ønsker: - hente ut bryterstatus - lese av temperaturen på en enhet - liste opp planlagte oppgaver på en enhet - kansellere en planlagt oppgave på en enhet - telefonmenyen endres avhengig av funksjonaliteten til valgt enhet Kravspesifikasjonen ble oppdatert og de nye ønskene ble implementert. Fordi vi hadde laget systemet med tanke på utvidelse ble det lett å implementere disse ønskene, selv om de ikke var med i det første designet. 24

13.2.2 Menyoversikt Etter kunden har angitt et enhetsnummer, får kunden opplest en meny basert på de valg som støttes av enheten. Hvis kunden ønsker å skru av eller på enheten, må kunden deretter velge om oppgaven skal utføres umiddelbart eller på et framtidig tidspunkt. Hvis oppgaven skal utføres på et framtidig tidspunkt angir kunden dato og klokkeslett, i tillegg må kunden oppgi et mobilnummer for tilbakemelding. Hvis oppgaven skal utføres umiddelbart får kunden valget mellom å høre progresjon for oppgaven over telefon eller få tilsendt en SMS-melding når oppgaven er utført. Hvis kunden ønsker å hente bryterstatus eller å lese av temperaturen, kontakter systemet enheten for å sjekke temperaturen eller om bryteren står av eller på. Kunden kan også få opplest planlagte oppgaver og eventuelt kansellere en planlagt oppgave. 13.2.3 Implementasjon Telefonmenyen har vi implementert med Fast AGI som er et Javagrensesnitt til Asterisk telefonisystem. For å kommunisere med kunden benytter telefonmenyen lydfiler. Lydfilene til filnavnene er definert som konstanter, slik at de vil være enkle å forandre. Vi laget en egen klasse SoundEngine som innholder generelle metoder for å blant annet lese opp siffer, tall, ordenstall, dato, tidspunkt og temperatur. I SoundEngine har vi også laget vår egen implementasjon av Fast AGI metoden getdata som mottar tastetrykk fra kundens telefon. Vi har laget vår egen implementasjon som har egne tilpasninger og håndterer unntakssituasjoner. En kunde kan angi en dato for når en oppgave skal utføres. Som regel skal en oppgave utføres inneværende år. For å spare kunden for unødvendige tastetrykk på telefonmenyen setter vi automatisk året oppgaven skal utføres på til inneværende år. Hvis datoen angitt er før dagens dato settes året til neste år. Hvis en 28. desember 2007 legger til en oppgave som skal utføres 1. januar, settes året automatisk til 2008. 25

I første omgang testet vi telefonmenyen som et selvstendig produkt, hvor vi benyttet en testklasse som emulerte de bakenforliggende systemene som ikke var utviklet enda. Testen ble gjennomført i henhold til vår testplan. Til slutt i prosjektet ble telefonmenyen testet mot systemet som helhet. Se testrapporten for ytterlige detaljer. 13.3 Rammeverket Hovedsystemet vårt er et rammeverk for å implementere funksjoner og tjenester til det nye Telepowersystemet. Vi har laget den grunnleggende arkitekturen og den bakenforliggende funksjonaliteten. Vi har implementert støtte for to ulike typer styringsenheter som gir ulik funksjonalitet og kommuniserer på forskjellige måter. Rammeverket tar i mot en forespørsel fra et grensesnitt og: - lagrer forespørselen - legger den i riktig kø for utføring på riktig tidspunkt - utfører forespørsler fra køene - lagrer resultatet - sender tilbakemelding til bruker 13.3.1 Implementasjon Rammeverket er implementert som en Javaapplikasjon. Rammeverket benytter Asterisk Manager API for å sette opp telefonsamtale til DTMF-styringsenhetene og Asterisk Fast AGI for DTMF kommunikasjonen. SMS-meldinger fra rammeverket sendes ved hjelp av Cronus sin SMS-server. Fleksibilitet og utvidelsesmuligheter har vært viktig, derfor har vi benyttet oss av en lagdeling av programmet. Vi benyttet blant annet Data Aksess Objekter (DAO) til lagring av data i systemet vårt. DAO fungerer som et lag i mellom programmet og datalageret. 13.3.2 Programflyt Systemet er bygd opp rundt 3 objekter: styringsenhet (unit), en kommando (command) og en forespørsel (unitrequest). En enhet har kommandoobjekter for alle funksjoner den støtter. Kommandoobjektene beskriver hvordan en funksjon skal utføres. Når en oppgave skal utføres 26

opprettes det et forespørselsobjekt. Forespørselsobjektet inneholder en referanse til enheten oppgaven skal utføres på, en referanse til kommandoobjektet som beskriver hvordan oppgaven skal utføres og et tidspunkt når oppgaven skal utføres. Forespørselsobjektet lagres i riktig dataaksessobjekt (UnitRequestDAO). Hvis oppgaven skal utføres umiddelbart legges den i riktig kø, basert på kommandoobjektet den referer til. Vi har en egen schedulertråd som hvert sekund sjekker lagrede forespørsler for oppgaver som skal utføres på nåværende tidspunkt og legger de i riktig kø. Se figur 12. 27

En forespørsel opprettes Phonemenu Webgrensesnitt håndterer Applikasjonsgrensesnitt Framtidige utvidelser Rammeverket Grensesnitt Forespørsler lagres alltid i datalageret Hvis opppgaven skal utføres umiddelbart legges den rett i kø Datalager Scheduler Scheduleren sjekker datalageret for planlagte oppgaver som skal utføres Køer Køhåndtererene henter ut forspørsler fra riktig kø og sender de videre til sin køelementhåndterer Køhåndterer Dtmf køelement- Køhåndterer SMS køelementhåndterer DTMF-caller SMS-sender GSM-nettet S5011 styringsenhet SMS5011 styringsenhet Pilene indikerer hvem som initialiserer kontakt. Dataflyten går i de fleste tilfeller begge veier. Figur 12. Programflyt

Det initialiseres separate køhåndterere for hver kø. Køhåndtererne sjekker riktig kø for forespørselsobjekter. Hver køhåndterer implementerer en køelementhåndterer (QueueElementHandler) som forsøker å utføre forespørselen. Køelementhåndtereren rapporterer om forespørselen ble vellykket gjennomført eller ikke. Hvis forespørselen ble gjennomført lagres informasjon om dette i systemet. Kunne ikke forespørselen gjennomføres, legges den tilbake i systemet for å utføres på nytt etter en gitt tid, med mindre oppgaven har overskredet maks antall forsøk. Hvis forespørselsobjektet inneholder et mobilnummer, sendes det ut en SMS-melding til kunden når forespørselen enten har blitt gjennomført eller overskredet maks antall forsøk. SMS-køelementhåndtereren henter SMS-kommandoobjektet som innholder en tekststreng som skal sendes til enheten for å utføre oppgaven. Tekststrengen sendes som SMS-melding via Cronus sin SMS-server til enheten. DTMF-køelementhåndtereren ringer opp enheten og kaller på kommandoobjektets execute metode. Execute metoden sørger for nødvendig DTMF-kommunikasjon for å utføre forespørselen. 13.4 Utvidelsesmuligheter Utvidelsesmuligheter er essensielt for systemet. Vi har hatt fokus på at det skal være enkelt å legge til nye brukergrensesnitt og nye typer enheter som enten benytter støttede kommunikasjonsmetoder eller som benytter nye måter å kommunisere på. I tillegg er det lagt opp til at det skal være enkelt å endre måten data lagres på. 13.5 Nye brukergrensesnitt For å gjøre det enkelt å utvide med nye grensesnitt har vi definert hvilke metoder et grensesnitt må implementere i et interface (RequestService). Den lagvise arkitekturen i programmet er også viktig for at det skal være enkelt å utvide med nye grensesnitt.

13.5.1 Nye type enheter For nye type enheter som benytter allerede støttede kommunikasjonsmetoder (SMS eller DTMF) må det opprettes ny subklasse av GsmUnit som beskriver enheten. Enheten må få kommandoobjekter som beskriver hvordan enheten utfører oppgavene den støtter. I de fleste tilfeller kan de eksisterende kommandoklassene benyttes, bare med annen informasjon. For nye typer enheter som benytter nye måter å kommunisere på, må det opprettes en ny subklasse av typen Unit som beskriver enheten. Det må også opprettes en subklasse av klassen Command og kommandoobjekter for hver oppgave enheten støtter. Systemet vil automatisk opprette en ny kø som håndterer de nye kommandoobjektene. Det må implementeres QueueHandler og QueueElementHandler for den nye kommandoklassen. 13.6 Utfordringer i konstruksjonsfasen God planlegging i utdypningsfasen gav utbytte i form av få problemer i konstruksjonsfasen. Underveis i konstruksjonsfasen fikk vi flere ønsker til telefonmenyen av Cronus. Telefonmenyen vokste til å bli veldig stor, det ble derfor en utfordring å beholde brukervennligheten til menyen. Vi brukte blant annet brukertesting for å sikre at brukervennligheten var god nok etter utvidelsene. Brukertestingen er beskrevet i testrapporten. Det var litt å utfordrende få rammeverket til å ringe opp styringsenheter og sende riktig DTMFkommando til styringsenheten. Vi måtte først konfigurere Asterisk Manager API riktig for å sette opp samtalen riktig, deretter måtte vi overlate kontrollen til Fast AGI som sørger for DTMFkommunikasjonen. 30

14. Overgangsfasen Overgangsfasen. Her er normal programmering ferdig. Endringer gjøres kun for optimalisering (tuning) og for å rette feil ( ) overgangsfasen inneholder ferdigstilling av prosjektet. (Gurholt og Hasle, 2003) I overgangsfasen har vi demonstrert og gjennomgått systemet vi har utviklet for Cronus. Vi laget en brukerveiledning for telefonmenyen. Brukerveiledingen er et selvstendigdokument og inngår i sluttrapporten. Arbeidet med å ferdigstille alle prosjektdokumentene var det viktigste arbeidet i overgangsfasen. 31

15. Konklusjon Vi har laget et godt produkt som oppdragsgiver er godt fornøyd med. Vi har lagt mye vekt på fleksibilitet og utvidbarhet, noe vi har fått utbytte av ettersom prosjektet har vokst og endret seg underveis. Vi har laget en brukervennlig og god telefonmeny og et solid rammeverk. Rammeverket kan enkelt utvides til å støtte nye typer enheter, gi ny funksjonalitet og utvides med nye grensesnitt. Det har vært spennende og utfordrende å programmere en strømstyringssentral, prosjektet har krevd at vi har satt oss inn i mange nye teknologier. Vi har dratt god nytte av god planlegging og strukturert arbeid. Samarbeidet i gruppa har fungert meget godt. Vi har alle vært godt motiverte, vi har hatt en god kommunikasjon og vært flinke til å utnytte hverandres sterke sider. Disse faktorene har gjort det gøy å jobbe med prosjektet og har vært viktig for at vi har fått et resultat vi er meget godt fornøyde med. 32

16. Figurliste Figur 1. Cronus; gud for tiden..5 Figur 2. S5011 styringsenhet 6 Figur 3. Skisse over dagens løsning... 8 Figur 4. Arkitekturskisse... 9 Figur 5. Forenklet klassediagram over programstruktur... 16 Figur 6. Forenklet klassediagram over Unit-hierarkiet... 17 Figur 7. Forenklet klassediagram av kommandoobjekthierarkiet... 17 Figur 8. Prinsipielt sekvensdiagram for kommunikasjon mellom telefonmenyen og rammeverket... 18 Figur 9. Prinsipielt sekvensdiagram for addrequest... 19 Figur 10. Prinsipielt sekvensdiagram for DTMF-køhåndterer... 20 Figur 11. Kodeutsnitt fra RequestService.addToExecutionQueue... 21 Figur 12. Programflyt... 28 33

17. Litteratur Cronus.no (u.å), Cronus Engineering URL: http://www.cronus.no/?sub=12&view=artikkel (16.01.07) Gurholt, Gunnar og Thor E. Hasle (2003): Grunnleggende systemutvikling Oslo: Cappelen Iu.hio.no (u.å.): Forprosjekt http://www.iu.hio.no/~ulfu/hovedprosjekt/student/forprosjekt.html (05.03.07) 34

18. Vedlegg Vedlegg 1 Vedlegg 2 Vedlegg 3 Vedlegg 4 Vedlegg 5 Vedlegg 7 Arbeidsplan Arbeidsdiagram Fremdriftsplan Brukstilfelle Samarbeidsavtale Risikoanalyse 35