Hovedprosjekt våren 2007

Transkript

1 Hovedprosjekt våren 2007 Bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo Dokument Produktdokumentasjon Prosjekttittel: Telepower Prosjektnummer: 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: Veileder: Eva Hadler Vihovde 1

2 1. Forord Produktdokumentasjonen beskriver systemet vi har utviklet i hovedprosjektet Telepower. Hovedprosjektet er avsluttende prosjekt for bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo. Informasjon om prosessen som førte frem til systemet finnes i prosessrapporten. Dokumentet er beregnet på vår oppdragsgiver Cronus Engineering AS som skal vedlikeholde og videreutvikle systemet og andre som måtte ha interesse av å sette seg inn i Telepower. Vi forutsetter at leseren har generelle datakunnskaper og har god kjennskap til Java og objektorientert systemutvikling. På prosjektets nettside finnes kildekoden og Javadokumentasjonen som gir detaljert informasjon om alle klasser og metoder. Faguttrykk og forkortelser er beskrevet i dataordboken. Sensor anbefales å lese prosessrapporten før dette dokumentet. 2

3 2. Innholdsfortegnelse 1. Forord Innholdsfortegnelse Innledning Produktet Styringsenhetene S MS Teknologier og verktøy Asterisk Maven Oppsett og konfigurasjon Kjøring av programmet Arkitektur Styringsenhet (unit) Kommando (command) Forespørsel (unitrequest) Køsystemet Grensesnitt Hovedklasse - UnitRequestService Data Aksess Objekter (DAO) Scheduler Application og Main Utils Log.java SmsSender.java Sekvensdiagrammer Programkonfigurasjon Feilhåndteringsinnstillinger SMS-innstillinger Manager API innstillinger Oppbygging No.cronus.telepower

4 11.2 No.cronus.telepower.dao No.cronus.telepower.model No.cronus.telepower.handlers No.cronus.telepower.utils Telefonmenyen Funksjonalitet Implementasjon Utvidelsesmuligheter Samsvar mellom kravspesifikasjon og produkt Figurliste Tabelliste Litteratur

5 3. Innledning Vi har laget et rammeverk til en strømstyringssentral og en telefonmeny som et brukergrensesnitt til sentralen. Se figur 1 for en oversikt over arkitekturen. Telefon- nettet Asterisk server FAST AGI PhoneMenu.java Manager GSM- API Rammeverket nettet Styringsenhet S5011 Figur 1. Arkitekturskisse 4. Produktet Vi har laget et rammeverk for en GSM/GPRS/SMS strømstyringssentral. Som planlagt ble ikke systemet vårt satt i drift ved prosjektets utløp, men er grunnlaget for videreutvikling av det nye Telepowersystemet. Strømstyringssentralen benyttes til å kontakte og kontrollere ulike strømstyringsenheter. Strømstyringsenhetene vi har implementert støtte for, har en temperatursensor og et relé som for eksempel kan benyttes til å skru av eller på varme eller belysning. Vi har utviklet et rammeverk for å implementere funksjoner og tjenester til strømstyringssentralen. 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 henholdsvis med SMS og tonesignalering (DTMF). Vi implementerte følgende funksjonalitet for S5011 (en DTMF styringsenhet) og SMS5011 (en SMS styringsenhet). 5

6 S5011 Skru av eller på releet på styringsenheten Lese av temperatur på enheten Hente ut relé status Tabell 1. Funksjonsoversikt SMS5011 Skru av eller på releet på styringsenheten Det vil være enkelt å implementere støtte for nye typer styringsenheter som bruker annen kommunikasjonsteknologi og/eller gir ny funksjonalitet. Vi har laget en telefonmeny som er et grensesnitt til rammeverket. Rammeverket kan enkelt bygges ut til å støtte flere typer grensesnitt som for eksempel PDA-, applikasjons- og webgrensesnitt. Rammeverket tar i mot en forespørsel fra et grensesnitt 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. Vi har laget rammeverket slik at det skal være enkelt å lage nye grensesnitt til det. Vi har implementert et telefonmenygrensesnitt. Cronus har planer om å senere implementere både web- og applikasjonsgrensesnitt til systemet. Alle forespørsler systemet mottar loggføres. 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 utviklet en køhåndterer for SMS-styringsenheter. Køhåndtereren henter oppgaver fra SMS-køen og sender SMS til riktig styringsenhet med forespurt oppgave. Styringsenheten sender en tilbakemelding som loggføres og formidles til kunden. 6

7 5. Styringsenhetene Vi har laget støtte for to typer styringsenheter. S5011 som styres med tonesignalering (DTMF) og SMS5011 som styres med SMS-meldinger. 5.1 S5011 Denne enheten er den som er i bruk hos dagens brukere av hyttevarmetjenesten. S5011 enheten har en innebygd GSM modul og fungerer på samme måte som en mobiltelefon. Enheten har en temperaturføler og et relé som for eksempel brukes til å skru av eller på varme og belysning. Cronus har komplett dokumentasjon for S5011, nedenfor beskriver vi nødvendig kommunikasjon for de funksjoner som er støttet av systemet vårt. Figur 2. S5011 styringsenhet All kommunikasjon mellom sentral og enhet skjer med DTMF-signalering. 1. enheten ringes opp 2. enheten svarer med å sende tonen D når den har mottatt samtalen 3. systemet sender enhetens pinkode 4. hvis pinkoden er korrekt, svarer enheten med å sende tonen D som bekreftelse 5. DTMF-kommandoen som skal utføres, sendes til enheten a. 21 sendes for å skru på enheten b. 20 sendes for å skru av enheten c. 1 sendes for å be om status 6. enheten sender tonen D for å bekrefte at den er blitt skrudd av eller på 7. hvis status er forespurt, svarer enheten med å sende statuskoder 8. statuskoden som mottas er 12 tegn, det siste representerer en 4 bits CRC-kode 9. statuskodene dekodes i henhold til enhetens spesifikasjoner. Spesifikasjonene er vedlagt som nummer 6. 7

8 5.2 MS5011 SMS5011 enheten har to releer og en temperturføler, den kan bygges ut med ytterlige 3 releer. Den kontrolleres med spesielt formaterte SMS-meldinger. SMS som sendes til enheten bygges opp slik: <pinkode> R<relénummer><relestatus (binært)> For eksempel: 1234 R11 for å skru på relé R10 for å skru av relé 1 Figur 3. SMS5011 styringsenhet 6. Teknologier og verktøy Systemet er utviklet i Java og bygget med Maven 2. Vi har benyttet Eclipse som utviklingsverktøy, Asterisk som telefonisystem, Subversion som versjonskontrollsystem og Subclipse som subversionklient. 6.1 Asterisk Asterisk is the most popular and extensible open source telephone system in the world, offering flexibility, functionality and features not available in advanced, high-end (high-cost) proprietary business systems. (asterisk.org, u.å.) Asterisk er en hustelefonsentral. Hovedoppgaven til en hustelefonsentral er å koordinere forbindelsen mellom ulike telefonapparater i et internt telefoninettverk og ut mot det offentlige telefonnettet (Wikipedia\hustelefonsentral, u.å.). Brukeren kan også lage egen funksjonalitet med å skrive dial plan script i Asterisk sitt eget språk, legge til egne moduler skrevet i C eller med å skrive Asterisk Gateway Interface (AGI) script i Perl eller andre programmeringsspråk (Wikipedia\Asterisk, u.å) Vi har skrevet telefonmenyen i Java som et AGI script. Vi benytter oss av Manager API for å sette opp samtaler til styringsenhetene, samtalen kobles videre til et AGI script som sørger for riktig DTMF-kommunikasjon. 8

9 6.2 Maven 2 Maven gir en omfattende utviklingsinfrastruktur (kompilering, testing, rapportering samarbeid og dokumentasjon fra en enkel beskrivelse av et Javaprosjekt, det er en enkel måte å bygge et prosjekt uten å måtte lage et byggesystem.(massol & O Brien, 2005) Vi har benyttet Maven 2 til å konfigurere avhengigheter og å bygge prosjektet vårt. 7. Oppsett og konfigurasjon Systemet baserer seg på en del infrastruktur som Cronus allerede har satt opp og kan derfor kun kjøres internt hos Cronus. Blant infrastrukturen vi dro nytte av i dette prosjektet var en Asteriskserver (se kapittel 8.1) og en SMS-server. Asteriskserveren blir brukt både til å motta innringninger til telefonmenyen og til å ringe ut til styringsenhetene. Asteriskserveren måtte konfigureres til å koble opp samtaler til riktige script. Systemet trenger to ulike script, et til telefonmenyen og et til kommunikasjon mot DTMF-enheter. Det konfigureres slik i konfigurasjonsfilen: /etc/asterisk/extensions.conf exten => 5500,1,Agi(agi://<hostname>/asterisktest.agi) #telefonmeny exten => 5503,1,Agi(agi://<hostname>/dtmfcaller.agi) #DTMF-kommunikasjon Koblingene mellom scriptnavnene og Javaklassene gjøres i Application.java som vist i figur 4. /*Sets up AGI scripts for Astrisk*/ MyMappingStrategy scripts = new MyMappingStrategy(); PhoneMenu phonemenu = new PhoneMenu(); phonemenu.setrequestservice( requestservice ); scripts.addscript( "asterisktest.agi", phonemenu ); DtmfCaller dtmf = new DtmfCaller(); dtmf.setunitrequestservice( unitrequestservice ); scripts.addscript( "dtmfcaller.agi", dtmf ); startagiserver( scripts ); Figur 4. Kodeutsnitt Application.java 9

10 Vi benytter oss av Cronus sin SMS-server. For å sende en SMS-melding må det lages en spesielt formatert tekstfil på serverens filområde. Derfor må filområdet til SMS-serveren angis. Det settes i Application.java. 7.1 Kjøring av programmet Programmet startes med å kjøre Main.java som ligger i no.cronus.telepower pakken. Hvis en skal videreutvikle eller kjøre programmet på en annen datamaskin må følgende utføres: Vi forutsetter at Eclipse og Maven 2 er installert. 1. kildekode og maven konfigurasjonsfilen (pom.xml) må lastes ned fra subversion serveren ( 2. opprett Eclipseprosjekt med å kjøre maven kommandoen:mvn eclipse:eclipse 3. Asterisk konfigurasjonsfilen: extensions.conf må oppdateres slik at hostname peker på maskinen hvor systemet skal kjøres. 4. programmet startes med å kjøre Main.java 10

11 8. Arkitektur En forespørsel opprettes Phonemenu Webgrensesnitt håndterer Applikasjonsgrensesnitt Framtidige utvidelser Rammeverket Grensesnitt Hvis opppgaven skal utføres umiddelbart legges den rett i kø Forespørsler lagres alltid i datalageret 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 5. Programflyt Figur 5. illustrerer flyten i programmet. Systemet er bygd opp rundt 3 objekter: en styringsenhet (unit), en kommando (command) og en forespørsel (unitrequest). En enhet har 11

12 kommandoobjekter for alle funksjoner den støtter. Kommandoobjektene beskriver hvordan en funksjon skal utføres. Når en oppgave skal utføres 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 dataaksessobjektet (UnitRequestDAO). Hvis oppgaven skal utføres umiddelbart legges den i riktig kø, basert på det 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ø. Køsystemet er bygd opp rundt en hashtabell (queues) med separate køer som utføres på forskjellig måte (SMS/DTMF). For hver kø er det en køhåndterer (QueueHandler) og hver køhåndterer har en køelementhåndterer. Køhåndtereren henter ut forespørselsobjekter fra riktig kø og sender den til køelementhåndtereren som utfører forespørselen. Se figur 6. 12

13 Figur 6. Forenklet klassediagram over programstrukturen Figur 6. Forenklet klassediagram over programstrukturen 13

14 8.1 Styringsenhet (unit) Styringsenheter blir definert i unitklassen. Ettersom ulike styringsenheter har ulike egenskaper, beskrives de som subklasser av superklassen Unit. I systemet har vi definert to typer styringsenheter i form av klassen S5011 og SMS5011. For å støtte en ny type styringsenhet, må det opprettes en subklasse av Unit som beskriver den. Se figur 7. Figur 7. Klassediagram, Unit GSM-unitobjektene har tre viktige metoder, getturnoncommand(), getturnoffcommand() og getstatuscommand(). De har forskjellige implementasjoner for hver enhetstype og de returnerer et kommandoobjekt som beskriver hvordan oppgaven utføres på gjeldene enhetstype. 14

15 8.2 Kommando (command) Hvordan en oppgave utføres blir beskrevet som et kommandoobjekt. Enkelte oppgaver utføres på svært ulik måte, derfor har vi et hierarki av subklasser som beskriver de ulike oppgavene. Ved innføring av en ny enhet må det opprettes kommandoobjekter for hver oppgave enheten støtter, se figur 8. Figur 8. Klassediagram, Command SMS-kommandoobjektene inneholder en tekststreng som er kommandoen som må sendes til SMS-styringsenheten for å utføre oppgaven. 15

16 DTMF-kommandoobjektene har forskjellige implementasjoner av metoden execute som sørger for nødvendig kommunikasjon med DTMF-enheten for å utføre oppgaven. 8.3 Forespørsel (unitrequest) Forespørselsobjektet representerer en forespørsel om å utføre en oppgave på en enhet, se figur 9. Den inneholder blant annet referanse til riktig unitobjekt, riktig kommandoobjekt, dato og tid oppgaven skal utføres og status til forespørselen beskrevet som en status enum, se tabell 2. Enum name Bekskrivelse INVALID Ugyldig forespørsel IN_QUEUE Er i kø for utføring PROCESSING Under utføring SUCCESSFUL Er vellykket utført FAILED Har overskredet maks antall forsøk WAITING Skal utføres på et framtidig tidspunkt CANCELLED Har blitt kansellert av bruker Tabell 2. Status Enum Figur 9. Klassediagram, UnitRequest 8.4 Køsystemet Køsystemet er bygd opp rundt en hashtabell (queues) med separate køer for oppgaver som utføres på forskjellig måter (SMS/DTMF) som illustrert i tabell 3. Hvis det opprettes ny klasse av kommandoobjekter opprettes det automatisk en ny kø i queues som vist i figur 10. Køene er implementert med LinkedBlockingQueue fordi den er thread-safe og den har metoden take som venter på innhold i køen, hvis køen er tom. Nøkkel Verdi SmsCommand SmsQueue{ } DtmfCommand DtmfQueue{ } Tabell 3. Illustrasjon over queues hashtabell 16

17 /*gets the class of the command object associated with the unitrequest */ Class commandclass = unitrequest.getcommand().getsuperclass(); /* if there are 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 10. Kodeutsnitt fra metoden addtoexecutionqueue i UnitRequestService.java Hver kø trenger en køhåndterer som henter ut et element fra riktig kø. Køhåndtererne er definert i QueueHandler.java. Det som skiller de ulike køhåndtererne fra hverandre er hvilken type køelementhåndterer de implementerer. Et kodeutsnitt av køhåndtererklassen finnes i figur 11. og et forenklet klassediagram over programstrukturen med køsystemet finnes i figur 6. Køelementhåndtereren utfører den forespørselen den mottar fra sin køhåndterer. Køelementhåndtererne er definert i interfacet QueueElementHandler.java. Vi har to implementasjoner av køelementhåndtererinterfacet, DtmfQueueElementHandler.java og SmsQueueElementHandler.java. SMS-køelementhåndtereren sender en kommando til styringsenheten med en tekstmelding. Innholdet i tekstmeldingen er beskrevet i variabelen commandstring i SMS- Commandobjektet som forespørselsobjektet referer til. DTMF-køelementhåndtereren bruker Manager API-et til å ringe opp styringsenheten. Når samtalen er satt opp, settes samtalen over til AGI scriptet DtmfCaller.java. DtmfCaller-en kaller på execute metoden til DTMF-Commandobjektet. Execute metoden sørger for nødvendig kommunikasjon med enheten for å utføre den ønskede oppgaven. 17

18 public class QueueHandler implements Runnable { private QueueElementHandler handler; < > public void run() { while (true) { Log.debug( "attempts to get request from queue the " + handler.getsupportedcommandtype() + " queue" ); /*Gets the request from the queue, that contains requests of the type the queueelementhandler supports */ UnitRequest request = unitrequestservice.takerequestfromqueue(handler.getsupportedcommandtype()); try { Log.debug( "got request from queue the "+ handler.getsupportedcommandtype() + " queue"); /*set the request status to processing */ unitrequestservice.reportprocessing( request ); /*Send the request to the queueelementhandler for execution */ handler.handlerequest( request.getunit(), request.getcommand(), request.getunitrequestid()); } catch (Exception e) { /* unitrequest could not execute*/ unitrequestservice.reportfailure(request, e); } } < > } Figur 11. Kodeutsnitt fra QueueHandler.java 18

19 8.5 Grensesnitt For at det skal være enkelt å utvide med nye grensesnitt til systemet er det definert et interface RequestService. Interfacet beskriver de metoder som et grensesnitt må implementere. Vi har laget en implementasjon av RequestService, RequestServicePhoneInterface som er den klassen som blir implementert som grensesnitt mellom rammeverket og telefonmenyen. Se figur 12. Figur 12. Klassediagram RequestService 19

20 8.6 Hovedklasse - UnitRequestService Dette er hovedklassen hvor det meste av logikken ligger. De andre klassene kaller i stor grad på metoder fra denne klassen. Eksempelvis kaller grensesnittet på metoder her for å legge til en forespørsel i køen, kansellere en forespørsel eller hente status til en forespørsel. Et annet eksempel er klassene som utfører en forespørsel kaller på metoder her for å oppdatere forespørselens status. Se figur 13. Figur 13. Klassediagram UnitRequestService 20

21 8.7 Data Aksess Objekter (DAO) Vi benytter Data Aksess Objekter for å lagre informasjon om enheter (Unit) og forespørsler (UnitRequest). Data Aksess Objekter er et J2EE design pattern og betraktes som best practice (Wikipedia\ Data Access Object, u.å.). Vi har definert Data Aksess Objekter for Unit og UnitRequest. Disse er definert i interfacene unitdao og unitrequestdao. For å teste systemet har vi implementert disse DAO-ene med en ArrayList i klassene UnitDaoMem og UnitRequestDaoMem. Før systemet skal settes ut i drift må DAO-ene gjøres persistente. Det kan enkelt gjøres med å lage ny implementasjon av unitdao og unitrequestdao som benytter en database. Se figur 14. Figur 14. Klassediagram UnitRequestDao og UnitDao 8.8 Scheduler Vi har en schedulerklasse med en runmetode som kjøres hvert sekund av en Timer. Runmetoden sjekker UnitRequestDao for forespørsler som skal utføres på nåværende tidspunkt og legger de til i kø for utføring. 8.9 Application og Main Programmet startes med klassen Main som inneholder en mainmetode. Mainmetoden oppretter objektet application og kaller dens initmetode. Initmetoden oppretter de nødvendige objekter og kobler disse sammen. Programkonfigurasjonen settes her, se kapittel Utils I pakken utils har vi verktøy som vi benytter i programmet vårt: verktøy for loggføring, sending av SMS og opplesing av lydfiler. 21

22 Log.java Log.java er et verktøy for logging. Log skriver ut informasjon om hva som skjer i programmet til standard output. Hvor detaljert informasjon loggverktøyet skriver ut er avhengig av hvilket loggnivå som er satt. Det finnes tre loggnivåer: debug, info og error SmsSender.java SmsSender er et verktøy for sending av SMS-meldinger ved hjelp av SMS-serveren som Cronus har. Metoden sendsms tar i mot en tekst og et mobilnummer og genererer en tekstfil på et format som er forståelig for SMS-serveren. Metoden venter til SMS-meldingen er sendt før den returnerer. Tekstfilen må ha følgende format: [SMS] From=<fra nummer> To=<til nummer> Text=<tekst som skal sendes> 22

23 9. Sekvensdiagrammer Noen av de viktigste funksjonene i rammeverket blir beskrevet med de prinsipielle sekvensdiagrammene nedenfor. Figur 15. Prinsipielt sekvensdiagram for addrequest 23

24 Figur 16. Prinsipielt sekvensdiagram for DTMF-køhåndterer 24

25 10. Programkonfigurasjon De ulike innstillinger som kan gjøres i programmet vårt er samlet i Application.java Feilhåndteringsinnstillinger Navn Beskrivelse Nåverdi Metodekall MaxAttempt WaitTime Antall ganger en forespørsel skal forsøkes utført Antall minutter systemet skal vente før det forsøker å utføre en forespørsel på nytt 2 unitrequestservice. setmaxattempt 2 unitrequestservice. setwaittime Tabell 4. Feilhåndteringsinnstillinger 10.2 SMS-innstillinger Navn Beskrivelse Nåverdi Metodekall Path Filstien til området hvor tekstfiler til z:/ smssender.setpath SMS-serveren skal lagres NB. - bruk forwardslash for å skille mellom mapper og ikke backslash - filstien må avsluttes med forwardslash FromNumber Telefonnummeret som skal stå som avsendernummer på SMS sendt fra systemet smssender.setfromnumber Tabell 5. SMS-innstillinger 25

26 10.3 Manager API innstillinger Navn Beskrivelse Nåverdi Metodekall HostName Hostname til Asteriskserveren xxx dtmfhandler. setmanagerhostname ManagerUsername Brukernavn for pålogging til Asteriskserveren xxx dtmfhandler. setmanagerusername ManagerPassword Passord for pålogging til Asterisk serveren xxx dtmfhandler. setmanagerpassword ChannelPrefix Kanalprefiks "SIP/callmanager1 /0" dtmfhandler. setchannelprefix Context Context "default" dtmfhandler.setcontext Exten Telefonnummeret til 5503 dtmfhandler.setexten DTMF-caller Priority Prioritet 1 dtmfhandler.setpriority Timeout Hvor mange millisekunder manager API skal vente på svar 30000L settimeout Tabell 6. Manager API innstillinger 26

27 11. Oppbygging Vi har delt opp programmet i flere forskjellige pakker som er beskrevet nedenfor. Pakkenavn Kort beskrivelse no.cronus.telepower no.cronus.telepower.dao no.cronus.telepower.model Annet Data Aksess Objektene Modellaget no.cronus.telepower.handlers Køhåndterere no.cronus.telepower.utils Tabell 7. Oversikt over pakker Verktøy 11.1 No.cronus.telepower Klassenavn Beskrivelse Application.java Oppretter nødvendige objekter og kobler disse sammen Sørger for kommunikasjon mellom rammeverk og DTMF- DtmfCaller.java enheter Main.java Inneholder mainmetoden, starter hele programmet MyMappingStrategy.java Kobling (mapping) av AGI-script PhoneMenu.java Telefonmenyen Interface som beskriver nødvendige metoder for et RequestService.java grensesnitt RequestServicePhoneInteface.java Rammeverkets grensesnitt til telefonmenyen Scheduleren som sjekker datalageret for oppgaver som skal Scheduler.java utføres Status.java Status Enum Tester.java Klasse for oppretting av testdata UnitRequestService.java Hovedklassen med det meste av logikken Tabell 8. no.cronus.telepower pakken 11.2 No.cronus.telepower.dao Klasse navn UnitDao.java UnitDaoMem.java UnitRequestDao.java UnitRequestDaoMem.java Tabell 9. no.cronus.telepower.dao Beskrivelse Interface som beskiver data aksess objektet for Units Implementasjon av UnitDao med Arraylist Interface som beskriver Data aksess objektet for UnitRequests Implementasjon av unitrequestdao med Arraylist 27

28 11.3 No.cronus.telepower.model Klassenavn Command.java DtmfCommand.java DtmfSwitchCommand.java S5011StatusCommand.java S5011TurnOffCommand.java S5011TurnOnCommand.java SmsCommand.java Unit.java GsmUnit.java SMS5011.java S5011.java UnitStatus.java StatusS5011.java UnitRequest.java Tabell 10. no.cronus.telepower.model Beskrivelse Superklassen, beskriver hvordan en oppgave skal utføres Subklasse av Command for DTMFoppgaver Subklasse av DtmfCommand, felles for skru av og på enheter Subklasse av DtmfCommand, henter status Subklasse av DtmfSwitchCommand, skru av enhet Subklasse av DtmfSwitchCommand, skru på enhet Subklasse av Command for SMS-oppgaver Superklassen, beskriver en enhet Subklasse av Unit, beskriver GSM-enheter Subklasse av GsmUnit, beskriver en SMS5011 enhet Subklasse av GsmUnit, beskriver en S5011 enhet Superklasse, beskriver status på en enhet Subklasse av UnitStatus, beskriver en S5011 status Forespørselsobjektet 11.4 No.cronus.telepower.handlers Klassenavn Beskrivelse QueueHandler.java Køhåndterer QueueElementHandler.java Køelementhåndterer, interface DtmfElementHandler.java DTMF-køelementhåndterer SmsElementHandler.java SMS-køelementåndterer Tabell 11. no.cronus.telepower.handlers 11.5 No.cronus.telepower.utils Klassenavn Log.java SmsSender.java SoundEngine.java Tabell 12. no.cronus.telepower.utils Beskrivelse Loggverktøy SMS-sender Samling av lydavspillingsmetoder for telefonmenyen 28

29 12. Telefonmenyen Telefonmenyen det grensesnittet til rammeverket vi har implementert. Det er utarbeidet en brukerveiledning. Brukerveiledningen gir en god oversikt over telefonmenyen og det anbefales å lese den først, for å få en god oversikt. Telefonmenyen er dynamisk og gir ulike valg avhengig av hvilke funksjoner valgt enhet støtter Funksjonalitet - en kan velge en styringsenhet med enhetsnummer - en blir presentert med ulike valg basert på hvilke funksjoner som støttes av enheten - oppgavene skru av eller på enhet kan enten utføres umiddelbart eller planlegges for utføring på et framtidig tidspunkt - hvis oppgaven skal utføres umiddelbart, kan en velge å høre oppgavens progresjon over telefon eller velge å få tilsendt en SMS-melding når oppgaven har blitt fullført - det er mulig å få opplest alle planlagte oppgaver på en enhet - det er mulig å kansellere en planlagt oppgave på en enhet (så framt den ikke allerede er påbegynt) 29

30 12.2 Implementasjon Telefonmenyen er 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. Klassen SoundEngine innholder generelle metoder for å blant annet lese opp siffer, tall, ordenstall, dato, tidspunkt og temperatur. SoundEngine har også en egen implementasjon av Fast AGI metoden getdata som mottar tastetrykk fra kundens telefon. Implementasjonen har følgende tilpasninger - kaster en feil hvis ikke lydfilen finnes - konverterer til integer og tar høyde for unntakssituasjoner for konverteringen - sjekker at forventet antall siffer er tastet Figur 17. gir oversikt over SoundEngine sine metoder. Figur 17. Klassediagram SoundEngine 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 30

31 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 Utvidelsesmuligheter Det er enkelt å legge til nye brukergrensesnitt, nye typer enheter som enten benytter støttede kommunikasjonsmetoder eller som benytter nye måter å kommunisere på. Det er også lagt opp til at det skal være enkelt å endre måten data lagres på. Et nytt grensesnitt må implementere metodene beskrevet i interfacet requestservice. 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. 31

32 14. Samsvar mellom kravspesifikasjon og produkt Vi har kjørt flere typer tester på systemet, blant disse var en systemtest hvor vi testet systemet vi har utviklet opp mot de funksjonelle kravene gitt i kravspesifikasjonen. Som det går fram av kapittel 5 i testrapporten er alle funksjonelle krav oppfylt. I kravspesifikasjonen er følgende ikke-funksjonelle krav gitt: Krav Vår vurdering i henhold til krav Telefonmenyen skal være brukervennlig. Brukervennligheten er god. Vi fikk gode tilbakemeldinger på den under brukertestingen, svakheter som ble avdekket under brukertestingen er utbedret, se kapittel 6 i testrapporten. Det skal være enkelt å støtte nye Arkitekturen med bruk av ulike subklasser av styringsenheter som: enheter og kommandoobjektet gjør det enkelt - bruker annen kommunikasjonsteknologi å lage støtte for nye enheter, se kapittel gir ny funksjonalitet Det skal være enkelt å endre måten data Det kan enkelt oppnås med å lage nye lagres på. implementasjoner av Data Aksess Objektene, se kapittel 10.8 Det skal være enkelt å legge til nye Lagvis arkitektur og interfacet grensesnitt til rammeverket RequestService som beskriver de nødvendige metoder et grensesnitt må implementer gjør det enkelt å legge til nye grensesnitt, se kapittel 14.1 Innstillinger skal settes et sentralt sted Programmets innstillinger settes i application.java, se kapittel 11. Tabell 13. Ikke funksjonelle krav Vi har brukt teknologiene som var gitt til oss som rammebetingelser og utviklet et system som oppfyller de funksjonelle og ikke-funksjonelle krav gitt i kravspesifikasjonen. 32

33 15. Figurliste Figur 1. Arkitekturskisse.. 5 Figur 2. S5011 styringsenhet 7 Figur 3. SMS5011 styringsenhet 8 Figur 4. Kodeutsnitt Application.java 9 Figur 5. Programflyt.. 11 Figur 6. Forenklet klassediagram over programstrukturen 13 Figur 7. Klassediagram, Unit. 14 Figur 8. Klassediagram, Command 15 Figur 9. Klassediagram, UnitRequest Figur 10. Kodeutsnitt fra metoden addtoexecutionqueue i UnitRequestService.java.. 17 Figur 11. Kodeutsnitt fra QueueHandler.java. 18 Figur 12. Klasediagram RequestService.. 19 Figur 13. Klassediagram UnitRequestService. 20 Figur 14. Klassediagram UnitRequestDao og UnitDao.. 21 Figur 15. Prinsipielt sekvensdiagram for addrequest. 23 Figur 16. Prinsipielt sekvensdiagram for DTMF-køhåndterer. 24 Figur 17. Klassediagram SoundEngine Tabelliste Tabell 1 Funksjonsoversikt 6 Tabell 2 Status Enum 16 Tabell 3 Illustrasjon over Queues hashtabell 16 Tabell 4 Feilhåndteringsinnstillinger Tabell 5 SMS-innstillinger 25 Tabell 6 Manager API innstillinger 26 Tabell 7 Oversikt over pakker 27 Tabell 8 no.cronus.telepower pakken 27 Tabell 9 no.cronus.telepower.dao. 27 Tabell 10 no.cronus.telepower.model. 28 Tabell 11 no.cronus.telepower.handlers 28 Tabell 12 no.cronus.telepower.utils 28 Tabell 13 Ikke funksjonelle krav 32 33

34 17. Litteratur Massol, Vincent, Timothy O Brien (2005) Maven a developer s notebook. Sabastopol: O Reilly. Asterisk.org (u.å) Asterisk URL: ( ) Wikipedia.no (u.å.) Hustelefonsentral. URL: ( ) Wikipeida.org (u.å) Data Access Objects (DAO). URL: ( ) Wikipeida.org (u.å) Asterisk (PBX). URL: ( ) 34

35 18. Vedlegg Vedlegg 6 Dokumentasjon S