Udvikling af IT-system til TEK-BrobygningsCenter - Semesterprojekt 2009

Transkript

1 SDU - Det Teknisk Fakultet Projektgruppe 4 DT-SIP4-U1 Vejleder: Marius Vestergaard Projektperiode: 11. februar maj 2009 Udvikling af IT-system til TEK-BrobygningsCenter - Semesterprojekt 2009 Udarbejdet af projektgruppen Agge Skov Larsen Alexey Bessonov Frantz Furrer Jakob Witte Larsen Synopsis Denne rapport beskriver udviklingen af et IT-system til styring af eksperimenter i TEK- BrobygningsCenter. Rapporten er produktet af et projektarbejde, hvor der anvendes Unified Process og SCRUM til udvikling og strukturering af IT-systemet. Implementeringen af IT-systemet er udført i Java. I rapportens resultatdel vil der blive opstillet funktionelle og ikke funktionelle krav, udarbejdet brugsmønsterbeskrivelser, tegnet analyseklassediagram og analysesekvensdiagrammer, designklassediagram og designsekvensdiagrammer. Derudover vil der på baggrund af kravene til IT-systemet blive udvalgt den bedst egnede softwarearkitektur og distribuering af IT-systemet. Derefter vil der være en beskrivelse af anvendte datakommunikationsløsninger, samt beskrivelse af de vigtigste dele af det implementerede system. Afslutningsvis beskrives anvendte statistiske metoder til analyse af fremtidige forbedringer af systemet. Det er vist gennem bearbejdning af centrale brugsmønstre at det er muligt at udarbejde en distribueret risikofri systemprototype med begrundet arkitektur. På baggrund af dokumentationen, vil der sidst i rapporten være en beskrivelse af hvordan det videre udviklingsforløb vil blive tilrettelagt.

2 Agge Skov Larsen Alexey Bessonov Frantz Furrer Jakob Witte Larsen

3 Forord Denne rapport beskriver et softwareprojekt udviklet for TEK-BrobygningsCenter 1 af fire studerende på 4. semester datateknologi. Der er gennem hele projektperioden lagt meget tid og arbejde i projektet, for at opnå et tilfredsstillende resultat. Dette kunne ikke have været opnået hvis projektgruppen ikke havde haft motivationen og inspirationen, som det har været at arbejde med et softwareprojekt som skal munde ud i en løsning, der skal tages i brug i den virkelige verden. Rapporten henvender sig primært til studerende og ingeniører med samme faglige kompetencer som projektgruppen. Desuden henvender dele af rapporten sig til TEK-BrobygningsCenter, samt til projektgruppen selv, der har fået til opgave at videreudvikle systemet og dermed har brug for dokumentation af det arbejde der er foretaget på nuværende tidspunkt. Idéen til projektet opstod da TEK-BrobygningsCenter var i gang med en fornyelse af centerets eksperimenter. Der var i den forbindelse nedsat et udvalg bestående af undervisere fra institutterne på Det Tekniske Fakultet, som skulle generere idéer til udvidelsen af centeret. Det var vigtigt for BrobygningsCenteret, at det var studerende fra Det Tekniske Fakultet der selv udviklede det nye produkt, og at der ikke blot blev købt en færdigbygget løsning. Ved at lade studerende udarbejde produktet sikredes en afspejling af hvordan der arbejdes på fakultetet, og det var samtidig muligt at illustrere de studerendes faglige niveau efter de første semestre. Dette vil give de besøgende et bedre indblik i arbejdet som ingeniørstuderende, samt hvilke kompetencer man udvikler som studerende efter forholdsvis kort tid på studiet. Udvalget fandt frem til at Jan Petersens 2 forslag om at udvikle en Håndtryksmåler var en oplagt mulighed for at opnå TEK-BrobygningsCenters mål og der blev derfor udarbejdet et projektoplæg 3, som beskrev de indledende forestillinger om projektet. Projektgruppen blev herefter kontaktet af Jan Petersen og tilbudt at udvikle produktet, da dele af Håndtryksmåleren indeholdt faglige elementer som gruppen havde studeret på 2. semester. Projektgruppen takkede ja til tilbuddet, da projektet var en oplagt chance for at forbedre måden som ingeniøruddannelserne bliver præsenteret på. Gruppen blev herefter ansat til at udvikle Håndtryksmåleren ud fra det oprindelige projektoplæg, som i første omgang beskrev en hardwareenhed med en mekanisk hånd og et tilkoblet SMS-modul. Efter at have arbejdet med Håndtryksmåleren i en periode opstod idéen om at udvide det oprindelige projektoplæg 4, til at indbefatte en softwaredel som øgede interaktiviteten med produktet. Hermed blev der også inddraget fagligheder fra 3. og 4. semester, og en del af det samlede produkt kunne dermed indgå som dette semesterprojekt. Under projektforløbet har der hele tiden været et meget tæt samarbejde med TEK- BrobygningsCenter, den tekniske vejleder Jan Petersen og Finn Godik Bormlund som har stået for udformning og konstruktion af den mekaniske hånd til Håndtryksmåleren. Der ønskes at give en stort tak til afdelingsleder Bo T. Andersen, Randi Hærup Poser og Mads Gorm Larsen fra TEK-BrobygningsCenter for godt samarbejde, Finn Godik Bormlund for udformning af hånd, semesterprojektvejleder Marius Vestergaard for god vejledning, semesterkoordinator Lone Borgersen for feedback på spørgsmål i forbindelse med softwarearkitekturen og Claus Vaarning for vejledning i forbindelse med statistiske overvejelser. Afslutningsvis ønskes det at takke Jan Petersen for at tilbyde projektgruppen at stå for dette projekt, for den vejledning der er i givet i forbindelse med udformningen af hardwaredelen af produktet, samt den altid konstruktive feedback på tilsendt materiale. 1 TEK-BrobygningsCenter er en afdeling på Det Tekniske Fakultet, Syddansk Universitet, der stå for præsentation af de forskellige ingeniøruddannelser. De arrangerer blandt andet rundvisninger for skoleklasser i BrobygningsCenteret, som indeholder en række fysiske eksperimenter. En nærmere beskrivelse af kunden følger i afsnit Lektor, Institut for Sensorer, Signaler og Elektroteknik og semesterkoordinator for 1. og 2. semester datateknologi 3 Det oprindelige projektoplæg for håndtryksmåleren forefindes på den medfølgende cd. 4 Det endelige projektoplæg for Håndtryksmåleren, som indbefatter dette semesterprojekt, er vedlagt som bilag 1. Side I af IV

4 Læsevejledning Læsevejledningen indeholder en beskrivelse af strukturen af rapporten, de forkortelser og angivelser der anvendes undervejs. Herudover er angivet en oversigt over den medfølgende cd s indhold. Herunder følger en beskrivelse af anvendte angivelser og henvisninger i rapporten: - Rapporten er inddelt i 3 dele: prolog, resultater og epilog, som er adskilt af en blank side. - Rapporten er under hver del inddelt i kapitler på formen 1,2,, afsnit på formen 1.1, samt underafsnit på formen Til hvert kapitel og afsnit vil der være en indledning. - Fodnotehenvisninger er et tal med hævet skrift, eksempelvis: 1, og bliver brugt til kildehenvisning eller en uddybende kommentarer. - Kildehenvisningen skrives som Kilde #1 - Side #2, hvor #1 er nummeret på kilden i litteraturlisten og #2 er siden i kilden. Eksempelvis: Kilde 1 - Side 377 betyder UML 2 and the Unified Process: Practical Object- Oriented Analysis and Design side Figur-, tabel-, diagram- og kildekodetekst er på formen, Figur x.y, hvor x er kapitlet og y er en figurnummer i kapitlet. - Der benyttes engelske betegnelser i design og kildekoden (for at undgå æ, ø og å). I brugsmønsterbeskrivelser og analyse benyttes danske betegnelser, for at gøre disse lettere at læse for kunden. - Når der i analyse, design og kildekode refereres til klasser, vil disse være anført med stort begyndelsesbogstav, fed og uden mellemrum. - Når der i analyse, design og kildekode refereres til attributter, pakker og lignende, vil disse være anført med lille begyndelsesbogstav, fed og uden mellemrum. - Der vil i rapporten blive brugt følgende forkortelser: o HMH: Håndtryksmåler Hardware o HMS: Håndtryksmåler Software - Kildekode er vist i en lyseblå ramme. - Der er fold-ud sider bagerst i rapporten, som indeholder UML-diagrammer. - Krav og brugsmønstre er prioriteret ud fra MoSCoW metoden: Must, Should, Could og Would. Den medfølgende cd starter automatisk i et browservindue, hvor det er muligt at navigere rundt på en overskuelig side. cd en indeholder: - Dokumentation for gruppens arbejdsproces - Projektgrundlag - Mødeindkaldelser - Referater - UML-diagrammer - Anvendte datablade Side II af IV - Projektjournaler - Rapporten - Refleksionsdokument - Kildekode - Anvendte programmer - Tidsplaner og backlogs Følgende projektjournaler og dokumenter produceret i projektperioden forefindes på cd en, dokumenter markeret med * forefindes desuden i bilag: Dokumentnavn Dokumentet indeholder Antal sider Teknisk dokumentation for Oversigt over konstruktionen af HMH, heriblandt blokdiagram, HMH printudlæg og assembler-kode. 41 Inceptionsdokument v1.1 Visionen for projektet og kravene der er opstillede i samarbejde med TEK-BrobygningsCenter. Herudover indeholder dokumentet en principskitse, korte brugsmønsterbeskrivelser, indledende risikoanalyse 17 og mockups af brugergrænseflade. Krav- og Den udarbejdede kravmodel, brugsmønstermodel og brugsmønsterdokument v1.2 brugsmønsterbeskrivelser for hele IT-systemet. 23 Design af brugergrænseflade v1.0 Beskrivelse af det udviklede brugergrænseflade, dette indebærer de første mockups og en sammenligning af den endelige brugergrænseflade og 7 mockups. Teknisk memo for seriel En beskrivelse af den anvendte teknologi i forbindelse med kommunikation* kommunikation med HMH og SMS-modul. 1 Styring af HMH v1.0* En gennemgang af hvordan HMH styres af det udviklede software. 2 Teknisk memo for SMSmodul* dette. En beskrivelse af det anvendte SMS-modul og kommunikationen med 2 Testcase Testcase for SyntaksControlTest og ReadSMSTest. 2 Brugertest v1.0 Beskrivelse af brugertesten, deriblandt fremgangsmåden, resultaterne og de stillede opgaver, samt notering af fejl og mangler. 7 Brugermanual v1.0 På nuværende tidspunkt installations- og afinstallations-vejledning. 3 Refleksionsdokument En gennemgang og vurdering af projektprocessen. 2 Tabel 0.1: Oversigt over projektjournaler og deres indhold. Samtlige journaler er placeret på den medfølgende cd.

5 Indholdsfortegnelse 1 Indledning Beskrivelse af TEK-BrobygningsCenter Oversigt over samlet produkt Beskrivelse af hardwareenhed Projektbeskrivelse Problemanalyse Problemformulering Mål og forventede resultater Procesmodel og støttediscipliner Model Værktøjer Anvendelse af kvalitetskontrol af software Overordnet plan for projektet Krav Brugsmønstermodel Risikoanalyse Udsnit af kravmodel Brugsmønsterbeskrivelser Analyse Beskrivelse af analyseklassediagram Analysesekvensdiagram for Opret konkurrencedeltager (B9) Analysesekvensdiagram for Deltag i konkurrence (B10) Softwarearkitektur Valg af arkitekturframework Anvendelse af designmønstre Designstrategier Udrulning Persistens Adgangsforhold Kontrolflow Grænsevilkår Detaljeret design Design af Opret konkurrencedeltager(b9) Design af Deltag i konkurrence (B10) Distribution Distribueringsmønster Valg af distribueringsmønster Pakkediagram over system Valg af kommunikationsform Anvendelse af persistens Mapning af domænemodel til database Oprettelse og manipulation af tabeller Implementering Implementering af seriel kommunikation Implementering af SMS-kommunikationen Implementering af database Implementering af RMI Udvikling af brugergrænseflade Analyse af måleværdier fra HMH-enheden Statistiske overvejelser til udbygning af system Grundlag Bestemmelse af forskel mellem drenge og piger Side III af IV

6 12.3 Estimering af score i discipliner Kvalitetskontrol Review Dynamisk kvalitetskontrol Brugertest Resterende arbejde Konklusion Perspektivering Referenceliste Anvendt litteratur Anvendte internetsider Programliste Bilag 1 Projektoplæg for Håndtryksmåler Bilag 2 Styring af HMH-enhed Bilag 3 Teknisk memo: Seriel kommunikation Bilag 4 Teknisk memo: SMS-modul Bilag 5 Analyseklassediagram Bilag 6 Designklassediagram Bilag 7 Designinteraktionsdiagram Opret konkurrencedeltager (B9) Bilag 8 Designinteraktionsdiagram Deltag i konkurrence (B10) Side IV af IV

7 1 Indledning Denne rapport omhandler udviklingen af et IT-system til TEK-BrobygningsCenter. IT-systemet er en del af et samlet produkt, som er et led i fornyelsen af BrobygningsCenterets faciliteter. Det samlede produkt består af to dele, en hardwareenhed og en softwaredel. Hardwareenheden udarbejdes af projektgruppen som et separat projekt 5. Denne rapport omhandler således kun udviklingen af softwaredelen. En præsentationsvideo af det samlede system, hvor både hardware og software introduceres kan forefindes på den medfølgende cd. Grundlaget for udviklingen af softwaredelen er et projektoplæg 6 udviklet i samarbejde med kunden, TEK-BrobygningsCenter. Rapporten gennemgår processen og overvejelserne i hele softwareudviklingsprocessen, og indeholder dokumentation for det udviklede system. Indledningsvis forefindes en beskrivelse af TEK-BrobygningsCenter og en kort oversigt over det samlede produkt, samt over hardwareenheden og dennes funktionaliteter. I det efterfølgende kapitel gennemgås projektbeskrivelsen for udviklingen af IT-systemet, hvor problemstillingen analyseres og mål for projektet defineres. 1.1 Beskrivelse af TEK-BrobygningsCenter Herunder følger en kort beskrivelse 7 af TEK-BrobygningsCenter. Denne beskrivelse vil ligge til grund for den senere analyse af problemdomænet. TEK-BrobygningsCenter er en afdeling på Det Tekniske Fakultet, der har til formål at skabe større interesse for teknik og naturvidenskab blandt de unge mennesker der besøger stedet, og samtidig at øge fokus på de ingeniøruddannelser som fakultetet tilbyder. Der er tale om en bred målgruppe af unge, der strækker sig helt fra elever i 6. klasse til elever på de gymnasiale uddannelser. BrobygningsCenterets strategi er, gennem leg og interaktivitet, med en række forskellige eksperimenter og forsøgsopstillinger, at lade de unge opleve de tekniske og naturvidenskabelige fænomener på en sjov og letforståelig måde. BrobygningsCenteret arrangerer rundvisninger på forskelligt fagligt niveau, hvor de unge først bliver introduceret til de forskellige naturvidenskabelige eksperimenter af en rundviser 8, og efterfølgende får mulighed for selv at afprøve eksperimenterne. Leg er en vigtig ingrediens når de unges interesse skal fanges, og derfor er eksperimenterne indrettet således, at de unge kommer i direkte interaktion med disse, og kommer til at anvende deres krop og sanser. Blandt de nuværende eksperimenter, som de besøgende får mulighed for at afprøve, kan nævnes et spejlkabinet, en drejestol, en svævende badebold, et lyslederkabel, et tredimensionelt foto, en teslakugle og meget andet. For at foretage en løbende opdatering af centeret, blev det i udgangen af 2008 bestemt, at et nyt produkt skulle tilføjes til BrobygningsCenterets faciliteter, der på daværende tidspunkt primært bestod af en række ældre fysiske eksperimenter. Ønsket fra BrobygningsCenterets side var derfor et nyt produkt, som ud over at være interaktivt og interessant for de besøgende, samtidig også afspejlede ny teknologi, som de besøgende benytter sig af i hverdagen, og som der undervises i på ingeniøruddannelserne. 1.2 Oversigt over samlet produkt På baggrund af TEK-BrobygningsCenters ønsker blev der udarbejdet et projektoplæg for udvikling af et nyt produkt til centeret. I dette afsnit skabes et kort overblik over det samlede produkt, og de elementer der indgår. 5 Ansat som studentermedarbejdere gennem TEK-BrobygningsCenter. 6 Projektoplægget for det samlede Håndtryksmålersystem forefindes i bilag 1. 7 Informationer om TEK BrobygningsCenteret er indsamlet gennem interview og fra deres hjemmeside: 8 En ingeniørstuderende på Det Tekniske Fakultet. Prolog Side 1 af 63

8 Produktet der skal udvikles til TEK-BrobygningsCenter er en Håndtrykmåler, der blandt andet måler trykstyrke via en mekanisk hånd. Tanken er at produktet skal indgå i de rundvisninger som foregår i centeret, og det er meningen at de besøgende selv skal kunne benytte Håndtryksmåleren. Samtidig er det tanken at der skal indgå et konkurrenceelement i produktet, så de besøgende dyster mod hinanden i forskellige discipliner. Projektoplægget fastlægger de overordnede rammer for projektets omfang, som illustreret herunder: Figur 1.1: Skitse af det samlede produkt, som angivet i det endelige projektoplæg, bilag 1. På baggrund af figur 1.1 og den resterede del af projektoplægget kan det samlede produkt dermed skitseres som vist herunder: Figur 1.2: Principskitse af samlet Håndtryksmåler-produkt. Som det ses af figur 1.2 består det samlede produkt af en hardwareenhed (HMH) og en softwaredel (HMS). Hardwareenheden er tilkoblet den mekaniske hånd, og foretager de enkelte målinger under konkurrencen, mens softwaredelen administrerer konkurrencens forløb og sørger for at resultater fra konkurrencen er tilgængelig for offentligheden. Samtidig administrerer softwaredelen et SMSmodul, som de besøgende kan kommunikere med via deres mobiltelefoner. Det er tanken, at softwaredelen skal udvides til at kunne administrere andre eksperimenter end Håndtryksmåleren. Side 2 af 63 Prolog

9 1.3 Beskrivelse af hardwareenhed Idet hardwareenheden (HMH) udvikles som et separat projekt, gives i dette afsnit en oversigt over denne del af produktet og dennes funktionaliteter, for at give et billede at det samlede produkt. De tekniske detaljer er undladt i afsnittet, for en nærmere beskrivelse henvises til Tekniske dokumentation for Håndtryksmåler, som kan findes på den medfølgende cd. Der henvises derudover igen til præsentationsvideoen af det samlede system på den medfølgende cd, som illustrerer hardwareenhedens funktionaliteter. HMS s primære funktion er at indsamle data fra den tilkoblede mekaniske hånd under afvikling af forskellige discipliner. Dette data beskriver styrken af det tryk der udføres. Samtidig indeholder enheden displays til både analog og digital visning af disse data og lamper til at indikerer over for konkurrencedeltageren hvornår en disciplin er i gang. Et billede af den konstruerede hardware er vist herunder: Figur 1.3: Billede af det udviklede hardware. Den centrale del af hardwareenheden er en microcontroller 9, som står for styring og afvikling af de enkelte discipliner, som eksperimentet tilbyder. Det er desuden microcontrolleren der står for kommunikationen med den tilkoblede computer. Denne kommunikation samt selve styringen af hardwaren er beskrevet i bilag 2, det medfølgende tekniske memo, Teknisk memo: Seriel kommunikation (bilag 3) og under implementering af denne kommunikation, afsnit HMH-enheden tilbyder i alt tre forskellige discipliner, som er beskrevet i tabellen herunder: Disciplin: Styrke Reflekser Udholdenhed Beskrivelse: Styrkedisciplinen måler hvor hårdt deltageren kan trykke i den tilkoblede hånd. Der foretages målinger over 5 sekunder på skalaen [0;99] og den højeste af disse værdier er deltagerens score. I refleksdisciplinen testes deltagerens reaktionsevne. Når den grønne lampe lyser startes en timer som stoppes igen idet øjeblik deltageren trykker i hånden. Timerværdien omregnes til millisekunder og nummeres herefter. Ved udholdenhedsdisciplinen måles hvor hårdt deltageren i gennemsnit trykker i en given periode. Der foretages målinger over 5 sekunder og gennemsnittet af disse målinger er deltagerens score. Tabel 1.1: Oversigt over tilgængelige discipliner i HMH. 9 En programmerbar integreret kreds som styrer Håndtryksmåleren. Prolog Side 3 af 63

10 2 Projektbeskrivelse I dette kapitel beskrives semesterprojektet, omhandlende udviklingen af softwaresystemet, som er en del af det samlede Håndtryksmålersystem. Der udarbejdes en problemanalyse, problemformulering, samt en beskrivelse af gruppens mål og forventede resultater til projektet, på baggrund af det udarbejdede projektoplæg og TEK-BrobygningsCenters visioner for produktet. Disse elementer vil danne grundlag for den videre planlægning af softwareudviklingsforløbet, som beskrives i det efterfølgende kapitel. 2.1 Problemanalyse I dette semesterprojekt er det som nævnt projektgruppens opgave, at udvikle softwaredelen af det samlede system, og der vil derfor være fokus på dette område gennem problemanalysen. Følgende afsnit indeholder en oversigt over de services IT-systemet skal tilbyde, på baggrund af projektoplægget, udviklet i samarbejde mellem TEK-BrobygningsCenter, Jan Petersen og projektgruppen. Det er ønsket fra TEK-BrobygningsCenter at softwaredelen af systemet, skal tilbyde følgende services 10 : - Systemet skal benyttes af besøgende i TEK-BrobygningsCenter. - Systemet skal give rundviseren mulighed for at demonstrere og administrere systemet. - Systemet skal gøre det muligt for de besøgende at interagere direkte med systemet. - Systemet skal gøre det muligt for de besøgende at kommunikere med systemet via deres mobiltelefoner. - Systemet skal gøre det muligt for de besøgende at tilgå konkurrencedata fra systemet via internettet. - Systemet skal tilbyde en simpel brugergrænseflade. - Systemet skal tilbyde forskellige discipliner, for at gøre det mere interessant for de besøgende. - Systemet skal på længere sigt kunne udvides til at håndtere flere af BrobygningsCenterets eksperimenter. Ud over ønskerne fra TEK-BrobygningsCenter, er der derudover fastlagt nogle generelle krav 11 til det IT-system, som skal udvikles på 4. semester datateknologi, ud fra semesterets mål: - Systemet skal være distribueret - Der skal være anvendt statistiske modeller i softwareløsningen I løbet af inceptionen blev der på baggrund af disse overordnede krav udarbejdet en kravmodel for projektet, som er beskrevet under kapitel Problemformulering TEK-BrobygningsCenters primære mål er at øge interessen for teknik og naturvidenskab, gennem interaktiv leg med de besøgende. I den forbindelse skal der udvikles et produkt bestående af en hardwareenhed og et tilhørende IT-system. Gennem projektperioden vil gruppen derfor bestræbe sig på at afklare følgende: Er det muligt gennem bearbejdning af centrale krav og brugsmønstre for IT-systemet, at udarbejde en distribueret risikofri systemprototype med begrundet arkitektur, der dokumenterer overfor TEK- BrobygningsCenter, at det er muligt at udvikle et IT-system, som gennem interaktiv leg øger interessen for teknik og naturvidenskab hos de besøgende i BrobygningsCenteret? 10 De services som systemet skal tilbyde er fastlagt ud fra interview med TEK-BrobygningsCenter og ud fra projektoplægget for systemet. 11 Krav fra semesterhåndbog for 4. semester datateknologi. Side 4 af 63 Prolog

11 2.3 Mål og forventede resultater På baggrund af problemanalysen, problemformulering og de overordnede mål for semestret har gruppen opstillet en række mål for projektforløbet. Følgende mål blev opstillet: - Gennemføre en inception, hvor krav og brugsmønstre fastlægges. - Foretage interviews vedrørende brugsmønstre og krav, for at klarlægge TEK - BrobygningsCenterets ønsker. - Tilstødende brugsmønstre og krav der har indflydelse på IT-systemet, valideres ved slutningen af hver iteration, og gruppen foretager en overvejelse om hvorvidt det er nødvendigt at realisere disse i efterfølgende iterationer. - Udarbejde en analysemodel over de centrale brugsmønstre. - Udarbejde et forslag til en forståelig, vedligeholdelsesvenlig og skalerbar softwarearkitektur, samt dokumentere dette design i en designmodel der viser den overordnede struktur for ITsystemet. - Anbefale en distribueret arkitektur og en konkret distributionsform for IT-systemet. Dette indbefatter at udarbejde et distribueret system, som ud over at kunne tilgås i selve BrobygningsCenteret, samtidig også kan tilgås via internettet. - Udvikle en softwarearkitekturprototype, som illustrerer de overordnede funktionaliteter ITsystemet skal tilbyde. - Undersøge og eliminere risici i forbindelse med konstruktionen af IT-systemet, ved at behandle centrale brugsmønstre. - Færdiggøre størstedelen af elaborationsfasen, således at der ved projektperiodens afslutning foreligger en sådan grad af dokumentation for IT-systemet, at det kan klargøres til konstruktion inden for en enkelt elaborationsiteration. - Redegøre for fordele og ulemper ved valgte løsninger i sammenligning med alternative løsninger. - Undersøge muligheden for implementeringen af statistiske modeller i softwareløsningen. - Undersøge princippet for kommunikation mellem IT-systemet og en mobiltelefon, via SMS. - Producere en simpel grafisk brugergrænseflade, som tager højde for at der senere kan uarbejdes en endelig brugergrænseflade til IT-systemet. - Foretage en test af systemets funktionalitet i slutningen af projektperioden og på baggrund af testen fastlægge en plan for det videre forløb. - Foretage review af systemet i løbet af projektperioden, i samarbejde med TEK- BrobygningsCenter. - Udarbejde en brugermanual indeholdende blandt andet installations- og afinstallationsvejledning. Prolog Side 5 af 63

12 3 Procesmodel og støttediscipliner Dette kapitel beskriver den procesmodel der benyttes i softwareudviklingsforløbet, samt metodens fordele og ulemper. Derudover beskrives de forskellige støttediscipliner, i form af værktøjer og kvalitetskontrol, der er anvendt i projektet. Afslutningsvis gives en oversigt over det faktiske forløb af projektets iterationer. 3.1 Model Den overordnede procesmodel der anvendes i projektet er Unified Process (UP), som er blevet benyttet på 3. semester. Det betyder at det samlede projekt inddeles i fire faser: Inception, elaboration, konstruktion og transition, hvor inceptionen og størstedelen elaborationen gennemføres i projektperioden. Som et mål for semesteret skal der i projektforløbet anvendes et agilt projektplanlægningsværktøj. Gruppen vil derfor gøre anvendelse af procesmodellen SCRUM i kombination med UP. Det er naturligt at anvende SCRUM i projektet, da der undervises i denne metode på 4. semester i PL-undervisning. Overordnet er SCRUM opbygget af: En product backlog, en sprint backlog og en release backlog. Product backloggen indeholder en liste over alle elementer som tilhører projektet. Selve udviklingsarbejdet inddeles i sprints, med en varighed på 14 til maksimum 30 dage, hvor et udvalg af de højest prioriterede elementer i product backloggen placeres i sprint backloggen. Under det enkelte sprint arbejdes udelukkende med de udvalgte elementer, og der kan altså ikke medtages nye arbejdsopgaver. Det vil undervejs hele tiden være mulighed for at tilføje nye krav til product backloggen, som dermed kan medtages i senere sprints. Når elementer er færdigbearbejdet placeres de derefter i release backloggen, og elementer der ikke er færdiggjort inden for det aktuelle sprint returneres til product backloggen. Ud over de førnævnte backlogs anvendes desuden en feature backlog, til at holde styr på de dele af projektet, som ikke er en decideret del af det endelige produkt. På figuren herunder er forløbet i SCRUM illustreret: Figur 3.1: SCRUM metoden. Der afholdes daglige SCRUM-møder, styret af en SCRUM-master, hvor tidsrammen for de enkelte elementer vurderes. På disse SCRUM-møder gør de ansvarlige for de enkelte elementer desuden opmærksom på eventuelle problemer som er opstået, og der lægges herefter en plan for hvad der arbejdes med resten af dagen. Det er vigtigt at SCRUM-møderne er så korte som mulig, så derfor er der kun en forklaring af problemer og ikke en diskussion af en løsning. Løsningerne på problemet kan diskuteres efter mødet. Fordelen ved anvendelsen af SCRUM er at det er nemt at holde overblik over de enkelte sprints da arbejdsmængden er afgrænset. Samtidig kan SCRUM let kombineres med andre metoder og værktøjer. Det er dog med SCRUM ikke muligt at lægge en projektplan for det fulde projektforløb, Side 6 af 63 Prolog

13 da der kan tilføjes krav til product backloggen løbende, og desuden kan det være svært at producere sammenhængende dokumentation for produktet, idet de enkelte sprints er uafhængige af hinanden. I dette projekt anvendes SCRUM i kombination med Unified Process, på den måde at elaborationsfasens iterationer afvikles som enkeltstående sprints. Den sidste periode til afrapportering forløber ligeledes som et sprint. Under inceptionsfasen hvor krav og brugsmønstre skal udforskes har gruppen bestemt sig for ikke at benytte SCRUM, da det er vigtigt at tilstødende problemer behandles løbende. 3.2 Værktøjer Til kvalitetssikring af IT-systemet anvendes forskellige værktøjer gennem hele projektperioden. Det var samtidig et semestermål at gruppen udforskede forskellige nye værktøjer. De anvendte værktøjer er beskrevet kort herunder: Planlægning Til udfærdigelse af tidsplan og diverse backlogs i forbindelse med SCRUM-planlægning benyttede gruppen Microsoft Excel 12. Backlogs blev baseret på et udleveret eksempel 13. Tidsplaner og backlogs kan forefindes på den medfølgende cd Systemmodelleringsværktøj Til udformning af statiske og dynamiske views af softwaresystemet anvendte gruppen Diagram Designer 14. Dette skyldes at gruppen har anvendt dette program med stor succes på foregående semester, og gruppen i den forbindelse har udfærdiget en template med alle nødvendige figurer og symboler til udfærdigelsen af UML-diagrammer. Idet alle gruppemedlemmer havde erfaring med brugen af dette program, var det nemt og hurtigt at udfærdige de nødvendige diagrammer. Samtidig bliver diagrammer tegnet i Diagram Designer simple og let overskuelige uden unødvendig farve og grafik. Diagram Designer og den af gruppen udviklede template medfølger på cd en Udviklingsværktøj Som softwareudviklingsmiljø anvendtes Eclipse IDE 15. Eclipse muliggør integration af både versionsstyring og test, som gruppen ligeledes har gjort brug af. Disse værktøjer beskrives i de efterfølgende underafsnit. Eclipse er valgt frem for andre udviklingsværktøjer, da det har indgået i undervisningen i softwareudvikling på 4. semestre, og det desuden er blevet introduceret på tidligere semestre Versionsstyring Til versionsstyring af kildekode har gruppen anvendt Subversion 16 (SVN) integreret i Eclipse. Gruppen har under projektperioden draget meget nytte af anvendelsen af SVN, der har vist sig som et stærkt værktøj i forbindelse med implementering af kildekode, idet det muliggør sideløbende programmering af flere dele af koden. 3.3 Anvendelse af kvalitetskontrol af software I Unified Process indgår test som en naturlig del af alle faser og det vil derfor være naturligt at udføre en løbende kvalitetskontrol. For at sikre kvaliteten af den software der bliver udviklet vil der under projektforløbet blive arbejdet efter 0-fejl udviklingen fejl udvikling handler om at få softwaren udviklet rigtige første 12 Microsoft Office Excel Udleveret i forbindelse med undervisning i SOFT4. 14 Diagram Designer v Eclipse IDE for Java EE Developers 16 Subversion Kilde 6 Kapitel 2. Prolog Side 7 af 63

14 gang. Dette sikres ved at spørge, hvis der er noget man er usikker på, ved at skrive beslutning ned når de foretages, konkludere åbent, og ved at lade de involverede se det foreløbige resultat. Alt dette foretages for at undgå fejl i den software der udvikles. Der er naturligvis ikke muligt at undgå fejl i den software der udvikles og der vil derfor under projektforløbet blive udført statisk- og dynamisk kvalitetskontrol af det udviklede software. I projektet anvendes testcases til kvalitetskontrol af kritiske områder af softwaren, for at sikre at disse er fejlfrie. Anvendelsen af testcases er beskrevet i afsnit De kvalitetskontrolaktiviteter, som gruppen har planlagt at gennemføre, fremgår af den overordnede tidsplan i afsnittet herefter. 3.4 Overordnet plan for projektet I dette afsnit gives en oversigt over det faktiske forløb af de enkelte iterationer som er udført under projektet. Herudover forefindes en oversigt over projektets milepæle, heriblandt den kvalitetskontrol der har fundet sted igennem projektperioden. Da projektperioden efter færdiggørelsen af projektgrundlaget strakte sig over i alt 11,5 uger, blev det besluttet at afsætte 2-3 uger til hver iteration, så der dermed kunne udføres 3 elaborationsiterationer, efter en indledende inceptionsiteration. Det faktiske forløb for projektperioden er illustreret i tabellen herunder, hvor SCRUM-masteren er angivet: Uge Fase Inception Elaboration Afrapportering Rapportretning og Aktivitet Projektgrundlag Iteration 0 Iteration 1 Iteration 2 Iteration 3 korrektur SCRUMmaster Agge Alexey Jakob Frantz Tabel 3.1: Overordnet tidsplan for projektet. En oversigt over projektets milepæle og kvalitetskontrolaktiviteter er angivet i tabel 3.2, herunder: Dato Milepæl 3/ Første udkast til projektgrundlag 11/ Godkendelse af projektgrundlag 17/ Godkendende review af inceptionsdokument med TEK-BrobygningsCenter 20/ Afslutning af inception 3/ Afslutning af iteration 1 14/ Inspektionsreview af dokumentation fra iteration 1 med projektgruppe 2 24/ Afslutning af iteration 2 28/ Fremvisning af udviklet hardware og præsentation af software for TEK- BrobygningsCenter og involverede personer 14/ Brugertest af systemprototype 15/ Afslutning af iteration 3 25/ Rapport færdig til korrekturlæsning 29/ Rapportaflevering Tabel 3.2: Plan over milepæle i projektet. Product, feature, release og sprint backlogs forefindes på den medfølgende cd, hvor en mere detaljeret tidsplan er vedlagt. Side 8 af 63 Prolog

15 RESULTATER

16 Denne del af rapporten indeholder en oversigt over resultaterne fra projektperioden. Der gøres opmærksom på at indholdet af resultatdelen ikke er en dybdegående gennemgang af dokumentationen for HMS-systemet, da dette ville blive alt for omfattende. Derimod vil de væsentligste beslutninger og valg foretaget i projektet blive gennemgået, samtidig med at der skabes et overblik over systemets opbygning ved gennemgang af centrale brugsmønstre. Den samlede dokumentation, produceret i projektperioden, kan forefindes på den medfølgende cd, og der vil derfor gennem hele resultatdelen være referencer til dokumenter placeret på denne. Det skal dog understreges at det ikke vil være nødvendigt at udforske indholdet af cd en for at kunne læse rapporten, selvom læseren opfordres til dette. I resultatdelen gennemgås først krav og analyse for HMS-systemet, med udgangspunkt i to udvalgte brugsmønstre og derefter beskrives softwarearkitekturen og designstrategier såsom deployering, kontrolflow og persistens. Herefter præsenteres valg fortaget i forbindelse med detaljeret design, distribuering af systemet, samt for kommunikationen mellem de enkelte dele af systemet. Implementering af centrale dele af systemet beskrives derefter, blandt andet implementering af valgt kommunikationsløsning og persistens. Afslutningsvis beskrives statistiske overvejelser i forbindelse med udvidelse af systemets funktionaliteter, som er undersøgt i forbindelse med elaborationen, hvorefter der til sidst redegøres for brugen af kvalitetskontrol i projektforløbet. 4 Krav Følgende kapitel giver et overblik over brugsmønster- og kravmodel for det samlede IT-system. Der tages i kapitlet udgangspunkt i to brugsmønstre i systemet, henholdsvis Opret konkurrencedeltager (B9) og Deltag i konkurrence (B10), da det er disse to brugsmønstre der har den største arkitekturmæssige og risikomæssige signifikans. De to brugsmønstre er ligeledes behandlet først i elaborationen. Da brugsmønstrene er kernen i hele systemet og er meget omfattende, gives dermed et indblik i hele systemets opbygning. For en beskrivelse af alle brugsmønstre og krav henvises læseren til Inceptionsdokumentet og Krav- og brugsmønsterdokument som indeholder brugsmønsterbeskrivelse for samtlige brugsmønstre. Disse dokumenter forefindes på den medfølgende cd. Krav og brugsmønstre er primært beskrevet i løbet inceptionen, i tæt samarbejde med TEK- BrobygningsCenter, som har haft væsentligt indflydelse på de formulerede krav i løbet af de første uger af projektperioden. Herudover er enkelte krav og brugsmønstre fundet i forbindelse med elaborationen, og disse er blevet vurderet og behandlet løbende ved afslutning af de enkelte sprints. Først i kapitlet illustreres den samlede brugsmønstermodel og primære og sekundære aktører mål med brugen af systemet beskrives. Herefter præsenteres udforskede risici ved hjælp af en faktortabel. Sidst i kapitlet forefindes brugsmønsterbeskrivelser for de to førnævnte brugsmønstre, samt et uddrag af den samlede kravmodel, som indeholder brugsmønstrenes tilhørende krav og deres prioritet. Side 10 af 63 Resultater

17 4.1 Brugsmønstermodel Afsnittet skaber et overblik over brugsmønstre i systemet, og indeholder derudover en beskrivelse primære og sekundære aktører i systemet. Brugsmønstermodellen illustrerer samtlige brugsmønstre i systemet, samt de berørte aktører og deres tilgang hertil. Aktørerne der er placeret på venstre side er primære og aktørerne på højre side er sekundære. Brugsmønstre som ikke er implementeret på nuværende tidspunkt er markeret med grå: Figur 4.1: Brugsmønsterdiagram over det samlede system. Aktøren Offentligheden henviser til at de pågældende brugsmønstre er offentligt tilgængelige på internettet, og derfor kan benyttes af alle herunder tidligere besøgende. Resultater Side 11 af 63

18 Tabel 4.1 indeholder en beskrivelse af de primære aktører til systemet, samt hvilke mål aktørerne har med at anvende systemet: Primære aktører Beskrivelse Mål Besøgende Besøgende interagerer med Håndtryksmålersystemet og deltager i konkurrencen. - Oprettes i system via SMS - Deltage i konkurrence - Tilgå konkurrencedata via internettet Rundviser Offentligheden Rundviser opretter klasser, demonstrerer konkurrencen og redigerer konkurrencens indstillinger. Offentligheden interagerer med systemet via internettet. Tabel 4.1: Beskrivelse af primære aktører til IT-systemet. - Oprette klasser - Demonstrere konkurrence - Administrere I/O-enheder - Redigere systemindstillinger - Redigere konkurrence - Starte konkurrence - Afslutte konkurrence - Tilgå konkurrencedata - Følge en igangværende konkurrence Tabel 4.2 indeholder en beskrivelse af de sekundære aktører til systemet, samt hvilke services aktørerne tilbyder til systemet: Sekundære aktører Beskrivelse Services Håndtryksmåler - Skal modtage instruktion om at udføre HMH-enheden skal kommunikere med ITsystemet. Hardwareenhed delkonkurrence. (HMH-enhed) - Skal sende konkurrencedata. SMS-modul Database SMS-modul skal kommunikere med ITsystemet og med de besøgendes mobiltelefoner. - Skal modtage besøgendes tilmelding til konkurrencen. - Skal sende besøgendes resultat ved afslutning af konkurrence. - Skal modtage konkurrencedata og Databasen skal kommunikere med ITsystemet opbevare disse - Skal opbevare disciplininformationer Tabel 4.2: Beskrivelse af sekundære aktører til IT-systemet. 4.2 Risikoanalyse Under inceptionen blev en indledende risikoanalyse foretaget, efter modellen FURPS+ 18, for at identificere kritiske punkter ved udviklingen af IT-systemet. Analysen er foretaget på baggrund af de ikke funktionelle krav der blev fundet i inceptionen. De enkelte brugsmønstre er i elaborationsfasen prioriteret på baggrund af denne analyse samt deres arkitekturmæssige signifikans. Brugsmønstrene er således behandlet i en sådan rækkefølge at de største risici udryddes først og at softwarearkitekturen kortlægges tidligt i udviklingsforløbet. Risikoanalysen er beskrevet i en faktortabel som gennem projektperioden er blevet udbygget i takt med at de enkelte risici er blevet adresseret. Herunder følger først en kort forklaring af de enkelte kolonner i faktortabellen, hvorefter selve tabellen vises: Faktor Kvalitetsscenarium Foranderlighed Påvirkning Succes prioritet Risiko En beskrivende overskrift til risikofaktoren. En uddybende beskrivelse, som giver et mere præcist billede af risikoen. En beskrivelse af hvad der på nuværende tidspunkt er implementeret i systemet, samt en kort beskrivelse af hvad der kan gøres i fremtiden for at varetage en risiko eller optimere den anvendte løsning. En beskrivelse af hvilken effekt risikoen har på systemet, hvis der ikke tages højde for denne. En Høj/Mellem/Lav prioritering af hvor vigtig den beskrevne risikofaktor er for det samlede system. En Høj succes prioritet betyder at en risikofaktor er nødvendig for at systemet kan realiseres. En Høj/Mellem/Lav prioritering af risikoen/sværhedsgraden ved at behandle den beskrevne risikofaktor. En Høj risiko betyder at en risikofaktor er svær at realisere, enten på grund af risikoen forbundet med faktoren, sværhedsgraden af implementeringen eller begge dele. Tabel 4.3: Forklaring af faktortabel. 18 FURPS+ står for: Functionality, Usability, Reliability, Performance, Supportability. Se evt. Kilde 10 Kapitel 6. Side 12 af 63 Resultater

19 Faktor Kvalitetsscenarium Foranderlighed Påvirkning Ydeevne kriterier: Behandlingstid fra SMS ankommer til SMS-modul og til den besøgende er oprettet i systemet. Behandlingstid når SMS er skal sendes, efter afslutning af konkurrencen. SMS-modul skal kunne håndtere belastning fra en besøgsgruppe. Forsinkelse på indlæsning fra HMH-enhed til visning i systemet. Forsinkelse i visning af konkurrencedata i appletten. Forsinkelse i følg konkurrence, i appletten. Afhængighedskriterier: Robusthed overfor ikke-overholdt SMS-syntaks. Fejltolerance overfor overførselsfejl mellem eksterne hardwareenheder og HMS. Tilgængelighed af konkurrencedata. Vedligeholdelseskriterier: Modificering af systemet i forbindelse med udvidelse af TEK- BrobygningsCenter. Læsbarhed af programkode. Brugerkriterier: Brugbarhed af systemet. Behandlingstiden må ikke overstige 30 sekunder for at oprettelsen foregår flydende. Behandlingstiden må ikke overstige 1 minut. En besøgsgruppe er oftest personer. Forsinkelse på indlæsning og visning af data fra HMH må ikke overstige 19 millisekunder. Visningen af data i appletten skal ske på under 10 sekund. Visning af igangværende konkurrence, skal kunne ses indenfor 1 minut af begyndelse af konkurrence. Der skal tages højde for at der kan være tastefejl i indsendte SMS er. HMS skal kunne håndtere hvis der mistes data i den serielle kommunikation. Konkurrencedata skal kunne tilgås via internettet 24 timer i døgnet. Der skal tages højde for at systemet skal kunne udvides til at administrere flere eksperimenter som tilføjes til TEK-BrobygningsCenteret. Det skal være muligt for en anden udviklingsgruppe at tilføje funktionaliteter til systemet på et senere tidspunkt. Nu - Behandlingstiden for én SMS er 1 sekund, men denne bliver længere hvis der modtages mange SMS er på samme tid. Fremtid Ingen. Nu - Behandlingstiden for én SMS er 1 sekund, men denne bliver længere hvis der er mange SMS er på samme tid. Fremtid Ingen. Nu - SIM-kortet har plads til 50 SMS er. Alle SMS er bliver sletter efter behandlingen Fremtid - Finder BrobygningsCenteret det nødvendigt at forøge plads til SMS er, skal et nyt SIM-kort erhverves Nu - Forsinkelsen er mindsket mindst muligt ved at lade de indkomne data styre hvornår værdien vises 19. Fremtid Ingen Nu - Forsinkelsen er mindsket mest muligt ved at undlade at hente data op fra databasen hver gang en applet startes, men derimod have konkurrencedataet liggende i hukommelsen på applikationsserveren. Fremtid Ingen. Nu Der er ikke taget højde for denne forsinkelse endnu. Fremtid - Forsinkelse kan mindskes ved at have en tråd kørende der kontrollerer om en konkurrence er i gang. Nu - Der vises fejlmeddelelse i hændelsesloggen. Fremtid - Ingen. Nu - Der er ikke taget højde for dette. Fremtid - Hvis mængden af fejl i overførsler viser sig at være stor kan en løsning på dette implementeres. Nu - Dette er sikret ved at placere konkurrencedata på en webserver. Fremtid - Ingen. Nu - Systemet er designet med udvidelse i tankerne, så det er muligt at tilføje flere klienter der administrer eksperimenter. Fremtid - Flere eksperimenter tilføjes og der udvikles klienter til at varetage dem. Nu - Kode er beskrevet i UMLdiagrammer. Fremtid - Udformning af Javadoc. Hvis behandlingstiden bliver for lang vil oprettelsen af konkurrencedeltagere komme til at tage meget lang tid, og de besøgende kommer til at vente før de kan få lov til at deltage i konkurrencen. Hvis behandlingstiden bliver for lang får de besøgende ikke SMS en mens de har besøget i frisk erindring. Konsekvensen af påvirkningen er ikke kendt. For at undersøge konsekvensen skal SMSmodulet modtage over 50 SMS er på under 1 sekund. Hvis forsinkelsen overtiger 19 ms vil der ske en forsinkelse af visningen af data fra styrke- og udholdenhedsdisciplinen. Se evt. bilag 2. Hvis forsinkelsen bliver for stor mister man lysten til at gense sine resultater. Succes prioritet Høj Høj Høj Høj Mellem Risiko Mellem Mellem Mellem Høj Mellem Hvis forsinkelsen bliver for stor mister man ideen i at følge en igangværende konkurrence. Lav Mellem Hvis der ikke kontrolleres for fejl i SMS vil der ske fejl i programafvikling. Hvis dette ikke gøres kan der ske fejl i programafvikling. Mellem Lav Høj Lav 20 Hvis dette ikke gøres mister man grunden til at lave appletten. Høj Lav Hvis dette ikke gøres, er systemet fastlåst til kun at kunne håndtere HMH. Høj Mellem Hvis ikke mindskes BrobygningsCenterets muligheder for at udvide systemet i fremtiden. Det skal være enkelt for rundviseren og de besøgende at benytte systemet. Nu - Dette er sikret ved at lave en simpel brugergrænseflade og sørge for der ikke er for mange og komplicerede menuer. Fremtid - Der kan foretages ændringer ud fra feedback fra rundvisere og besøgende. Hvis dette ikke gøres kan systemet ikke anvendes og udviklingen vil have været spild af tid og penge. Tabel 4.4: Faktortabel over risici i systemudviklingen baseret på modellen FURPS+. Mellem Høj Lav Mellem 19 Systemet laver ikke andet end at kontrollere for indkomne data under deltagelse, således at data vises lige så snart de er behandlet. 20 Til overførsel af data benyttes RS-232-standarden, som sikrer få overførselsfejl mellem enhederne. Resultater Side 13 af 63

20 4.3 Udsnit af kravmodel Tabellen herunder viser et udsnit af den samlede kravmodel for IT-systemet, som beskriver de funktionelle og ikke funktionelle krav tilhørende de to udvalgte brugsmønstre, Opret konkurrencedeltager (B9) og Deltag i konkurrence (B10). En samlet kravmodel over alle krav til IT-systemet forefindes i Krav- og Brugsmønsterdokumentet som findes på cd en. I tabellen er de enkelte krav prioriteret dels på baggrund af TEK-BrobygningsCenters ønsker og dels på baggrund af deres betydning for softwarearkitekturen. Krav markeret med kursiv er krav som ikke direkte tilhører de to brugsmønstre, men som har indflydelse på deres behandling: Udsnit af kravmodel Brugsmønster ID Type Detaljer Særlige forhold Prioritet B9 B10 F18 F18.1 F18.2 F18.3 F19 F28 F29 K02 K05 K06 F14 F13 F20 F21 F22 F23 F27 F31 F32 Opret konkurrencedeltager Opret konkurrencedeltager Opret konkurrencedeltager Opret konkurrencedeltager Opret konkurrencedeltager Opret konkurrencedeltager Opret konkurrencedeltager I/O-enheder Interaktion Interaktion Start konkurrence Rediger konkurrence Deltage i konkurrence Deltage i konkurrence Deltage i konkurrence Deltage i konkurrence Udvidelse af system Start konkurrence Start konkurrence HMS skal give mulighed for de besøgende at oprette sig som deltager via SMS. HMS skal kunne afkode SMS vha. forudbestemt syntaks. HMS skal kunne registrere den besøgendes tlf. nr., køn, alder og navn. HMS skal kunne registrere yderlige oplysninger om de besøgende end F18.2 beskriver. HMS skal vise at konkurrencedeltageren er oprettet, på topscorelisten. HMS skal give mulighed for de besøgende at oprette sig i systemet uden brug af mobiltelefon. HMS skal føre hændelseslog over SMS-modul HMS skal kommunikere med SMS-modulet via USB. HMS skal sende og modtage SMS via SMSmodul. HMS skal oprette en ny konkurrencedeltager med en minimal tidsforsinkelse efter modtagelse af SMS. HMS skal give rundviser mulighed for at starte en konkurrence for en skoleklasse. HMS skal tage løbende backup af igangværende konkurrence. HMS skal give konkurrencedeltageren mulighed for at deltage i forskellige konkurrencediscipliner. HMS skal give konkurrencedeltageren mulighed for at deltage i konkurrencen 3 gange. HMS skal give den besøgende mulighed for at identificere sig i systemet med sit mobilnummer. HMS skal kunne beregne og vise den forventede score ud fra konkurrencedeltagerens oplysninger. HMS skal kunne udvides til at håndtere data fra andre eksperimenter end HMH. HMS skal give mulighed for at vælge hvilke discipliner der skal køres. HMS skal give mulighed ændre max antal forsøg i konkurrencen. Rundviser giver de besøgende mulighed for at indsende SMS. De besøgende skal sende SMS med den korrekte syntaks. Maksimal tidsforsinkelse på 10 sekunder. Systemet kunne på sigt tilbyde flere forskellige konkurrencer. Den besøgende skal testes i Styrke, Refleks og Udholdenhed, i denne rækkefølge. Der skal anvendes statistiske modeller i disse beregninger. Must Must Must Could - Want Should Should Must Should - Should Must Should Must Should K01 I/O-enheder HMS skal kommunikere med HMH via USB. Must K04 Brugervenlighed HMS skal have en simpel grafisk brugergrænseflade. - Tabel 4.4: Udsnit af kravmodel, som viser krav tilhørende de to brugsmønstre B9 og B10. - Want Want Side 14 af 63 Resultater

21 4.4 Brugsmønsterbeskrivelser Herunder findes brugsmønsterbeskrivelse for de to udvalgte brugsmønstre. Som nævnt kan brugsmønsterbeskrivelser for samtlige brugsmønstre forefindes Krav og Brugsmønsterdokument som er placeret på cd en Brugsmønsterbeskrivelse Opret konkurrencedeltager (B9) ID: Formål: Oversigt: Primære aktører: Sekundære aktører: Interessenter: Prækondition: Postkondition: Krydsreferencer: Udvidelser: Mockups: B9 At give den besøgende mulighed for at oprette sig som konkurrencedeltager i systemet. Den besøgende opretter sig som konkurrencedeltager i systemet ved at indsende en SMS med et antal forudbestemte personlige oplysninger. Rundviser SMS-modul Den besøgende: Ønsker hurtigt og enkelt at blive oprettet i systemet for at deltage i konkurrencen. TEK-BrobygningsCenter: Ønsker at de besøgende interagerer med en kendt teknologi fra deres hverdag, derfor er oprettelsen via mobiltelefon ønsket. Den besøgendes skoleklasse skal være oprettet i systemet. Den besøgende figurerer som oprettet på topscorelisten. F18, F18.1, F18.2, F18.3, F19, F28, F29, F30, K02, K05, K06 Mulighed for besøgende kan oprette sig i systemet uden brug af mobiltelefon. Brugergrænseflade udformning kan ses i Design af brugergrænseflade som findes på cd en. Hændelsesforløb: Primær aktør: System: Sekundær aktør: 1. Rundviser giver de besøgende mulighed for at oprette sig som konkurrencedeltager via SMS, efter skoleklassen er oprettet i systemet. Punkt 2 til 4 gentages så længe en skoleklasse er i gang hver 10. sekund. Punkt 4.1 til 4.8 gentages for alle SMS er i listen. Alternative forløb: 2. Systemet forespørger SMS-modul om at sende en liste over SMS er, der er gemt i dens hukommelse. 4. Hvis der findes nye SMS er 4.1. Systemet forespørger SMS- modul om at sende SMS-tekst for den ældste SMS-besked der findes i hukommelsen SMS tekst, mobil. nr., og tidspunktet gemmes i hændelseslog over SMS-modul 4.4. Hvis SMS-tekstens syntaks er overholdt SMS ens indhold afkodes, og den besøgende bliver oprettet som en ny konkurrencedeltager og tilknyttes til den pågældende skoleklasse Systemet viser at konkurrencedeltageren er oprettet, på topscorelisten Systemet forespørger SMS-modul om at slette den aktuelle SMS. Ingen 4.8. Sletningen af SMS føres til hændelseslog. 3. SMS-modul sender en liste over SMS er der er gemt i dens hukommelse SMS-modul sender SMS-tekst for den forespurgte SMS. 4.7 SMS-modul sletter SMS en fra dens hukommelse. Resultater Side 15 af 63

22 4.4.2 Brugsmønsterbeskrivelse Deltag i konkurrence (B10) ID: Formål: Oversigt: Primære aktører: Sekundære aktører: Interessenter: Prækondition: Postkondition: Krydsreferencer: Datakrav: Udvidelser: Mockups: B10 At give den besøgende mulighed for at deltage i en konkurrence. En besøgende i BrobygningsCenteret ønsker at deltage i konkurrencen. Den besøgende får mulighed for at indtaste sit mobilnummer, hvorefter deltageren bliver ledt igennem konkurrencens discipliner. Konkurrencen består af de af rundviseren forudbestemte discipliner, og under konkurrencen vises deltagerens forventede, samt opnåede resultater. Efter den besøgende har været gennem konkurrencens discipliner fastholdes resultatet en kort periode, hvorefter næste besøgende kan påbegynde konkurrencen. Den besøgende kan kun prøve konkurrencen tre gange. Besøgende HMH-enhed Besøgende: Ønsker at deltage i konkurrencen. Den besøgende ønsker desuden at kunne gentage sit forsøg i konkurrencen. TEK-BrobygningsCenter: Ønsker at give de besøgende mulighed for at interagere direkte med Håndtryksmålersystemet og deltage i konkurrencen. HMS har forbindelse til og har initialiseret HMH-enheden. Rundviser har oprettet en skoleklasse og startet konkurrencen. Den besøgende er oprettet i systemet (se brugsmønster Opret konkurrencedeltager (B09). Den besøgendes resultater for konkurrencen er gemt. F14, F16, F20, F21, F22, F23, F27, K01, K04 Kommunikation med HMH-enhed fremgår af bilag 2 og Teknisk memo: Seriel kommunikation (bilag 3). Ingen Brugergrænseflade udformning kan ses i Design af brugergrænseflade som findes på cd en. Hændelsesforløb: Aktør: System: HMH-enhed: 1. En besøgende indtaster sit mobilnummer for at starte konkurrencen. 2. Hvis telefonnummeret ikke er oprettet i systemet. 2.1 Systemet viser fejlmeddelelse med information om manglende oprettelse i systemet. 3. Ellers hvis den besøgende allerede har prøvet konkurrencen tre gange. 3.1 Systemet viser en fejlmeddelelse med information om max tre forsøg. Punkt 4.2 og 4.3 gentages under hele konkurrencedisciplinen. Punkt 4.1 til 4.5 gentages for konkurrencens discipliner. Alternative forløb: 4. Ellers 4.1 Systemet viser de forventede resultater og sender opstartssignal for den aktuelle konkurrencedisciplin til HMH. 4.3 Systemet viser og gemmer data for disciplinen, modtaget fra HMH. 4.5 Systemet viser og gemmer det samlede resultat for konkurrencedisciplinerne. 4.6 Systemet returnerer til skærm for indtast nummer. Ingen 4.2 HMH sender data for disciplinen til systemet. 4.4 HMH sender signal om at disciplin er afsluttet. Side 16 af 63 Resultater

23 5 Analyse Analysen, som beskrives i dette kapitel, er udført på baggrund af brugsmønsterbeskrivelserne og kravmodellen, som er udarbejdet i kravdisciplinen. Der blev på baggrund af beskrivelserne ved hjælp af navne- og udsagnsordsmetoden udarbejdet et analyseklassediagram, som beskrives først i kapitlet. De enkelte analyseklasser vil blive beskrevet kort for at skabe et overblik over systemets domænemodel. Derudover vil hændelsesforløbet for de to udvalgte brugsmønsterbeskrivelser blive beskrevet og illustreret ved hjælp af analysesekvensdiagrammer for at skabe et generelt overblik over den centrale del af analysen. Det skal understreges at dette kapitel kun behandler to af de udarbejdede analysesekvensdiagrammer. De resterende diagrammer forefindes på cd en under Krav- og brugsmønsterdokument. 5.1 Beskrivelse af analyseklassediagram I dette afsnit vil domænemodellen blive præsenteret og der vil være en beskrivelse af alle analyseklasser som optræder i modellen. Analysediagrammet er vedlagt i bilag 5, som kan foldes ud ved siden af rapporten, og i tabellen herunder følger en beskrivelse af de enkelte klasser i UML-diagrammet: Klasse: BrobygningsCenter Rundviser SkoleKlasse Besøgende Konkurrence Demonstration Eksperiment Disciplin Resultater Beskrivelse: BrobygningsCenter repræsenterer TEK-BrobygningsCenter. Til BrobygningsCenteret er der tilknyttet en række Eksperimenter, en Rundviser, samt den SkoleKlasse som vises rundt i centeret. BrobygningsCenteret administrerer SMS-kommunikation og adgangskontrol for Rundviseren. BrobygningsCenteret indeholder desuden en hændelseslog over systemets kommunikation med ydre enheder og en topscoreliste for den aktuelle SkoleKlasse. Rundviser er en person som er tilknyttet BrobygningsCenter. Når der ankommer en SkoleKlasse til BrobygningsCenter er det Rundviserens opgave at oprette den nye SkoleKlasse i systemet og starte Konkurrencen. Derudover er det også Rundviserens opgave at udføre en Demonstration af hver enkel Disciplin. Rundviseren har mulighed for at tilgå systemfunktioner som de Besøgende ikke skal have adgang til. Der skelnes ikke mellem den enkelte Rundviser, og der er derfor en fælles adgangskode for alle Rundvisere. Rundviser har mulighed for at logge ind og logge ud, samt at skifte og kontrollere adgangskode. Attributten status holder styr på om en Rundviser er logget ind. En SkoleKlasse er en gruppe af elever, der er på besøg i BrobygningsCenteret, denne bliver oprettet i BrobygningsCenter af Rundviseren. SkoleKlassen bliver beskrevet af attributterne: uddannelsessted, klassetrin, klassenavn, by og årgang. uddannelsessted er navnet på skolen, klassetrin er f.eks. 6. klasse, klassenavn er f.eks. 6.B, by er byen skolen ligger i og årgang er f.eks. skoleåret 2008/2009. I SkoleKlasse er der mulighed for at oprette, redigere og slette Besøgende der er tilknyttet SkoleKlasse. En Besøgende er en person der tilhører en SkoleKlasse der er på besøg i BrobygningsCenteret. En Besøgende er kendetegnet ved attributterne navn, alder, køn, antalforsøg og mobilnummer. Rundviseren sammensætter en konkurrence af forskellige Discipliner. De Besøgende har et fastlagt antalforsøg i Konkurrencen. Konkurrencen startes og afsluttes af Rundviseren, og i tilfælde af systemnedbrud, kan Konkurrencen genoptages. En Rundviser kan foretage en Demonstration af en eller flere Discipliner både før og efter en Konkurrence er startet. Et Eksperiment er en forsøgsopstilling i BrobygningsCenteret. Eksperimenterne er identificeret med et navn, og har desuden en status der viser om Eksperimentet er klar. Til hvert Eksperiment er der tilknyttet en eller flere Discipliner. En Disciplin er en konkurrencedisciplin under et Eksperiment. Disciplinen er kendetegnet ved et navn og et opstartssignal, som starter Disciplinen. En Disciplin kan være tilknyttet en Konkurrence. Disciplinen indeholder desuden nogle statistiske beregninger, der foretages under Disciplinens udførsel. Der skal blandt andet beregnes den forventede score i Disciplinerne for hver af de Besøgende. Efter de Besøgende har deltaget i Konkurrencen oprettes et Resultat som indeholder et samletresultat, samt konkurrencedata for hver Disciplin som den Besøgende har deltaget i. Tabel 5.1: Generel beskrivelse af klasserne i analyseklassediagrammet. Resultater Side 17 af 63

24 5.2 Analysesekvensdiagram for Opret konkurrencedeltager (B9) Herunder følger en kort gennemgang af hændelsesforløbet for brugsmønsteret Opret konkurrencedeltager (B9), hvorefter analysesekvensdiagrammet for brugsmønsteret er illustreret. Hændelsesforløbet i B9 startes når Rundviseren har oprettet en SkoleKlasse og SMS-modulet er initialiseret og klar til anvendelse. Når en konkurrencedeltager skal oprettes i systemet, sker dette på baggrund af den SMS som den pågældende Besøgende har indsendt til modulet. Når en SMS er hentet fra SMS-modulet, tilføjes dette til hændelsesloggen, for at Rundviseren kan se hvilke SMS er der er modtaget. Efterfølgende tjekkes der om den hentede SMS overholder den korrekte syntaks. Hvis SMS en er skrevet korrekt, bliver den Besøgende oprettet som konkurrencedeltager og dette tilføjes til hændelsesloggen. Den besøgende vil herefter desuden optræde på topscorelisten. Hvis der er fejl i SMS en, tilføjes dette i stedet til hændelsesloggen. Afslutningsvis slettes den pågældende SMS. Hele hændelsesforløbet bliver gentaget så længe en SkoleKlasse deltager i Konkurrencen. Analysesekvensdiagrammet for brugsmønsteret kan ses herunder: Diagram 5.1: Analysesekvensdiagram for hovedhændelsesscenariet i brugsmønster B9. Side 18 af 63 Resultater

25 5.3 Analysesekvensdiagram for Deltag i konkurrence (B10) I dette afsnit redegøres for hændelsesforløbet i brugsmønstret Deltag i konkurrence (B10), og analysesekvensdiagrammet vises. Brugsmønster B10 startes ved at en besøgende der allerede er oprettet i systemet indtaster sit mobilnummer. Før deltagelsen starter, kontrolleres det hvor mange gange den besøgende har forsøgt sig i konkurrencen, og hvis dette ikke overstiger det maksimale antal forsøg, som i henhold til krav F21 er sat til 3, oprettes et resultatobjekt og deltagelsen startes. Under deltagelse i konkurrencen hentes konkurrencedata fra HMH og dette data bliver løbende gemt i det pågældende Resultat-objekt. Dette gentages for alle de discipliner som den pågældende konkurrence består af. Efter deltagelsen i alle discipliner er overstået gemmes resultatet hos den pågældende besøgende og antalforsøg forøges. Såfremt den besøgende tidligere har forsøgt sig i konkurrencen gemmes det nye resultat kun hvis den samlede nye samlede score er højere end eksisterende. Analysesekvensdiagrammet for brugsmønstret er angivet herunder: Diagram 5.2: Analysesekvensdiagram for hovedhændelsesscenariet i B10. Resultater Side 19 af 63

26 6 Softwarearkitektur I dette kapitel vil systemets arkitekturframework blive valgt og efterfølgende vil der være en beskrivelse af designmønstre og designstrategier som er anvendt i designet af systemet. Når et system designes skal dette være forståeligt, let at vedligeholde og skalerbart. Samtidig skal man sørge for at minimere afhængighed mellem pakker, undgå cirkulære afhængigheder og have en lav kobling mellem klasser. For at tage højde for disse designmål skal der vælges et fornuftigt arkitekturframework hvorpå systemet skal opbygges, og anvendes designmønstre hvor det er nødvendigt for at undgå blandt andet cirkulære afhængigheder. Disse beslutninger vil blive foretaget i dette kapitel. 6.1 Valg af arkitekturframework I dette afsnit vil systemets arkitekturframework blive valgt. Der vil først være en generel beskrivelse af hvad et arkitekturframework er, og derefter en beskrivelse af det valgte framework. Et framework er et skelet som en softwareløsning kan bygges op om. Denne softwareløsning bliver udformet efter det problem der skal løses. Fordelen ved at anvende et framework er at der kan fokuseres på funktionaliteten, da de opdelinger der foretages i designet er forudbestemt af frameworket. Der er gennem tiden udviklet forskellige arkitekturframeworks til brug i softwarekonstruktion, et af de mest kendte er Model View Controller (MVC), se figur 6.1 herunder: Figur 6.1: Illustration af MVC-arkitekturframeworket MVC er et hierarkisk arkitekturframework som er opdelt i tre lag med hver deres funktion, herunder følger en beskrivelse af disse: Model View Controller Repræsenterer domænet og dets dataobjekter, forretningsenheder og regler. Model har ikke styr på Controller- og View-objekter, da det er Controller og View der lægger mærke til ændringer i Model. Repræsenterer brugergrænsefladen, typisk en grafisk brugergrænseflade. View indeholder såkaldte subviews, som tager sig af at vise forskellige dele af Model. Reagerer på begivenheder i View og konverterer disse til hændelser i Model. Tabel 6.1: Oversigt over pakker i MVC-frameworket. Opbygningen af dette arkitekturframework giver mulighed for at udvikle brugergrænseflade og domæne separat, som dermed samtidig kan testes hver for sig. Det er dermed muligt at udskifte en brugergrænseflade uden at ændre i domænet, samt ændre i domæne eller kontrol uden at det har indflydelse på brugergrænsefladen. Side 20 af 63 Resultater

27 Mange moderne arkitekturframeworks bygger på MVC, heriblandt PCMEF som det er valgt at anvende til dette IT-system. Frameworket PCMEF er blevet introduceret i undervisningen på 4. semester. Dette frameworks hierarkiske opbygning egner sig godt til de snit der senere skal foretages i forbindelse med distribueringen af et system. Ud over fordelene ved den hierarkiske struktur, er der for PCMEF også defineret nogle principper der sikrer en mere stabil og skalerbar opbygning. Der vil efterfølgende være en generel beskrivelse af en PCMEF og de førnævnte principper PCMEF arkitekturframeworket Dette arkitekturframework er lige som MVC hierarkisk opbygget og har derfor de samme fordele. Herunder er der en beskrivelse af lagene i PCMEF: Presentation Control Entity Mediator Foundation Dette lag indeholder klasser der definerer brugergrænsefladen. Brugerens interaktion med et system sker gennem klasserne i Presentation. Dette lag indeholder klasser der behandler forespørgsler fra Presentation. På grund af behandlingen er Control ansvarlig for en del af systemets beregninger under programafvikling. Denne pakke i domænelaget indeholder klasser der repræsenterer domæneobjekter beskrevet i analysen, og tager sig af forespørgsler fra Control, samt opbevarer data hentet fra databasen og data der skal gemmes i databasen, i form af objekter. Denne pakke i domænelaget indeholder klasser der tager sig af kommunikation mellem Entity og Foundation. Mediator tager sig af to ting, isolerer de to pakker i domænelaget og sørger for at Control-klasserne ikke behøver at kommunikere direkte med Foundation. Dette lag er ansvarlig for alt kommunikation med database, server og eksterne enheder. I dette lag bliver forbindelser til alle disse oprettet og overførsler af data sker herigennem. Tabel 6.2: Oversigt over pakker i PCMEF arkitekturframeworket. Tilføjes en ekstra pakke, acquaintance, som indeholder diverse interfaces som samtlige lag benytter sig af, kaldes arkitekturframeworket for PCMEF+. acquaintance-pakken er beskrevet i tabel 6.3. Lagdelingen i PCMEF+ er illustreret på figuren herunder: Figur 6.2: Grafisk illustration af PCMEF+ arkitekturframeworket Resultater Side 21 af 63

28 Der bliver i PCMEF+ defineret nogle principper, som gør et system mere robust, samt øger skalerbarheden og simplificerer vedligeholdelsen af systemet. Herunder er der en beskrivelse af disse principper: Downward Dependency Principle (DDP) Der må ikke forekomme afhængigheder af objekter der ligger i lag over objektet. Upward Notification Principle (UNP) Der skal sørges for at mindske mængden af kommunikation op igennem lagene. Det betyder objekter højere oppe i hierarkiet abonnerer på ændringer i de lavere lag. Neighbour Communication Principle (NCP) Der kan kun kommunikeres direkte mellem pakker der er i samme lag. Cycle Elimination Principle (CEP) Alle cirkulære afhængigheder skal elimineres. Dette kan sikres ved at anvende interfaces. Class Naming Principle (CNP) Der skal på klassenavne tilføjes det første bogstav fra den pakke som klassen tilhører, eks. SchoolClass i Entity kaldes ESchoolClass. Acquaintance Package Principle (APP) Der tilføjes en acquaintance-pakke som kun indeholder interfaces. Denne klasse sørger for at centralisere afhængigheder til en klasse samtidig med at tillade kommunikation mellem pakker der ikke er naboer. Et PCMEF framework hvor APP anvendes kaldes også PCMEF+. Tabel 6.3: Beskrivelse af designprincipper i PCMEF+ frameworket. 6.2 Anvendelse af designmønstre Det er muligt at optimere sit design ved anvendelse at designmønstre (design patterns), det kan for eksempel være at minimere afhængighed mellem pakker. Et designmønster er en generel løsning på et problem der ofte opstår i forbindelse med softwaredesign. Fordelen ved at anvende et designmønster er at det er en gennemtestet løsning på et generelt problem, som let kan integreres i designet af et system. Der vil efterfølgende være eksempler på designmønstre, der er anvendt i designet af HMS-systemet Facade pattern Dette designmønster bruges til at mindske kommunikation og afhængigheder mellem subsystemer, dette gøres ved at indsætte en abstrakt eller konkret dominant klasse der tager sig af størstedelen eller alt kommunikation med andre subsystemer. Der ses i figuren herunder et eksempel hvor Entity-pakken har en facadeklasse der tager sig af kommunikation med CActioner og MContactSMSModule: Figur 6.3: Illustration af facade designmønsteret Side 22 af 63 Resultater

29 Dette designmønster anvendes i forbindelse med Entity, som vist på figur 6.3, dette er valgt for at reducere antallet af forbindelser til Entity Mediator pattern Mediator designmønsteret betyder at der oprettes klasser der indkapsler kommunikation mellem objekter, der ikke nødvendigvis hører til samme pakke. Da der er valgt at anvende PCMEF+ frameworket benyttes Mediator designmønsteret i form af pakkerne Control og Mediator. Control formidler mellem Presentation-laget og Entity-pakken, mens Mediator formidler mellem Entitypakken og Foundation-laget. Dette kan ses på pakkediagrammer over HMSAdministration og HMSServer, som kan ses i afsnit 8.1. Resultater Side 23 af 63

30 7 Designstrategier Dette kapitel beskriver strategierne der er anvendt i designet af systemet i forbindelse med hvordan systemet skal udrulles, persistensgøres, samt håndtere adgangskontrol, kontrolflow og grænsevilkår. Designstrategierne vil blive behandlet for at sikre at softwarearkitekturen bliver stabil, skalerbar og vedligeholdelsesvenlig, samt at sørge for det bliver den bedst mulige løsning ud fra kravene til systemet. Der vil i de efterfølgende afsnit være en diskussion af hver af disse designstrategier for HMSsystemet, og til hvert afsnit vil der være en udvælgelse og begrundelse for valg af løsning. 7.1 Udrulning I dette afsnit forefindes en beskrivelse og en begrundelse for hvordan systemet er udrullet. Det er et krav fra TEK-BrobygningsCenters side at systemet skal kunne oprette besøgende i systemet via SMS og sende en SMS efter deltagelse i konkurrencen. Herudover skal systemet kunne udvides til at håndtere flere eksperimenter, samt tilbyde visning af konkurrencedata via internettet. Det er valgt at anvende et SMS-modul frem for en SMS-server, hos en ekstern leverandør, for at sikre en mere stabil modtagelse og udsendelse af SMS er. Derudover er det vigtigt for BrobygningsCenteret at besøgende har mulighed for at se denne del af systemet og samtidig har det også været et ønske fra BrobygningsCenterets side selv at administrere SMS-modulet. For at tage højde for de førnævnte krav er det nødvendig at: - Have en server der kan håndtere objekter der skal tilgås af de forskellige klienter. - Have en database hvor konkurrencedata kan lagres. - Have et SMS-modul tilsluttet en klient, så der kan sendes og modtages SMS er. Dette medfører at systemet bygges op omkring en centralt placeret server, med tre forskellige klienter tilkoblet. Løsningen af hvordan det udviklede software er udrullet ses illustreret i figur 7.1 herunder: Figur 7.1: Diagram over deployering af HMS-systemet. Side 24 af 63 Resultater

31 I tabellen herunder er der en beskrivelse af de klienter og servere systemet inddeles i, som illustreret i figur 7.1: HMSAdministration HMSClient HMSApplet HMSServer Beskrivelse: Denne klient er placeret i TEK- BrobygningsCenter og har et eksperiment og et SMS-modul tilsluttet. Denne klient er ligesom HMSAdministration placeret i TEK- BrobygningsCenter og har et eksperiment tilsluttet, men har færre funktionaliteter. Denne klient tilgås via internettet gennem en browser. Funktionaliteter: - Oprette en klasse. - Sende en test SMS. - Modtage SMS er. - Starte en konkurrence. - Starte deltagelse i konkurrence. - Demonstrere konkurrencen. - Oprette besøgende. - Redigere systemindstillinger. - Afslutte konkurrencen. - Deltage i konkurrencen. - Starte deltagelse i konkurrence. - Demonstrere konkurrence. - Se besøgendes konkurrencedata. - Se topscorelister, samlede resultater og disciplinresultater. - Følge en igangværende konkurrence. Denne serverapplikation tager sig af - Håndtere en skoleklasse oprettet af håndteringen af delte objekter i systemet, HMSAdministration. som skal tilgås af flere klienter. - Håndtere kommunikation med database. - Håndtere kommunikation med klienter. Tabel 7.1: Beskrivelse af klienter og servere i systemet. Det ses at HMSAdministration, der er placeret i TEK-BrobygningsCenter, har tilsluttet et SMSmodul og et eksperiment. HMSAdministration står derfor for både den generelle administration af konkurrencer, det tilsluttede eksperiment og SMS-modulet. En skoleklasse oprettes via HMSAdministration, men selve skoleklassen placeres på HMSServer 21, hvilket sikrer at klassen kan tilgås af de øvrige HMSClient s i TEK-BrobygningsCenter, samt af HMSApplet. HMSServer vil være placeret på samme intranet som klienterne i TEK-BrobygningsCenter, hvilket sikrer en hurtig dataoverførsel mellem klienterne i BrobygningsCenteret og serveren. Herudover vil det være muligt at oprette en klasse og afvikle en konkurrence selvom intranettet ikke skulle have forbindelse til internettet. Havde HMSServer været placeret hos en ekstern udbyder ville de førnævnte fordele ikke være opnået. Databaseserveren er ligeledes placeret på intranettet og har ikke forbindelse til internettet, denne tilgås via HMSServer som igen tilgås via internettet af HMSApplet. Da databaseserveren ikke har forbindelse til internettet øges sikkerheden i forbindelse med kommunikation med databasen, idet den ikke kan tilgås direkte fra internettet. 21 HMSServer skal placeres på en server som projektgruppen får stillet til rådighed gennem TEK-BrobygningsCenter. Resultater Side 25 af 63

32 7.2 Persistens Når et program afvikles, ligger dette og alle de tilhørende objekter i computerens hurtige hukommelse. For objekter eller data der bliver produceret under programafvikling, kan bruges efter programmet er lukket eller gemmes til næste gang det startes, anvendes persistens. Der er flere muligheder når data skal persisteres: Flad fil En flad fil ligger på den computer hvor programmet kører, data gemmes og hentes fra den flade fil når det er nødvendigt. Dette anvendes når der er meget data, data skal gemmes i kort tid eller når data kun bliver brugt sjældent Database En database er et system der tager sig af at gemme data. Der findes forskellige slags databaser, heriblandt relationelle databaser og objekt databaser. En relationel database anvendes når der skal foretages komplekse forespørgsler til databasen og hvis der er store datamængder. Objekt databasen benyttes når det er nødvendigt at gemme objekter direkte. Fordelen ved en database er at det er nemt at udtrække specifikke data fra databasen, og samtidig kan den tilgås og redigeres fra flere forskellige applikationer Valg af persistens I HMS-systemet bliver der anvendt en relationel database, da der er mange forskellige objekter i systemet der skal persisteres, og det vil derfor være nemmere at udtrække data om disse fra en database. Derudover har der i softwarekonstruktionsundervisningen været en introduktion til anvendelsen af database management systemet MySQL 22, som derfor benyttes i projektet. 7.3 Adgangsforhold I et program kan der være flere aktører der skal have forskellige rettigheder, og det skal i den forbindelse være muligt at kende forskel på aktørerne, samt være muligt at autentificerer aktørerne. I HMS bliver der på nuværende tidspunkt ikke anvendt nogen form for adgangskontrol, hvilket ikke er gjort da adgangskontrol ikke er vigtigt for systemet. Der er dog undersøgt forskellige fremgangsmåder hvorpå adgangskontrollen i fremtiden kan håndteres: Global adgangstabel En global adgangstabel indeholder alle aktører, klasser og metoder. Når en aktør vil anvende en klasse eller metode, kræver det at der slås op i adgangstabellen og kontrolleres om aktøren har lov til dette. Ulempen ved denne metode er at adgangstabellen bliver større med systemet og det bliver derfor langsomt at søge i den Adgangskontrolliste En adgangskontrolliste indeholder en liste af associationer mellem aktører og metoder. Hver gang en aktør tilgår et objekt bliver der kontrolleret om aktøren har lov til at anvende metoden. Ved anvendelse af adgangskontrolliste ved man hurtigt hvem der har adgang til et bestemt objekt Kapabilitet En kapabilitet er en association mellem en klasse og en aktør. Når en aktør vil tilgå en metode kontrolleres det om der er en association mellem aktøren og klassen, hvis der er en association får aktøren lov at tilgå klassen. Ved anvendelse af kapabilitet ved man hurtigt hvilke klasser en aktør har adgang til. I BrobygningsCenteret skal alle rundvisere have samme rettigheder og det er derfor ikke nødvendigt med individuelle brugere og dertilhørende kodeord. Der er derfor på nuværende tidspunkt et fælles 22 Programmer benyttet til arbejdet med MySQL er oplistet i programlisten, afsnit Side 26 af 63 Resultater

33 kodeord for alle rundvisere. Skal der senere anvendes en af de beskrevne fremgangsmåder, vil det være simplest at anvende og implementere global adgangskontrol. De beskrevne ulemper ved global adgangskontrol vil ikke blive aktuelle i HMS-systemet, da der på nuværende tidspunkt kun er to aktører. 7.4 Kontrolflow Når et program afvikles kan alle dele af koden ikke køre samtidig, da dette ville kræve resurser som ikke er til rådighed, derfor skal der i design tages højde for kontrolflow. Kontrolflow kan opbygges på følgende måder: Proceduredrevet kontrolflow Operationer venter på input fra brugeren hver gang dette er nødvendigt, denne metode fungerer ikke optimalt med objekt orienterede programmeringssprog, eftersom afviklingen af metoder er distribueret over et stort antal objekter. Proceduredrevet kontrolflow er godt til test af subsystemer, men bør undgås i et endeligt system Begivenhedsdrevet kontrolflow Et Main-loop modtager alle eksterne begivenheder og videregiver disse til de tilhørende objekter. Begivenhedsdrevet kontrolflow medfører en simpel programstruktur og centraliserer alle input til systemet, men komplicerer implementeringen af multistepsekvenser Trådning Trådning er en måde at håndtere flere proceduredrevne og begivenhedsdrevne kontrolflows samtidig. Ved anvendelse af trådning kan der opstå problemer hvis flere tråde skal dele en eller flere af de samme objekter, og der skal i den forbindelse eksempelvis laves foranstaltninger der sørger for at to eller flere tråde ikke forsøger at redigere i samme objekt samtidig. I designet af systemet bliver der anvendt trådning. Tråden der tager sig af SMS-modulet anvender proceduredrevet kontrolflow, dette gøres fordi SMS-modulet er en passiv enhed. Lige som tråden der tager sig af SMS-modulet anvender tråden der styrer konkurrencen også proceduredrevet kontrolflow. Dette gøres fordi HMH ligesom SMS-modulet er en passiv enhed. Den resterende del af systemet vil blive styret af begivenhedsdrevet kontrolflow. 7.5 Grænsevilkår Grænsevilkårene beskriver initialisering, terminering og sammenbrud af et system. Der er i HMS-systemet på nuværende tidspunkt ikke i detaljer defineret krav til grænsevilkår, da dette ikke har udgjort en risiko for udviklingen af systemet. Der er dog indført funktioner til opstart og afslutning af henholdsvis SMS-modul og HMH-enhed når HMSAdministration afsluttes. I fremtiden skal grænsevilkår håndteres af specifikke brugsmønstre og håndtering af sammenbrud vil blive udarbejdet i løbet af konstruktionsfasen. Resultater Side 27 af 63

34 8 Detaljeret design I det foregående afsnit blev der valgt at anvende PCMEF+ som arkitekturframework, og på baggrund af dette er der udformet et designklassediagram over domænet ud fra analyseklassediagrammet, beskrevet i kapitel 5. I overgangen fra analyse til design konverteres analyseforbindelser i domænet til aggregerings- og kompositionsforbindelser, og der tilføjes attributter og metoder i klasserne. Efter domænet er konverteret fra analyse til design, vil dette blive placeret i pakken Entity i domænelaget i PCMEF+, efterfølgende vil kontrol- og kommunikationsklasser blive tilføjet til de respektive lag i arkitekturframeworket. Det færdige designklassediagram for Entity er placeret i bilag 6 og kan foldes ud ved siden af rapporten. 8.1 Design af Opret konkurrencedeltager(b9) I dette afsnit gennemgås designet af brugsmønster B9. Designinteraktionsdiagrammet forefindes i bilag 7 som fold-ud diagram bagerst i rapporten. Når en ny klasse er oprettet, kan besøgende oprette sig selv som deltagere ved at sende en SMS til SMS-modulet. Klassen CSMS styrer SMS-modulet og er dermed ansvarlig for oprettelse af nye konkurrencedeltagere. SMS-modulet er en passiv enhed, og kan kun gøre 1 ting ad gangen. Dette afspejles i designet af CSMS, idet den afvikles af en separat tråd. Diverse forespørgsler som CSMS modtager fra Presentation, kan ikke udføres med det samme, da SMS-modulet først skal blive færdig med sit igangværende job. Forespørgsler må derfor stilles i kø, og dette løses ved at ændre de tilhørende attributter i CSMS. Der foretages et regelmæssig tjek på værdier af disse attributter, når SMS-modulet er klar til at udføre en ny opgave. Når der oprettes en ny skoleklasse, ændres værdien af maycreatevisitors til true. CSMS finder på den måde ud af, at der må oprettes nye konkurrencedeltager, og begynder at læse SMS er fra SMS-modulet. Dette er illustreret i sekvensdiagrammet, hvor metoden createvisitors() i MContactDatabase, bliver kaldt regelmæssigt så længe maycreatevisitors er true. Der beskrives nu kort sekvensen for oprettelse af nye besøgende. createvisitors() i MContactDatabase får FSMSCommunication til at hente en SMS fra SMS-modulet med readsms(), kontrollere om den overholder den korrekte syntaks med syntaxcontrol(), og uddrage den besøgendes informationer fra SMS en, hvis den er skrevet korrekt. MContactDatabase kalder derefter createvisitor() på ESchoolClass med de besøgendes informationer som parametre. ESchoolClass opretter et nyt Visitor objekt og tilføjer den til listen over dens besøgende med addvisitor(). Den nye konkurrencedeltager figurerer dermed i systemet, og kan nu deltage i konkurrencen. 8.2 Design af Deltag i konkurrence (B10) I dette afsnit gennemgås designet af brugsmønster B10. Designinteraktionsdiagrammet forefindes ligeledes som fold-ud diagram bagerst i rapporten i bilag 8. Når en besøgende er oprettet som konkurrencedeltager, kan brugsmønsteret Deltag i konkurrence (B10) startes. Når konkurrencedeltageren har angivet sit mobilnummer, invokeres metoden initparticipation() i CActioner, der finder den aktuelle besøgende og henter antallet gange den besøgende har deltaget i konkurrencen. Hvis antallet er under den maksimale tilladte, hentes den besøgendes navn, og sendes til præsentationslaget. Konkurrencen startes med metodekald run() på CRunCompetition. Der bliver først hentet informationer om hvilke discipliner der skal køres i konkurrencen med getdisciplineinfo() i ECompetition. Metoden returner disciplinernes portnumre og startsignaler. writedata() i FExperimentCommunication invokeres derpå, og den sørger for at sende startsignaler på den rigtige port nummer, således at eksperimenternes microcontroller kan køre igennem de valgte discipliner. readdata() i FExperimentCommunication læser måleresultater fra eksperimenterne og returnerer dem til MContactExperiment, der gemmer midlertidigt data og returner dem til et højere lag, så de vises på skærmen. Side 28 af 63 Resultater

35 Når et stopsignal ankommer fra HMH-enheden, udregnes den samlede score for en disciplin med calculatescore() der sammen med det midlertidige data overføres til et nyt Result objekt. Hvis den besøgende har et resultat i forvejen, sammenlignes de to samlede scorer, og hvis det nye Result er bedre, bliver den nye Result tilknyttet til den besøgende på bekostning af det gamle. Konkurrencen gennemføres for alle tilknyttede discipliner, og sekvensforløbet afsluttes ved at antallet af gange en besøgende har prøvet konkurrencen bliver forøget. Resultater Side 29 af 63

36 9 Distribution I kapitlet gennemgås de distributionsmønster som der er blevet undersøgt i forbindelse med distribuering af systemet, fordele og ulemper for de forskellige distribueringsmønster vil blive gennemgået og de mest passende distribueringsmønster vil blive udvalgt. Derefter vil der være en gennemgang af fordele og ulemper ved de kommunikationsformer som er blevet undersøgt. På baggrund af dette vil den mest optimale kommunikationsform for systemet blive udvalgt. 9.1 Distribueringsmønster Der vil i dette afsnit være en beskrivelse af de distributionsmønstre som er blevet undersøgt til distribuering af HMS-systemet. På baggrund af kravene til systemet og de forskellige fordele og ulemper distribueringsmønstrene tilbyder, vil den rette distributionsform blive udvalget. Figur 9.1: Illustration af distribueringsmønstre Distributed Presentation Dette distribueringsmønster medfører at præsentationslaget opdeles, hvilket giver meget tynde klienter. Ved anvendelse af dette distributionsmønster ligger en del af brugergrænsefladen på klienten, resten af applikationen ligger på serveren. Det kræves at serveren har stor regnekraft eller at applikationen der skal afvikles kræver få beregninger, da der ellers vil opstå problemer når mange klienter tilgår serveren samtidig Remote User Interface Dette distribueringsmønster medfører at hele præsentationslaget og hele eller dele af dettes kontrollaget distribueres, hvilket giver en lidt tykkere klient end distribueret præsentation. Ved anvendelse af dette distribueringsmønster ligger hele brugergrænsefladen på klienten. Ligesom ved Distributed Presentation kræves der en kraftig server til at håndtere klientforespørgslerne Distributed Application Kernel Distribueringsmønstret medfører at præsentationslaget, kontrollaget og dele af applikationskernen distribueres, hvilket giver en kompliceret implementering af den valgte kommunikationsform. Dette distribueringsmønster medfører desuden en tyk klient. Ved anvendelse af dette distribueringsmønster bliver brugergrænsefladen og en del af applikationen afviklet på klienten, dette aflaster serveren, ved at lade klienterne tage sig af nogle af beregningerne Remote Database Dette distribueringsmønster medfører at hele præsentationslaget, kontrollaget og applikationskernen er distribueret, hvilket giver en meget tyk klient og en mindre kompliceret implementering end ved Distributed Application Kernel, samt fjerner en masse arbejde fra serveren, som kun skal tilbyde en database. Ved anvendelse af dette distribueringsmønster skal der kun tilgås data fra en 23 Kilde 13 Side 4 Side 30 af 63 Resultater

37 databaseserver og det resulterer i at klienten tager sig af alle beregningerne. På den måde aflastes serveren Distributed Database Dette distribueringsmønster medfører at noget af databasen bliver lagt på klienten, den del der ligger på klienten kan være en cache der indeholder ofte tilgået data fra databasen. 9.2 Valg af distribueringsmønster På baggrund af de gennemgåede distribueringsmønstre beskriver dette afsnit distribueringen for de tre klienter HMSAdministration, HMSClient og HMSApplet. Det er valgt at inddele systemet i tre tiers, og herunder følger en beskrivelse af de enkelte klienter HMSAdministration og HMSClient Det er valgt at designe HMSAdministration efter Distributed Application Kernel fordi klienten skal have en del af applikationskernen til at styre eksterne enheder, herunder HMH-enheden og SMSmodulet. Den del af applikationskernen, der indeholder konkurrenceelementer skal befinde sig på HMSServer, da den skal være tilgængeligt for alle klienter. HMSClient vil blive designet på samme måde når denne klienttype skal udvikles, da klienten også skal håndtere et eksperiment HMSApplet HMSApplet er opbygget som et Remote User Interface, da denne klient har en grafisk brugergrænseflade der indeholder nogle af de funktionaliteter som forefindes i HMSAdministration. Dermed skal den have præsentation og kontrol, men ikke en applikationskerne da den ikke skal styre en ekstern enhed eller foretage tunge beregninger. Herunder ses distribueringen af HMS-systemet. Figur 9.2: Illustration af distribueringen af HMS-systemet. Resultater Side 31 af 63

38 9.3 Pakkediagram over system På baggrund af den valgte distributionsform er systemet inddelt i de pågældende subsystemer, som dermed kan distribueres på de forskellige enheder. På pakkediagrammet herunder er angivet hvorledes systemet er opdelt. På diagrammet er kun medtaget de centrale klasser for at højne læsbarheden. For en yderligere dokumentation af indholdet af de enkelte pakker henvises til designklassediagrammer for de enkelte pakker som forefindes på cd en. Diagram 9.1: Pakkediagram over distribution af system. Side 32 af 63 Resultater

39 9.4 Valg af kommunikationsform I det følgende afsnit beskrives de tre kommunikationsformer for distribuerede systemer som gruppen valgt at undersøgte nærmere, for at finde den bedste løsning til kommunikation mellem henholdsvis HMSAdministration og HMSServer, samt HMSApplet og HMSServer. Der vil først være en kort beskrivelse af de tre kommunikationsformers fordele og ulemper for henholdsvis servlet-, socket-, og RMI-kommunikation. Til sidst i afsnittet vil den kommunikationsform som er mest velegnet til HMS bliver udvalgt Servlet En servlet er en Java-applikation der kører på en server og dynamisk generer webindhold til klienten. Eksempelvis kan det være en forespørgsel fra klienten om noget data fra en database, som servletten modtager, behandler ved at hente data fra en database, og til sidst genererer Html-kode som indeholder de forespurgte data til klienten. En servlet har hele Java API til rådighed og kan derfor være en god løsning i avancerede webapplikationsprojekter. Derudover foretages hele regnearbejdet på serveren, hvor servletten kører. Ved denne kommunikationsform er klienten meget tynd, og kommunikationen med servlet foregår ved hjælp af HTTP 24 gennem en browser. Denne løsning passer fint til arkitekturframeworket Distributed Presentation, men da dette framework ikke bliver brugt til distribuering af HMS-systemet, er denne løsning ikke at foretrække Socket Socket er en API 25 til at håndtere interprocess-kommunikation over et netværk, og er en bindeled mellem applikationerne og selve netværket. Når en socket modtager data fra et netværk, sørger den for at videregive data til den rigtige applikation. Ligeledes modtager en socket data fra en applikation og videregiver det til netværket. Denne kommutationsform passer godt til overførsel af strenge, og der er mulighed for overførsel af objekter med ObjectInputStream og ObjectOutputStream. For at overføre et objekt, skal klassen være defineret både på klient- og serversiden. Hvis systemet skal udvides, er det en begrænsning, for kun den nyeste version af klienten vil fungere RMI RMI står for Remote Method Invocation. Med RMI er det muligt via en Java-applikation på en klient, at få tilgang til objekter og metoder der befinder sig på en server. Dette kræver dog at objekter på serveren implementerer et remote-interface, der skal indeholde alle de metoder, som klienten skal benytte. Desuden skal interfacet også forefindes på klienten. I det følgende beskrives RMI princippet. Først registreres et fjernobjekt på serveren med et alias i RMI Registry, så klienten kan undersøge om serverobjektet er tilgængeligt ved at foretage en søgning i RMI Registry på det alias. RMI Registry er en slags telefonbog på fjernobjekter. Hvis RMI Registry finder en match, returneres en stub for fjernobjektet til klienten og bliver til en reference på klientens remote-interface. En stub er et objekt der er ansvarlig for RMIkommukationen til fjernobjektet på klientsiden. Stubben pakker metodeinformationerne ind (marshalling) og sender dem til serveren. Serveren pakker informationerne ud og udfører metoden. Har metoden en returtype, pakkes den ind og sendes til stubben. RMI s stærke side er, at metoderne der kaldes på serveren, kaldes som om de ligger på klienten. Dette betyder at programmøren af klienten ikke skal bekymre sig om hvordan metoden er implementeret på serveren. RMI understøtter Dynamic Class Loading, på den måde kan klienten blive opdateret med de nyeste versioner af class filer under programkørsel, hvilket gør løsningen mere fleksibel. 24 HyperText Transmission Protocol 25 API: Application Programming Interface Resultater Side 33 af 63

40 9.4.4 Valg af løsning Arkitekturframeworks Remote User Interface og Distributed Application Kernel bliver implementeret på den bedste måde ved at foretage et så lille indgreb i det ikke-distribuerede system som muligt, og dette giver RMI mulighed for ved implementering af de førnævnte interfaces. RMI kommunikationsform er velegnet til HMS-systemet, fordi de to klienter, henholdsvis HMSAdministration og HMSApplet skal tilgå mange objekter og metoder på HMSServer. Derudover er det praktisk ved implementeringen, at metoderne kaldes på serveren som om de befinder sig på klienten. Beskrivelsen af hvordan RMI er implementeret i HMS-systemet gennemgås i afsnit Side 34 af 63 Resultater

41 10 Anvendelse af persistens Når en konkurrence er i gang, eksisterer en skoleklasse og de tilhørende besøgende som objekter på HMSServer, i dens primære hukommelse. Når en ny SkoleKlasse oprettes, fjernes referencen til den gamle SkoleKlasse, og objekterne bliver hermed fjernet fra hukommelsen. Den gamle SkoleKlasse skal derfor gøres persistent før en ny SkoleKlasse bliver oprettet, for at opfylde krav F35: F35 Tilgang til data HMS skal give den besøgende mulighed for at se sine præstationer efter endt konkurrencedeltagelse. Det skal være muligt at se resultatet for hver af de discipliner den besøgende har deltaget i. Tabel 10.1: Uddrag fra kravmodel: Krav F35 angående tilgang til data efter endt konkurrencedeltagelse. I afsnit 7.2 blev den relationelle database valgt som persistenstype, og MySQL som relationel database management system. I de følgende afsnit følger en beskrivelse af hvordan mapningen fra domænemodel til relationel database er udført, samt nogle eksempler på hvordan data bliver gemt og hentet ved brug af SQL-sætninger Mapning af domænemodel til database Det er ikke nødvendigt at gøre hele domænemodellen persistent, kun de klasser der bliver brugt af HMSApplet: SchoolClass, Visitor og Result. Appletten har dermed alle resultater til rådighed, disse kan sorteres efter skoleklasser og besøgende. Da klassen Discipline indeholder opstartsignaler der skal hentes af alle de klienter der har eksperimenter tilkoblet, skal denne også gøres persistent. Domænemodellen over de persistente klasser og deres attributter ses på figur Figur 10.1: Domænemodel over persistente klasser og deres attributter. Den relationelle database består af en samling af tabelbaserede relationer, hvis rækker repræsenter data, og kolonner repræsenter datatyper. Der må derfor ske en mapning fra den objekt-orienterede domænemodel til den tabel-orienterede databaseopbygning. Som regel bliver alle klasser og dennes attributter i domenæmodellen mappet over i en ny tabel, men af og til kan en klasse blive splittet op i flere tabeller, og omvendt. Der skal også tages højde for associationer mellem klasserne, da mapningen i tilfælde af mange-til-mange associationer kun er realiserbare ved tilføjelser af nye tabeller. Domænemodellen over persistente klasser indeholder kun kompositionsforbindelser, og der skal derfor ikke tilføjes nye tabeller. Når der oprettes en tabel, benyttes indeksering af alle rækker, således at alle mappede objekter får et unikt indeks, der betegnes som en primærnøgle (primary key). Primærnøglen kan benyttes som reference i andre tabeller, hvor den bliver til en sekundærnøgle (foreign key). Nøgler er Resultater Side 35 af 63

42 uundværlige når flere tabeller skal sættes sammen. Primærnøgler er også nyttige når et bestemt mappede objekt skal findes i databasen. Da der er en kompositionsforbindelse fra SchoolClass over til Visitor, skal sletningen af en række og hermed en primærnøgle i SchoolClass, medføre til kaskadesletning af rækken i Visitor, hvor der forefindes en sekundærnøgle for den pågældende SchoolClass. På figur 10.2 illustreres den logiske databasemodel over databasens tabeller. Det skal bemærkes at MySQL ikke understøtter datatypen arrays, derfor gemmes resultdata(disciplinedata) som en lang streng, hvor alle målinger adskilles med kommategn. Alternativet er at oprette en ny tabel til resultdata, hvor hver måling har i en kolonne for sig. Da der på intet tidspunkt skal hentes et bestemt måling fra databasen, er dette blevet vurderet til at være en dårligere løsning. schoolclassid = schoolclassid 1..* visitorid = visitorid 1 disciplineid = disciplineid 1..* Figur 10.2: Logiske databasemodel Oprettelse og manipulation af tabeller SQL er et programmeringssprog til relationelle databaser og giver mulighed for: - Oprette, ændre og nedlægge en tabel. - Udvælge, indsætte, rette og slette data i en tabel. - Kontrollere brugernes adgang til database. Der følger nu et eksempel på oprettelse af en tabel, et eksempel på udvælgelse af data, og et eksempel på indsætning af data i en tabel. Alle eksempler er taget fra HMS-systemet. Til at oprette af en ny tabel i databasen benyttes SQL-sætningen CREATE TABLE. SQLsyntaksen for den typiske anvendelse af denne kommando ses i tabel I tabel 10.2 vises et eksempel, hvor tabellen discipline oprettes. Det skal bemærkes at disciplineid er sat til AUTO_INCREMENT, så et unikt ID tildeles automatisk når en ny række indsættes. CREATE TABLE [table name] ( [column definitions] ) [table parameters] Tabel 10.1: Syntaks for oprettelse af tabel. Side 36 af 63 Resultater

43 CREATE TABLE hms.discipline Tabel 10.2: Oprettelse af tabellen discipline. Når data skal udvælges fra en tabel, benyttes SQL-sætningen SELECT. En forenklet syntaks for denne SQL-sætning ses i tabel SELECT [select expr] FROM [table references] WHERE [where condition] Tabel 10.3: Syntaks for udvælgelse af data. I SQL-sætningen SELECT skal der specificeres hvilke kolonner der skal hentes, og de bliver returneret som resultset, som er en sæt af rækker med de udvalgte kolonner der indeholder det fundne data. En condition kan sættes på for at afgrænse søgningen efter data. I tabel 10.4 vises et eksempel, hvor der hentes name på disciplinen og disciplineid for alle discipliner, som en besøgende med visitorid 10 har et resultat i. Da de to kolonner befinder sig i forskellige tabeller, benyttes NATURAL JOIN til at sætte tabellerne sammen, således at en række fra Result bliver forlænget med en række fra Discipline, hvor nøglerne er identiske. De to kolonner bliver derefter udvalgt fra den sammensatte række, og dermed fås det ønskede resultset. SELECT FROM hms.result Tabel 10.4: Udvælgelse af data fra discipline for en bestemt besøgende. Når data skal indsættes i en tabel, benyttes SQL-sætningen INSERT INTO, hvis syntaks for den typiske anvendelse ses i tabel INSERT INTO [table name] ( [column definitions] ) VALUES ( [values] ) Tabel 10.5: Syntaks for indsætning af data. I tabel 10.6 ses et eksempel på indsætning af data, hvor en ny skoleklasse bliver tilføjet til SchoolClass. Det skal bemærkes at schoolclassid (der har AUTO_INCREMENT) tildeles automatisk, når dens værdi er angivet til null. Den tildelte primærnøgle kan hentes ved SQLsætningen LAST_INSERT_ID(). INSERT INTO hms.schoolclass Tabel 10.6: Indsætning af data for en skoleklasse. I dette afsnit blev det beskrevet hvorfor der benyttes en database, hvordan mapningen fra domænemodellen til databasen er udført, og der er vist eksempler på de anvendte SQL-sætninger. I afsnit 11.3 følger en beskrivelse af, hvordan databaseadgang er implementeret i Java, eksemplet med udvælgelse af data fra dette afsnit føres videre. Resultater Side 37 af 63

44 11 Implementering Dette kapitel indeholder en redegørelse af de centrale dele af implementeringen. Der vil derfor være en beskrivelse af hvordan den serielle kommunikation, SMS-kommunikation, databaseadgangen og RMI er implementeret i systemet. Til sidst i kapitlet vil der være en beskrivelse af hvordan systemets brugergrænseflade er udviklet Implementering af seriel kommunikation I dette afsnit beskrives hovedtræk i implementeringen af den serielle kommunikation i HMSsystemet. Til seriel kommunikation benyttes en RxTx driver 26 og RxTx API. Som et alternativ kunne Java Comm API 27 blive anvendt, men da dette ikke længere opdateres af Sun og der ikke findes drivere til Linux, hvilket gør applikationen systemafhængig, vælges det førstenævnte Etablering af forbindelse Opsætning af den serielle kommunikation med HMH-enheden er vist i kildekode SMSmodulet opsættes på samme måde om HMH-enheden, med de undtagelser at der vælges en anden baud rate 28, og der benyttes en anden COM-port. Som det første led i opsætningen, skal et objekt af klassen CommPortIdentifier instantieres [linje 35] med metodekald getportidentifier(). Denne klasse en ansvarlig for kontrol af adgang til COM-porte, og det instantierede objekt benyttes til at åbne en ny seriel forbindelse på den udvalgte COM-port [linje 46]. Referencen på den åbnede port, gemmes som et nyt SerialPort objekt. Dernæst opsættes portindstillinger [linje 47], baud rate, antal af databits og stopbits, samt parity kontrol, med metoden setseriealportparams() på SerialPort. Uddrag af: initexperimentconnections() i FExperimentCommunication Kildekode 11.1: Opsætning af seriel kommunikation 26 RxTx er et bibliotek der tilbyder seriel og parallel kommunikation for JDK. Se 27 Java Comm API 28 Hastigheden af den serielle kommunikation. Side 38 af 63 Resultater

45 Skrivning af data Den nye serielforbindelse tilføjes til et HashMap, comports [linje 49]. med COM-portens nummer som key. Hvis HMS-systemet udvides med flere eksperimenter, ville dette objekt indeholde alle de serielle forbindelser til eksperimenter der er tilsluttet til den aktuelle klient. I kildekode 11.2 ses hvordan comports bliver anvendt. Metoden writedata() skriver et tal på den valgte seriel port. Nummeret på porten angives som parameter, og bliver brugt til at slå op i comports, der returner SerialPort objektet. Derefter kan selve skrivningen foretages ved anvendelse af OutputStream s metode write(). Ligeså anvendes read() fra InputStream til at læse data fra en seriel port. writedata() i FExperimentCommunication Kildekode 11.2: Skrivning af data på COM-port Implementering af SMS-kommunikationen Metoden readsms(), som læser SMS er fra SMS-modulet, anses for at være den vigtigste i klassen FSMSCommunication. Derfor gennemgås implementering af denne metode i dette afsnit. I beskrivelsen af metoden antages det, at designsekvensdiagrammet for brugsmønster Opret konkurrencedeltager (B9) og teknisk memo for SMS-modul (bilag 4) er gennemlæst. Metoden behandler den indlæste SMS-besked og returner en String[] med besøgendes mobilnummer, køn, alder og navn. Hvis der er fejl i SMS, returneres kun den besøgendes mobilnummer. For at indlæse SMS-beskeden [linje 181], sendes AT-kommando AT+CMGR til SMSmodulet, med nummeret på SMS en der skal indlæses. Metoden writeat() er ansvarlig for selve kommunikationen med SMS-modulet, og returner modulets respons, hvilket er en streng med de ønskede SMS-informationer i dette tilfælde. Det første der sker efter indlæsning, er kontrol om responsen indeholder en SMS-besked. Hvis responsen er +CMGR: 0,,0 betyder det at beskeden ikke findes, og dette bliver fanget i en ifsætning [linje 183]. Der laves en substring af responsen [linje 184] på den plads hvor mobilnummeret er angivet. SMS-modulet returner mobilnummeret i HEX og i UCS2-format, derfor foretages der en konvertering til UTF8-format med decodeucs2(). Derefter læses den næste linje af responsen [linje 185], der har selve indholdet af SMSbeskeden. Lige som mobilnummeret, konverteres denne til UTF8-format. Der kontrolleres om SMS-beskeden overholder den korrekte syntaks [linje 186] med syntaxcontrol(), der returnerer en boolean. Hvis meddelelsen er skrevet korrekt, udrages køn, alder og navn og gemmes i det array der returneres til sidst. Resultater Side 39 af 63

46 readsms() i FSMSCommunication Kildekode 11.3: Læsning af SMS. Dette afsnit omhandlede metoden readsms() der læser SMS er fra SMS-modulet og udrager den besøgendes informationer fra SMS en Implementering af database I dette afsnit beskrives hvordan databaseadgang er implementeret i Java. Databaseadgang dækker etablering af forbindelse til database, sende forespørgsler til databaser, og behandling af resultaterne fra forespørgslerne. I kapitel 10 gennemgås eksempler på anvendte SQL-sætninger i HMSsystemet. I dette afsnit beskrives hvordan disse kan blive implementeret i Java Impedance mismatch Et af de store problemer i kommunikationen mellem applikationsprogrammer og relationelle databaser er, at applikationsprogrammer ikke kan manipulere direkte med data uden brug af SQL. Dette problem betegnes som Impedace mismatch, og skyldes at SQL manipulerer data som mængder af rækker, mens applikationssprog manipulerer data som individuelle poster. For at løs dette problem benyttes JDBC, som er en Java API der definerer hvordan en Java applikation kan tilgå rationelle databaser. I de følgende eksempler illustreres hvordan API en bliver brugt til at foretage SQL forespørgsler Etablering af forbindelse Det der oversætter JDBC-kaldene til SQL-sætninger, er en JDBC-driver. Driveren skal registres, dette sker ved at indlæse driveren, som registrer sig selv i JDBC-systemets drivermanager. Indlæsning af driveren ses i kildekode 11.4: Uddrag af: FDatabaseCommunication() i FDatabaseCommunication Kildekode 11.4: Indslæsning af JDBC-driveren Når driveren er registreret, kan forbindelsen til database oprettes. Til dette benyttes metode getconnection(), fra DriverManager, der forsøger at oprette forbindelse til den angivende database URL. Metoder returnerer en Connection, der bliver gemt som et objekt, conn, således at Side 40 af 63 Resultater

47 der kan foretages databasekald på denne Connection senere hen. Oprettelse af en databaseforbindelse ses i kildekode 11.5: initdatabasecommunication() i FDatabaseCommunication Kildekode 11.5: Oprettelse af forbindelse til database Udvælgelse af data I det følgende beskrives hvordan data bliver hentet fra databasen, og der tages udgangspunkt i SQLsætning fra tabel 10.4 fra forrige kapitel, hvor der hentes disciplindata for en angivet besøgende. Kildekoden for dette eksempel ses i kildekode Forespørgslen på databasedata foretages [linje 140] ved først at oprette et Statement objekt med createstatement() på conn, og derefter executequery(string sql) på det nye Statement objekt. SQL-sætningen kan altså indsættes direkte som parameter i metoden, hvilket er ret brugervenligt. executequery(string sql) returner [linje 141] et ResultSet objekt, resultset, som indeholder data fra databaseforespørgslen. For at læse en streng fra resultset, benyttes [linje 146] dennes metode getstring(string columnname) eller getstring(int columnindex). Der skal altså angives strengens placering, og det kan gøres enten ved at angive kolonnens navn eller dennes indeks. For at gøre kildekoden mere overskueligt, angives kolonnens navn. resultset tilbyder metoder til at læse andre datatyper, blandt andet boolean, int, double og Time. Data kan kun læses fra én række ad gangen, derfor benyttes [linje 144] en while-løkke til at hente data fra alle rækker. getvisitordisciplines() i FDatabaseCommunication Kildekode 11.6: Implementering af udvælgelse af disciplindata for en bestemt besøgende Resultater Side 41 af 63

48 I dette afsnit blev der kort beskrevet hvordan databaseadgang i HMS-systemet er blevet implementeret. FDatabaseCommunication består af flere forskellige databasekald, men disse bliver ikke beskrevet i rapporten, da deres struktur ligner eksemplet den gennemgåede kildekode Implementering af RMI Dette afsnit indeholder en kort beskrivelse af hvordan kommunikationsformen RMI er implementeret i HMS-systemet. HMSServer har to remote interfaces AIEntity og AIContactDatabase, der også forefindes på HMSAdministration og HMSApplet. Klassen EEnity på HMSServer implementer AIEntity, og da det er en facadeklasse til domænelaget, kan alle domæneobjekter tilgås fra klienterne gennem dette interface. På samme måde har AIContactDatabase metoder fra MConctactDatabase, og dermed kan klienterne foretage databasekald gennem interfacet Etablering af forbindelse Opstart af RMI kommunikationen på serversiden ses i kildekode Først skal RMI Registry startes op [linje 19], og derefter skal fjernobjekter registreres [linje 30]. Klassen Naming benyttes til at registrere fjernobjekter i RMI-registry med de angivende aliasser. Klienterne anvender disse aliasser, når de slår op i RMI Registry for at få fat i de tilhørende fjernobjekter. For overskuelighedens skyld benyttes klassenavnene, Entity og ContactDatabase. Uddrag af: main() i InitHMSServer Kildekode 11.7: Opstart af RMI-registry og binding af fjernobjekter. Opstart af RMI kommunikationen på klientsiden illustreres i kildekode Denne gang benyttes klassen Naming til at hente en stub for fjernobjektet med det angivende navn [linje 21]. Interfacet aientity får stubben som en reference, og der kan nu kan foretages metodekald på fjernobjekter ved kald på interfacet. Uddrag af: CAdministration() i CAdministration Kildekode 11.8: Klienten finder fjernobjektet på serverens RMI-registry. Side 42 af 63 Resultater

49 Metodekald på fjernobjekter Et eksempel på metodekald er vist i kildekode Der hentes et klassenavn med getnameofclass() og et navn på skolen med getschool() [linje 50] for en eksisterende skoleklasse, med kald på aientity. Det ses hermed, at klienten ikke kender til implementering af metoderne, men kan benytte dem alligevel som om den ligger på klienten. getclassinfo() i CActioner Kildekode 11.9: Metodekald fra klienten på fjernobjekter I dette afsnit bliver det gennemgået hvordan RMI-kommunikationen er implementeret. Dennes klare fordel, kald af fjernobjekter på serveren som om de ligger på den lokale maskine, er blevet illustreret Udvikling af brugergrænseflade Dette afsnit indeholder en kort beskrivelse af hvordan den grafiske brugergrænseflade (GUI 29 ) til IT-systemet er blevet udviklet og implementeret i præsentationslaget. Gennem hele elaborationen er der lagt meget tid i udviklingen af en grafisk brugergrænseflade til IT-systemet. Dette valg skyldes primært at det har været vigtigt at det udviklede software løbende kunne præsenteres overfor kunden, i dette tilfælde TEK-BrobygningsCenter. Hermed var det muligt for BrobygningsCenteret hele tiden at have mulighed for at følge med i udviklingsforløbet og funktionaliteten af systemet. Samtidig har det fra TEK-BrobygningsCenters side været meget vigtigt at det udviklede system var interaktivt og let tilgængeligt, i overensstemmelse med centerets vision, hvilket betød at den grafiske brugergrænseflade havde stor betydning. Ud over at det gennem projektperioden har været vigtigt at kunne illustrere systemets funktionaliteter overfor BrobygningsCenteret, på en ordentlig måde, havde gruppen samtidig ingen erfaring med udvikling af GUI til softwaresystemer, og det har derfor været nødvendigt at udvikle denne færdighed tidligt i projektperioden. Udviklingen af brugergrænsefladen foregik ved først at indtegne mockups for hvert skærmbillede, som illustrerede selve indholdet at de enkelte menuer. Disse mockups blev præsenteret for TEK- BrobygningsCenter som hermed kunne komme med feedback og rettelser. Efter godkendelsen fra BrobygningsCenterets side kunne selve implementeringen af GUI en fortsætte. Implementeringen af brugergrænsefladen blev herefter udført ved benyttelse swing-biblioteket i Java. Swing er et indbygget API 30 til udvikling af GUI i Java, biblioteket indeholder de nødvendige komponenter til opbygning af en grafisk brugergrænseflade. Ved at lade en klasse arve fra en eksisterende swing-komponent er det muligt at tilpasse komponentens udseende til det ønskede grafiske design. 29 GUI: Graphical User Interface 30 API: Application Progamming Interface Resultater Side 43 af 63

50 Et eksempel på mockup og endelig udformning af brugergrænseflade kan ses i tabellen herunder: Første forslag til brugergrænsefladen: Endelig udgave brugergrænseflade: Tabel 11.1: Eksempel på mockup og endelig udformning af brugergrænseflade implementeret i systemet. Tilsvarende billeder af den resterende del af den implementerede brugergrænseflade kan desuden forefindes på cd en under Design af brugergrænseflade. Idet GUI en blev opbygget på grundlag af eksisterende komponenter, blev der ikke foretaget analyse og design af præsentationslagets udformning. Fremgangsmåden var dermed i stil med Extreme Programming, hvor brugergrænsefladen blev bygget op direkte som kildekode, i takt med at den skulle benyttes, når de enkelte brugsmønstre blev implementeret. Dette var desuden muligt på baggrund af valget af arkitekturframeworket PCMEF+, hvor præsentationslaget er et selvstændigt lag. Der blev sideløbende med implementeringen af præsentationslaget indtegnet designklassediagrammer over den producerede kode for at kunne dokumentere udformningen af de enkelte komponenter og for at skabe overblik over lagets funktionaliteter. Disse designklassediagrammer kan forefindes på cd en. Det blev desuden besluttet at konstruere hele præsentationslaget manuelt, og dermed kode det hele fra bunden, frem for at benytte et IDE 31, såsom NetBeans 32 eller lignende. Dette valg blev foretaget idet det dels havde været nødvendigt for gruppen at sætte sig ind i brugen af et helt nyt udviklingsværktøj, og da det derudover er nødvendigt at have en grundlæggende forståelse af opbygningen af de enkelte komponenter i swing-biblioteket, hvilket kun kan opnås ved at programmere koden manuelt. Samtidig ville det alligevel have været nødvendigt manuelt at konstruere enkelte komponenter, blandt andet til dynamiske indtegning af grafer som er illustreret til højre i tabel På nuværende tidspunkt er implementeret grafiske brugergrænseflades som dækker alle de brugsmønstre som er implementeret. Det implementerede GUI er som nævnt dokumenteret og dokumentationen er vedlagt på cd en. I takt med at de resterende dele at programmet implementeres vil brugergrænsefladen ligeledes blive udvidet, og fejl og mangler som opdages løbende under test af systemet vil blive rettet. I kraft af at der ikke er foretaget design af præsentationslaget planlægger gruppen at udføre refaktorering af hele laget for at optimere den producerede kode. Refaktoreringen foretages for at rydde ud i overflødig kode og for at optimere måden det er implementeret på, uden at ændre på funktionaliteten. 31 IDE: Integrated Development Environment. 32 NetBeans IDE er et udviklingsmiljø tilsvarende Eclipse, men med indbyggede funktioner til konstruktion af GUI. Side 44 af 63 Resultater

51 11.6 Analyse af måleværdier fra HMH-enheden I dette afsnit analyseres måleværdier fra HMH-enheden, og der beskrives hvordan fejlværdier lokaliseres og rettes af softwaresystemet. Under afprøvning af HMH, er en fejl fra microcontrollerens side blevet opdaget. I meget sjældne tilfælde, modtager HMSClient en værdi, der åbenlyst ligger langt fra forrige og efterfølge sampleværdier, som vist på figur De forkerte måleresultater bliver i den videre beskrivelse betegnet som peaks. Der er registreret to steder hvor peaks kan optræde: værdien 73 måles i sjældne tilfælde som 99, og værdien 25 som 51. Foreløbigt er der ikke opsamlet data nok til at foretage en mere detaljeret beskrivelse af optræden af peaks. Figur 11.1: Eksempel på en registreret peak. Figur 11.2: Eksempel på skrækscenarium. Da konstruktion af HMH var afsluttet på det tidspunkt peak-problemet blev opdaget, har projektgruppen besluttet i første omgang at løse dette problem softwaremæssigt. Løsningen indebærer lokalisering og udskiftning af fejlmålingen med et kvalificeret gæt på den rigtige værdi. Lokaliseringen foregår ved at kontrollere om den målte værdi ligger inden for et acceptområde på ±15 ud fra den forrige værdi. På figurer 11.1 og 11.2 ses acceptområdet som et skraveret område. De blå målepunkter som ligger i acceptområdet forbliver uændret imens de målepunkter der ligger udenfor acceptområdet udskiftes med de forventede resultat som er illustreret som grønne punkter. Under konkurrenceforløbet vises der real-time grafer over målingerne, så den besøgende kan følge med i hvor hårdt der bliver trykket i hånden på det givende tidspunkt. Real-time kravet forøger kompleksiteten af løsningen, da det kvalificerede gæt kun kan basere sig på forrige målinger. I analyse af det indsamlede data, kunne det konkluderes, at det på baggrund af forrige målinger, er muligt at komme med et godt estimat af den forventede værdi. På figur 11.2 ses et skrækscenarium, hvor hånden blev trykket så hurtigt som muligt for at få en hurtigt skiftende kurve. Samtidig simuleres en peak, hvor værdien 25 ændres til 51. Selv i dette scenarium ligger de forventede resultater forholdsvis tæt på de målte værdier. De forventede resultater på figuren 11.1 og 11.2 findes på baggrund af en lineær regressionslinje der baserer sig på de to forrige målinger. Ved at ændre regressionslinjen til ikke-lineær, er det muligt at komme med et estimat der passer endnu bedre. Rettelse af peaks er blevet implementeret i metoden readdata() i MContactExperiments, således at målingerne bliver rettet efter de er læst fra microcontrolleren, men før de bliver vist grafisk og gemt i resultater. Detektering af en peak bliver indtil videre vist i hændelsesloggen. Under brugetesten, blev der fundet to automatiske rettelser af peaks ved at analysere hændelseslog, begge steder ved værdien 25. Dette viste at metoden readdata() i MContactExperiments var i stand at rette op på fejlen, men der skal foretages yderligere tests, for at sikre at denne løsning er tilstrækkelig. Hvis der i fremtiden skal foretages en revurdering af HMH vil det være en fordel at ændre i microcontrollerens kode, i stedet for at beholde den løsning der er implementeret på nuværende tidspunkt. Hardwareløsningen vil være mere optimal, da det er i hardwaren fejlen opstår. Resultater Side 45 af 63

52 12 Statistiske overvejelser til udbygning af system Dette kapitel indeholder en analyse af muligheden for to udbygninger af systemet på baggrund af en række statistiske beregninger. Det drejer sig henholdsvis om en analyse af behovet for at vægte scoren i de enkelte discipliner alt afhængig af personlige parametre som køn, alder og lignende for deltageren, samt muligheden for at implementere en estimering af de scorer som en besøgende opnår. Først i kapitlet gennemgås grundlaget for de statistiske beregninger, hvor de data der lægger til grund for de statistiske beregninger beskrives. Herefter analyseres forskellen på scoren i de enkelte discipliner for piger og drenge, og til sidst følger en analyse af muligheden for at estimere den opnåede score i udholdenhedsdisciplinen. De statistiske beregninger er foretaget i Excel 33 og R 34. Måledata samt beregninger kan forefindes på cd en under Statistiske Beregninger Grundlag I dette afsnit beskrives grundlaget for de statistiske beregninger som følger i dette kapitel, og de benyttede stokastiske variabler, samt deres sandsynlighedsfordeling beskrives. Grundlaget for de statistiske beregninger der foretages i dette kapitel er data indsamlet under brugertesten 35 af systemet. Der blev indsamlet scorer for alle de besøgende som deltog i testen for hver af konkurrencens tre discipliner, henholdsvis styrke, refleks og udholdenhed. Det betyder dermed at der arbejdes med følgende stokastiske variable: W : Score i styrkedisciplinen X : Score i refleksdisciplinen Y : Score i udholdenhedsdisciplinen Score i styrke- og udholdenhedsdisciplinen måles på en skala fra 0 til 99, mens score i refleksdisciplinen måles i millisekunder, hvilket dermed giver følgende værdimængder for de tre stokastiske variable: W { 0,1, 2,,99} [ 0; [ { 0,1, 2,,99} V = Diskret endelig. V = Kontinuerlig uendelig. 36 X V = Diskret endelig. W Der blev foretaget målinger 37 på i alt 11 besøgende under testen, 6 piger og 5 drenge, og disse målinger kan betragtes som 11 uafhængige observationer af hver af de tre variable. De statistiske beregninger i dette kapitel er altså foretaget på et forholdsvis begrænset grundlag, da der ikke har været mere end 11 målinger til rådighed, er det begrænset hvor meget der på nuværende tidspunkt kan konkluderes. I takt med at systemet bliver testet i større udstrækning vil der dog blive mere og mere data tilgængeligt, og de samme beregninger kan så gentages med større sikkerhed, og konklusionerne kan revurderes. 33 Microsoft Office Excel R v2.8.1, by R-project. 35 Se afsnit 13.5 for en yderligere beskrivelse af brugertesten. 36 I praksis er der en rent hardwaremæssig begrænsning på dette interval og det er således kun muligt at måle reaktionstider der er under 8000 ms. Dette har dog ikke den store betydning, da det må formodes at det ikke er muligt at have en reaktionstid på over 8 sekunder. 37 De indsamlede målinger forefindes på cd en under Statistiske beregninger. Side 46 af 63 Resultater

53 På baggrund af de 11 målinger af de tre stokastiske variable kan deres sandsynlighedsfordeling bestemmes. Dette gøres ved at indtegne målingerne i et QQ-plot, som vist herunder: Normal Q-Q Plot - Styrke Normal Q-Q Plot - Refleks Normal Q-Q Plot - Udholdenhed Målte Kvantiler Målte Kvantiler Målte Kvantiler Teoretiske Kvantiler Teoretiske Kvantiler Diagram 12.1: QQ-plot over score for styrke, refleks og udholdenhed. Teoretiske Kvantiler Det ses af diagrammerne at punkterne tilnærmelsesvis ligger på en ret linje, hvilket betyder at det kan antages at de tre definerede stokastiske variable er normalfordelte Bestemmelse af forskel mellem drenge og piger Da konkurrenceelementet er en vigtig del af systemet, og de besøgende opnår en samlet placering efter deres deltagelse, er idéen om at gøre konkurrencen retfærdig for alle opstået. For at konkurrencen skal være retfærdig, skal faktorer som køn og alder ikke være afgørende for ens samlede placering. Derfor foretages en undersøgelse af, om det med stor sandsynlighed kan bevises at der er en forskel på drenges og pigers scorer i de enkelte discipliner. Hvis denne forskel kan bevises kan det herefter overvejes hvorledes en eventuel vægtning af scorerne kan foretages. Det forventes, at der vil kunne spores en forskel i pigernes og drengenes scorer i styrke og udholdenhed, og dette ønskes bevist i dette afsnit, samtidig med at det ønskes undersøgt hvorvidt der ligeledes er en forskel at spore mellem de to grupper i refleksdisciplinen. Det skal undersøges om der er en signifikant forskel mellem pigernes og drengenes score i hver af de tre discipliner, eller om forskellene bare skyldes tilfældigheder. Der foretages derfor uparret T - test for at sammenligne de to grupper, da de er af forskellig størrelse. I første omgang sammenlignes scoren i styrkedisciplinen, hvilket betyder at vi betragter de to stokastiske variable W Piger og W Drenge, som beskriver målingerne af styrkescoren i de to grupper. De enkelte målinger er desuden uafhængige af hinanden og normalfordelte, med forventningen µ W, Piger og µ W, Drenge, samt standardafvigelsen σ W, Piger og σ W, Drenge. Det skal dermed undersøges hvorvidt der er forskel på de to gruppegennemsnit, hvilket betyder at testhypoteserne kan defineres som: Ved T -testen benyttes følgende testobservatør: H 0 : Drenge og piger er lige gode ( µ W, Drenge µ W, Piger H 1 : Drenge og piger er ikke lige gode ( µ W, Drenge µ W, Piger T Styrke W Piger W = S + Drenge 1 1 P ndrenge npiger = ) ) (12.1) For at nulhypotesen kan forkastes, og det kan konkluderes at der er en forskel på pigernes og drengenes scorer, skal det være gældende at: TStyrke > t α /2 Resultater Side 47 af 63

54 Hvor t α /2 er kvantilet i t -fordelingen, med npiger + ndrenge 2 frihedsgrader. Benyttes et signifikansniveau på α = 0,05, skal følgende være gældende: TStyrke > t 0,025 T > 2,262 (12.2) 38 Styrke I formel (12.1) er W Piger og W Drenge gennemsnittet af målingerne i de to grupper, da dette er det bedste estimat for µ Piger og µ Drenge, mens S P er den interpolerede varians. I kraft af at der er så få målinger til rådighed, må det antages at de to gruppers standardafvigelse er ens, og det bedste estimat af den fælles varians er dermed den interpolerede varians, som beregnes ved: For styrkedisciplinen haves følgende værdier 39 : ( ) ( ) n 1 S + n 1 S 2 SP = n + n Drenge Drenge Piger Piger Drenge Piger Antal målinger piger, n Piger 6 Antal målinger drenge, n Drenge 5 Gennemsnit piger, Gennemsnit drenge, Standardafvigelse piger, Standardafvigelse drenge, W Piger 27,33 W Drenge 52,8 S Piger 3,33 S Drenge 11,45 Interpoleret standardafvigelse, S 8,03 P Tabel 12.1: Værdier til beregning af testobservator. Som ved indsættelse i (12.3) og (12.1) dermed giver: t Styrke = 5, 24 (12.3) Ud fra (12.2) er det dermed muligt at forkaste nulhypotesen, og konkludere at der er forskel i pigernes og drengenes score i styrkedisciplinen, ganske som forventet. Udføres en lignende beregning for henholdsvis refleks- og udholdenhedsmålingerne ved benyttelse at tilsvarende hypoteser, fås følgende værdier for testobservatøren: t Refleks = 1,17 t = 3, 21 Udholdenhed Hvormed det ses, at det ligeledes for udholdenhedsdisciplinen gælder, at der er en forskel mellem de to grupper, hvorimod det umiddelbart ikke kan bevises, at der er forskel på pigernes og drengenes scorer i refleksdisciplinen. Disse resultater betyder, at der skal overvejes at indføre en vægtning af de besøgendes scorer på baggrund af deres køn, da det kan påvises at drengene vil opnå bedre scorer end pigerne. Dette er dog ikke gældende for refleksmålingen, hvor der som nævnt ikke kan spores en forskel. Selve vægtningen mellem de enkelte grupper kan foretages på baggrund af forventningsværdien for hver at grupperne, så den endelige score beregnes ud fra hvad der forventes af personen på baggrund af dennes køn. 38 Værdien 0,025 t er fundet ved opslag i tabel D.5 side 484 i kilde De statistiske beregninger forefindes i Excel-dokumentet Statistiske beregninger på den medfølgende cd. Side 48 af 63 Resultater

55 I fremtiden, når der indsamles flere konkurrencedata, og der vil være data tilgængelig for forskellige aldersgrupper, kunne man derudover forestille sig, at man tog denne parameter med i overvejelserne, og inddelte scorerne i flere grupper, hvormed en mere omfattende ANOVA-test 40 kunne foretages. Dette ville betyde at man ville kunne vægte scoren på baggrund af for eksempel både alder og køn, hvis det kan bevises at alderen har en indflydelse på scoren i den pågældende disciplin Estimering af score i discipliner Følgende afsnit indeholder en gennemgang af to forskellige metoder til at estimere scoren i de forskellige discipliner henholdsvis ud fra de indsamlede målinger samt ud fra deltagerens score i foregående discipliner. I afsnittet foretages estimeringer af udholdenhed, men fremgangsmåden vil være den samme for at estimere score for andre discipliner. Estimeringen af den forventede score i disciplinerne skal foretages for at opfylde krav F23: F23 Deltage i konkurrence HMS skal kunne beregne og vise den forventede score ud fra konkurrencedeltagerens oplysninger. Tabel 12.2: Uddrag fra kravmodel: Krav F23 angående beregning af forventet score. Der skal anvendes statistiske modeller i disse beregninger. Tanken er at den forventede score skal illustreres på den grafiske brugergrænseflade under deltagelse i konkurrencen, og ved tilgang til data via applet, som det er illustreret på figuren herunder: Figur 12.1: Illustration af hvordan estimering af score kan vises på brugergrænseflade. Det simpleste estimat af scoren i udholdenhedsdisciplinen som kan foretages er et punktestimat af forventningsværdien baseret på samtlige målinger. Det bedste bud på en populations forventningsværdi er gennemsnittet af målingerne, hvilket betyder at den for alle deltagere kan beregnes ved: 1 1 n = Y = Y Y Yn Yi n = n i= 1 µ Udholdenhed = 25,8 µ ( ) Udholdenhed 1 2 Det er desuden muligt at foretage et punktestimat for standardafvigelsen, for at få angivelse af estimatets præcision, med den unbiased estimator: ( ) 2 i n 2 1 SUdholdenhed = Y Y n 1 i= 1 S Udholdenhed = 10, 97 Det første estimat giver os dermed en forventningsværdi på 25,8 med en standardafvigelse på 10,97. Dette estimat kan ikke siges at være særligt nøjagtigt, da standardafvigelsen er forholdsvis høj, og det er derfor ønskeligt at optimere estimeringen. I forrige afsnit blev det vist at der er forskel på scoren i udholdenhedsdisciplinen for henholdsvis piger og drenge. Det betyder at det vil være muligt at reducere variansen af estimatoren, ved af betragte de to grupper hver for sig, og foretage et estimat for henholdsvis drenge og pige. 40 ANOVA står for Analysis Of Variance og er en generalisering af to-udvalgs T-testen, som blev benyttet i afsnit ANOVA muliggør derfor sammenligning mellem flere end to grupper. Resultater Side 49 af 63

56 Estimering af forventningsværdi og standardafvigelse er opsummeret i tabellen herunder: µ 18,83 Udholdenhed,Piger µ 34,20 Udholdenhed,Drenge S Udholdenhed,Piger 6,74 S Udholdenhed,Drenge 9,12 Tabel 12.3: Punktestimering af forventningsværdi for piger og drenge. Som det ses af tabellen forbedrer opdelingen af piger og drenge estimeringerne. Som nævnt i forrige afsnit vil det derudover være muligt, når mere data er tilgængeligt, at undersøge sammenhængen mellem aldre og score i udholdenhedsdisciplinen. Hvis en sammenhæng kan påvises vil det være muligt yderligere at specificere parametre for de scorer som udvælges til punktestimeringen. Ud over et primitivt punktestimat er det desuden muligt at bestemme et konfidensinterval for scoren i udholdenhedsdisciplinen. Idet både forventningsværdien, µ, og standardafvigelsen, σ, er ukendt for målingerne benyttes et T -interval, som kan beregnes ved: S Y tα /2, Y + tα /2 n S n (12.4) Hvor t α /2 er kvantilet i t -fordelingen med n 1 frihedsgrader. Et 95 % konfidensinterval for scoren i udholdenhedsdisciplinen for henholdsvis drenge og piger kan derfor ved benyttelse af (12.4) bestemmes til: Piger Drenge t 0,025 2,571 2, % konfidensinterval [ 11, 76; 25,90 ] [ 22,87; 45, 53 ] Tabel 12.4: Punktestimering af forventningsværdi for piger og drenge. Ud over at basere estimatet af forventningsværdien for score i udholdenhedsdisciplinen, på de scorer som andre besøgende har opnået, er der desuden mulighed for at estimere scoren ud fra de scorer en besøgende allerede selv har opnået i foregående discipliner. Dette er muligt såfremt der kan spores en sammenhæng mellem for eksempel udholdenhed og styrke eller udholdenhed og reflekser, hvormed scoren i styrke eller reflekser kan benyttes til at estimere scoren i udholdenhed. For at kontrollere om der er en lineær sammenhæng mellem de enkelte discipliner bestemmes korrelationen mellem de stokastiske variable. Den empiriske korrelation, R, kan estimeres med: R S WY WY = = SW SY n n i= 1 ( Wi W ) ( Yi Y ) n ( Wi W ) ( Yi Y ) i= 1 i= Hvor S WX er kovariansen mellem de stokastiske variable, som kan estimeres med: ( ) ( ) WY i i n 1 i= 1 (12.5) 41 n 1 S = W W Y Y (12.6) 42 Værdien af korrelationen ligger i intervaller [ 1;1] og opnås en korrelation tæt på -1 eller 1 kan der spores en stæk lineær sammenhæng mellem variablene. Er korrelationen derimod omkring nul er de 41 Kilde 4 Side Kilde 4 Side 268. Side 50 af 63 Resultater

57 to variable ukorrelerede, hvilket ikke betyder at der ikke kan være en sammenhæng mellem variablene, men at der ikke er en lineær sammenhæng mellem dem. Fortegnet på korrelationen angiver retningen på sammenhængen. Hvis korrelationen er positiv vil en stor værdi af den ene variabel sandsynligvis medføre en stor værdi af den anden variabel, og omvendt. Den empiriske korrelation mellem scoren i de tre discipliner kan derfor bestemmes til: Styrke Reflekser tid Udholdenhed Styrke 1 Reflekser tid -0,536 1 Udholdenhed 0,863-0,688 1 Tabel 12.5: Korrelationsmatrice over sammenhæng mellem discipliner. Som det ses af tabellen er det muligt at spore en sammenhæng mellem udholdenhed og styrke, idet korrelationen mellem disse er forholdsvis høj. Plottes de parvise scorer i styrke og udholdenhed i et scatterplot, som det kan ses i diagram 12.2, bekræftes denne påstand angående sammenhængen. Af tabel 12.5 ses desuden at der er en antydning af en sammenhæng mellem både reflekser og udholdenhed samt reflekser og styrke, men korrelationen er umiddelbart ikke høj nok til at denne sammenhæng vil kunne benyttes. Idet det er vist at det er sandsynligt at der er en lineær sammenhæng mellem scoren i styrke- og udholdenhedsdisciplinen, vil der hermed være muligt at foretage en regressionsanalyse mellem de to variable, for at fastlægge denne sammenhæng, og dermed ud fra score i styrkedisciplinen kunne forudsige noget omkring scoren i udholdenhedsdisciplinen. Det kan derfor antages at scoren i udholdenhedsdisciplinen, Y i, har følgende sammenhæng med scoren i styrkedisciplinen, w i : Y = α + β w + e (12.7) i i i Hvor e i er en stokastisk variabel der beskriver den fejl der er i den lineære sammenhæng. Det 2 antages at denne fejl er uafhængig og normalfordelt med forventningen nul, og variansen σ, hvilket betyder at forventningsværdien til udholdenheden kan beskrives med: ( ) E Y i = α + β w (12.8) Koefficienterne i (12.8) kan estimeres med mindste kvadraters rette linje: n ( ) ( ) wi w yi y i 1 SY β = = = r ^ α = y β w n 2 SW w w i= 1 ( i ) Hvilket på baggrund af de indsamlede målinger giver følgende regressionslinje: ( ) = 1, , 618 wi E Y i Målingerne for score i styrke- og udholdenhedsdisciplinen er plottet parvis i diagrammet herunder hvor regressionslinjen desuden er angivet: i Resultater Side 51 af 63

58 Diagram 12.2: Scatterplot og regressionslinje for score i styrke- og udholdenhedsdisciplinen. Ud fra regressionslinjen er det derefter muligt at beregne et prediktionsinterval for observationsværdierne af scoren i udholdenhed. Dette prediktionsinterval kan dermed benyttes til at forudsige et interval for hvilken score der opnås i udholdenhed ud fra den besøgendes score i styrkedisciplinen. Prediktionsintervallet kan bestemmes med: 1 w w α + βw + tα /2 s 1+ + s n SE ( β ) På diagrammet herunder er angivet er 95 % prediktionsinterval for scoren i udholdenhedsdisciplinen beregnet ud fra de indsamlede målinger: 2 (12.9) Diagram 12.3:Prediktionsinterval for enkeltobservationer af udholdenhed baseret på score i styrke. I dette afsnit blev to forskellige metoder til estimering af scoren i udholdenhedsdisciplinen undersøgt. I den første metode blev der bestemt et 95 % konfidensinterval for scoren for piger og drenge. Denne metode kan benyttes til at lave en estimering af scoren i de tilfælde hvor der ikke er nogen scorer tilgængelig for den pågældende person. I tilfælde hvor den besøgende for eksempel først har forsøgt sig i styrkedisciplinen, kan scoren for de discipliner der er korrelerede med denne, beregnes på baggrund af denne score. Dette må forventes at være et mere nøjagtigt estimat såfremt der kan påvises en stærk korrelation mellem de to discipliner, men det betyder at estimatet skal beregnes lige inden disciplinen startes, og dermed ikke kan vises fra konkurrencens start, som det er tilfældet med den anden beregningsmetode. Side 52 af 63 Resultater

59 13 Kvalitetskontrol I dette kapitel følger en beskrivelse af de teknikker der er blevet anvendt for at sikre den bedst mulige kvalitet af IT-systemet. Der vil først være en beskrivelse af formålet med de to reviewtyper som er blevet udført i projektperioden. Derefter vil der være en beskrivelse af hvorledes selve kildekoden er blevet testet, med udgangspunkt i den testsuite som er blevet uarbejdet for at teste korrektheden af systems algoritme til afkodning af SMS-beskedernes indhold. Afslutningsvis vil der være en beskrivelse af den gennemførte brugertest og det opnåede resultat Review Reviewteknikken er blevet anvendt i projektforløbet for at sikre kvaliteten af IT-systemet så tidligt som muligt. Denne teknik er praktisk da den kan anvendes til at udføre kontrol af dokumentation for IT-systemet, imens det udvikles. Teknikken er desuden meget effektiv til afsløring af fejl. Der er blevet udført to forskellige reviewtyper: Godkendende review og inspektionsreview. Det førstnævnte er anvendt til at sikre systemets indhold, og at det lever op til de opstillede krav ved afslutningen af inceptionen. Det sidstnævnte er anvendt til at sikre den tekniske kvalitet af ITsystemet Godkendende review Godkendende review blev udført af TEK-BrobygningsCenter i slutningen af inceptionsfasen. Formålet med dette review var at sikre kvaliteten af inceptionsdokumentet og øge forståelsen mellem de involverede parter, i dette tilfælde TEK-BrobygningsCenteret og producenterne. På baggrund af det godkendende review og de derfra kommende kommentarer, blev det muligt at foretage et faseskift og dermed påbegynde elaborationen. Den anvendte teknik for udførelsen af godkendende review er vist på figuren herunder: Figur 13.1: Teknik for godkendende review Inspektionsreview Der er blevet foretaget en inspektion af eksterne eksperter 43 på en udvalgt del af analyse- og designdokumentationen af IT-systemet i slutningen af den første elaborationsiteration. Fordelen ved denne reviewtype er at IT-systemet ikke nødvendigvis skal være kørende for at der kan rettes op på fejl. Denne inspektion er blevet foretaget som et led i 0-fejl 44 udviklingen for hermed at afsløre og rette fejl så tidligt som muligt, samt for at måle kvaliteten af systemet. For at kunne opnå dette, blev inspektionen gennemført med en høj grad af formalisme. Det er producenternes rolle at tie imens eksperterne detaljeret gennemgår det udleverede reviewdokument og fremhæver alle fejl og mangler. Desuden skal eksperter kunne sige god de producerede UML-diagrammer og at disse overholder UML-standarden. 43 Projektgruppe 2 44 Som beskrevet i procesmodellen, kapitel 3. Resultater Side 53 af 63

60 Der foretages referat under hele inspektionsreview der anvendes til at udarbejde den endelige fejlrapport 45 som eksperter skal godkende. Derefter følger producenterne op på fejlene. Teknikken for udførelsen af inspektionsreview som er blevet anvendt er vist på figuren herunder: Figur 13.2: Teknik for inspektionsreview Dynamisk kvalitetskontrol Under systemudviklingsforløbet er der anvendt white-box-testing hver gang en del af systemet blev implementeret. Denne test blev udført af den ansvarlige for implementeringen, og blev derudover ikke dokumenteret i detaljer. For de mere kritiske dele af systemet blev der derudover foretaget black-box-testing ved udarbejdning af testcases og benyttelse af JUnit. I afsnittet følger en beskrivelse af de udviklede testcases til kontrol af læsning af SMS. Til kvalitetskontrol af den mest kritiske del af IT-systemet, oprettelse af besøgende via SMS, er der blevet foretaget to tests af den udviklede komponent til styring af SMS-modulet, for at lokalisere de eventuelle fejl. For at udspecificere givende inputs, de forvente outputs, og de reelle outputs i testen, udarbejdedes en testcase som indeholdt disse informationer. I tabel 13.1 ses et uddrag af testcasen SyntaxControlTest 46. Metoden syntaxcontrol(string SMSMessage) tjekker om SMSbeskeden overholder den korrekte syntaks, og returner true eller false. Meddelelsens syntaks er K AA Navn, hvor K står for køn, AA for alder som skal være tocifret. Der foretages ingen kontrol af navnet. Testcasen er specificeret til en black-box-test, derfor er testdata til input genereret ud fra analyseviden om hvilket input der skal accepteres, og hvilket der skal forkastes. Rækkefølgen af input er logisk opbygget for at opfange flest mulige inputscenarier. Ved at registrere output i test A blev der konstateret, at nogle meddelelser med forkert syntaks fejlagtigt blev accepteret. Testen kan dermed betragtes som vellykket, da der blev fundet fejl i komponenten. Efter rettelser af kildekoden blev der foretaget endnu en test, hvor der ikke blev fundet flere fejl. Navn: SyntaxControlTest Komponent: Klassen FSMSCommunication. Metoden syntaxcontrol(string SMSMessage) Input Forventet output Output test A Output test B D 1 Mads Mikkelsen False False False D 00 Mads Mikkelsen False False False D 01 Mads Mikkelsen True True True D 015 Mads Mikkelsen False True False D -1 Mads Mikkelsen False True False Tabel 13.1: Uddrag af testcase SyntaxControlTest. Til tests af komponenten, benyttes testframeworket JUnit, som består af nogle integrerede klasser, der giver muligheder for at foretage en automatiseret test, via en testcase som vist i tabel Forefindes på cd en 46 Den fulde udgave af testcasen SyntaxControlTest findes i på cd en. Side 54 af 63 Resultater

61 Testcasen placeres i en klasse, der arver fra TestCase. Klassen TestSuite benyttes til at organisere testcases og invokere dem sekventielt efter hinanden. Opbygningen af JUnit ses i figuren herunder: Figur 13.3: JUnit testframework med SMS-modul testcases. De to testcases er samlet i SMSTestSuite, som tester to dele af komponenten: først testes om syntaksen overholdes, og derefter læses selve SMS en. De to tests har forskellige formål: I den første metode kontrolleres der om meddelelsen er skrevet korrekt, i den anden om alle informationer fra SMS en er uddraget korrekt. ReadSMSTest forudsætter at SyntaxControlTest er fejlfri. I tabellen herunder vises ReatSMSTest: Navn: ReadSMSTest Komponent: Klassen FSMSCommunication. Metoden String[] readsms(int smsnum) Input SMS Forventet output Output test A Output test B M 22 Alexey M 22 Alexey M 22 Åge Sørensen M 22 Åge Sørensen M 22 Γπ M 22 Γπ M 22 Alexey M 22 ge S rensen null null Null Tabel 13.2: Testcase ReadSMSTest. Ikke foretaget M 22 Åge Sørensen M 22 À Der blev fundet fejl i ReadSMSTest, se tabel Da SMS-modulet som standard var indstillet til ASCII-format 47 var det ikke muligt at afkode SMS er med æ, ø og å korrekt, hvilket medførte, at de besøgende med disse bogstaver i navnet ikke kunne blive oprettet korrekt. Fejlen blev rettet ved at ændre formatet til UTF8 og endnu en test blev foretaget. Det viste sig herefter, at tegn som ikke indgår i UTF8-formatet 48 blev afkodet forkert. Fejlen ses som ubetydelig idet de pågældende tegn ikke benyttes. 47 Se eventuelt Teknisk memo: SMS-modul, bilag Datablad for SMS-modulet TC65 Resultater Side 55 af 63

62 SyntaxControlTest og ReadSMSTest betragtes som to vellykkede tests. Der blev fundet og rettet fejl i begges testcases. Alle tænkelige inputscenarier er blevet afprøvet, og på den baggrund kan denne del af komponenten betragtes som fuldstændig funktionsdygtig. Testframework har dermed været med til at kvalitetskontrollere en af de mest kritiske dele af IT-systemet Brugertest 49 Der er udover den omtalte kvalitetskontrol, blevet udført en brugertest i slutningen af elaborationen. Formålet med brugertesten var at afgøre, om systemet er velegnet til sit formål, fit for purpose, samt at undersøge hvad der skete i systemets omverden. Derudover skulle brugertesten sikre, at systemet var velegnet på alle vigtige områder. Brugertesten blev samtidig brugt til opsamling af data til de statistiske overvejelser, gennemgået i kapitel 12. Udgangspunktet for at foretage en brugertest i slutningen af elaborationen var at systemet var komplet, korrekt og stabilt. Det betyder at systemet indeholdte alle de metoder og data som er beskrevet i de brugsmønstre, som er implementeret. Begrundelsen for at brugertesten var planlagt så tidligt i udviklingsforløbet er at det ikke ville være nyttigt at vente med at afholde brugertesten til efter systemet er konstrueret. I dette tilfælde ville det være for sent at rette op på fejl og mangler. Ud fra den gennemførte brugertest kunne det konkluderes at systemet er velegnet til sit formål. Der vil på baggrund af testernes kommentarer og de fejl og mangler der blev observeret under brugertesen blive udarbejdet en plan for rettelser af disse (denne forefindes i kapitlet resterende arbejde). De observerede data og kommentarer fra brugetesten forefindes i den udarbejdede brugertestjournal. 49 Brugertestdokument som indeholder planlægningen af testen, beskrivelse af testens forløb og de opnåede resultater forefindes på cd en. Side 56 af 63 Resultater

63 14 Resterende arbejde I dette kapitel gennemgås det resterende arbejde for udviklingen af HMS-systemet. Det primære resterende arbejde vil være, de på nuværende tidspunkt, lavt prioriterede krav og brugsmønstre der ikke er bearbejdet i detaljer, samt fejl fundet i forbindelse med diverse tests. Der er udarbejdet kravmodel og brugsmønsterbeskrivelser for alle brugsmønstre, men der er ikke foretaget analyse, design og implementering for følgende brugsmønstre: B1, B3, B4, B6 og B7. Dette skyldes at disse brugsmønstre ikke har indflydelse på systemarkitektur og risici for systemet, og derfor har de været prioriteret lavt i elaborationen. I de elaborationsiterationer, som er foretaget, er nogle krav ikke behandlet, på grund af deres lave prioritet, disse fremgår af kravsporingsmatricen i Krav- og brugsmønsterdokument v1.2, som forefindes på den vedlagte cd. I tabellen herunder vil der være en beskrivelse af specifikke mangler i de brugsmønstre der er behandlet i løbet af elaborationsiterationerne. Disse mangler er primært fundet i brugertesten, og er derfor mangler der i mange tilfælde vil kunne udbedres under konstruktionsfasen. Brugsmønster Resterende arbejde - Brugergrænsefladen skal tilpasses så udfyldningen af felterne ikke virker B2 forvirrende for brugerne. - Der skal implementeres en metode der kan rydde hændelsesloggen, så der ikke B5 vises gamle og dermed irrelevante hændelser. - Beskeder i hændelseslog skal gøre mere forståelige. - Der er på nuværende tidspunkt muligt at indsende SMS, hvor der kan angives B9 køn både som M/K og D/P. Dette viste sig at være et forvirrende element under brugertesten og skal derfor ændres til kun at understøtte M/K notationen. - Der skal findes en måde hvorpå deltagere i konkurrencen kan blive informeret om hvilken disciplin der skal udføres som den næste, så der ikke opstår forvirring under konkurrencen. - Pausen fra et mobilnummer indtastes og til konkurrencen starter, skal B10 forlænges. - Der skal under deltagelsen i konkurrencen kun vises resultat for den enkelte disciplin i stedet for visning af alle discipliner samtidig, hvilket medfører større grafer så det bliver lettere at følge med. - Der mangler generelt en beskrivelse af funktionerne i appletten og tilføjelse af mouseovers til markering af elementer der kan klikkes på. B11 - Der skal udskrives Mand/Kvinde i stedet for M/K i appletten. - Der skal tilføjes mulighed for at se deltageres resultater ved klik på topscorelisten. - Der skal tilføjes mouseover på topscorelisten, når en konkurrence følges, for at B12 gøre opmærksom på at man på den måde kan se de deltagendes resultater. Tabel 14.1: Beskrivelse af mangler for specifikke brugsmønstre. I forbindelse med den grafiske brugergrænseflade blev der fundet en fejl i måden TEK- BrobygningsCenters logo skaleres på. Derudover mangler der en generel refaktorering af kildekoden for brugergrænsefladen. Der skal derudover laves en konsolbaseret brugergrænseflade til applikationen HMSServer, for det er muligt at administrere denne. HMSServer bliver på nuværende tidspunkt afviklet på en af gruppen opsat server, i grupperummet, der er konfigureret på samme måde som den server som gruppen har fået stillet til rådighed gennem TEK-BrobygningsCenter. For at have optimale testforhold har gruppen valgt at anvende serveren i grupperummet, da det var nemmere at administrere den server. På nuværende tidspunkt er COM-portnumrene der anvendes ved kommunikation med SMSmodul og HMH-enheden, kodet til et fast nummer. Dette skal ændres således at HMSAdministration selv kan finde ud af hvilken COM-portnummer der anvendes til de to enheder. Resultater Side 57 af 63

64 I forbindelse med konkurrencen i BrobygningsCenteret, skal der implementeres estimering af en deltagers forventede resultater, på baggrund af de statistiske overvejelser i kapitel 12. Når en konkurrence bliver afsluttet på HMSAdministration, skal der tilføjes en feature der sørger for det ikke er muligt at afslutte programmet før konkurrencedata er gemt i databasen og der er sendt SMS er til deltagerne. Før systemet er klar til transition skal der desuden være en funktionalitet i systemet til at genoptage en konkurrence efter systemnedbrud af HMSAdministration. Herudover skal der foretages yderligere test af hele systemet for at finde fejl, kontrollere at disse er blevet rettet og at alle exceptions håndteres korrekt, så systemet er stabilt på alle områder. Når systemet er klar til anvendelse i TEK-BrobygningsCenter skal brugermanualen til systemet færdiggøres. På nuværende tidspunkt indeholder denne en installations- og afinstallationsvejledning og mangler således en brugervejledning der beskriver hvordan programmet betjenes. Systemet er designet efter at det skal være muligt at tilføje flere klienter benævnt HMSClient, der skal tage sig af styringen af yderligere eksperimenter. Opbygningen af disse klienter er ikke behandlet da der kun er udviklet et nyt eksperiment i dette projektforløb. Denne klient vil give mulighed for at tilføje nogle af de eksperimenter der på nuværende tidspunkt er i BrobygningsCenteret. Som det fremgår, er størstedelen af det resterende arbejde justeringer og tilpasninger af brugergrænsefladen, samt analyse, design og implementering af mindre betydningsfulde brugemønstre. Det vil derfor være nødvendig at udføre en afsluttende elaborationsiteration, af kortere varighed, hvor de mindre betydningsfulde brugsmønstre behandles i det omfang der er nødvendigt. Resten af det resterende arbejde vil blive udført i konstruktionen. Side 58 af 63 Resultater

65 EPILOG

66 15 Konklusion Dette projekt har beskæftiget sig med udviklingen af et IT-system til TEK-BrobygningsCenter, som ønskede et IT-system der gennem interaktiv leg øgede interessen for teknik og naturvidenskab hos de besøgende i BrobygningsCenteret. Formålet med denne rapport er at dokumentere vigtige beslutninger i forbindelse med designet og distribueringen af det udviklede system. I det efterfølgende konkluderes på de mål, som projektgruppen satte sig for i begyndelsen af projektperioden. Der er blevet: - gennemført en inception, hvor krav og brugsmønstre er blevet fastlagt i tæt samarbejde med TEK-BrobygningsCenter. Krav og brugsmønstre er fastlagt ud fra interview og review med BrobygningsCenteret. - foretaget reviews i samarbejde med henholdsvis TEK-BrobygningsCenter og eksterne eksperter for at sikre kvaliteten af systemet. - udforsket og elimineret risici i forbindelse med konstruktionen af IT-systemet, ved behandling af centrale brugsmønstre. - udarbejdet en analysemodel over de centrale brugsmønstre, som kortlægger problemdomænet. - udarbejdet et forslag til en forståelig, vedligeholdelsesvenlig og skalerbar softwarearkitektur, som er dokumenteret designmodel der viser den overordnede struktur for IT-systemet. Systemet kan dermed på længere sigt udvides til at håndtere flere af BrobygningsCenterets eksperimenter. - udarbejdet en distribueret arkitektur med den bedst egnede distributionsform, der giver mulighed for at tilgå systemet i BrobygningsCenteret via internettet. Der er defineret tre subsystemer, henholdsvis HMSServer, HMSAdministration og HMSApplet, som distribueres på forskellige enheder og som kommunikerer via RMI. - udviklet en softwarearkitekturprototype, som illustrerer de overordne funktionaliteter IT-systemet skal tilbyde, herunder give rundviseren mulighed for at administrere systemet og besøgende mulighed for at deltage i konkurrencen. Softwarearkitekturprototypen tilbyder håndtering af forskellige discipliner, for at gøre den interaktive leg mere interessant for de besøgende. - implementeret en statistisk model til løsning af fejl fra HMH-enheden. Derudover er der blevet foretaget statistiske beregninger på opsamlede data fra brugertesten, for at udarbejde en statistisk model til estimering af de besøgendes score og vægtning af score for at gøre konkurrencen retfærdig for henholdsvis drenge og piger. TEK-BrobygningsCenteret kan tage stilling til om denne del ønskes implementeret i fremtiden. - udarbejdet og testet en kommunikationsløsning mellem IT-systemet og SMS-modulet, således at de besøgende kan sende og modtage SMS er fra IT-systemet. - foretaget brugertest i slutningen af projektperioden for at undersøge brugbarheden af systemet. På baggrund af denne brugertest er det muligt at planlægge det videre udviklingsforløb. - udarbejdet en grafisk brugergrænseflade, der illustrerer over for TEK-BrobygningsCenteret at ITsystemet tilbyder interaktiv leg. - udarbejdet en foreløbig brugermanual som hjælper rundvisere med at administrere klienten i TEK-BrobygningsCenter. - udarbejdet dokumentation løbende for det udviklede system, så det er muligt at fortsætte udviklingen af IT-systemet efter projektperioden. Størstedelen af elaborationsfasen er blevet gennemført således at IT-systemet kan klargøres til konstruktionsfasen efter en enkelt elaborationsiteration. TEK-BrobygningsCenterets afdelingsleder Bo T. Andersen har udtalt at han ønsker IT-systemet bliver videreudviklet, således at det kan sættes i drift indenfor den nærmeste fremtid. Hermed kan det konkluderes, at der lykkedes at udarbejde en systemprototype som BrobygningsCenteret mener, kan øge interessen for teknik og naturvidenskab hos de besøgende i BrobygningsCenter. Side 60 af 63 Epilog

67 16 Perspektivering I perspektiveringen præsenteres en plan for det videre forløb af udviklingsprocessen. Derudover gives et forslag til funktionaliteter som systemet på længere sigt kan udvides med, såfremt BrobygningsCenteret har ønsker om dette. Efter projektperiodens afslutning er der aftalt et møde med BrobygningsCenteret og der vil på dette møde blive planlagt det videre forløb. Den foreløbige plan er, at der bliver afsat en uge for at færdiggøre elaborationen. Den sidste uge af elaborationen, har til formål at følge op på resterende arbejde tilhørende elaborationen, samt at klargøre systemet til konstruktion. Efter afslutningen af elaborationen skal systemet konstrueres således at det kan sættes i drift efter sommerferien. Omfanget af konstruktionsfasen er ikke nærmere bestemt, da det afhænger af hvad BrobygningsCenteret ønsker udført. Da der i systemet er taget højde for tilkobling flere eksperimenter, vil det være naturligt at gøre sig overvejelser om hvilke eksperimenter det kunne være interessant at tilføje til IT-systemet. Et eksperiment der allerede på nuværende tidspunkt kan komme i betragtning er den såkaldte Robobasker. Dette eksperiment har tilsluttet nogle sensorer, hvilket betyder at det er muligt at udvikle en hardwareenhed der kan tilsluttes HMS-systemet, så eksperimentet kan indgå i konkurrencen. For at øge interaktiviteten har BrobygningsCenteret derudover overvejet muligheden for tilslutning af webcam i forbindelse med brugsmønsteret Følg konkurrence (B12) og udviklingen af en applikation til Facebook med de besøgendes resultater, som skal være en integreret del af systemet. Generelt er det svært at fastlægge yderligere planer for fremtiden, da det er BrobygningsCenteret der sætter grænserne for omfanget af systemet. Det eneste der er fastlagt indtil videre er at en version af systemet skal sættes i drift efter sommerferien. Herefter er det op til BrobygningsCenteret at bestemme fremtiden for systemet. Epilog Side 61 af 63

68 17 Referenceliste Herunder ses det litteratur, internetsider samt de programmer der er anvendt under projektet Anvendt litteratur 1. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (Addison-Wesley Object Technology Series) Paperback , 2. udgave, Addison-Wesley ISBN Java Software Solutions Paperback , 6. udgave, Pearson Education (Us) ISBN Computer Networking - A Top-Down Approach 4th Edition James F. Kurose University of Massachusetts, Amherst Keith W. Ross Polyteehnie University Brookly PEARSON ISBN Statistikk for universiteter og Høgskoler Løvås 2 utgave Gunnar G. Løvås Universitetsforlaget ISBN Practical Software Engineering - A Case-Study Approach 2004 Leszak A. Maciaszek og Bruc Lee Liong PEARSON ISBN Softwaretest - Teknik Struktur Metode 2. udgave Poul Staal Vinje Nyt Teknisk Forlag ISBN Brugervenlige edb-systemer 2. udgave Rolf Molich Teknisk forlag ISBN Projektledelse af systemudvikling 3. udgave Poul Staal Vinje Nyt Teknisk Forlag ISBN Materialer udleveret som kopi via Blackboard, til undervisning i softwarekonstruktion: 9. The rational unified process made easy: a practitioner's guide to the RUP (Chapter 7) Per Kroll and Philippe Kruchten Addison-Wesley Longman Publishing Co., Inc. ISBN Side 62 af 63 Epilog

69 10. Object-Oriented Software Engineering: Using UML, Patterns and Java (2nd Edition) (Chapter 6 and 7) Bernd Bruegge and Allen H. Dutoit Prentice Hall ISBN Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (Chapter 33) Craig Larman Prentice Hall ISBN Systematic Testing (Udkast) Henrik Bærbak Christensen Department of Computer Science University of Aarhus, Version Client/Server Architectures for Business Information Systems. A Pattern Language. Klaus Renzel & Wolfgang Keller: Anvendte internetsider Beskrivelse af TEK-BrobygningsCenter: Sun Developer Network (SDN): RxTx serial and parallel communication API: Programliste Installationsprogram til HMSAdministration Forefindes på cd en Java SE Runtime Environment (JRE) 6 Update 11 Forefindes på cd en. Diagram Designer v1.21 Forefindes på cd en. Eclipse IDE for Java EE Developers Java SE Development Kit (JDK) 6 Update 11 Forefindes på cd en. Notepad++ v5.11 Forefindes på cd en. Graph Version 4.3 Forefindes på cd en Sun Microsystems MySQL Server Sun Microsystems MySQL GUI Tools 5.0.r17 Microsoft Office Excel 2003 R-Project - R Forefindes på cd en GeoVid - Vidshot Capturer 1.0 Forefindes på cd en Epilog Side 63 af 63

70 Bilag 1 Projektoplæg for Håndtryksmåler Håndtryksmåler Der ønskes designet, opbygget og implementeret en håndtryksmåler i en opstilling i TEK- BrobygningsCenteret. Den overordnede vision for TEK-BrobygningsCenteret er at præsentere uddannelserne på Det Tekniske Fakultet for besøgende folkeskole- og gymnasieklasser, og samtidig formidle naturvidenskabelig og teknisk viden ved hjælp af leg. Den grundlæggende idé er at de besøgende skal deltage i en konkurrence, hvor de interagerer med en håndtryksmåler ved at give denne et håndtryk. Man kunne her forestille sig at konkurrencen kunne bestå i at: Give det hårdeste håndtryk. Trykke hårdest over en given periode. Teste reaktionsevne. Teste tidsfornemmelse ved at skulle holde et tryk i f.eks. 3 sekunder. Teste hukommelse ved at skulle gentage en given kombination. Resultatet fra konkurrencen skal dels præsenteres visuelt, dels sendes som en SMS til den besøgendes telefon, samt være tilgængelig efter besøget via internettet. Det samlede system skal bestå af en hardwaredel, indeholdende håndtryksmåleren, og en softwaredel som dels tager sig af at kontrollere konkurrencens forløb og at kommunikere med de besøgende. Derudover skal der tilkobles et SMS-modul, som uden tidsforsinkelse kan sende SMS er til et indtastet telefonnummer. Overordnet kan idéen skitseres som følgende: Figur B1.1: Skitse af systemet. Den mekaniske udformning af målecellen bliver foretaget, af ekstern leverandør. Hardwaren bliver udviklet af en projektgruppe som er ansat som studentermedhjælpere ved TEK-BrobygningsCenter. Softwaren bliver udviklet af en projektgruppe som semesterprojekt på datateknologi 4. semester. Udarbejdet af: Jan Petersen, Agge Skov Larsen, Alexey Bessonov, Frantz Furrer og Jakob Witte Lars Bilag

71 Bilag 2 Styring af HMH-enhed HMH-enheden er hardwaredelen i Håndtryksmåler-systemet, og er den del der tager sig af afviklingen af de enkelte discipliner, samt af at indsamle data fra disse. Enheden er tilkoblet en computer, som den kommunikerer med via en seriel forbindelse ved hjælp af USB. Dette bilag beskriver hvorledes enheden styres via opstarts- og afslutningssignaler, samt hvilke data der sendes fra enheden under en igangværende konkurrence. For en beskrivelse af hvordan selve kommunikationen med enheden foregår henvises til Tekniske memo Seriel kommunikation, bilag 3. For en videre beskrivelse af opbygningen af HMH-enheden henvises til Teknisk dokumentation for Håndtryksmåler, som kan forefindes på den medfølgende cd. Tekniske faktorer HMH-enhed Kommunikation med enheden foregår gennem den microcontroller 50, der styrer konkurrencens forløb i hardwaren. Styring af HMH-enhed Når HMH-enheden tændes, initialiseres microcontrolleren og venter herefter på input fra den tilkoblede computer. Ved at sende bestemte startsignaler er det herefter muligt at aktivere HMHenheden, og derefter starte de enkelte discipliner. Et generelt overblik over funktionaliteten af microcontrolleren er givet herunder, hvor inputs og outputs fra HMH-enheden er illustreret: Diagram B2.1: Forenklet flowdiagram over assemblerkode i microcontroller. 50 ATmega8 Datablad forefindes på cd. Bilag

72 Som det ses at diagram 1.1, vil et typisk forløb for kommunikation med HMH-enheden forløbe som beskrevet herunder: 1. Opstartssignal sendes til HMH. 2. Startsignal for ønsket disciplin sendes til HMH. 3. Målinger sendes fra HMH 4. Punkt 2-3 gentages så længe det ønskes. 5. Afslutningssignal sendes til HMH Styringssignaler De signaler der styrer de forskellige funktionaliteter i HMH-enheden består af tre forskellige tal. Når HMH-enheden modtager de tre tal beregnes checksummen af disse og hvis denne stemmer overens med et af de indkodede signaler udføres instruktionen. Det skal bemærkes at opstartssignalet skal sendes to gange, for at sikre mod en fejlagtig opstart af microcontrolleren. Herunder følger en oversigt over de 5 forskellige styringssignaler: Startsignal { , , } {9,95,50} Afslutningssignal { , , } {54,123,158} Tabel B2.1: Signaler til opstart og afslutning af HMH Styrke { , , } {68,119,167} Reflekser { , , } {67,104,155} Udholdenhed { , , } {54,113,153} Tabel B2.2: Signaler til start af discipliner. Oversigt over output fra HMH-enheden Når en disciplin er startet sendes de målte værdier løbende fra HMH og når disciplinen er færdig afsluttes med en stopbyte. Denne stopbyte har værdien 255, og er det eneste tidspunkt data sendt fra HMH kan have denne værdi, og det er således muligt at kontrollere hvornår afviklingen af en disciplin er færdig, ved at teste for denne værdi. Output for en enkelt disciplin er illustreret på figuren herunder: Figur B2.1: Output fra en disciplin sendt fra HMH. Det data der sendes fra HMH under afviklingen af de tre discipliner enheden stiller til rådighed er beskrevet i tabellen herunder: Disciplin: Beskrivelse: Antal målinger, n : Styrke Styrkedisciplinen måler hvor hårdt deltageren kan trykke i den tilkoblede hånd. Der foretages målinger over 5 sekunder i intervallet [0;99] og den 256 højeste af disse værdier er deltagerens score. Reflekser I refleksdisciplinen testes deltagerens reaktionsevne. Når en lampe lyser startes en timer som stoppes igen idet deltageren trykker i hånden. 2* *Omregning fra målingen til millisekunder er angivet under tabellen. Udholdenhed Ved udholdenhedsdisciplinen måles hvor hårdt deltageren i gennemsnit trykker i en given periode. Der foretages målinger over 5 sekunder og 256 gennemsnittet af disse målinger er deltagerens score. Tabel B2.3: Oversigt over discipliner i HMH. Reaktionstiden i refleksdisciplinen beregnes ved hjælp af følgende formel: ( ) Reaktionstid = 256 data + data 0,128ms 0 1 For både styrke- og udholdenhedsdisciplinen sendes data med et interval på: 5 sekunder 19,5ms 256 målinger Bilag

73 Bilag 3 Teknisk memo: Seriel kommunikation Sammendrag Der anvendes en hardwarekomponent CP til oprettelse af en virtuel COM-port, af RS-232 standarden. Denne benyttes til kommunikationen med henholdsvis SMS-modulet og HMHenheden. Tekniske faktorer SMS-modul HMH-enhed Motivation Kommunikationen med de ydre enheder, herunder HMH og SMS-modul, er den mest kritiske del i HMS-systemet. Løsning HMH-enhedens microcontroller opsamler data fra håndtrykket, og anvender seriel kommunikation til at overføre data til computeren. Kommunikationen mellem SMS-modulet og computeren er ligeledes en seriel kommunikation. De færreste moderne computere er udstyret med en RS-232 COM-port, til seriel kommunikation. Alle moderne computere har til gengæld en USB-port. Derfor er i der blevet undersøgt mulighederne for en USB til RS-232 løsning for at kunne anvende RS-232 som kommunikationsform. Det er valgt en hardwarekomponent CP2102, som er en USB til RS-232 bro. CP2102 driveren opretter en virtuel COM-port af RS-232 standarden på computeren. Principskitse for denne løsning ses på figur 1. Figur B3.1: Principskitse for seriel kommunikation med CP2102. Med denne løsning kan der programmeres direkte til RS-232 COM-port, uden at der skal tages højde for den fysiske USB-forbindelse. Til seriel kommunikation i Java benyttes en RxTx driver og RxTx API. Som et alternativ kunne Java Comm API blive anvendt, men da dette ikke opdateres længere af Sun, og der ikke findes drivere til Linux, vælges det førstenævnte. Uløste sager Ingen på nuværende tidspunkt Alternative løsninger Der er mulighed for anvendelse af en færdigudviklet USB til RS-232 adapter, denne løsning ville være for omkostningsfuld og ville ikke vise en udviklet hardwareløsning overfor TEK- BrobygningsCenter. 51 Datablad for CP2102 forefindes på cd. Bilag

74 Bilag 4 Teknisk memo: SMS-modul Sammendrag SMS-modulet TC65 benyttes til at sende og modtage SMS er. Modulet skal være tilsluttet til en computer, som tager sig af at styre modulet. Tekniske faktorer Siemens TC65 Datablad forefindes på cd. Da de færreste moderne computere er udstyret med en seriel port, har gruppen konstrueret en seriel-til-usb adapter, der etablerer en virtuel seriel-port på computeren (når drivere er installeret). Således kan der programmeres direkte til seriel-porten uden at tage højde for den fysiske USB-forbindelse, se eventuelt bilag 3. Motivation SMS-kommunikationen er en central del af Håndtryksmålersystemet. Løsning Det er et vigtigt krav for TEK-BrobygningsCenter, at de besøgende opretter sig som konkurrencedeltagere, og får deres samlede score med yderlige informationer via SMS. For at løse dette krav, anvendes Siemens TC65, som er et hardware-modul, der kan koble sig på direkte til GSM-nettet. Dette er blevet vurderet til at være den bedste løsning, da alternativet var benyttelse af eksterne SMS-servere, der ikke kan garantere en stabil og hurtig leveringstid af SMS-beskeder. Kommunikationen med SMS-modulet foregår ved at sende AT-kommandoer fra computeren gennem en seriel-port. En AT-kommando, som er en streng, behandles herefter af SMS-modulet, der udfører den ønskede kommando, og returner en streng med resultatet. En manual over alle ATkommandoer som TC65 understøtter forefindes på cd en. Det skal bemærkes, at SMS-modulet er en passiv enhed, derfor skal der bl.a. spørges om antallet af beskeder for at finde ud af om der er kommet nogle nye. Programmering af TC65 gennemgås i appendiks i slutningen af dette memo. Uløste sager Ingen på nuværende tidspunkt. Alternative løsninger Løsningen med eksterne SMS-servere er ikke blevet undersøgt nærmere. Appendiks - Java programmering af TC65 med AT-kommandoer Kommunikationen foregår ved at der sendes en AT-kommando på serielporten fra computeren, og responsen fra modulet læses derpå. Responslæsningen kan blive ret problematisk, da modulet i nogle tilfælde sender responsen i flere dele, med pauser imellem der kan variere i længde. Der er derfor to mulige strategier til hvordan responsen skal læses. En tråd der står for læsningen kan sættes til at sove indtil hele responsen er sendt, således at responsen først læses når tråden er aktiv igen. For at være sikker på at hele responsen er læst, skal sovepausen vare så langt tid som muligt. Lange sovepauser medfører imidlertid langsom læsning, hvilket er uønsket hvis der stilles krav til læsehastigheden. Dette er en simpel løsning, men ikke den bedste. En anden metode at læse responsen på, er ved at læse antallet af responslinjer. Når TC65 sender responsen i flere dele, er det altid med fuldførte linjer. Eksempel: 1. AT+CMGD= 1 2. (pause i respons, SMS-modulet udfører jobbet) 3. OK Bilag

75 Responspausen kan altså ikke opstå midt i AT+CMGD= 1. (TC65 sender AT-kommandoen tilbage som en indikation på modtagelse.) For at læse linjer, benyttes BufferedReader fra java.io biblioteket, der tilbyder en metode readline(). Således, når der vides hvor mange linjer responsen er på, kan der hele tiden forespørges om at læse en ny linje hvis den er tilgængelig, ready(), så længe dele af responsen mangler at blive læst. Dermed fjernes den kostbare ventetid fra hele responsen er sendt til den bliver læst. OutputStream fra java.io benyttes til at sende AT-kommandoer. Da den ønskede streng skal sendes som bytes på seriel-porten, benyttes getbytes() på strengen, og selve skrivesekvensen foretages ved at benytte write(bytes) fra OutputStream. Det skal bemærkes, at en AT-kommando skal afsluttes med \r\n. read(byte[]) fra InputStream benyttes til at læse en byte ad gangen. Dette tages i brug, når en SMS skal sendes, da TC65 returner nogle bytes undervejs, og ikke linjer. InputStream.available() kontrollerer om data er tilgængeligt. Initialiseringssekvens for TC65 er som følgende: Kommando type AT-kommando Antal linjer i responsen Default-indstillinger AT&F 3 Gem AT&W 3 8 bits, no parity, 1 stop bit AT+ICF=3 3 DSR til AT&S0 3 DCD til AT&C1 3 Gem AT&W 3 Text-mode AT+CMGF=1 3 UCS2 charset AT+CSCS= UCS2 3 Pinkode AT+CPIN= pinkode 3 Tabel B4.1: Initialiseringssekvens for TC65. Når SMS er bliver sendt til GSM-netværket benyttes GSM 03.38, som er en standart GSM tegnsæt. TC65 modtager beskeder i GSM-format, men når de skal udlæses på seriel porten, bliver de konverteret af modulet til enten ASCII eller UCS2 tegnsæt. (faktisk skal det angives AT+CSCS= GSM hvis det skal udlæses i ASCII, hvilket er noget misvisende). Da ASCII ikke understøtter æøå-bogstaver, benyttes UCS2 tegnsæt. UCS2 er forgænger for UTF-16 (Unicode 16- bit), men dette anvendes altså af TC65. Java understøtter Unicode (og andre tegnsæt), men ikke UCS2. Det er dog ikke et problem, da de 8 laveste bit er identiske, og det er kun dem, der er relevante (de indeholder alle tal og bogstaver fra det danske alfabet). Andre relevante AT-kommandoer Kommando type AT-kommando Antal linjer i Responslinje responsen der uddrages Typisk respons Test SMS-modul AT 3 3 OK Sluk SMS-modul AT^SMSO 8 8 ^SHUTDOWN Læs SMS AT+CMGR= num 5 3 SMS streng Send SMS AT+CMGS= mobil 5* 5* OK Slet SMS AT+CMGD= num 3 3 OK SMS er i hukommelsen AT^SLMS 7 3 ^SLMS: ''MT'',antal Tabel B4.2: Oversigt over relevante AT-kommandoer. Når en SMS skal sendes, skal mobil nr. angives, hvorefter selve meddelelsen skal skrives. Dette kan ikke gøres samtidig, da der først skal kontrolleres om TC65 er klar, ved at forsøge at læse en byte. Når meddelelsen er skrevet afsluttes med ctrl-z, hvilket skrives som \u001a i Java. Der skal derfor ikke afsluttes med \r\n som i andre tilfælde. Bilag

76 Bilag

77 Bilag 5 Analyseklassediagram Bilag

78 Bilag 6 Designklassediagram Bilag

79 Bilag 7 Designinteraktionsdiagram Opret konkurrencedeltager (B9) Bilag

80 Bilag 8 Designinteraktionsdiagram Deltag i konkurrence (B10) Bilag