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