Udviklingafdatabasesystem tilregionsjælands Befolkningsundersøgelse

Transkript

1 Udviklingafdatabasesystem tilregionsjælands Befolkningsundersøgelse Gruppe856c 2.Semester Sundhedsteknologimedspecialei MedicinskInformatik AalborgUniversitet 2009

2

3 Aalborg Universitet Institut for Sundhedsvidenskab og Teknologi TITEL: Udvikling af databasesystem til Region Sjællands Befolkningsundersøgelse TEMA: Medicinsk Informatik i klinisk praksis PROJEKTGRUPPE: Gruppe 856c GRUPPEMEDLEMMER: Kenneth Andersen Merete Martlev Jensen Ann Merete Duedal Jensen Anne Soe Korsager Rikke Kristensen VEJLEDERE: Mette Dencker Johansen SEMESTER: Sundhedsteknologi med speciale i Medicinsk Informatik 2. semester PROJEKTPERIODE: Foråret 2009 OPLAGSTAL: 8 SIDEANTAL: 175 Synopsis: Region Sjælland planlægger en befolkningsundersøgelse, der har til formål at sætte fokus på risikofaktorers indvirkning på kroniske sygdomme. I første omgang opsamles data fra deltagere, hvilket stiller krav til det system, der skal benyttes under lagring og håndtering af data. I dette projekt består data af besvarelser fra et subjektivt spørgeskema omhandlende personlige oplysninger, sygdom, fysisk aktivitet, deltagerens forældre, medicinforbrug, kost og drikkevarer. Metoderne, som anvendes er Unied Process, Entitets-Relation Modellering og Low-Fidelity Prototyping og sprogene er Unied Modeling Language, Java og Structured Query Language. Der er udviklet et databasesystem bestående af en database og brugergrænseade til håndtering af data fra Region Sjællands Befolkningsundersøgelse. I databasesystemet kan data indtastes, redigeres og udtrækkes. Det udviklede system betragtes ikke som et færdigt produkt til brug i Region Sjællands Befolkningsundersøgelse, men som et fundament, der kan udvikles og udbygges på baggrund af de krav, styregruppen for befolkningsundersøgelsen har stillet. Rapportens indhold er frit tilgængeligt, men oentliggørelse må kun ske efter aftale med forfatterne.

4

5 Forord Dette projekt er udarbejdet af projektgruppe 856c på civilingeniøruddannelsen i Sundhedsteknologi med speciale i Medicinsk Informatik på 2. semester på Aalborg Universitet, foråret Det overordnede tema for projektperioden er Medicinsk Informatik i klinisk praksis. Formålet er at lære at anvende og evaluere videnskabelige metoder i modellering og/eller designe et klinisk informationssystem. Rapporten henvender sig til censor og vejleder, som er tilknyttet projektet og andre interesserede. Der rettes en tak til Christina Ellervik, 1. reservelæge, Ph.D., Klinisk Biokemisk Afdeling, Næstved Sygehus og Palle Pedersen, Cand.Scient, Ph.D., Klinisk Biokemisk Afdeling, Næstved Sygehus. Projektet er udarbejdet af Kenneth Andersen Merete Martlev Jensen Ann Merete Duedal Jensen Anne Soe Korsager Rikke Kristensen III

6

7 Læsevejledning Rapporten er inddelt i otte dele. Del I indeholder en foranalyse med indledende overvejelser og problemformulering. Del II omhandler modellering af databasen. Del III til Del VII beskriver udviklingen af det samlede system i worows; krav, analyse, design, implementering og test, svarende til delenes opdeling. Del III indeholder en systembeskrivelse, deploymentdiagram og use case modellering. Del IV beskriver analysen af systemet og indeholder analyseklasser og interaktionsdiagrammer. I Del V designes systemet vha. designklasser og interaktionsdiagrammer. Del VI omhandler implementering af databasesystemet i undersystemer. I Del VII testes det implementerede system først igennem test af undersystemer og dernæst igennem testscenarier, der opstilles på baggrund af use casene. I den efterfølgende del, Del VIII, foretages en syntese af projektet, og denne indbefatter status i forhold til kravspecikation fra Region Sjællands Befolkningsundersøgelse, diskussion, konklusion og perspektivering. Rapporten indeholder desuden Appendix og Bilag, der ndes sidst i rapporten. I Appendix ndes beskrivelser af Entitets-Relations Modellering, designklassespecikationer, samt mailudveksling med styregruppen for Region Sjællands Befolkningsundersøgelse. Desuden ndes baggrundsviden om databaser i Appendix, og bilagene består af informationer og kravspecikation modtaget fra styregruppen for Region Sjællands Befolkningsundersøgelse. Til rapporten er der vedlagt en DVD, hvorpå kildekoden til det udviklede system ndes, samt en kopi af den samlede rapport i pdf-format. Desuden er systemet i eksekverbar udgave vedlagt på DVDen. Harvard-metoden er brugt til kildehenvisninger. Kildehenvisninger anført efter punktum refererer til det foregående afsnit, og kildehenvisninger anført før punktum refererer til foregående sætning. 1

8 INDHOLD Indhold 1 Indledning 7 Del I - Foranalyse 9 2 Overvejelser ved Region Sjællands Befolkningsundersøgelse inden datalagring Lovgivning Etik og screening Databehandling Systemer til datalagring ved Region Sjællands Befolkningsundersøgelse Regneark Databaser Databaser i forhold til regneark Valg af system til datalagring til Region Sjællands Befolkningsundersøgelse 17 4 Problemformulering Løsningsstrategi Del II - Modellering af database 23 5 Entitets-Relation Modellering Entitets-Relationsdiagram for Region Sjællands Befolkningsundersøgelse Omsætning fra Entitets-Relation diagram til relationer Normalisering af relationer

9 INDHOLD Del III - Krav 33 6 Krav Systembeskrivelse Systemarkitektur Use case modellering Afgrænsning af use cases Low-Fidelity prototype af brugergrænseaden Test af Low-Fidelity prototype Del IV - Analyse 53 8 Analyseklasser Klassespecikationer for analyseklasser Klassediagram for analyseklasserne Interaktionsdiagrammer for analyse Kommunikations- og sekvensdiagrammer Del V - Design Designklasser Designklasser udledt fra analyseklassen Brugergrænseade Designklasse udledt fra analyseklasserne Database og Eksport Designklasser udledt fra analyseklassen Spørgeskema Klassediagram for designklasserne Interaktionsdiagrammer for design Kommunikations- og sekvensdiagrammer Del VI - Implementering Implementering af brugergrænseade Implementeringsovervejelser

10 INDHOLD 12.2 Grask opsætning af brugergrænseaden Implementering af designklasser Implementering af database Oprettelse af tabeller Implementering af kommunikation Forbindelse til database Indtastning, redigering og udtrækning af data Eksport af data Del VII - Test Test af undersystemer Test af brugergrænseade Test af database Test af kommunikation Test af use cases Indtast data Redigér data Udtræk data Del VIII - Syntese Status i forhold til kravspecikation fra Region Sjællands Befolkningsundersøgelse Funktionelle krav Ikke-funktionelle krav Diskussion Konklusion Perspektivering 135 4

11 INDHOLD Litteraturliste 136 Appendix 139 A Udspecicering af Entitets-Relationsdiagram 141 B Klassespecikationer for designklasser 157 B.1 Klassespecikationer for GUI-klasserne B.2 Klassespecikationer for de øvrige klasser C Mailudveksling med styregruppen for Region Sjællands Befolkningsundersøgelse 171 D Databaseteori 173 Bilag 177 A Kravspecikation vedr. IT understøttelse af Region Sjællands Befolkningsundersøgelse 179 B Region Sjællands Befolkningsundersøgelse med optageområde for Sygehus Syd 180 C Subjektivt spørgeskema 181 5

12

13 Kapitel 1 Indledning I Danmark er der stort fokus på at styrke sundhedsfremme og forebyggelse af sygdomme. Dette fokus bliver stadig større, da antallet af danskere med en kronisk sygdom er stigende samtidig med, at kendskabet til sammenhængen mellem risikofaktorer og sygdom gennem de seneste år er vokset. [Sundhedsstyrelsen, 2007] Desuden er middellevetiden i Danmark den næstlaveste i EU; kun Irland har en lavere middellevetid [Nyt fra Danmarks Statistik, 2003]. Den primære årsag er overdødelighed som følge af livsstilsrelaterede sygdomme [Sundhedsstyrelsen, 2007]. Kendskab til risikofaktorer ligger til grund for målrettet forebyggelse. Dermed kan adskillige mennesker undgå at udvikle en folkesygdom, hvis der iværksættes en indsats for forebyggelse og sundhedsfremme. Der er forskellige risikofaktorer, der har indvirkning på befolkningens sundhedstilstand, herunder de individuelle livsstilsfaktorer, såsom kost og motion, og de generelle samfundsforhold og levekår, som indkomst, boligforhold, uddannelsesmuligheder, arbejdsmuligheder, arbejdsmiljø og sundhedsvæsenets indretning. [Sundhedsstyrelsen, 2007] Et af redskaberne til at kortlægge ovennævnte risikofaktorers påvirkning på kroniske folkesygdomme, som fx cancer, lungesygdomme, stofskiftelidelser, kredsløbssygdomme og allergier, er befolkningsundersøgelser. En befolkningsundersøgelse indebærer at undersøge raske som syge personer i et bestemt geogrask område. Et aktuelt eksempel på en sådan undersøgelse er Region Sjællands Befolkningsundersøgelse. Udover at Region Sjællands Befolkningsundersøgelse skal nde sammenhænge mellem risikofaktorer og sygdomme i regionen, skal den medvirke til at klarlægge sundhedstilstande, herunder ikke-erkendte sygdomme som diabetes og åreforkalkning hos den generelle befolkning i regionen. På længere sigt skal denne befolkningsundersøgelse yderligere bidrage til forskning indenfor arveligheden af multifaktorielle folkesygdomme og beskrive ændringer i niveauet af risikofaktorer. I Region Sjællands Befolkningsundersøgelse forventes et deltagerantal på ca og befolkningsundersøgelsen designes som et longitudinelt studie med opfølgning hvert år. Næstved Kommune er den første kommune, som vil blive inviteret, og 7

14 1. Indledning det forventes, at denne del af befolkningsundersøgelsen vil forløbe over ca. 4 år med start medio 2009 og vil inkludere omkring deltagere fra kommunen. Befolkningsundersøgelsen består af tre forskellige dele. Hver deltager skal udfylde et subjektivt spørgeskema omhandlende nuværende og tidligere sygdomme, levevaner, familiemæssige og sociale forhold, samt trivsel. Derudover udføres en objektiv fysisk helbredsundersøgelse af deltagerne, og der oprettes en biobank, hvor biokemiske data opbevares til senere forskningsformål. For hver enkelt deltager vil det samlede antal parametre fra helbredsundersøgelsen, spørgeskemabesvarelsen og blodprøverne være ca. 500, hvilket med ca deltagere vil resultere i parametre. Desuden vil dette tal fordobles for hvert fremmøde. Således er et af kendetegnene ved befolkningsundersøgelsen en stor mængde data af forskellige formater, der skal opsamles og lagres med varierende procedurer. Eksempelvis planlægger befolkningsundersøgelsens styregruppe, at størstedelen af data skal overføres direkte fra elektronisk måleudstyr og ved brug af software til oversættelse af spørgeskemaer på papirform til kommaseparerede (csv) ler. Alligevel vil der være nogle få parametre, der kræver manuel indtastning. Derudover skal der opbevares et elektrokardiogram for hver deltager. For at disse data efterfølgende kan tilgås på en nem og hensigtsmæssig måde, er det nødvendigt at overveje hvilke hensyn, der skal tages før og under lagring af data. Denne rapport vil derfor omhandle de datalagringsmæssige aspekter ved Region Sjællands Befolkningsundersøgelse, herunder udviklingen af et lagringssystem til brug under befolkningsundersøgelsen. 8

15 Del I Foranalyse Foranalysen omhandler lagringsmæssige aspekter og overvejelser ved datalagring i forbindelse med Region Sjællands Befolkningsundersøgelse. Aspekterne indbefatter den gældende lovgivning, etiske overvejelser om screening og databehandling. Overvejelserne indenfor disse kategorier skal sammen med en sammenligning mellem to løsningsmuligheder, regneark og database, danne grundlag for at vælge det system, som skal anvendes til datalagring under befolkningsundersøgelsen. Herefter følger en problemafgrænsning og problemformuleringen for projektet opstilles. For at opnå et overblik over den resterende rapport sluttes delen med en løsningsstrategi, hvor metoderne til løsningen præsenteres.

16

17 Kapitel 2 Overvejelser ved Region Sjællands Befolkningsundersøgelse inden datalagring Dette kapitel behandler de overvejelser og hensyn, der skal tages før lagring af data fra Region Sjællands Befolkningsundersøgelse kan nde sted. Disse overvejelser medvirker til at bestemme selve designet af lagringsystemet ved at stille en række funktionelle krav. Region Sjællands Befolkningsundersøgelse involverer opbevaring af personoplysninger, hvormed persondataloven skal overholdes. I det følgende beskrives denne lovs betydning og etiske overvejelser i forbindelse med datalagring til befolkningsundersøgelsen. Udover de lovmæssige og etiske aspekter om screening skal det overvejes, hvordan data efterfølgende skal behandles, da dette har betydning for måden, hvorpå data lagres optimalt. 2.1 Lovgivning Ifølge direktivet 95/46/EF omhandlende beskyttelse af fysiske personer i forbindelse med behandling af personoplysninger og om fri udveksling af sådanne oplysninger stilles der krav om, at identikationsoplysninger, såsom CPR-nr., skal krypteres [Nielsen and Waaben, 2001]. Dette betyder, at der er begrænset adgang til de lagrede oplysninger, og kun de dataansvarlige og forskningsgruppen har adgang til alle oplysninger. Endvidere kræves det, at oplysningerne kan rettes, slettes eller anonymiseres i tilfælde, hvor de er forkerte, vildledende eller hvis deltageren ikke ønsker at deltage i befolkningsundersøgelsen længere. Ydermere skal det i en tilladelse fra tilsynsmyndigheden præciseres hvilke o- plysningstyper, der må vidergives. [Nielsen and Waaben, 2001] [Datatilsynet, 2009] Ifølge rapporten Vejledninger i God Videnskabelig Praksis med særlig fokus på sundhedsvidenskab, naturvidenskab og teknisk videnskab fra januar 2009 giver persondataloven pligt til at give deltagerne indsigt i de oplysninger, der behandles om den registrerede, hvis vedkommende ønsker det. [Udvalgene vedrørende Videnskabelig Uredelighed, 2009] Adgangen til de opsamlede data må kun ske ved at benytte fortrolig adgangskode, som skal skiftes ud mindst en gang årligt, hvilket vil betyde, at der skal implementeres en log ind funktion i lagringssystemet. 11

18 2. Overvejelser ved Region Sjællands Befolkningsundersøgelse inden datalagring Dette betyder for Region Sjællands Befolkningsundersøgelse, at oplysningerne indsamlet fra befolkningsundersøgelsen skal lagres således, at der forendes en kobling mellem deltagerne og de indsamlede data om den enkelte deltager. Der skal være en nøgle med personhenførbare data, der kobler data med deltagerne. Denne nøgle må kun være kendt af den dataansvarlige og styregruppen, så en forsker i et konkret projekt aldrig kan få oplyst denne nøgle. 2.2 Etik og screening Ved opsamling af store mængder data vedrørende menneskers helbredsmæssige tilstand kan der være data, der tyder på ikke-erkendte sygdomme hos de deltagende, hvilket resulterer i etiske overvejelser om screening. De dataansvarlige vil i sådanne situationer have et ansvar overfor deltagerne og har pligt til at oplyse dem om deres fund. Deltagerne har mulighed for at fraskrive sig retten til disse oplysninger, hvilket vil sige, at de inden deltagelse kan underskrive en samtykkeerklæring om, at de ikke vil have del i denne viden. I tilfælde af, at der ndes uventede fund af helbredsmæssig betydning hos en deltager i Region Sjællands Befolkningsundersøgelse, bliver pågældende deltager informeret om dette. Den enkelte deltager får ikke kendskab hertil, hvis der er givet samtykke til, at vedkommende ikke ønsker denne information. Der er i undersøgelsen deneret grænser for, hvornår de biokemiske variable kan give begrundet mistanke om forekomst af sygdomme. Udover at de biokemiske variable undersøges ved blodprøvetagningen før nedfrysning, skal data tjekkes ved lagring. Det kan fx gøres ved at implementere grænser i lagringssystemet som en sikkerhed for, at ingen værdier over disse grænser overses. Styregruppen for Region Sjællands Befolkningsundersøgelse planlægger desuden at udvikle algoritmer til at tjekke tidligere deltageres undersøgelser, således at de deltagere, hvor det er nødvendigt, henvises til den rette videre behandling. Dette skal derfor implementeres i lagringssystemet. Fund af ikke-erkendte sygdomme giver mulighed for at afdække sygdomsmæssige forhold, hvilket vil være uetisk ikke at reagere på. Der skal tages stilling til, hvorledes oplysninger håndteres i tilfælde af fund af fx en arvelig sygdom, som ere familiemedlemmer også har en risiko for at lide af, selvom de ikke nødvendigvis er en del af undersøgelsen. I et lagringssystem til brug ved undersøgelsen skal der derfor være strukturer, der understøtter det, der vælges angående uventede fund. 2.3 Databehandling Når der søges tilladelse fra Datatilsynet angående datalagring er denne altid tidsbegrænset. Det betyder, at personhenførbare oplysninger skal anonymiseres eller destrueres 12

19 2.3. Databehandling ved tilladelsens ophør. Der er ikke en generel tidsramme for dette, hvorfor denne skal fastlægges for hver enkelt situation. Behandlet data fra forskning bør altid stilles til rådighed for andre forskere efter et projekts afslutning, således yderligere forskning eller genvurdering af de opnåede resultater er mulig. Efter tilladelsens ophør vil data stadig have betydning for forskning på trods af, at data ikke længere er personhenførbare og ikke har værdi for den enkelte deltager, da analyse stadig er mulig. Det er desuden vigtigt i databehandlingsøjemed, at persondata bliver adskilt fra forskningsdata. [Udvalgene vedrørende Videnskabelig Uredelighed, 2009] Region Sjællands Befolkningsundersøgelse er designet som et longitudinelt studie, hvormed der foretages gentagne observationer af samme deltagere over en længere tidsperiode. Det resulterer i, at deltagerne skal genindkaldes en til ere gange, hvormed den samlede datamængde forøges for hvert fremmøde, og databehandlingen kompliceres. Den øgede datamængde bevirker, at måden data lagres på er et vigtigt element, når data senere skal behandles og analyseres. Tidsrammen for hele studiet er minimum 20 år, hvilket er af betydende karakter, da opbevaring af data ikke må være at nde i identicerbar form i længere tid end nødvendigt. I Region Sjællands Befolkningsundersøgelse er der ere stationer, hvor helbredsundersøgelsen nder sted, hvilket bevirker, at der skal være mulighed for, at data kan lagres parallelt. Derudover skal det senere være muligt for ere forskere at udtrække data parallelt til forkellige forskningsprojekter. Lagringsystemet skal derfor kunne håndtere ere brugere samtidig. Det er vigtig at kunne fremnde CPR-nr. i Region Sjællands Befolkningsundersøgelse, når en deltager skal genindkaldes til undersøgelse efter år, eller hvis det ønskes at linke en deltager til andre registre såsom Cancer-, Landspatient- og Dødsårsagsregisteret. En sådan kobling kan bidrage til forskning i årsager til udvikling af kroniske sygdomme [Osler and Jørgensen, 2004]. Som nævnt er det vigtigt, at persondata er adskilt fra data, hvormed data bør lagres således, at de enkelte deltageres data er identicerbare for forskerne fx vha. et deltagernr.. Dermed har de dataansvarlige stadig mulighed, som de eneste, at koble CPR-nr. og deltagere vha. deltagernr.. Det er vigtigt, at lagring af opnåede videnskabelige data udføres hensigtsmæssigt, således alle lovmæssige aspekter opfyldes. Endvidere bør både deltagere og forskere have gavn af befolkningsundersøgelsen, hvilket muliggøres ved en hensigtsmæssig lagring, da deltagernes oplysninger hurtigt og nemt skal ndes frem til screening og behandling. Da der ndes ere forskellige måder at lagre data på, bør det undersøges hvilket system, der er mest brugbart til lagring af data fra befolkningsundersøgelsen. 13

20

21 Kapitel 3 Systemer til datalagring ved Region Sjællands Befolkningsundersøgelse Ved lagring af store mængder data, som det er tilfældet ved Region Sjællands Befolkningsundersøgelse, er det nødvendigt at anvende det mest hensigtsmæssige lagringssystem. Der ndes ere typer løsninger til elektronisk lagring af data, der overordnet er opdelt i regneark og databaser. Dette kapitel giver et overblik over disse to valgmuligheder, hvor deres fordele og ulemper klarlægges. På dette grundlag vælges et system til at lagre data fra befolkningsundersøgelsen. 3.1 Regneark Et af de mest anvendte regnark er Microsoft Oce Excel, herefter betegnet Excel. Statistikprogrammer som fx SPSS er desuden deneret som regneark. Regneark kræver oftest, at programmet til regnearket er installeret, når data skal tilgås, hvis ikke et open source program er tilgængelig eller data er konverteret til et format, som kan åbnes af andre programmer. Det sidste kan betyde, at data ikke kan behandles men kun kan synliggøres. De este som bruger IT, har også anvendt regneark, og regneark er derfor ofte betegnet som intuitive og brugervenlige. [Tomida, 2006] I et regneark præsenteres data i en to-dimensionel tabel, hvorfra analyser kan foretages. Regnearket er bygget op af celler, som dannes ud fra rækker og søjler. Regneark har en række- og søjlebegrænsning, hvormed data som overskrider denne begrænsning skal opdeles på ere regneark, fx er Microsofts række- og søjlebegrænsning på søjler og rækker [Microsoft Developer Network, 2006]. Regneark arbejder ikke kun med rådata, når analyser udføres. Antallet af gemte parametre øges med antallet af analyser, hvilket betegnes som dataredundans, fordi meget unødvendig data gemmes. Regneark vil oftest være udarbejdet på én computer, hvormed data kun kan tilgås fra denne computer. Hvis en serverløsning er valgt, kan computere tilkoblet denne tilgå data. 15

22 3. Systemer til datalagring ved Region Sjællands Befolkningsundersøgelse Det vil ikke være muligt for ere brugere at redigere i det lagrede data samtidig, selvom en serverløsning er valgt. Regneark gemmer de ændringer, der bliver lagret sidst og alle foregående simultane ændringer vil gå tabt [Tomida, 2006]. 3.2 Databaser Den mest udbredte databasetype er den relationelle database. Herudover ndes der den hierakiske database og den objektorienterede database. [Jensen et al., 2006] Eksempler på relationelle databaser er MySQL, MS SQL og Oracle. Databasesystemer er platformsuafhængige, men kræver hardware- og softwareomkostninger ved opstart [Database - Advantages & Disadvantages, 2009]. Adgangen til data for brugere sker gennem host and query languages, hvilket kræver træning i det sprog, der benyttes. Dog ndes der systemer til oversættelse af forespørgsler. Databasesystemer betegnes som komplekse, svære og tidskrævende at designe [Database - Advantages & Disadvantages, 2009]. Dataindtastning, -lagring og -udtrækning er forbundet med få omkostninger. Alternativt kan adgangen til data lagret i databasen foregå gennem en brugergrænseade udviklet til formålet. I en relationel database præsenteres data oftest i ere tabeller, der kobles sammen vha. relationer. Tabellerne består af felter, der ligesom regneark er dannet af rækker og søjler. Ved brug af databaser kan regler opsættes for at sikre, at data er sammenhængende ved tilføjelser, opdateringer eller sletning af data. Der arbejdes kun på rådata, hvormed dataredundans minimeres. Flere brugere kan tilgå data samtidig, ligesom ere brugere kan redigere, slette og tilføje data parallelt. I disse tilfælde håndterer et database managementsystem (DBMS) simultane ændringer. For mere information angående DBMS, se Appendix D på side 173. Databasesystemer er derfor forbundet med få opdateringsfejl og øget konsistens, og giver desuden stor datasikkerhed. [Database - Advantages & Disadvantages, 2009] Databasesystemer betyder dataintegritet og uafhængighed fra andre applikationer, hvilket anses som en fordel, men hvis der sker skader på databasen, påvirker det næsten alle tilhørende applikationer. [Database - Advantages & Disadvantages, 2009] 3.3 Databaser i forhold til regneark Som nævnt i Afsnit 3.2 kan der i databasesystemer opsættes regler for at sikre datakonsistens, mens regneark ikke giver denne mulighed. Her kan brugere selv indsætte data i en prædeneret struktur, men der er ingen måde at tjekke, om brugeren indsætter data rigtigt i denne struktur. Databaser begrænser brugernes adgang til data og tillader ikke 16

23 3.4. Valg af system til datalagring til Region Sjællands Befolkningsundersøgelse brugeren at ændre datastrukturen. [Tomida, 2006] Dataredundans er vigtig at overveje ved store mængder data, som tilfældet er med Region Sjællands Befolkningsundersøgelse, da dataredundans øges med mængden af data. I denne sammenhæng har databaser en fordel i forhold til regneark, se evt. Afsnit 3.1 på side 15 og Afsnit 3.2 på forrige side. Brugervenligheden af databasesystemet er afhængig af designet af brugergrænseaden, hvorimod brugervenligheden af regneark altid er den samme og afhænger således af brugerens præferencer. Grundet størrelsen af befolkningsundersøgelsen bør række- og søjlebegrænsningen ved regneark medtages i overvejelserne, da denne kan overskrides, hvormed ere tabeller er nødvendige. Denne begrænsning har databasesystemer ikke, jævnfør Afsnit 3.2 på modstående side. Parallel tilgang til data er centralt ved datalagring ved Region Sjællands Befolkningsundersøgelse, da ere helbredsundersøgelser udføres samtidig og data dermed skal kunne overføres parallelt. Ligeledes skal udtrækning af data kunne ske parallelt, da ere forskere skal kunne tilgå data samtidig. I denne forbindelse er datadeling nemmere ved brug af databaser, da det kan fungere blandt ere brugere på samme computer eller på forskellige computere forbundet gennem et netværk. Dette er muligt, da der kan opstilles regler, der beskytter data, se evt. Afsnit 3.2 på forrige side. Ved brug af databaser er det nemmere at dele data mellem forskellige operativsystemer, netop pga. platformsuafhængighed. Med Microsoft Excel er data nemmere at læse for et Windows operativsystem end for et alternativt operativsystem, hvilket gælder for regneark generelt. [Tomida, 2006] En vigtig fordel ved databaser er sikkerhed. De este DBMS'er tillader, at der skabes brugere med forskellige niveauer af sikkerhed. Før en bruger tilgår en database, bør brugeren logge ind med et brugernavn og adgangskode. Hver bruger kan have forskellige rettigheder og begrænsninger. [Tomida, 2006] 3.4 Valg af system til datalagring til Region Sjællands Befolkningsundersøgelse På baggrund af ovenstående sammenligning af regneark og databaser konkluderes det, at lagringen af data til Region Sjællands Befolkningsundersøgelse skal gennemføres med en databaseløsning. Det vurderes, at brugervenligheden er størst ved en databaseløsning med brugergrænse- ade fremfor ved regneark. Da antallet af deltagere og parametre for hver deltager er så stort, vil det betyde, at fx Microsoft Excels rækkebegrænsning på overskrides, og 17

24 3. Systemer til datalagring ved Region Sjællands Befolkningsundersøgelse regnearket skal opsplittes. Opsplittede tabeller i et regneark bliver uoverskuelige, da der ikke er direkte sammenhæng mellem disse. Desuden begrundes valget med at en databaseløsning giver mulighed for at tilgå data parallelt, og krav til IT-sikkerheden kan nemmere opfyldes ved en databaseløsning, da databaser har større datasikkerhed. Et eksempel er, at personoplysningerne ikke skal være kendt af alle brugere til systemet. Derfor skal løsningen kunne opfylde, at brugere har forskellig adgang til data, hvilket databasesystemer kan opfylde. 18

25 Kapitel 4 Problemformulering I de foregående kapitler blev nødvendigheden af hensigtsmæssig datalagring beskrevet. Ved hjælp af sammenligning af regneark og databaser blev en databaseløsning valgt til at lagre data opsamlet fra Region Sjællands Befolkningsundersøgelse. I det følgende beskrives det foreliggende projekts afgrænsning og der opstilles en problemformulering og løsningsstrategi. Ønsket fra styregruppen for Region Sjællands Befolkningsundersøgelse er som udgangspunkt en grunddatabase, der kan integrere data fra spørgeskema, helbredsundersøgelse og biokemiske undersøgelser. Da befolkningsundersøgelsen påbegyndes i Næstved Kommune, kan dette ses som et pilotprojekt. Det vælges derfor at afgrænse det foreliggende projekt til at udvikle en database til brug under pilotprojektet, da der muligvis kan opstå ændringer i procedurer og protokoller efter pilotprojektets afslutning. Det betyder, at det foreliggende projekt bygger på beskrivelser og informationer udarbejdet til befolkningsundersøgelsen, samt mailudveksling med styregruppen. Disse informationer kan læses i Appendix C på side 171 og Bilag A, B og C. Endvidere begrænses det foreliggende projekt af, at befolkningsundersøgelsen endnu ikke er påbegyndt og dermed ikke endelig formuleret og planlagt. Designet af helbredsundersøgelsen og protokollerne for biokemisk opsamlet data er endnu ikke færdiggjort, hvorfor det vælges at fokusere på spørgeskemaundersøgelsen, der er klar til at blive sendt til borgerne i Næstved Kommune. Styregruppen har opdelt spørgeskemaet i følgende kategorier; Spørgeskema, Deltager, Sygdom, Fysisk aktivitet, Forældre, Kost og drikkevarer, Medicin, Kvinder, Rygning, Uddannelse, erhverv og bopæl, Trivsel og velbendende, Ophold i solen, Læge og AP-skema. Det vælges at fokusere på et af hovedmålene med Region Sjællands Befolkningsundersøgelse, hvilket er at opspore diabetes og undersøge genetisk disponering for diabetes. På baggrund af det mål udvælges det at fokusere på nogle af de kategorier, der kan have betydning for udvikling af diabetes. Herudover vælges kategorier, der indeholder information om den enkelte deltager og dennes udfyldte spørgeskema. De valgte kategorier er 19

26 4. Problemformulering derfor; Spørgeskema, Deltager, Sygdom, Fysisk aktivitet, Forældre, Kost og drikkevarer og Medicin. Disse kategorier vil derfor medtages i den videre analyse, design og implementering af grunddatabasen. For at kunne lagre og udtrække data fra grunddatabasen skal der desuden designes og implementeres en brugergrænseade. På baggrund af ovenstående afgrænsning er følgende problem formuleret, som besvares i den resterende del af rapporten: Problemformulering Der analyseres, designes og implementeres et databasesystem indeholdende en grunddatabase og en brugergrænseade til lagring og udtrækning af data fra spørgeskemaer fra Region Sjællands Befolkningsundersøgelse i Næstved. 4.1 Løsningsstrategi Databasen designes gennem Entitets-Relations (ER) modellering, som er en struktureret metode til at modellere en database, hvormed fx datakonsistens ved ere brugere, skelnen mellem ukendt og ikke-indtastet data og fornuftig lagring er mulig. Dette vil være vanskeligt at opnå ved en ustruktureret metode. Der laves en low-delity (Lo-Fi) prototype af brugergrænseaden. Brugergrænseaden realiseres ligesom kommunikationen til databasen ved brug af programmeringssproget Java, som er kendetegnet ved at være et objektorienteret sprog. Derfor vælges det at benytte udviklingsmetoden Unied Process (UP), der dokumenteres ved brug af modelleringssproget Unied Modeling Language (UML). Entitets-Relations modellering ER-modellen beskriver den underliggende struktur af en database, og opbygges af to typer basisobjekter, entitetsklasser og relationsklasser. En entitetsklasse er en samling af entiteter med egenskaber indenfor samme område, hvor hver entitet betragtes som en unik forekomst af entitetsklassen. Entiteter beskriver objekter i den verden, som ønskes modelleret, og kan enten være konkrete eller abstrakte. Hver entitetsklasse er beskrevet ved et sæt af attributter, som repræsenterer egenskaber af hvert medlem i en entitetsklasse. Hver entitet i en entitetsklasse skal have de samme attributter, men værdien af disse er ikke nødvendigvis ens. Attributternes tilladte værdier kaldes for domæne. Desuden skal hver entitet i en entitetsklasse unikt kunne identiceres, hvortil primær- og fremmednøgler anvendes. Hvis en attribut har funktionen primærnøgle understreges navnet i denne. [Silberschatz et al., 2005] En relationsklasse er en samling af relationer af samme type, og en relation beskriver en association mellem ere entiteter. En relationsklasse består af en række attributter, 20

27 4.1. Løsningsstrategi der kaldes beskrivende attributter. Hver relation i en relationsklasse skal have samme attributter, men værdierne af disse er ikke nødvendigvis ens. ER-modellen beskrives grask i ER-diagrammer, hvor entitetsklasser, relationsklasser og attributter optræder i den logiske struktur, der ønskes implementeret i databasen. Low-Fidelity Prototyping En Lo-Fi prototype har til formål at illustrere et systems grundidé eller aspekter af et sådan, hvormed en prototype kan bidrage under analysen, designet og implementeringen. Lo-Fi prototyper benyttes til at teste ideer og evaluere grundidéen, hvorefter systemet kan forbedres. I interaktionsdesign er en Lo-Fi prototype en model af et system, eller dele af et system. Det kan fx være et storyboard, der viser brugerens interaktion med systemet, et powerpoint show eller mock-ups af brugergrænseader lavet i papir eller software med begrænset funktionalitet. [Sharp et al., 2007] Unied Process UP er en objektorienteret metode til design og udvikling af software og karakteriseres ved at være iterativ og inkrementel, hvorfor systemet ikke udvikles som et lineært forløb. UP består af et antal inkrementelle faser, hvori der udføres iterativt arbejde indenfor en række workows. Faserne opdeles i Inception, Elaboration, Construction og Transition. Inception er en forberedelsesfase, hvor mål og muligheder for systemet deneres, Elaboration er en etableringsfase, hvor en mere detaljeret analyse af krav og arkitektur udføres, Construction er en konstruktionsfase, hvor systemet udvikles gennem iterationer og Transition er den afsluttende fase, hvor systemet overdrages til brugeren. Hver fase karakteriseres ved en række workows, som udgøres af Krav, Analyse, Design, Implementering og Test. Afhængigt af den pågældende fase, udføres arbejde i et udvalg af de angivne workows. [Eriksson et al., 2004] UP karakteriseres desuden ved at være use case drevet, arkitekturcentreret og risikodrevet. De forskellige use cases benyttes til at illustrere de funktionelle krav og UP, som use case drevet metode, sikrer at applikationsområdet er i fokus i modelleringen fremfor hele problemdomænet. UP er arkitekturcentreret i den forstand, at der udarbejdes en veldeneret arkitektur tidligt i forløbet, og risikodrevet, da kritiske risici håndteres målrettet fra begyndelsen af udviklingsprocessen. [Eriksson et al., 2004] 21

28 4. Problemformulering Unied Modeling Language UML er et objektorienteret modelleringssprog, som indeholder forskellige diagramtyper og elementer. Det system der skal udvikles beskrives vha. deployment-, proces-, logisk-, implementerings- og use case views. Hvert view er en abstraktion af systemet, der viser forskellige aspekter af samme system, og som sammenbinder udviklingsmetoden med kommunikationssproget. Samlingen af alle views viser det fuldstændige system. På baggrund af iterationer i de forskellige workows igennem en række faser, fremkommer modeller, som enten helt eller delvist kan sidestilles med disse views og som kommunikeres igennem diagrammer. Afhængig af det pågældende workow, benyttes deployment-, use case-, aktivitets-, klasse-, kommunikations- og sekvensdiagrammer. [Eriksson et al., 2004] 22

29 Del II Modellering af database Del II beskriver design af databasen til Region Sjællands Befolkningsundersøgelse vha. Entitets-Relation Modellering. Et endeligt Entitets-Relationsdiagram vil blive præsenteret, samt en beskrivelse heraf. Dette vil ende ud i forskellige relationer, som er mulige at implementere.

30

31 Kapitel 5 Entitets-Relation Modellering I dette kapitel dokumenteres ER-diagrammet for hele databasen. Derefter reduceres udvalgte entitetsklasser, Deltager og Forældre, i ER-diagrammet til en samling relationer, hvilke desuden beskrives. De resterende entitetsklasser beskrives og reduceres til relationer i Appendix A på side 141. Disse udtrykker tilsammen ER-modellen. Databasen designes som en relationel database, da dette er den mest anvendte form for databaser. Relationelle databaser bruger en samling af tabeller til at repræsentere data og relationer mellem disse data, se evt. Appendix D på side Entitets-Relationsdiagram for Region Sjællands Befolkningsundersøgelse På Figur 5.1 på næste side ses det overordnede ER-diagram for databasen. I ER-diagrammet er entitetsklasserne repræsenteret ved rektangler, attributter som ovaler, mens relationerne er vist ved rhomber. Hvis en entitetsklasse ikke kan eksistere uden en anden entitetsklasse vises dette ved en dobbeltstreg. [Silberschatz et al., 2005] Oplysninger om graden af relationerne på et ER-diagram kaldes kardinalitet. [Silberschatz et al., 2005] Spørgeskemaet, helbredsundersøgelsen og blodprøverne fra Region Sjællands Befolkningsundersøgelse er alle med i diagrammet. For at skabe overblik er attributter ikke at nde på guren. Entitetsklasserne er fundet ved at inddele spørgsmålene fra spørgeskemaet og målingerne fra helbredsundersøgelsen i kategorier. 25

32 5. Entitets-Relation Modellering Deltager 1 1 Udfylder Spørgeskema Fysisk aktivitet AP-skema 1 1 Sygdom Blodprøver 1 Får foretaget 1 Læge 1 Indeholder 1 Rygning Helbredsundersøgelse Medicin Kvinder Kropsmål 1 Indeholder 1 Kredsløb 1 1 Ophold i solen Forældre 1 1 Lunge Trivsel og velbefindende 1 Kost/Drikkevarer 1 Uddannelse, erhverv og bopæl Figur 5.1: Overordnet ER-diagram for databasen. Entitetsklasserne er repræsenteret ved rektangler og rhomberne betegner relationerne. Desuden ses kardinaliteterne mellem entiteter. Attributterne er ikke på dette diagram, men udspeciceres i andre gurer. Dobbeltstregerne indikerer, at Spørgeskema og Helbredsundersøgelse ikke kan eksistere uden en deltager. Det er, som nævnt i Kapitel 4 på side 19, valgt at fokusere på kategorier, der kan have betydning for udvikling af diabetes. Hver kategori bliver til en entitetsklasse, og derfor designes entitetsklasserne Spørgeskema, Deltager, Sygdom, Fysisk aktivitet, Forældre, Kost og drikkevarer og Medicin. Det er dog kun entitetsklasserne Deltager og Forældre, som udspeciceres med attributter og reduceres til relationer i dette kapitel. Udspeciceringen af det overordende ER-diagram vises for begge entitetsklasser, hvormed attributterne er medtaget på Figur 5.2 for entitetsklassen Deltager og Figur 5.3 på næste side for entitetsklassen Forældre. Deltagernr. CPR-nr. Dødsfald Navn Dato for 2. invitation Deltager Adresse Dato for 1. invitation Telefonnr. Genindkaldel - sesdato Fremmødt dato Figur 5.2: Udspecicering af ER-diagrammet for Entitetsklassen Deltager. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. 26

33 5.1. Entitets-Relationsdiagram for Region Sjællands Befolkningsundersøgelse Far: uddannelse Deltagernr. Mor: sukkersyge Far: sukkersyge Mor: depression Far: depression Mor: galdesten Far: galdesten Mor: uddannelse Mor: allergi Far: forhøjet blodtryk Far: allergi Mor: forhøjet blodtryk Forældre Mor: astma Far: forhøjet kolesterol Far: astma Mor: forhøjet kolesterol Mor: blødersygdom Far: kræft Far: blødersygdom Mor: kræft Far: blodprop i lunge Far: blodprop i hjertet Far: blodprop i hjernen Mor: blodprop i hjernen Mor: blodprop i lunge Mor: blodprop i hjertet Figur 5.3: Udspecicering af ER-diagrammet for Entitetsklassen Forældre. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Attributterne til entitetsklasserne er baseret direkte på de spørgsmål, der er stillet i spørgeskemaet til befolkningsundersøgelsen, se Bilag C. Deltagernummeret er unikt for hver eneste deltager, hvorfor denne attribut fungerer som en primærnøgle for alle entitetsklasser. Primørnøglen er understreget i diagrammerne. Alle attributter vil blive repræsenteret ved en streng, fx vil attributten Dødsfald i entitetsklassen Deltager kunne antage værdierne Ja og Nej. Hvis intet er valgt, er strengen tom. Attributterne tilhørende entitetsklassen Deltager kan antage ere værdier i form af en streng med enten et navn, nummer eller dato. Entitetsklassen Forældre indeholder attributter, der kan antage værdier i form af en streng med specikke sygdomme eller uddannelser. 27

34 5. Entitets-Relation Modellering 5.2 Omsætning fra Entitets-Relation diagram til relationer Det er anvendeligt at transformere ER-diagrammet til et sæt af relationer. Til hver entitet hører en relation, og hver relation indeholder et sæt af navngivne søjler. Søjlerne tilsvarer attributterne i ER-diagrammet, og de attributter, der fungerer som nøgler i ERdiagrammet, er primærnøgler i relationerne. Desuden indeholder den enkelte relation et arbitrært antal rækker. En struktureret relation besidder en minimal mængde redundans og tillader, at der kan indsættes, modiceres og slettes rækker uden nogen former for fejl eller inkonsistens. [Silberschatz et al., 2005] Da en database ofte har et stort antal relationer og attributter og et endnu større antal rækker og det desuden er tidskrævende at opdage repetitioner, bør der opstilles nogle regler. Disse regler gør det muligt at opfange situationer, hvor en relation bør nedbrydes i to eller ere relationer. Nedbrydningen foregår efter nogle foruddenerede regler og sker i tre trin, denne proces kaldes normalisering. [Silberschatz et al., 2005] 5.3 Normalisering af relationer Målet med normaliseringen er at muliggøre lagring af data på en sådan måde, at denne let kan tilgås, samt at forhindre uhensigtsmæssigheder i de resulterende relationer, fx unødvendig redundans. Der ndes tre normalformer, benævnt 1. til 3. normalform. Da normalformerne er adaptive vil en relation på 3. normalform også pr. denitation være på 1. og 2. normalform. En relation er på 1. normalform, hvis alle attributter er identiceret, atomare og der ikke eksisterer attributter, der kan antage ere værdier. Desuden skal primærnøglen identiceres på 1. normalform, og alle andre attributter skal være afhængige af primærnøglen. Dog må et subset af primærnøgler ikke bestemme en attribut funktionelt, hvilket kaldes for partiel afhængighed. På 2. normalform må der ikke være redundant data, hvilket vil sige, at ingen attribut må kunne elimineres uden, at det vil ødelægge den unikke identi- kation af nøglen. En relation på 1. normalform er også på 2. normalform, hvis der kun er én primærnøgle. En relation på 3. normalform indeholder ingen transitiv afhængigheder, hvormed ingen ikke-nøgle attributter må være afhængige af hinanden. Hvis dette er tilfældet, dannes nye relationer. [Silberschatz et al., 2005] Herunder normaliseres relationer transformeret fra entitetsklasserne Deltager og Forældre ud fra ovenstående regler for normalformer. 28

35 5.3. Normalisering af relationer Deltager Den oprindelige relation for entitetsklassen Deltager er illustreret på Figur 5.4. Som det ses af guren er CPR-nr. isoleret forinden normaliseringen, så denne attribut kun optræder i én relation. Fra denne relation kan en deltagers CPR-nr. kobles med Deltagernr. Dette gøres fordi, det ikke er alle brugere, der skal have adgang til deltagernes CPR-nr.. Deltager Oprindelig relation Deltagernr Navn Adresse Telefonnr. Dødsfald Fremmødedato Genindkaldelsesdato Dato 1. invitation Dato 2. invitation DeltagerCPRnr Deltagernr CPR nr Figur 5.4: Den oprindelig relation for entitetsklassen Deltager. En ny relation dannes, som består af CPR-nr. og Deltagernr., da CPR-nummeret skal beskyttes og ikke være tilgængeligt for alle. 1. normaliseringstrin I 1. normaliseringstrin opdeles attributterne Navn og Adresse i ere attributter for at opnå atomare relationer. Desuden opdeles Telefonnr. da denne attribut kan antage én til ere værdier. Det vælges, at der til hver deltager kun kan knyttes to numre, nemlig Privatnr. og Mobilnr.. Figur 5.5 viser de nye relationer på 1. normalform fra den oprindelige entitetsklasse Deltager. Deltager Oprindelig tabel Deltagernr Navn Adresse Telefonnr Dødsfald Fremmødedato Genindkaldelsesdato Dato 1. invitation Dato 2. invitation Deltager 1. normalform Deltagernr Fornavn Efternavn Gade Husnr Postnr By Privatnr Mobilnr Dødsfald Fremmødedato Genindkaldelsesdato Dato 1. invitation Dato 2. invitation Figur 5.5: Relationen Deltager på 1. normalform for entitetsklassen Deltager. Relationen forinden normaliseringen er vist, og det er markeret, hvordan attributterne Navn, Adresse og Telefonnr. er omdannet til ere attibutter. 29

36 5. Entitets-Relation Modellering 2. normaliseringstrin Relationerne for entitetsklassen er allerede på 2. normalform og dokumenteres derfor ikke her, men der henvises til Figur 5.5 på forrige side. 3. normaliseringstrin I 3. normaliseringstrin dannes en ny relation indeholdende Postnr. og By, da By er transitiv afhængig af Postnr. Dette skyldes, at hvis Postnr. er kendt, kan By ligeledes bestemmes. Relationerne på 3. normalform kan ses på Figur 5.6. Deltager 2. normalform Deltagernr Fornavn Efternavn Gade Husnr Postnr By Privatnr Mobilnr Dødsfald Fremmødedato Genindkaldelsesdato Dato 1. invitation Dato 2. invitation PostnrBy 3. normalform Postnr By Deltager 3. normalform Deltagernr Fornavn Efternavn Gade Husnr Postnr Privatnr Mobilnr Dødsfald Fremmødedato Genindkaldelsesdato Dato 1. invitation Dato 2. invitation Figur 5.6: Relationen Deltager på 3. normalform for entitetsklassen Deltager. Relationen på 1. normalform er vist, og det er markeret, hvordan attributterne Postnr. og By er omfattet af en nydannet relation. Forældre Den oprindelige relation for entitetsklassen Forældre er illustreret på Figur 5.7 på modstående side. 30

37 5.3. Normalisering af relationer Forældre Oprindelig relation Deltagernr Mor: sukkersyge Mor: depression Mor: galdesten Mor: allergi Mor: astma Mor: blødersygdomme Mor: blodprop i hjernen Mor: blodprop i hjertet Mor: blodprop i lunge Mor: kræft Mor: forhøjet kolesterol Mor: forhøjet blodtryk Mor: uddannelse Forældre Fortsat Far: sukkersyge Far: depression Far: galdesten Far: allergi Far: astma Far: blødersygdomme Far: blodprop i hjernen Far: blodprop i hjertet Far: blodprop i lunge Far: kræft Far: forhøjet kolesterol Far: forhøjet blodtryk Far: uddannelse Figur 5.7: Den oprindelig relation for entitetsklassen Forældre. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. Normaliseringen af relationen dokumenteres ikke, da den oprindelige relation overholder kravene om at være på 3. normalform. 31

38

39 Del III Krav Hovedparten af arbejdet i workowet Krav udføres i Inception- og Elaborationsfasen. Her deneres funktionelle krav til systemet i form af en systembeskrivelse efterfulgt af den basale arkitektur, som afspejles i et deploymentdiagram, samt af use case modellering. Use case modellering består af et use case diagram, beskrivelser af aktører og use cases, hvoraf sidstnævnte også indeholder aktivitetsdiagrammer. Use casene afgrænses til senere analyse, design og implementering og sidst i denne del præsenteres en Lo-Fi prototype af databasesystemets brugergrænseade.

40

41 Kapitel 6 Krav I dette kapitel beskrives systemets overordnede funktioner. Efter en systembeskrivelse de- neres arkitekturen og use cases for databasesystemet. En systembeskrivelse opstilles på baggrund af mailudveksling med styregruppen for Region Sjællands Befolkningsundersøgelse, samt egne overvejelser. 6.1 Systembeskrivelse Der ønskes udviklet et databasesystem, hvor det for brugeren skal være muligt at indtaste data, samt overføre data til databasen om deltagerens personlige oplysninger, sygdom, medicin, kost og drikkevarer, fysisk aktivitet og deltagerens forældre ud fra spørgeskemaet fra Region Sjællands Befolkningsundersøgelsen. Disse indtastninger og overførsler af data skal kun gemmes, hvis CPR-nr., deltagernr., navn, postnr. og by er indtastet og overført. Databasesystemet skal understøtte, at brugeren forinden indtastning og overførsel af data kan tjekke om deltageren allerede ndes i databasen. For at kunne foretage en nærmere analyse af data, er det nødvendigt, at brugeren desuden har mulighed for at udtrække data fra databasen, og dermed eksportere data til et andet program, fx statistikprogrammet SPSS. Ydermere vil redigering af de indtastede data være nødvendigt, hvis brugeren har skrevet forkerte oplysninger ind, eller hvis en deltagers oplysninger ændres ved fx ytning. I det tilfælde at en deltager ikke længere ønsker at deltage i befolkningsundersøgelsen, skal vedkommendes oplysninger kunne slettes. Af sikkerhedsmæssige årsager skal det ikke være muligt for alle brugere at tilgå alt i databasen, hvorfor det er en nødvendighed at have adgangskontrol. Hver bruger får sit eget unikke log ind, bestående af brugernavn og adgangskode. Ligeledes skal det være muligt at logge ud for at sikre, at andre uden tilladelse ikke kan tilgå data i databasen. Flere brugere skal kunne tilgå databasen på samme tid, både ved indtastning og udtrækning. Systemet skal registrere, hvis fejl opstår og give repons på disse til brugeren. Kun ved korrekt overførsel vil data blive gemt i databasen. Systemets brugere er klinikere, forskere samt dataansvarlige. Brugerne af systemet skal 35

42 6. Krav have forskellige rettigheder. Forskerne skal kun have adgang til at udtrække data, k- linikerne skal have mulighed for at lagre data, mens de dataansvarlige har adgang til samtlige funktionaliteter i systemet. Dette sikres med adgangskontrol. Personhenførebare data skal kun være tilgængelige for de dataansvarlige. Ligeledes er det også den eneste bruger, der skal kunne redigere og slette data. 6.2 Systemarkitektur Data fra befolkningsundersøgelsen lagres i en database, der afvikles på en server. Data skal tilgås gennem en brugergrænseade, som dermed fungerer som en klient. Relationerne mellem klienten og serveren ses på deploymentdiagrammet på Figur 6.1. Der er tre stereotyper, der hyppigt bruges om typer af kode, Entity, Boundary og Control. Serveren skal have kode af typen Entity, da der skal lagres data her. Klienten skal både have kode af typen Boundary, fordi den graske brugergrænseade ligger her, og kode af typen Control, fordi den kontrollerende kode ligeledes ligger på klienten. [Eriksson et al., 2004] Klient Server Boundary Control Entity Figur 6.1: Deploymentdiagram for databasesystemet, hvor kode af typen Control, Boundary og Entity er vist. Serveren fungerer som Entity, hvormed data fra spørgeskema kan lagres. Klienten virker som Boundary og Control, da brugergrænseaden og kontrollen ligger her. 6.3 Use case modellering Formålet med use case modellering er at identicere og beskrive de funktionelle krav, der er til databasesystemet. I dette afsnit beskrives aktører til databasesystemet, og der opstilles et use case diagram med de funktioner, der er relevante for brugerne af databasesystemet. Aktørbeskrivelse Aktørerne er brugere af databasesystemet, men de har ikke nødvendigvis samme rolle. De identicerede aktører er fundet ud fra systembeskrivelsen, og deres rolle beskrives i det følgende. 36

43 6.3. Use case modellering Kliniker Klinikere deneres som sundhedspersonale, der er involverede i at foretage de fysiske helbredsundersøgelser. Klinikere er desuden de aktører, der har ansvar for, at data lagres i databasen. Klinikeren har derfor arbejdsopgaverne at indtaste og overføre data til databasen. Forsker Denne aktør denherer alle de aktører, der efterfølgende skal benytte data fra befolkningsundersøgelsen til analyser i forskningsøjemed. Forskerne skal kunne udtrække data, som består i at søge efter relevante data i databasen og gemme disse. Dataansvarlig De dataansvarlige deneres til at være personer, der har fuldstændig adgang til databasen og ansvaret for vedligeholdelse af databasen, og dermed har adgang til samtlige arbejdsgange i databasesystemet. Herunder skal aktøren kunne redigere eller slette i en deltagers information ud fra CPR-nr., hvis fx data er indtastet eller overført forkert. Database Databasen deneres til at være den enhed, hvor data fra befolkningsundersøgelsen lagres og kan udtrækkes fra Use case diagram De identicerede use cases og aktører til databasesystemet ses på Figur 6.2 på den følgende side. I det følgende opstilles beskrivelser og aktivitetsdiagrammer til hver use case. Enhver use case i use case diagrammet kan betragtes som en afsluttet arbejdsgang, der igangsættes af en ekstern aktør, og som er værdiskabende for samme. Dermed er en use case en opsummering af scenarier for en enkelt opgave. [Eriksson et al., 2004] Use cases og aktivitesdiagrammer For hver use case præsenteret på Figur 6.2 på næste side er aktivitetsdiagrammer udarbejdet. Et aktivitetsdiagram beskriver owet af aktiviteter og dermed en sekvens af handlinger i use casen. Et sådan diagram danner grundlag for identikation af metoder 37

44 6. Krav Log ud <<include>> Log ind Kliniker Overfør data Indtast data Forsker Redigér data Udtræk data Databaseansvalig Database Figur 6.2: Use case diagram for databasesystemet med de tilknyttede aktører. De stiplede pile betyder at use casen Log ind er inkluderet i de andre use cases, da andre use cases ikke kan udføres før, der er logget ind i systemet. til senere klassespecikationer. [Eriksson et al., 2004] Efter et overordnet aktivitetsdiagram for hver use case opstilles et mere uddybende aktivitetsdiagram opdelt i swimlanes. En swimlane for Brugeren og en swimlane for hver af stereotyperne Boundary, Control og Entity. Denne opdeling er valgt, da det er disse stereotyper systemet arbejder med, hvormed det tydeliggøres, hvilke aktiviteter, der foregår hvor i systemet. Log ind I use casen Log ind indtaster brugeren sit brugernavn og adgangskode i et log ind vindue. Dernæst vælges det at logge ind i databasesystemet. Det undersøges om, der ndes en bruger med det indtastede brugernavn og adgangskode. Afhængig af om brugernavn og adgangskode godkendes af systemet, vises en fejlmeddelelse eller næste vindue. På Figur 6.3 ses første aktivitetsdiagram for use casen Log ind. Korrekt login? Vis vindue Indtast brugernavn og adgangskode Vælg Log ind [Nej] [Ja] Vis vindue Vis fejlmeddelelse Figur 6.3: Aktivitetsdiagram for use casen Log ind, som er inkluderet i de andre use cases. 38

45 6.3. Use case modellering På Figur 6.4 ses en deltaljeret udgave af aktivitetsdiagrammet opdelt i swimlanes. Bruger Boundary Control Entity Indtast brugernavn og adgangskode Vis vindue Vælg Log ind Generér forespørgsel Send forespørgsel Tryk OK Vis fejlmeddelelse [Nej] Korrekt login? [Ja] Vis vindue Figur 6.4: Aktivitetsdiagrammet for use casen Log ind opdelt i swimlanes, hvormed aktiviteter brugeren står for er placeret i en Bruger swimlane, brugerens interaktion med brugergrænseaden er placeret i Boundary, aktiviteter relateret til den styrende kode er placeret i Control og aktiviteter i databasen er placeret i Entity. Log ud I use casen Log ud vælger brugeren at logge ud af databasesystemet. Dette valg registreres og medfører, at brugeren er logget ud. Use casen har sammen med log ind ansvaret for brugeradgang til systemet. På Figur 6.5 ses første aktivitetsdiagram for use casen Log ud. Vis vindue Vælg Log ud Vis vindue Figur 6.5: Aktivtitetsdiagram for use casen Log ud. På Figur 6.6 på næste side ses en deltaljeret udgave af aktivitetsdiagrammet opdelt i swimlanes. 39

46 6. Krav Bruger Boundary Control Entity Vælg Log ud Vis vindue Registrér valg Vis vindue Figur 6.6: Aktivitetsdiagrammet for use casen Log ud opdelt i swimlanes, hvormed aktiviteter brugeren står for er placeret i en Bruger swimlane, brugerens interaktion med brugergrænseaden er placeret i Boundary, aktiviteter relateret til den styrende kode er placeret i Control og aktiviteter i databasen er placeret i Entity. Overfør data I use casen Overfør data indtaster klinikeren deltagernummeret på den deltager, hvis data skal overføres. Det undersøges, om deltageren allerede eksisterer i databasen, hvis dette er tilfældet, vises en meddelelse om, at deltagerens data i stedet skal redigeres. I det tilfælde at deltageren ikke er oprettet vælges Overfør data, hvorved data overføres. Klinikeren vælger Gem, det valideres om data er korrekt overført, hvis det er tilfældet gemmes data. På Figur 6.7 ses første aktivitetsdiagram for use casen Overfør data. Findes deltager? Vis vindue Indtast deltagernr. Vælg Find deltager [Ja] Vis meddelelse Vis vindue [Nej] Vælg Overfør data Registreret korrekt? [Nej] [Ja] Vælg Gem Gem data Vis vindue Vis meddelelse Figur 6.7: Aktivitetsdiagram for use casen Overfør data. På Figur 6.8 på næste side ses en deltaljeret udgave af aktivitetsdiagrammet opdelt i 40

47 6.3. Use case modellering swimlanes. B ru g e r B o u n d a ry C o n tro l E n tity Indtast deltagernr. Vis vindue Vælg Find deltager Generér forespørgelse Find data Findes deltager? Tryk OK Vis meddelelse [Ja] [Nej] Tryk OK Vis meddelelse Vælg Overfør data Vælg Gem Vis overførte værdier Tryk OK Registreret korrekt? [Nej] [Ja] Gem data Vis meddelelse Vis vindue Figur 6.8: Aktivitetsdiagrammet for use casen Overfør data opdelt i swimlanes, hvormed aktiviteter brugeren står for er placeret i en Bruger swimlane, brugerens interaktion med brugergrænseaden er placeret i Boundary, aktiviteter relateret til den styrende kode er placeret i Control og aktiviteter i databasen er placeret i Entity. Indtast data I use casen Indtast data indtaster klinikeren deltagernummeret for den deltager, hvis data indtastes. Det undersøges om deltagernummeret allerede er oprettet i systemet. Hvis det allerede eksisterer, vises en meddelelse om, at deltagerens data i stedet skal redigeres. Hvis deltagernummeret ikke ndes, indtaster klinikeren data om personen. Når brugeren har indtastet alt data vælges Gem, det valideres om data er korrekt indtastet, hvis dette 41

48 6. Krav er tilfældet gemmes data. På Figur 6.9 ses første aktivitetsdiagram for use casen Indtast data. Findes deltager? Vis vindue Indtast deltagernr. Vælg Find deltager [Ja] Vis meddelelse Vis vindue [Nej] Indtast data Registreret korrekt? [Nej] [Ja] Vælg Gem Gem data Vis vindue Vis meddelelse Figur 6.9: Aktivitetsdiagram for use casen Indtast data. 42

49 6.3. Use case modellering På Figur 6.10 ses en deltaljeret udgave af aktivitetsdiagrammet opdelt i swimlanes. B ru g e r B o u n d a ry C o n tro l E n tity Indtast deltagernr. Vis vindue Vælg Find deltager Generér forespørgelse Find data Findes deltager? Tryk OK Vis meddelelse [Ja] [Nej] Tryk OK Vis meddelelse Indtast data Vælg Gem Vis indtastede værdier Tryk OK Registreret korrekt? [Nej] [Ja] Gem data Vis meddelelse Vis vindue Figur 6.10: Aktivitetsdiagrammet for use casen Indtast data opdelt i swimlanes, hvormed aktiviteter brugeren står for er placeret i en Bruger swimlane, brugerens interaktion med brugergrænseaden er placeret i Boundary, aktiviteter relateret til den styrende kode er placeret i Control og aktiviteter i databasen er placeret i Entity. Redigér data I use casen Redigér data indtaster den dataansvalige deltagernummeret tilknyttet den deltager, hvis data det ønskes at redigere eller slette i. Hernæst vælges Find deltager, hvormed det valideres, om deltageren er oprettet i systemet. Hvis denne ikke ndes, vises en meddelelse. Hvis den ønskede deltager ndes, hentes data for deltageren og den dataansvarlige kan ændre, tilføje eller slette data for den pågældende person. Når brugeren har foretaget 43

50 6. Krav sine ændringer vælges Gem, hvorved de redigerede data gemmes. På Figur 6.11 ses første aktivitetsdiagram for use casen Redigér data. Findes deltager? Vis vindue Indtast deltagernr. Vælg Find deltager [Nej] [Ja] Foretag ændringer Registreret korrekt? Vis meddelelse Vælg Gem [Ja] [Nej] Gem data Vis vindue Vis meddelelse Figur 6.11: Aktivitetsdiagram for use casen Redigér data. 44

51 6.3. Use case modellering På Figur 6.12 ses en deltaljeret udgave af aktivitetsdiagrammet opdelt i swimlanes. B ru g e r B o u n d a ry C o n tro l E n tity Indtast deltagernr. Vis vindue Vælg Find deltager Generér forespørgsel Find data Findes deltager? Vis meddelelse Foretag ændringer Vis personoplysninger Registreret korrekt? Vælg Gem Vis indtastede værdier [Nej] [Ja] Gem data Vis meddelelse Vis vindue Figur 6.12: Aktivitetsdiagrammet for use casen Redigér data opdelt i swimlanes, hvormed aktiviteter brugeren står for er placeret i en Bruger swimlane, brugerens interaktion med brugergrænseaden er placeret i Boundary, aktiviteter relateret til den styrende kode er placeret i Control og aktiviteter i databasen er placeret i Entity. Udtræk data I use casen Udtræk data vælger brugeren de søgekriterier, der ønskes. Når brugeren har valgt hvilke kriterier, der skal undersøges nærmere, vælges Udtræk data. Derefter vises de valgte søgekriterier for brugeren, som herefter skal godkende valget. Når brugeren godkender valget, ndes data svarende til søgningen. Brugeren skal dernæst vælge, hvor data skal gemmes og i hvilket format, hvormed data eksporteres og gemmes. På Figur 6.13 på den følgende side ses første aktivitetsdiagram for use casen Udtræk data. 45

52 6. Krav Vis vindue Vælg Udtræk data Vælg søgekriterier Vis valgte søgekriterier Vælg Eksportér Vis vindue Gem til fil Vælg Gem Vis datamappe Figur 6.13: Aktivitetsdiagram for use casen Udtræk data. På Figur 6.14 ses en deltaljeret udgave af aktivitetsdiagrammet opdelt i swimlanes. B ru g e r B o u n d a ry C o n tro l E n tity Vælg Udtræk data Vis vindue Vælg søgekriterier Registrér valg Tryk OK Vis valgte søgekriterier Generér forespørgsel Find data Vælg Gem Vis datamappe Send data Gem til fil Vis vindue Figur 6.14: Aktivitetsdiagrammet for use casen Udtræk data opdelt i swimlanes, hvormed aktiviteter brugeren står for er placeret i en Bruger swimlane, brugerens interaktion med brugergrænseaden er placeret i Boundary, aktiviteter relateret til den styrende kode er placeret i Control og aktiviteter i databasen er placeret i Entity. 6.4 Afgrænsning af use cases Der er i det foregående vist og beskrevet aktivitetsdiagrammer for de opstillede use cases, hvormed databasen og dens indhold kan anvendes og have værdi for de fremtidige brugere. I den forbindelse er det valgt at fokusere den videre analyse, design og implementering 46

53 6.4. Afgrænsning af use cases på udvalgte use cases. Disse er Indtast data, Redigér data og Udtræk data, hvormed de resterende use cases; Log ind, Log ud og Overfør data, ikke behandles yderligere. Use casene Log ind og Log ud Use casene Log ind og Log ud medtages ikke i den videre analyse og design. Dette skyldes, at databasen vil indeholde personfølsomme oplysninger, hvorved sikkerhedskravene til disse er for vidtrækkende til dette projekt. Use casen Overfør data Det er i det foreliggende projekt ikke muligt at designe og implementere den elektroniske overførsel af data, da der ikke er adgang til Optical character recognition, der vil blive anvendt til at overføre data fra spørgeskemaet og helbredsundersøgelsen. Der er endvidere ikke adgang til elektronisk data, som allerede er scannet ind vha. Optical character recognition. Ligeledes er der ikke adgang til det elektroniske måleudstyr, hvor de resterende data bliver overført fra. 47

54

55 Kapitel 7 Low-Fidelity prototype af brugergrænseaden I det følgende beskrives en Lo-Fi prototype, der viser grundidéen bag databasesystemets brugergrænseade. Lo-Fi prototypen testes, og overvejelser om layout af brugergrænse- aden beskrives før og efter testen. En Lo-Fi prototype har til formål at give et overblik over brugergrænseaden, således eventuelle fejl og mangler kan opdages før implementeringen. Især vil en test af Lo-Fi prototypen udført af udenforstående testpersoner tydeliggøre problemer ved designet. [Sharp et al., 2007] Designet af Lo-Fi prototypen tager udgangspunkt i spørgeskemaet fra Region Sjællands Befolkningsundersøgelse. Da spørgeskemaet er opdelt fra styregruppens side, udnyttes denne opdeling i dannelsen af faneblade. Således tildeles information om henholdvis deltager, medicinforbrug, sygdom, fysisk aktivitet, deltagerens forældre og kost og drikkevarer hvert sit faneblad i brugergrænseaden. Dette forventes at være optimalt i forhold til overskuelighed af indtastning, redigering og udtrækning af data. Figur 7.1 og Figur 7.2 på den følgende side viser eksempler på fanebladene Deltager og Forældre fra Lo-Fi prototypen af brugergrænseaden. De resterende faneblade vil overordnet have det samme udseende og opbygning, hvorfor disse ikke vises. 49

56 7. Low-Fidelity prototype af brugergrænseaden Region Sjællands Befolkningsundersøgelse Deltager Medicin Sygdom Fysisk akt... Forældre Kost... Eksportér Deltagernr.: Fremmødedato: CPR-nr.: Genindkaldelsesdato : Fornavn: Efternavn : Gade: Husnr.: Postnr.: By: 1. invitation: 2. invitation: Dødsfald: Nej Ja Figur 7.1: Lo-Fi prototype af brugergrænseaden, hvor fanebladet Deltager er vist. Lo-Fi prototypen er udviklet i grask software. Region Sjællands Befolkningsundersøgelse Deltager Medicin Sygdom Fysisk akt... Forældre Kost... Eksportér Forældrenes sygdomme Moderens sygdomme: Blødersygdom Sukkersyge Depression Galdesten Allergi Faderens sygdomme: Blødersygdom Sukkekrsyge Depression Galdesten Allergi Forældrenes uddannelse Moderens uddannelse Ingen Erhvervsfaglig Kortvideregående Mellemlang videregående Lang videregående Faderens uddannelse: Ingen Erhvervsfaglig Kort videregående Mellemlang videregående Lang videregående Figur 7.2: Lo-Fi prototype af brugergrænseaden, hvor fanebladet Forældre er vist. Lo-Fi prototypen er udviklet i grask software. 7.1 Test af Low-Fidelity prototype Formål Formålet med testen er at teste brugervenligheden mht. overskuelighed, navigation og hvor intuitiv brugergrænseaden er, samt at opdage eventuelle uhensigtsmæssigheder ved 50

57 7.1. Test af Low-Fidelity prototype designet. Udførelse Lo-Fi prototypen testes i Usability laboratoriet på Aalborg Universitet. Lo-Fi prototypen består, i testen, af en papirmodel af brugergrænseaden, og tre testpersoner der hver udfører to opgaver ved at navigere i brugergrænseaden. I det første testscenarie opretter testpersonerne en deltager med specikke værdier og i det andet testscenarie udtrækker testpersonerne et datasæt fra databasen. Under testene opfordres testpersonerne til at tænke højt, og deres valg og tanker noteres. Resultater I starten af testen viste brugergrænseaden sig at være intuitiv, da ingen af testpersonerne var i tvivl om, hvordan interaktion med de enkelte elementer fungerede. Det var tydeligt, at testpersonerne kunne genkende dele af designet, såsom lister, tekstfelter og faneblade fra andre applikationer. Testene afslørede dog enkelte problemer. Eksempelvis troede alle testpersoner, at det var nødvendigt at vælge en værdi for hver eneste parameter i både Indtast data og Udtræk data, hvilket ikke er hensigten. Desuden skabte fanebladet Eksportér forvirring, da dette faneblad både skulle benyttes ved indtastning og udtrækning af data. Testen viste, at opdelingen mellem arbejdsgangene indtast og udtræk data skulle adskilles tydeligt i brugergrænseaden. Desuden manglede der valgmuligheder i listerne, fx muligheden for ikke at vælge nogle sygdomme ved indtastning og muligheden for at vælge alle sygdomme ved udtrækning af data. Disse overvejelser og resultater tages i betragtning i udviklingsprocessen under implementering af brugergrænseaden. 51

58

59 Del IV Analyse Arbejdet i workowet Analyse udføres især i Elaborationsfasen og indeholder analyseklasser, som abstraherer over systemet i problemdomænet, samt interaktionsdiagrammer. Der opstilles i det følgende en analysemodel af systemet, der har til formål at specicere systemets funktionaliteter på a- nalyseniveau, og dermed ikke designmæssige perspektiver. A- nalysen indeholder analyseklasser, samt interaktionsdiagrammer, som består af et kommunikations- og sekvensdiagram for hver use case.

60

61 Kapitel 8 Analyseklasser I dette kapitel opstilles analyseklasser på baggrund af kravene beskrevet i Kapitel 6 på side 35. Analyseklasser kan senere transformeres til designklasser, hvormed systemet designes. Analyseklasserne er identiceret vha. navneords-/verbumanalyse af systembeskrivelsen, beskrivelser af use cases og aktivitetsdiagrammerne. Beskrivelserne er gennemgået for navneord og udsagnsord. De fundne navneord udgør kandidatklasser, hvorfra enkelte udvælges som analyseklasser og andre som attributter. På samme måde ligger udsagnsord i beskrivelserne til grund for klassernes metoder. [Eriksson et al., 2004] Udvælgelsen af analyseklasser ud fra kandidatklasserne ses på Figur 8.1. Kandidatklasser Bruger Database Sygdom Befolkningsundersøgelse Medicin Analyse Forældre Meddelelse Region Kost Drikkevarer Program Fysisk aktivitet Kliniker Spørgeskema Hovedvindue Deltagernummer Fejl Deltager Person Søgekriterium Eksport GUI Brugergrænseflade Valg Fil Databaseansvarlig Personpolysning Analyseklasser Database Sygdom Medicin Forældre KostDrikkevarer FysiskAktivitet Spørgeskema Deltager Eksport Brugergrænseflade Figur 8.1: Analyseklasserne udvalgt fra de fundne kandidatklasser. Udvælgelsen af analyseklasser sker på baggrund af den viden om hvilke parametre, der skal opsamles, den overordnede arkitektur af systemet og kandidatklasserne. De valgte kategorier i spørgeskemaet har fået hver sin klasse tildelt. Derudover er der yderligere valgt tre 55

62 8. Analyseklasser klasser, der tilsammen har til hensigt at skabe det overordnede billede af funktionaliteten i systemet. 8.1 Klassespecikationer for analyseklasser Følgende analyseklasser er valgt; Brugergrænseade, Database, Spørgeskema, Eksport, Deltager, Medicin, Sygdom, FysiskAktivitet, Forældre og KostDrikkevarer. I det følgende vises en klassespecikation for hver klasse med tilhørende beskrivelse. Brugergrænseade På Figur 8.2 ses klassespecikationen for analyseklassen Brugergrænseade. Brugergrænseflade baggrundsfarve faneblade visgui() registrerinteraktion() visdeltager() vismeddelelse() visdatamappe() visdata() Figur 8.2: Analyseklassespecikation for klassen Brugergrænseade. Det øverste felt angiver klassens navn, næste felt klassens attributter, og det nederste felt klassens metoder. Analyseklassen Brugergrænseade modellerer hovedsagligt den graske opsætning af brugergrænseaden, samt håndtering og handling på brugerens interaktion med brugergrænse- aden. Den skal indeholde en række faneblade i henhold til Lo-Fi protoypen af brugergrænseaden. Database På Figur 8.3 ses klassespecikationen for analyseklassen Database. Database hentdata() gem() hentvalgt() Figur 8.3: Analyseklassespecikation for klassen Database. Det øverste felt angiver klassens navn, næste felt klassens attributter, og det nederste felt klassens metoder. 56

63 8.1. Klassespecikationer for analyseklasser Analyseklassen Database modellerer, hvordan data hentes og gemmes i databasen. Dermed udgør dennes korrespondance kommunikationen til databasen, og dermed bindeleddet mellem databasen og brugergrænseaden. Eksport På Figur 8.4 ses klassespecikationen for analyseklassen Eksport. filnavn gemtilfil() Eksport Figur 8.4: Analyseklassespecikation for klassen Eksport. Det øverste felt angiver klassens navn, næste felt klassens attributter, og det nederste felt klassens metoder. Analyseklassen Eksport modellerer eksporteringen af udtrukket data fra databasen til en l. Spørgeskema, Medicin, KostDrikkevarer, Forældre, FysiskAktivitet, Deltager, Sygdom Disse klasser vises samlet, da de grundlæggende benytter samme metoder. På Figur 8.5 ses klassespecikationerne for analyseklasserne. Spørgeskema Medicin KostDrikkevarer Forældre deltagernr dato medicin antalår kost drikkevarer forældresygdom forældreuddannelse hentdata() gem() hentvalgt() validerdeltager() validerdata() hentdata() gem() hentvalgt() validerdeltager() validerdata() hentdata() gem() hentvalgt() validerdeltager() validerdata() hentdata() gem() hentvalgt() validerdeltager() validerdata() FysiskAktivitet Deltager Sygdom fysiskaktivitet hentdata() gem() hentvalgt() validerdeltager() validerdata() deltagernr. cpr adresse navn telefonnr hentdata() gem() hentvalgt() validerdeltager() validerdata() sygdom hentdata() gem() hentvalgt() validerdeltager() validerdata() Figur 8.5: Analyseklassespecikationer for klasserne Spørgeskema, Medicin, KostDrikkevarer, Forældre, FysiskAktivitet, Deltager, Sygdom. Felterne angiver klassernes navne, attributter og metoder. 57

64 8. Analyseklasser Disse analyseklasser skal modellerer oplysninger om hvert sit område, deneret ud fra spørgeskemaet fra Region Sjællands Befolkningsundersøgelse. Analyseklassen Spørgeskema modellerer oplysninger om det spørgeskema, som deltageren har udfyldt. Analyseklassen Medicin modellerer lagring af oplysninger om deltagerens medicinforbrug. Analyseklassen KostDrikkevarer modellerer lagring af oplysninger om deltagerens mad- og drikkevaner. Analyseklassen Forældre modellerer lagring af oplysninger om deltagerens svar omhandlende sine forældres sygdomshistorie og uddannelse. Analyseklassen FysiskAktivitet modellerer lagring af oplysninger om deltagerens fysiske aktivitet. Analyseklassen Deltager modellerer oplyninger relateret til deltageren fx CPR-nr., adresse og dato for fremmøde til helbredsundersøgelsen. Analyseklassen Sygdom modellerer lagring af oplysninger om deltagerens sygdomshistorie. 8.2 Klassediagram for analyseklasserne På Figur 8.6 på næste side ses analyseklassediagrammet for de beskrevne analyseklasser. Formålet med analyseklassediagrammet er at give overblik over systemet. Klassediagrammet er en statisk beskrivelse af klasser i systemet og deres relationsforhold klasserne imellem. [Eriksson et al., 2004] Det ses på guren, at hver Brugergrænseade klasse eksporterer data til én Eksport klasse, hver Eksport klasse eksporterer data fra én Brugergrænseade klasse. Hver Brugergrænseade klasse har én Deltager klasse, én Medicin klasse, én Sygdom klasse, én FysiskAktivitet klasse, én KostDrikkevarer klasse, samt én Forældre klasse. Ligeledes har hver Deltager klasse, Medicin klasse, Sygdom klasse, Fysisk- Aktivitet klasse, KostDrikkevarer klasse og Forældre klasse én Brugergrænseade klasse. Hver Brugergrænseade klasse gemmer data i én Database klasse, og hver Database klasse henter data fra én Brugergrænseade klasse. Ligeledes har hver Spørgeskema klasse én Brugergrænseade klasse, og hver Brugergrænseade klasse har én Spørgeskema klasse. Desuden nedarver klasserne Deltager, Sygdom, FysiskAktivitet, Forældre, Medicin og KostDrikkevarer fra klassen Spørgeskema. Det betyder, at disse klasser har nogle fællestræk med klassen Spørgeskema og derfor også indeholder klassen Spørgeskemas metoder. 58

65 8.2. Klassediagram for analyseklasserne Spørgeskema Deltager 1 KostDrikkevarer Medicin Sygdom FysiskAktivitet Forældre har har har har har har har har har har har har Brugergrænseflade henter fra gemmes i eksporterer til 1 Eksport eksporteres fra 1 Database Figur 8.6: Analyseklassediagram, som viser relationer mellem analyseklasserne, samt deres multiplicitet. 59

66

67 Kapitel 9 Interaktionsdiagrammer for analyse I dette kapitel opstilles og beskrives interaktionsdiagrammerne, bestående af kommunikationsdiagrammer og sekvensdiagrammer. Kapitlet er opdelt efter use cases, hvormed der opstilles både kommunikationsdiagram og sekvensdiagram for den enkelte use case. 9.1 Kommunikations- og sekvensdiagrammer Formålet med interaktionsdiagrammer er at give overblik over systemet med henblik på den senere realisering af use casene, dvs. understøttelsen af use cases i koden. Interaktionsdiagrammer kan anvendes ved både analyse og design af systemet. [Eriksson et al., 2004] Kommunikationsdiagrammer viser den dynamiske udførelse af metoder i et strukturelt forløb ved objekters kommunikation og fokuserer således på relationerne mellem objekterne. Forløbet af metodekald er vist ved nummerering og der markeres fra hvilken klasse, metoden kaldes. [Eriksson et al., 2004] Sekvensdiagrammer viser den dynamiske udførelse af metoder i et tidsligt forløb gennem kommunikation imellem objekterne. Objekter, som indgår i kommunikationen, listes fra venstre mod højre i diagrammer alt afhængig af deres plads i kommunikationssekvensen, og objekternes livsforløb angives nedad. Sekvensdiagrammer viser også interne metodekald. [Eriksson et al., 2004] Da der kan træes forskellige valg i hver use case, er det valgt at opstille diagrammerne på instansform, således der vises ét muligt scenarie af hver use case. Indtast data De to følgende interaktionsdiagrammer viser et scenarie hvor brugeren opretter en deltager, der ikke allerede eksisterer i databasen, hvorved der skal indtastes data for denne, ydermere vælges det, at denne deltager er syg. Kommunikationsdiagrammet er vist på Figur 9.1 på den følgende side, hvor brugerinter- 61

68 9. Interaktionsdiagrammer for analyse aktion medfører, at brugergrænseaden vises vha. metoden visgui() fra klassen Brugergrænseade. Når der er indtastet personoplysninger om deltageren, gemmes data med metodekaldet gem() fra klassen Deltager, samt gem() fra klassen Sygdom. Metoden gem() i klassen Sygdom kaldes, da deltageren er syg. Data gemmes i databasen med metoden gem() kaldt fra klassen Database. 1:visGUI() 1.2: gem() Bruger : Brugergrænseflade 1.1: gem() : Sygdom 1.2.1: gem() : Deltager 1.1.1: gem() : Database Figur 9.1: Kommunikationsdiagram for use casen Indtast data. Det strukturelle forløb er vist ved metodernes nummerering. Sekvensdiagrammet for use casen Indtast data er vist på Figur 9.2 på næste side, hvor brugergrænseaden vises ved kaldet af metoden visgui(). Brugeren kan herefter indtaste de data for deltageren, der ønskes gemt i databasen. Dette registreres og metoden registrerinteraktion() kaldes, hvor klasserne Deltager, Sygdom og Database oprettes vha. konstruktøren tilhørende disse klasser. Brugeren vælge at gemme, hvorefter metoden gem() benyttes. Data valideres, da det risikeres, at data er indtastet i forkert format, og derefter gemmes data i databasen og brugeren informeres om dette med metoden vismeddelelse(). 62

69 9.1. Kommunikations- og sekvensdiagrammer SD: Indtast data Brugergrænseflade() : Brugergrænseflade registrerinteraktion() Deltager() : Deltager Sygom() Database() : Database : Sygdom gem() validerdata() gem() gem() validerdata() gem() vismeddelelse() visgui() Figur 9.2: Sekvensdiagram for use casen Indtast data. Den vertikale akse angiver tiden, mens den horisontale akse angiver objekterne. Redigér data Standardscenariet er, at den dataansvarlige af databasesystemet redigerer i en deltagers data gemt i databasen. De to følgende interaktionsdiagrammer viser et scenarie hvor en deltager yttet til en anden adresse i samme by, hvormed gadenavn og husnr. skal redigeres. Figur 9.3 på den følgende side viser kommunikationsdiagrammet for use casen. Det ses, at det første metodekald er visgui() fra klassen Brugergrænseade. Deltagerens data hentes frem vha. metoden hentdata() fra klassen Deltager, og for at hente disse data i databasen anvendes metoden hentdata() fra klassen Database. Efter at brugeren har redigeret deltagerens data, gemmes disse med metoden gem() fra klassen Deltager og data gemmes i databasen med metoden gem() fra klassen Database. 63

70 9. Interaktionsdiagrammer for analyse 1:visGUI() : Brugergrænseflade Bruger 1.1:hentData() 1.2: gem() : Deltager 1.1.1: hentdata() 1.2.1: gem() : Database Figur 9.3: Kommunikationsdiagram for use casen Redigér data. Det strukturelle forløb er vist ved metodernes nummerering. Sekvensdiagrammet vises på Figur 9.4 på næste side, og guren illustrerer, at brugergrænseaden vises for brugeren efter første metodekald. Dermed har brugeren mulighed for at vælge den deltager, hvis data skal redigeres, og metoden hentdata() fra klassen Deltager kaldes. En metode af samme navn kaldes derefter i klassen Database, således data hentes, men før det vises for brugeren med metoden visdata(), valideres data for at se om deltageren ndes, og brugeren bekræfter, at det er denne deltagers data, der ønskes at redigeres. Herefter redigerer den dataansvarlige deltagerens data, og disse ændringer gemmes i databasen vha. metoden gem(), når disse er valideret. 64

71 9.1. Kommunikations- og sekvensdiagrammer SD: Rediger visgui() : GUI registrerinteraktion() Deltager() : Deltager hentdata() Database() : Database hentdata() validerdata() visdeltager() registrerinteraktion() visdata() registrerinteraktion() gem() validerdata() gem() visgui() Figur 9.4: Sekvensdiagram for use casen Redigér data. Den vertikale akse angiver tiden, mens den horisontale akse angiver objekterne. Udtræk data De to følgende interaktionsdiagrammer viser et scenarie, hvor brugeren ønsker at udtrække data fra de deltagere, der er kvinder og indtager en bestemt kost, hvorfor der udtrækkes data fra klasserne Deltager og KostDrikkevarer. Kommunikationsdiagrammet for use casen Udtræk data er vist på Figur 9.5, hvor det kan ses, at brugergrænseaden først vises vha. brugerinteraktion. Dernæst kaldes metoden hentvalgt() fra klassen Deltager, hvormed det, som brugeren har valgt at udtrække fra fanebladet Deltager, hentes. Derefter kaldes metoden hentvalgt() fra klassen Database. Dernæst kaldes metoden hentvalgt() fra klassen KostDrikkevarer, hvor det valgte i Kost- 65

72 9. Interaktionsdiagrammer for analyse Drikkevarer fanebladet hentes. Hvorefter metoden hentvalgt() fra klassen Database kaldes. Sidst gemmes det valgte data vha. metoden gemtilfil() fra klassen Eksport. Dermed kan data gemmes på en lokation på computeren bestemt af brugeren, og videre analyse på data kan gennemføres. : Eksport 1.3: gem() 1:visGUI() : Brugergrænseflade 1.2:hentValgt() : KostDrikkevarer Bruger 1.1:hentValgt() 1.2.1: hentvalgt() : Deltager 1.1.1: hentvalgt() : Database Figur 9.5: Kommunikationsdiagram for use casen Udtræk data. Det strukturelle forløb er vist ved metodernes nummerering. Sekvensdiagrammet for use casen Udtræk data er præsenteret på Figur 9.6 på modstående side, hvor metodekaldene mellem de forskellige klasser vises. Først kaldes metoden vis- GUI(), hvormed brugergrænseaden synliggøres for brugeren. Herefter har brugeren mulighed for at udvælge data til udtrækning og senere analyse, og denne brugerinteraktion registreres. Når dette er gjort, kaldes metoden hentvalgt() i klassen Deltager og Kost- Drikkevarer, som kalder en metode af samme navn i klassen Database. Dermed hentes data fra databasen, og der gives besked til brugeren. Brugeren kan vælge hvor og med hvilket navn data skal gemmes, og data gemmes ved kaldet af metoden gemtilfil() i klassen Eksport. 66

73 9.1. Kommunikations- og sekvensdiagrammer SD: Indtast data Brugergrænseflade() : Brugergrænseflade registrerinteraktion() Deltager() : Deltager Sygom() Database() : Database : Sygdom gem() validerdata() gem() gem() validerdata() gem() vismeddelelse() visgui() Figur 9.6: Sekvensdiagram for use casen Udtræk data. Den vertikale akse angiver tiden, mens den horisontale akse angiver objekterne. 67

74

75 Del V Design I denne del beskrives arbejdet i workowet Design, som hovedsageligt udføres i Elaborations- og Constructionsfasen. Resultater i analysen videreudvikles i design, og der fokuseres på, hvordan databasesystemet skal implementeres. Først beskrives det, hvordan overvejelser fra analysen bidrager til udviklingen af designklasser. Desuden består dokumentationen af denne del af designklassediagram og interaktionsdiagrammer, bestående af kommunikations- og sekvensdiagrammer.

76

77 Kapitel 10 Designklasser I den foregående del er der på analyseplan foretaget en realisering af databasesystemets use cases, samt en identikation af analyseklasserne. Disse klasser er ikke tilstrækkelige i forhold til implementeringen af databasesystemet. Derfor identiceres designklasser i dette kapitel. Sidst i kapitlet ndes klassediagrammet for designklasserne Design er en teknisk udvidelse af resultaterne i analyse. Klasserne og deres forhold fra analyse suppleres med nye elementer, der fokuserer på, hvordan databasesystemet skal implementeres mht. de tekniske deltaljer. Resultaterne fra analyse overføres til design og beholdes som systemets centrum. Designklasserne er, i modsætning til analyseklasser, direkte implementerbare, og skal derfor fungere som værktøj under implementeringen af systemet. [Eriksson et al., 2004] Derfor identiceres der i dette kapitel designklasser på baggrund af de fundne analyseklasser, de opstillede use cases, samt viden om implementering af systemet. De fundne designklasser udgør samtlige klasser, der skal implementeres. Metoderne og attributterne deneres ved at tage udgangspunkt i de enkelte analyseklasser, der hver især vurderes med en teknisk vinkel. Sammen med viden om implementeringssproget Java er det muligt at specicere metoder og attributter så detaljeret, at de sammen med interaktionsdiagrammer giver nok information til at påbegynde implementering. Til hver klasse er der opstillet en klassespecikation for alle designklasser, og disse kan sammen med en tilhørende beskrivelse ses i Appendix B på side 157. Klasserne, der præsenteres i det følgende, er ikke inddelt i pakker. Dette vil være hensigtmæssigt ved udvikiling af et komplet databasesystem til Region Sjællands Befolkningsundersøgelse, da mængden af klasser hermed øges, hvorved pakkeinddeling vil være medvirkende til at bevare et overblik. 71

78 10. Designklasser 10.1 Designklasser udledt fra analyseklassen Brugergrænseade Analyseklassen Brugergrænseade beskriver systemets brugergrænseade samlet. Systemet skal indeholde en del menuer, i form af faneblade. I den forbindelse er det valgt at dele analyseklassen Brugergrænseade op således, at hvert faneblad i hovedmenuen er en k- lasse for sig selv. For hvert faneblad er der en brugergrænseade til både indtastning og redigering og en til udtrækning. I denne forbindelse adskiller klassen ResultatGUI sig, da den samme brugergrænseade anvendes til Indtast data, Redigér data og Udtræk data. Udover dette, er det valgt at lave en klasse, FrameGUI, der sørger for oprettelsen af hovedmenuen og dermed fanebladene, og en klasse, VelkommenGUI, der opsætter et velkomstvindue, når databasesystemet startes. Analyse Design : VelkommenGUI : FrameGUI : DeltagerGUI : DeltagerGUIUdtræk : KostDrikkevarerGUI : KostDrikkevarerGUIUdtræk : Brugergrænseflade : SygdomGUI : SygdomGUIUdtræk : ForældreGUI : ForældreGUIUdtræk : MedicinGUI : MedicinGUIUdtræk : FysiskAktivitetGUI : FysiskAktivitetGUIUdtræk : ResultatGUI Figur 10.1: Oversigt over hvilke designklasser, der er identiceret ud fra analyseklassen Brugergrænseade. Disse designklasser er; VelkommenGUI, FrameGUI, DeltagerGUI, DeltagerGUIUdtræk, KostDrikkevarerGUI, KostDrikkevarerGUIUdtræk, SygdomGUI, SygdomGUIUdtræk, ForældreGUI, ForældreGUIUdtræk, MedicinGUI, MedicinGUIUdtræk, FysiskAktivitetGUI, FysiskAktivitetGUIUdtræk og ResultatGUI. 72

79 10.2. Designklasse udledt fra analyseklasserne Database og Eksport 10.2 Designklasse udledt fra analyseklasserne Database og Eksport Da analyseklassen Database er tiltænkt som kommunikationsleddet mellem computeren og databasen, ndes det hensigtsmæssigt at omdøbe denne klasse til Databasekommunikation. For at undgå en klasse med uhensigtsmæssig lav funktionalitet er det desuden valgt at nedlægge analyseklassen Eksport. Klassens funktionalitet er dækket under den nyoprettede designklasse Databasekommunikation. På Figur 10.2 ses designklassen, der er oprettet på baggrund af analyseklasserne Database og Eksport. Analyse Design : Database : Databasekommunikation : Eksport Figur 10.2: Analyseklasserne Database og Eksport erstattes med designklassen Databasekommunikation, da det anses for et mere sigende navn i forhold til den tiltænkte funktionalitet af analyseklassen. Analyseklassen Eksport inkluderes i den samlede designklasse pga. lav funktionalitet Designklasser udledt fra analyseklassen Spørgeskema Analyseklassen Spørgeskema forbliver den samme i forbindelse med oprettelsen af designklasser. Designklasserne Deltager, Medicin, Sygdom, FysiskAktivitet, Forældre og Kost- Drikkevarer er derfor stadig nedarvninger af designklassen Spørgeskema er derfor stadig nedarvninger til klassen Spørgeskema. På Figur 10.3 ses designklassen for Spørgeskema. : Spørgeskema : Deltager : Medicin : Sygdom : FysiskAktivitet : Forældre : KostDrikkevarer Figur 10.3: Oversigt over designklassen Spørgeskema, som ikke er ændret i forhold til i analysefasen. Dermed er designklasserne Deltager, Medicin, Sygdom, FysiskAktivitet, Forældre og KostDrikkevarer stadig nedarvninger af designklassen Spørgeskema. 73

80 10. Designklasser 10.4 Klassediagram for designklasserne På Figur 10.4 ses klassediagrammet for designklasserne, hvilket er en statisk beskrives af det designede system. I klassediagrammet vises relationsforholdet klasserne imellem og deres multiplicitet. Der er en komposition mellem klassen FrameGUI og de resterende GUI-klasser, da de andre GUI-klasser ikke kan eksistere uden klassen FrameGUI. Ligeledes kan det ses, at klassen Spørgeskema er superklasse til klasserne Deltager, Medicin, Sygdom, FysiskAktivitet, KostDrikkevarer og Forældre. Hver af disse klasser har en GUIklasse og hver GUI-klasse har én af disse kontrolklasser. Hvert Spørgeskema har én FrameGUI, og hver FrameGUI har ét Spørgeskema. Hver ResultatGUI gemmes i én Databasekommunikation, og hver Databasekommunikation henter fra én ResultatGUI. 1 : Deltager 1 1 har har har har : DeltagerGUI : DeltagerGUIUdtræk 1 1 : Medicin 1 1 har har har har 1 : MedicinGUI : MedicinGUIUdtræk : Sygdom har har har har : SygdomGUI : SygdomGUIUdtræk : Databasekommunikation henter fra 1 gemmes i 1 : Spørgeskema 1 : FysiskAktivitet har har har har 1 : FysiskAktivtet- GUI : FysiskAktivtet- GUIUdtræk : FrameGUI : ResultatGUI 1 1 : KostDrikkevarer 1 1 har har har har 1 : KostDrikkevarer- GUI : KostDrikkevarer- GUIUdtræk 1 : Forældre 1 1 har har har har 1 : ForældreGUI : ForældreGUIUdtræk har har Figur 10.4: Klassediagram for designklasserne. Klassediagrammet viser et statisk overblik over systemet. Relationsforhold mellem klasserne og deres multiplicitet angives. 74

81 Kapitel 11 Interaktionsdiagrammer for design I dette kapitel opstilles interaktionsdiagrammer for design af use casene Indtast data, Redigér data og Udtræk data. Formålet med interaktionsdiagrammer i design er at give overblik over objekternes kommunikation med henblik på implementering. Først præsenteres kommunikationsdiagrammet og derefter sekvensdiagrammet for hver use case. Implementeringen sker herefter på baggrund af klassespecikationer og sekvensdiagrammer Kommunikations- og sekvensdiagrammer De angivne interaktionsdiagrammer udarbejdes på instansform, hvormed et enkelt scenarie for den pågældende use case vises og beskrives. Indtast data De to følgende interaktionsdiagrammer viser et scenarie hvor brugeren opretter en deltager, der ikke allerede eksisterer i databasen, hvorved der skal indtastes data for denne, ydermere vælges det, at denne deltager er syg. Figur 11.1 på næste side illustrerer kommunikationsdiagrammet for use casen Indtast data. Den første brugergrænseade vises for brugeren vha. metoden initcomponents() fra klassen VelkommenGUI. Dernæst vælger brugeren at trykke på knappen Indtast data for at markere, at der skal indtastes data til en ikke-oprettet deltager. Herefter kaldes metoden fanebladsopsætningindtast() fra klassen FrameGUI, som initialiserer use casen. Når brugeren vælger fanebladet Gem, som er opsat af klassen ResultatGUI, skal de indtastede data hentes fra brugergrænseaden, hvilket sker med metoden setvalgteparametreindtast(). I denne forbindelse kaldes metoden gemindtastetdeltagerarray() fra klassen Deltager, hvorefter metoderne getsingleselectlistinfo() og gettextfeltinfo() kaldes fra klassen Spørgeskema. Ligeledes skal metoden gemindtastetsygdomarray() kaldes fra klassen Sygdom, hvorefter metoden getindtastmultiselectlistinfo() kaldes fra klassen Spørgeskema. Sidst kaldes metoden indsætdata() fra klassen Databasekommunikation og data kan 75

82 11. Interaktionsdiagrammer for design gemmes i databasen. 1:initComponents() Bruger : VelkommenGUI 1.1: fanebladsopsætningindtast() : Databasekommunikation : indsætdata() 1.1.1:setValgteParametreIndtast() : gemindtastetsygdomarray() : FrameGUI : ResultatGUI : Sygdom : gemindtastetdeltagerarray() : getindtastmultiselectlistinfo () : Deltager : getsingleselectlistinfo () : gettextfeltinfo() : Spørgeskema Figur 11.1: Kommunikationsdiagram for use casen Indtast data. Det strukturelle forløb er vist ved metodernes nummerering. Figur 11.2 på modstående side viser sekvensdiagrammet for use casen Indtast data, hvor metoden initcomponent() sørger for, at brugeren præsenteres for en brugergrænseade, som viser de tre valgmuligheder for anvendelse af systemet. Brugeren vælger Indtast data i brugergrænseaden, hvilket registreres af metoden mouseclickedindtast(). Metoden fanebladsopsætningindtast() fra klassen FrameGUI kaldes, som initialiserer use casen. Forinden er objekter af de andre klasser oprettet. Brugeren kan dermed vælge fanebladet Deltager, så denne deltagers data kan indtastes. Det registreres, at brugeren har valgt fanebladet Gem vha. metoden statechanged(), hvormed metoden setvalgteparametreindtast() kaldes fra klassen ResultatGUI(). Værdierne samles i et array vha. metoderne gemindtastetdeltagerarray() og gemindtastetsygdomarray(). De indtastede værdier præsenteres for brugeren med metoden setnavnværdiindtast() og når brugeren har godkendt at data skal gemmes, kaldes metoden okknapactionperformed(). Dernæst kaldes metoden indsætdata(), hvormed der oprettes forbindelse til databasen vha. metoden opret- Forbindelse() og data lagres i databasen. Brugeren informeres om, at data er gemt vha. metoden vismeddelelse() fra klassen FrameGUI. 76

83 11.1. Kommunikations- og sekvensdiagrammer SD: Indtast data initcomponents() : VelkommenGUI : FrameGUI : ResultatGUI : Deltager : Spørgeskema : Sygdom : Kommunikation : DeltagerGUI : SygdomGUI mouseclickedindtast() fanebladsopsætningindtast() opsætningframe() statechanged() setvalgteparametreindtast() getsamletarrayindtast() gemindtastetdeltagerarray() getsingleselectlistinfo() gettextfeltinfo() gemindtastetsygdomarray() getindtastmultiselectlistinfo() gettextfeltinfo() setnavnværdiindtast() okknapactionperformed() indsætdata() opretforbindelse() vismeddelelse() Figur 11.2: Sekvensdiagram for use casen Indtast data. Den vertikale akse angiver tiden, mens den horisontale akse angiver objekterne. 77

84 11. Interaktionsdiagrammer for design Redigér data Standardscenariet er, at den dataansvarlige af databasesystemet redigerer i en deltagers data gemt i databasen. De to følgende interaktionsdiagrammer viser et scenarie hvor en deltager yttet til en anden adresse i samme by, hvormed gadenavn og husnr. skal redigeres. Figur 11.3 på næste side illustrerer kommunikationsdiagrammet for use casen Redigér data. Den første brugergrænseade vises for brugeren vha. metoden initcomponents() fra klassen VelkommenGUI. Dernæst vælger brugeren at trykke på knappen Redigér data for at markere, at der skal redigeres data til en oprettet deltager. Herefter kaldes metoden fanebladsopsætningrediger() fra klassen FrameGUI, som initialiserer use casen. For at brugeren kun skal indtaste deltagernummeret for at nde en deltager i databasen, deaktiveres de andre tekstfelter i fanebladet Deltager og de andre faneblade deaktiveres vha. metoden setfelterdeaktiverrediger(). Herefter kan deltagerens data hentes fra databasen med metoden nddeltager() fra klassen Databasekommunikation. Når deltagerens data er vist i brugergrænseaden, kan brugeren redigere i alle data om deltageren. Da brugeren vælger fanebladet Gem, som er opsat af klassen ResultatGUI, skal data hentes fra brugergrænseaden. I denne forbindelse skal metoden gemindtastetdeltagerarray() kaldes fra klassen Deltager, hvorefter metoderne getsingleselectlistinfo() og gettextfelt- Info() kaldes fra klassen Spørgeskema. For at gemme ændringerne i databasen kaldes metoden redigerdata() fra klassen Databasekommunikation. 78

85 11.1. Kommunikations- og sekvensdiagrammer 1:initComponent() : VelkommenGUI Bruger 1.1:fanebladsopsætningRediger() 1.1.1:setFelterDeaktiverRediger() : FrameGUI : DeltagerGUI : vismeddelelse() : getdeltagerinfo () : getsamletarray() : finddeltager() : Databasekommunikation : Spørgeskema 1.1.2: setvalgteparametreindtast() : redigerdata() : gettextfeltinfo() : getsingleselectlistinfo () : setdeltagerarray () : gemindtastetdeltagerarray() : ResultatGUI : Deltager Figur 11.3: Kommunikationsdiagram for use casen Redigér data. Det strukturelle forløb er vist ved metodernes nummerering. Figur 11.4 på den følgende side viser sekvensdiagrammet for use casen Redigér data, hvor metoden initcomponent() sørger for, at brugeren præsenteres for en brugergrænseade, som viser valgmulighederne for anvendelse af systemet. Brugeren vælger Redigér data fra brugergrænseaden, hvilket registreres af metoden mouseclickedrediger(). Metoden fanebladsopsætningrediger() fra klassen FrameGUI initialiserer use casen. Forinden er objekter af de andre klasser oprettet. Dernæst skal brugeren skrive deltagernummeret, hvormed metoden FindDeltagerKnapActionPerformed() kaldes. I denne metode hentes det indtastede deltagernr. og deltageren ndes i databasen, hvorfor der oprettes forbindelse til databasen og metoden genererattributarray() danner et array indeholdende alle navne på attributter i databasen. Herefter sættes deltagerens data i brugergrænseaden. Brugeren vælger fanebladet Deltager, så deltagerens data kan redigeres. Det registreres, at brugeren har valgt fanebladet Gem vha. metoden statechanged(), hvormed metoden setvalgteparametreindtast() kaldes fra klassen ResultatGUI(). Værdierne samles i et array vha. metoderne gemindtastetdeltagerarray(). Værdier fra brugergrænseaden præsenteres for brugeren med metoden setnavnværdiindtast() og når brugeren har godkendt, at data skal gemmes, kaldes metoden okknapactionperformed(). Dernæst oprettes forbindelse til databasen vha. metoden opretforbindelse() og data gemmes. Brugeren informeres om, at data er gemt vha. metoden vismeddelelse() fra klassen FrameGUI. 79

86 11. Interaktionsdiagrammer for design SD: Rediger initcomponents() : VelkommenGUI : FrameGUI : DeltagerGUI : Spørgeskema : Databasekommunikation : Deltager : ResultatGUI mouseclickedrediger() fanebladsopsætningrediger() fanebladsopsætningindtast() opsætningframe() setfelterdeaktiverrediger() FindDeltagerKnapActionPerformed() getdeltagerinfo() getsamletarray() finddeltager() opretforbindelse() genererattributarray() setdeltagerarray() statechanged() setvalgteparametreindtast() getsamletarrayindtast() getsingleselectlistinfo() gemindtastetdeltagerarray() gettextfeltinfo() setnavnværdiindtast() okknapactionperformed() redigerdata() opretforbindelse() vismeddelelse() Figur 11.4: Sekvensdiagram for use casen Redigér data. Den vertikale akse angiver tiden, mens den horisontale akse angiver objekterne. 80

87 11.1. Kommunikations- og sekvensdiagrammer Udtræk data De to følgende interaktionsdiagrammer viser et scenarie, hvor brugeren ønsker at udtrække data fra de deltagere, der er kvinder og indtager en bestemt kost, hvorfor der udtrækkes data fra klasserne Deltager og KostDrikkevarer. Figur 11.5 illustrerer kommunikationsdiagrammet for use casen Udtræk data. Den første brugergrænseade vises for brugeren vha. metoden initcomponents() fra klassen VelkommenGUI. Dernæst vælger brugeren at trykke på knappen Udtræk data for at markere, at der skal udtrækkes data fra databasen. Herefter kaldes metoden fanebladsopsætning- Udtræk() fra klassen FrameGUI, som initialiserer use casen.når brugeren vælger fanebladet Eksportér, som er opsat af klassen ResultatGUI, skal de indtastede data hentes fra brugergrænseaden. I denne forbindelse kaldes metoden gemudtruknedeltagerarray() fra klassen Deltager, hvorefter metoderne getsingleselectlistinfo() og gettextfeltinfo() kaldes fra klassen Spørgeskema. Ligeledes skal metoden gemudtruknekostdrikkevarerarray() kaldes fra klassen KostDrikkevarer, hvorefter metoderne getsingleselectlistinfo() og getindtast- MultiSelectListInfo() kaldes fra klassen Spørgeskema. Data hentes fra databasen vha. metoden gemudtræk() fra klassen Databasekommunikation. 1:initComponents() : VelkommenGUI Bruger 1.1:fanebladsopsætningUdtræk() : FrameGUI 1.1.1: setvalgteparametreudtræk() : udtrækdata() : gemudtruknedeltagerarray() : Databasekommunikation : ResultatGUI : Deltager : gemudtruknekostdrikkevarerarray() : getsingleselectlistinfo () : gettextfeltinfo() : getsingleselectlistinfo () : getmultiselectlistinfo () : KostDrikkevarer : Spørgeskema Figur 11.5: Kommunikationsdiagram for use casen Udtræk data. Det strukturelle forløb er vist ved metodernes nummerering. Figur 11.6 på side 83 viser sekvensdiagrammet for use casen Udtræk data, hvor meto- 81

88 11. Interaktionsdiagrammer for design den initcomponent() sørger for, at brugeren præsenteres for en brugergrænseade, som viser de tre valgmuligheder for anvendelse af systemet. Brugeren vælger Udtræk data i brugergrænseaden, hvilket registreres af metoden mouseclickedudtræk(). Metoden fanebladsopsætningudtræk() fra klassen FrameGUI, som initialiserer use casen. Forinden er objekter af de andre klasser oprettet. Brugeren kan dermed vælge fanebladene Deltager og Kost og drikkevarer og vælger de værdier, der skal udtrækkes. Det registreres, at brugeren har valgt fanebladet Eksportér vha. metoden statechanged(), hvormed metoden setvalgteparametreudtræk() kaldes fra klassen ResultatGUI(). Værdierne samles i et array vha. metoderne gemudtruknedeltagerarray() og gemudtruknekostdrikkevarerarray(). De valgte værdier præsenteres for brugeren med metoden setnavnværdiudtræk() og når brugeren har godkendt, at data skal udtrækkes, kaldes metoden okknapaction- Performed(). Dernæst oprettes forbindelse til databasen vha. metoden opretforbindelse(). Brugeren vælger herefter hvor og med hvilket navn data skal gemmes, og data gemmes i en l. 82

89 11.1. Kommunikations- og sekvensdiagrammer SD: Udtræk data initcomponents() : VelkommenGUI : FrameGUI : Deltager : KostDrikkevarer : Spørgeskema : ResultatGUI : Databasekommunilkation : DeltagerGUIUdtræk : KostDrikkevarerGUIUdtræk mouseclickedudtræk() fanebladsopsætningudtræk opsætningframe() statechanged() setselectedtoone() setselectedtoone() setvalgteparametre() getsamletarrayudtræk() gemudtruknedeltagerarray() getsingleselectlistinfo() gettextfeltinfo() gemudtruknekostdrikkevarerarray() getsingkeselectlistinfo() getmultiselectlistinfo() setnavnværdiudtræk() okknapactionperformed() udtrækdata() genererattributarray() generertabelarray() opretforbindelse() Figur 11.6: Sekvensdiagram for use casen Udtræk data. Den vertikale akse angiver tiden, mens den horisontale akse angiver objekterne. 83

90

91 Del VI Implementering Workowet Implementering foregår hovedsageligt i Elaborations- og Constructionsfasen, dog mest i sidstnævnte fase. I dette workow implementeres systemet i kode på baggrund af det udviklede design i Del V. Denne del indeholder implementeringen af tre undersystemer, som hver beskriver en funktionel del af det endelige databasesystem. De enheder databasesystemet samlet set består af er brugergrænseade, database og kommunikation, der hver gennemgås i separate kapitler.

92

93 Kapitel 12 Implementering af brugergrænseade I dette kapitel dokumenteres implementeringen af brugergrænseaden, samt de vigtigste klasser benyttet i forbindelse med denne. Implementeringen af brugergrænseaden sker på baggrund af de denerede designklasser. Undersystemet brugergrænseade består af en række klasser, der håndterer brugergrænseaden og står for den graske opsætning af denne Implementeringsovervejelser I workowet design er det fundet hensigtsmæssigt at danne GUI-klasser for use casene Indtast og Redigér data og GUIUdtræk-klasser for use casen Udtræk data. Det skyldes, at brugergrænseaderne skal opfylde forskellige mål. Indtast og Redigér data har den samme fanebladsopsætning, da der ikke er væsentlige forskelle, hvorfor det også er valgt, at de samme GUI-klasser opsætter disse. Ved Redigér data deaktiveres alle felter, faneblade og lister pånær deltagernr., inden den valgte deltagers data er fundet i databasen. Ved Udtræk data skal en bruger kunne udtrække data om deltagere uden, at en specik værdi er valgt i hver liste, hvorfor der er tilføjet en værdi i listerne, kaldet Alle. Endvidere er det muligt ved udtrækning af data at søge på køn og aldersgruppe. Disse elementer er ikke mulige ved indtastning og redigering af data, da disse indirekte angives ved CPR-nr Grask opsætning af brugergrænseaden Brugergrænseaden implementeres ved brug af GUI Builder, der er et værktøj i NetBeans IDE Med dette værktøj er det muligt at vælge forskellige GUI-objekter og paneler fra en palet. Disse kan efterfølgende ved brug af musen placeres hvor på arbejdsområdet, det ønskes. Ud fra denne visuelle opbygning af brugergrænseaden autogenereres koden for layout. Der implementeres forskellige interfaces, ActionListener(), MouseListener() og ChangeListener(), for at lytte efter og reagere på brugerinteraktion i GUI-klasserne. For listenerne deneres henholdvis en ActionPerformed(), MouseClicked() og statechanged() 87

94 12. Implementering af brugergrænseade til komponenterne, der kaldes, når den pågældende hændelse nder sted. FrameGUI nedarves fra JFrame, hvorpå forskellige faneblade kan placeres. Fanebladene nedarves fra JTabbedPane. FrameGUI indeholder desuden kode, der håndterer skiftene mellem de forskellige faneblade. Den autogenerede kode for de forskellige faneblade ndes i klasserne; VelkommenGUI, DeltagerGUI, DeltagerGUIUdtræk, ForældreGUI, ForældreGUIUdtræk, FysiskAktivitetGUI, FysiskAktivitetGUIUdtræk, KostDrikkevarerGUI, KostDrikkevarerGUIUdtræk, MedicinGUI, MedicinGUIUdtræk, ResultatGUI, Sygdom- GUI og SygdomGUIUdtræk. Klassen VelkommenGUI er mainklassen, hvorfra et velkomstvindue oprettes. I GUI-klasserne oprettes variable af typen JLabel, JButton, JTextField og JList. Listerne i GUI-klasserne er enten denerede til at tillade single-selection eller multiple-interval-selection. Ved single-selection er det kun muligt for brugeren at vælge én værdi fra listen, hvorimod brugeren kan vælge ere værdier ved multiple-interval-selection Implementering af designklasser Kontrolklasserne beskrives parallelt med GUI-klasserne, således en sammenhæng mellem den graske opbygning og den kontollerende kode for brugergrænseaden bevares. Det er valgt at beskrive implementeringen af GUI-klasserne og GUIUdtræk-klasserne samlet, da layoutet ligner hinanden indenfor hvert faneblad. Klasserne VelkommenGUI og FrameGUI har ingen kontrolklasser, da disse to klasser opsætter henholdsvis velkomstvinduet og fanebladene. Klassen ResultatGUI præsenterer hvad brugeren har valgt i lister og indskrevet i felter. Klassen VelkommenGUI Brugergrænseaden, der oprettes i denne klasse, præsenteres for brugeren ved opstart af systemet. Klassen indeholder komponenter af typen JButton og implementerer MouseListener til at lytte på brugerinteraktion med komponenterne, udover dette vælges layoutet til brugergrænseaden. Det vælges at bruge biblioteket NimRODLookAndFeel, i stedet for Netbeans default-layout. Ved hjælp af NimRODLookAndFeel deneres baggrundsfarve, farve på faneblade, lister, tekst mm.. I denne brugergrænseade kan der foretages tre valg; Indtast data, Redigér data og Udtræk data. Alt efter brugerens valg skal der kaldes en tilhørende metode, som opsætter en brugergrænseade til den valgte funktionalitet. Et screenprint af velkomstvinduet, som klassen VelkommenGUI opsætter, ses på Figur 12.1 på næste side. 88

95 12.3. Implementering af designklasser Figur 12.1: Screenprint af brugergrænseaden, som brugeren præsenteres for ved opstart af systemet. Velkomstvinduet opsættes i klassen VelkommenGUI. Klassen FrameGUI Et screenprint af FrameGUI vises ikke, da klassen FrameGUI ikke indeholder komponenter, men opsætter et faneblad for hver af de resterende GUI-klasser, samt opretter en instans af kontrolklasserne. I FrameGUI implementeres ChangeListener på fanebladene, hvormed det kan registeres, om brugeren skifter mellem faneblade. I metoden state- Changed() undersøges det, om brugeren har valgt fanebladet Eksportér/Gem for at få vist sine indtastninger eller de værdier, som ønskes udtrukket fra databasen. Hvis brugeren vælger dette faneblad, skal metoder fra klassen ResultatGUI kaldes. Yderligere undersøger en metode om de indtastede værdier i felterne; CPR-nr., Deltagernr., Postnr., By, Privatnr. og Mobilnr. opfylder den gældende syntaks. Kontrolklassen Spørgeskema Klassen Spørgeskema er deneret som en superklasse til de resterende klasser, som styrer den bagvedliggende kode til brugergrænseaden. Klassen indeholder forskellige metoder til at hente brugerens valg fra brugergrænseaden og lægge valget for den enkelte komponent i en arrayliste. Klassen har ingen graske komponenter eller opsætningsmæssig indydelse. Metoderne fra Spørgeskema kaldes, når fanebladet Eksportér/Gem vælges af brugeren. Klasserne DeltagerGUI og DeltagerGUIUdtræk Layoutet af fanebladet Deltager opsættes af klassen DeltagerGUI, hvis funktionaliteterne Indtast data eller Redigér data er valgt. Hvis brugeren derimod vælger funktionaliteten 89

96 12. Implementering af brugergrænseade Udtræk data, opsætter klassen DeltagerGUIUdtræk fanebladet Deltager, og fanebladet får tilføjet tre lister. To lister hvor det kan deneres i hvilken aldersgruppe, der skal udtrækkes data fra og en liste, hvor køn vælges. Brugergrænseaderne præsenteres for brugeren ved valg af fanebladet Deltager. Klasserne indeholder komponenter i form af JList, JButton og JTextField og implementerer ActionListener til at lytte på brugerinteraktion på komponenter af typen JButton. I brugergrænseaderne indtaster, redigerer eller udtrækker brugeren data om deltageren. Et screenprint af brugergrænsenaden for fanebladet Deltager ses på Figur Figur 12.2: Screenprint af brugergrænseaden som viser fanebladet Deltager, hvis funktionaliterne Indtast data eller Redigér data er valgt. Layout af dette faneblad opsættes af klassen DeltagerGUI. Hvis brugeren vælger funktionaliteten Udtræk data, vil tre lister tilføjes med alder til og fra, samt køn. Layout af dette faneblad opsættes af klassen DeltagerGUIUdtræk. Kontrolklassen Deltager Klassen Deltager styrer den bagvedliggende kode til fanebladet Deltager opsat af klassen DeltagerGUI eller klassen DeltagerGUIUdtræk. Klassen indeholder en metode til at samle de valgte og indskrevne værdier i brugergrænseaden i en arrayliste. Desuden undersøger en metode, om der er komponenter, hvori brugeren ikke har valgt nogle værdier. Hvis dette er tilfældet sættes værdien til en tom streng i det samlede array. Klassen indeholder desuden metoder til at validere indtastede telefonnumre, CPR-nr. og datoer ud fra opstillede kriterier. Telefonnumre og CPR-numre skal have en længde på henholdsvis otte og ti cifre, og de må ikke indeholde andet end talværdier. Ved dato undersøges det om syntaksen, dd.mm.åå, er overholdt. Når use casen Redigér data er valgt, sættes værdier i 90

97 12.3. Implementering af designklasser fanebladet, efter de er hentet fra databasen ud fra det indskrevne deltagernr., hvorefter det er muligt at se og redigere data. Klasserne KostDrikkevarerGUI og KostDrikkevarerGUIUdtræk Layoutet af fanebladet Kost og drikkevarer opsættes af klassen KostDrikkevarerGUI, hvis funktionaliteterne Indtast data eller Redigér data er valgt. Hvis brugeren derimod vælger funktionaliteten Udtræk data, opsætter klassen KostDrikkevarerGUIUdtræk fanebladet Kost og drikkevarer, og listerne får tilføjet værdien Alle. Brugergrænseaderne præsenteres for brugeren ved valg af fanebladet Kost og drikkevarer. Klasserne indeholder udelukkende komponenter af typen JList. I brugergrænseaderne indtaster, redigerer eller udtrækker brugeren data om deltagerens kost- og drikkevaner. Næsten alle lister pånær én er implementeret som single-selection, hvormed det er muligt højst at vælge én værdi i listen, eller vælge Alle i listerne ved udtrækning af data. Én liste er implementeret som multiple-interval-selection, hvor det derfor er muligt at vælge ere værdier fra listen. Et screenprint af brugergrænseaden for fanebladet KostDrikkevarer ses på Figur Figur 12.3: Screenprint af brugergrænseaden som viser KostDrikkevarer fanebladet, hvis funktionaliterne Indtast data eller Redigér data er valgt. Layout af dette faneblad opsættes af klassen KostDrikkevarerGUI. Hvis brugeren vælger funktionaliteten Udtræk data, vil værdien Alle tilføjes til listerne. Layout af dette faneblad opsættes af klassen KostDrikkevarerGUIUdtræk. 91

98 12. Implementering af brugergrænseade Kontrolklassen KostDrikkevarer Klassen KostDrikkevarer styrer den bagvedliggenden kode til fanebladet Kost og drikkevarer opsat af klassen KostDrikkevarerGUI eller klassen KostDrikkevarerGUIUdtræk. Klassen indeholder en metode til at samle de valgte og indskrevne værdier i brugergrænse- aden i en arrayliste. Desuden undersøger en metode, om der er lister, hvori brugeren ikke har valgt nogle værdier. Hvis dette er tilfældet sættes værdien til en tom streng i det samlede array, hvis listen tillader single-selection. Hvis listen er multiple-interval-selection dannes et array bestående af tomme strenge ligeså lang som listen. Når use casen Redigér data er valgt sættes værdier om deltagerens kost og drikkevaner i fanebladet, efter de er hentet fra databasen ud fra det indskrevne deltagernr., hvorefter det er muligt at se og redigere data. Klasserne SygdomGUI og SygdomGUIUdtræk Layoutet af fanebladet Sygdom opsættes af klassen SygdomGUI, hvis funktionaliteterne Indtast data eller Redigér data er valgt. Hvis brugeren derimod vælger funktionaliteten Udtræk data, opsætter klassen SygdomGUIUdtræk fanebladet Sygdom, og listerne får tilføjet værdien Alle. Brugergrænseaderne præsenteres for brugeren ved valg af fanebladet Sygdom. Klasserne indeholder komponenter i form af JList og JTextField. Flere af listerne tillader multiple-interval-selection, da deltageren kan lide af nul til ere sygdomme. Listerne der er single-selection omhandler hvorvidt deltageren er bloddonor, antal tapninger og antal år som bloddonor, samt en liste om hvorvidt deltageren har åreknuder og hvis dette er tilfældet angivelsen af alderen ved første åreknude. Disse lister er implementeret således, at år eller tapninger kun er mulige at angive, hvis der er svaret ja til at deltageren er bloddonor. Dette gælder ligeledes for information om åreknuder. Deltagerens vægt som 20-årig og ved fødsel er ligeledes implementeret i lister med single-selection. Ydermere implementeres et felt til angivelse af fødselsvægt, hvis denne er nøjagtigt kendt. I brugergrænseaderne indtaster, redigerer eller udtrækker brugeren data om deltagerens sygdomshistorie. Et screenprint af brugergrænseaden for fanebladet Sygdom ses på Figur 12.4 på modstående side. 92

99 12.3. Implementering af designklasser Figur 12.4: Screenprint af brugergrænseaden som viser fanebladet Sygdom, hvis funktionaliterne Indtast data eller Redigér data er valgt. Layout af dette faneblad opsættes af klassen SygdomGUI. Hvis brugeren vælger funktionaliteten Udtræk data, vil værdien Alle tilføjes til listerne. Layout af dette faneblad opsættes af klassen SygdomGUIUdtræk. Kontrolklassen Sygdom Klassen Sygdom styrer den bagvedliggende kode til fanebladet Sygdom opsat af klassen SygdomGUI eller klassen SygdomGUIUdtræk. Klassen indeholder en metode til at samle de valgte og indskrevne værdier i brugergrænseaden i en arrayliste. Desuden undersøger en metode, om der er lister eller tekstfelter, hvori brugeren ikke har valgt eller skrevet nogle værdier. Hvis dette er tilfældet sættes værdien til en tom streng i det samlede array, hvis listen tillader single-selection. Hvis listen er multiple-interval-selection dannes et array bestående af tomme strenge lige så lang som listen. Når use casen Redigér data er valgt, sættes værdier om deltagerens sygdomshistorie i fanebladet, efter de er hentet fra databasen ud fra det indskrevne deltagernr., hvorefter det er muligt at se og redigere data. Klasserne ForældreGUI og ForældreGUIUdtræk Layoutet for fanebladet Forældre opsættes af klassen ForældreGUI, hvis funktionaliteterne Indtast data eller Redigér data er valgt. Hvis brugeren derimod vælger funktionaliteten Udtræk data, opsætter klassen ForældreGUIUdtræk fanebladet Forældre, og listerne får tilføjet værdien Alle. Brugergrænseaderne præsenteres for brugeren ved 93

100 12. Implementering af brugergrænseade valg af fanebladet Forældre. Klasserne indeholder udelukkende komponenter af typen JList. Listerne omhandlende forældrenes sygdom er implementeret som multiple-intervalselection, mens lister omhandlende forældrenes uddannelse er single-selection. I brugergrænseaderne indtaster, redigerer eller udtrækker brugeren data om deltagerens forældre. Et screenprint af brugergrænseaden for fanebladet Forældre ses på Figur Figur 12.5: Screenprint af brugergrænseaden som viser Forældre fanebladet, hvis funktionaliterne Indtast data eller Redigér data er valgt. Layout af dette faneblad opsættes af klassen ForældreGUI. Hvis brugeren vælger funktionaliteten Udtræk data, vil værdien Alle tilføjes til listerne. Layout af dette faneblad opsættes af klassen ForældreGUIUdtræk. Kontrolklassen Forældre Klassen Forældre styrer den bagvedliggende kode til fanebladet Forældre opsat af klassen ForældreGUI eller klassen ForældreGUIUdtræk. Klassen indeholder en metode til at samle de valgte og indskrevne værdier i brugergrænseaden i en arrayliste. Desuden undersøger en metode, om der er lister, hvori brugeren ikke har valgt nogle værdier. Hvis dette er tilfældet sættes værdien til en tom streng i det samlede array, hvis listen tillader singleselection. Hvis listen er multiple-interval-selection, dannes et array bestående af tomme strenge lige så lang som listen. Når use casen Redigér data er valgt, sættes værdier om deltagerens forældre i fanebladet, efter de er hentet fra databasen ud fra det indskrevne deltagernr., hvorefter det er muligt at se og redigere data. 94

101 Klasserne MedicinGUI og MedicinGUIUdtræk Implementering af designklasser Layoutet for fanebladet Medicin opsættes af klassen MedicinGUI, hvis funktionaliteterne Indtast data eller Redigér data er valgt. Hvis brugeren derimod vælger funktionaliteten Udtræk data, opsætter klassen MedicinGUIUdtræk fanebladet Medicin, og listerne får tilføjet værdien Alle. Brugergrænseaderne præsenteres for brugeren ved valg af fanebladet Medicin. Klasserne indeholder udelukkende komponenter af typen JList. Til hver medikament er der implementeret to lister; en for antallet af præparater og en for antallet af år med det/de pågældende medikament. Listen med antallet af år er kun aktiveret, hvis brugeren har angivet, at det pågældende medikament anvendes. Alle lister er implementeret som single-selection, hvorfor én enkelt værdi kan vælges. I brugergrænse- aderne indtaster, redigerer eller udtrækker brugeren data om deltagerens medicinforbrug. Et screenprint af brugergrænseaden for fanebladet Medicin ses på Figur Figur 12.6: Screenprint af brugergrænseaden som viser Medicin fanebladet, hvis funktionaliterne Indtast data eller Redigér data er valgt. Antallet af år for indtagelse af medikamenterne kan først angives, hvis antallet af medikamenter er angivet. Layout af dette faneblad opsættes af klassen MedicinGUI. Hvis brugeren vælger funktionaliteten Udtræk data, vil værdien Alle tilføjes til listerne. Layout af dette faneblad af klassen MedicinGUIUdtræk. Kontrolklassen Medicin Klassen Medicin styrer den bagvedliggenden kode til fanebladet Medicin opsat af klassen MedicinGUI eller klassen MedicinGUIUdtræk. Klassen indeholder en metode til at samle de valgte og indskrevne værdier i brugergrænseaden i en arrayliste. Desuden undersøger 95

102 12. Implementering af brugergrænseade en metode, om der er lister, hvori brugeren ikke har valgt nogle værdier. Hvis dette er tilfældet sættes værdien til en tom streng i det samlede array. Når use casen Redigér data er valgt, sættes værdier om deltagerens medicinforbrug i fanebladet, efter de er hentet fra databasen ud fra det indskrevne deltagernr., hvorefter det er muligt at se og redigere data. Klasserne FysiskAktivitetGUI og FysiskAktivitetGUIUdtræk Layoutet af fanebladet Fysisk aktivitet opsættes af klassen FysiskAktivitetGUI, hvis funktionaliteterne Indtast data eller Redigér data er valgt. Hvis brugeren derimod vælger funktionaliteten Udtræk data, opsætter klassen FysiskAktivitetGUIUdtræk fanebladet F- ysisk aktivitet, og listerne får tilføjet værdien Alle. Brugergrænseaderne præsenteres for brugeren ved valg af fanebladet Fysisk aktivitet. Klasserne indeholder udelukkende komponenter af typen JList. Alle listerne er implementeret som single-selection, hvorfor kun én enkelt værdi kan vælges. Ligeledes ved udtræk er det kun muligt at udtrække en værdi eller Alle. I brugergrænseaderne indtaster, redigerer eller udtrækker brugeren data om deltagerens fysisk aktivitet, kondition og transportvaner til og fra arbejde. Et screenprint af brugergrænseaden for fanebladet Fysisk aktivitet ses på Figur Figur 12.7: Screenprint af brugergrænseaden som viser fanebladet Fysisk aktivitet, hvis funktionaliterne Indtast data eller Redigér data er valgt. Layout af dette faneblad opsættes af klassen FysiskAktivitetGUI. Hvis brugeren vælger funktionaliteten Udtræk data vil værdien Alle tilføjes til listerne. Layout af dette faneblad opsættes af klassen FysiskAktivitetGUIUdtræk. 96

103 12.3. Implementering af designklasser Kontrolklassen FysiskAktivitet Klassen FysiskAktivitet styrer den bagvedliggende kode til fanebladet Fysisk aktivitet opsat af klassen FysiskAktivitetGUI eller klassen FysiskAktivitetGUIUdtræk. Klassen FysiskAktivitet indeholder en metode til at samle de valgte og indskrevne værdier i brugergrænseaden i en arrayliste. Desuden undersøger en metode, om der er lister, hvori brugeren ikke har valgt nogle værdier. Hvis dette er tilfældet sættes værdien til en tom streng i det samlede array. Når use casen Redigér data er valgt, sættes værdier om deltagerens fysisk aktivitet i fanebladet, efter de er hentet fra databasen ud fra det indskrevne deltagernr., hvorefter det er muligt at se og redigere data. Klassen ResultatGUI Et screenprint af ResultatGUI vises ikke, pga. de få komponenter denne indeholder. ResultatGUI opsætter fanebladet Gem eller Eksportér, hvis henholdvis funktionaliteterne Indtast data og Redigér data eller Udtræk data er valgt. Klassen indeholder en JList og en JButton. De valg, der er foretaget i de andre faneblade, importeres til listen og knappen fungerer som en OK knap, der tillader brugeren enten at gemme eller eksportere sine valg. Klassen ResultatGUI indeholder en metode, der danner én arrayliste bestående af de samlede arraylister fra klasserne Deltager, KostDrikkevarer, Sygdom, Forældre, Medicin og FysiskAktivitet. 97

104

105 Kapitel 13 Implementering af database I dette kapitel gennemgås realiseringen af undersystemet database. Dette sker ud fra de beslutninger, der er taget under ER-modelleringen i Kapitel 5 på side 25. Der vises enkelte kodeeksempler på implementeringen. Databasen implementeres, som tidligere nævnt, som en relationel database, og realiseres som en MySQL database. Det vælges at benytte sproget Structured Query Language (SQL) til at sende forespørgsler, og databasestyringsprogrammet phpmyadmin anvendes til visualisering. For mere information om MySQL og SQL se Appendix D på side Oprettelse af tabeller At implementere undersystemet database består i at denere, hvilke tabeller den allerede installerede MySQL database skal indeholde. I tabellerne angives tabellernes navne, attributternes navne og datatyper, primærnøgler, samt eventuelle restriktioner. Databasens tabeller omsættes fra ER-diagrammet fra Kapitel 5 på side 25. Da der er ni normaliserede relationer, oprettes ni tabeller til at håndtere data. Disse er følgende; Deltager, DeltagerCPRnr, Forældre, FysiskAktivitet, KostDrikkevarer, Medicin, PostnrBy, Spørgeskema og Sygdom. De normaliserede relationer for Deltager og Forældre ndes i Kapitel 5 på side 25 og de resterende i Appendix A på side 141. Tabellernes egenskaber Strukturen for hver tabel angives ved feltnavn, datatype, kollation, nulværdi og standardværdi. Under feltnavnet listes de attributter, der tilhører den pågældende tabel. Datatypen angiver den tilladte datatype og størrelse for den enkelte attributs domæne. Kollation de- nerer på hvilken måde data sorteres og sammenlignes. En typisk kollation er alfabetisk, og er især vigtig at specicere ved en bogstavrække. Nulværdi angiver, hvorvidt det er tilladt for feltet at være tomt og standardværdi angiver default-værdien for feltet. Det vælges, at alle attributter er af datatypen character (char), da det dermed kun behøves 99

106 13. Implementering af database at operere på arraylister indeholdende strenge i Java i stedet for ere typer af arraylister. Også attributter indeholdende tal, såsom CPR-nr. er af datatypen char. Grunden til dette er desuden, at der ikke gøres noget matematisk ved et CPR-nr.. Som kollation vælges en type, der sorterer i alfabetisk rækkefølge og kan håndtere det danske alfabet. I overensstemmelse med databasedesign i Kapitel 5 på side 25 er attributten Deltagernr primærnøgle i alle tabeller pånær tabellen PostnrBy, hvor attributten Postnr er primærnøgle. Denne tabel adskiller sig desuden fra de andre tabeller ved, at der allerede ved implementering af tabellen indsættes værdier deri. Dette gøres, da relationen mellem Postnr og By allerede på forhånd kendes. Derudover angives attributten Postnr i tabellen Deltager som fremmednøgle med reference til primørnøglen Postnr i tabellen PostnrBy, så denne kun kan antage de værdier attributten Postnr har i tabellen PostnrBy. Dette afholder en bruger i at indtaste et postnr., der ikke eksisterer i tabellen. Nulværdier er tilladte for alle felter pånær felter tilhørende primærnøgler. For alle andre felter er standardværdien NULL. Som storage engine er det valgt at benytte typen INNODB på trods af, at der som default bruges MyISAM. MyISAM kan ikke håndtere fremmednøgler, hvilket eksisterer i tabellen Deltager. Tabeller af typen INNODB kan derimod håndtere fremmednøgler. Herudover kan tabeller af typen INNODB også håndtere transaktioner, hvilket er nødvendigt, når der sendes ere SQL forespørgsler efter hinanden, som kun skal comittes, hvis alle er blevet eksekveret. En transaktion har pr. denition ACID egenskaber. Disse egenskaber er forklaret i Appendix D på side 173. Eksempel på oprettelse af tabel Til oprettelse af tabeller benyttes SQL forespørgsler, der indtastes i phpmyadmin og eksekveres af MySQL. Herunder vises et par eksempler på sådanne forespørgsler. Det første eksempel, der vises, er oprettelse af tabellen PostnrBy. Relationen for denne ses på Figur 5.6 på side 30 i Kapitel 5. De andre tabeller implementeres efter samme princip bortset fra, at de har Deltagernr som primærnøgle. CREATE TABLE PostnrBy( Postnr CHAR(4), By CHAR(20), PRIMARY KEY (Postnr) ) TYPE=INNODB Tabellen kaldes PostnrBy og består af attributterne Postnr og By, som begge er af datatypen char, som tidligere beskrevet. Postnr har længden 4, da dette er gældende 100

107 13.1. Oprettelse af tabeller for postnumre i Danmark, og By er 20 chars, da bynavne kan variere i længden, men højst sandsynligt ikke overstiger 20 bogstaver. Primærnøglen er Postnr og tabeltypen INNODB. Tabellen PostnrBy skal eksistere, inden tabellen Deltager kan oprettes, da Deltager har en fremmednøgle, nemlig primørnøglen i tabellen PostnrBy. Det følgende eksempel er oprettelsen af tabellen Deltager, hvor en fremmednøgle tilføjes. CREATE TABLE Deltager( Deltagernr CHAR(10), Fornavn CHAR(20), Efternavn CHAR(30),... Postnr CHAR(4), PRIMARY KEY (Deltagernr), FOREIGN KEY (Postnr) REFERENCES PostnrBy(Postnr) ) TYPE=INNODB Ovenstående eksempel ligner oprettelsen af PostnrBy bortset fra, at Deltager indeholder andre attributter og har en anden primærnøgle. Den største forskel er, at der efter angivelsen af primærnøglen er angivet en fremmednøgle med reference til tabellen PostnrBy. 101

108

109 Kapitel 14 Implementering af kommunikation I dette kapitel gennemgås implementeringen af designklassen Databasekommunikation. Undervejs vises enkelte simplicerede kodeeksempler. Al kommunikation til og fra databasen sker i klassen Databasekommunikation. Klassen Databasekommunikation håndterer foruden kommunikationen med databasen også eksportering af de data, der udtrækkes. For at kunne kommunikere med databasen fra Java bruges et sæt klasser kaldet Java DataBase Connectivity (JDBC), som ligger i pakken java.sql, hvilken derfor skal importeres. Sproget SQL bruges til at kommunikere mellem klient og database Forbindelse til database For at få adgang til databasen indlæses en databasedriver, mysql-connector-java bin.jar, der understøtter JDBC og giver adgang til den specikke database. I metoden, opretforbindelse() i klassen Databasekommunikation, oprettes forbindelse til MySQL serveren. Det følgende eksempel viser denne metode. public Connection opretforbindelse(){ Connection forbindelse = null; try { Class.forName("com.mysql.jdbc.Driver"); forbindelse = DriverManager.getConnection(url, brugernavn, adgangskode); } catch (ClassNotFoundException ex) { frameguiref.vismeddelelse(12);} catch (SQLException e) { frameguiref.vismeddelelse(5);} return forbindelse; } 103

110 14. Implementering af kommunikation Først initieres forbindelsen forbindelse, hvorefter driveren til databasen hentes og indlæses. Der oprettes forbindelse med adresse, brugernavn og adgangskode til databasen. Der håndteres to typer undtagelser i metoden. Hvis driveren ikke er tilgængelig på den pågældende computer, vises en fejlmeddelelse om dette. Hvis der derimod ikke kan oprettes forbindelse til databasen, fx hvis der ikke er internetforbindelse, vises en anden fejlmeddelelse. I metoden vismeddelelse() oprettes en standard dialogboks, hvori teksten kan varieres efter anvendelse. Numrene svarer derfor til forskellige typer meddelelser. Når forbindelsen er oprettet, er det vha. SQL muligt at sende forespørgsler til databasen. Alt efter hvilken forespørgsel, der sendes, indsættes, opdateres eller hentes data i databasen Indtastning, redigering og udtrækning af data Hvis det ønskes at indtaste eller redigere data i databasen, benyttes metoden executeupdate(). Herunder ses et simpliceret eksempel på en SQL forespørgsel, ved indtastning af data. stmt.executeupdate("insert INTO Deltager (Deltagernr, Fornavn) VALUES ('12','Hans')"); I tabellen Deltager indsættes værdierne 12 og Hans i kolonnerne Deltagernr og Fornavn. Følgende eksempel er en simpliceret SQL forespørgsel, der benyttes ved redigering af data. stmt.executeupdate("update Deltager SET Fornavn ='Peter' WHERE Deltagernr='12'"); I Deltager tabellen sættes Fornavn til Peter, hvor Deltagernr er 12. Det betyder, at der nu står Peter, hvor der før stod Hans. Hvis det ønskes at udtrække data fra databasen, kaldes metoden executequery(), efterfulgt af en SQL streng, som denerer, hvad der skal hentes. Når data hentes fra en MySQL database, returneres et såkaldt resultset fra databasen. Resultsettet kan læses sekventielt vha. ResultSet.next() og ResultSet.getString(kolonnenavn) for hver post. Til udtrækning af en enkelt deltagers data benyttes metoden nddeltager() i klassen Databaskommunikation. Det nedenstående kodeeksempel viser et udsnit af denne metode. Metoden kaldes, når en bruger har indtastet et deltagernr. og trykket på knappen Find Deltager. 104

111 14.3. Eksport af data try { ResultSet rs = stmt.executequery("select * FROM DeltagerCPRnr NATURAL JOIN (SELECT * FROM Deltager WHERE Deltagernr=('"+Deltagernr+"')) as Tabel NATURAL JOIN Foraeldre NATURAL JOIN FysiskAktivitet NATURAL JOIN KostDrikkevarer NATURAL JOIN Medicin NATURAL JOIN Spoergeskema NATURAL JOIN Sygdom NATURAL JOIN PostnrBy"); while(rs.next()){ for(int i=3; i<attributarray.size();i++){ redigerarray.add(rs.getstring(attributarray.get(i))); } } } catch (SQLException ex) { frameguiref.vismeddelelse(4); } I ovenstående benyttes joins, som er SQL forespørgsler, der kobler data fra to eller ere tabeller sammen ud fra en fælles attribut. MySQL understøtter inner joins og outer joins. Natural join er en type inner join, der, i eksemplet, kombinerer data fra samtlige tabeller ud fra det valgte deltagernr. Alle tabeller for den specikke deltager joines og lægges i et resultset. Hver enkelt streng fra resultsettet læses og lægges i en arrayliste. Dette gøres for hver enkelt række i resultsettet. De tre første pladser springes over, da disse indeholder køn og alder fra og til. I det tilfælde, hvor deltageren ikke eksisterer i databasen, vises en meddelelse om dette Eksport af data Ved eksport af data forstås, at der fra udvalgte søgekriterier udtrækkes data fra databasen og disse gemmes i en l, som derefter kan tilgås af andre programmer såsom SPSS eller Excel, hvor data statistisk kan behandles. Til eksport af data benyttes en metode kaldet udtrækdata(). Første del i metoden udtræk- Data() er at kombinere data ud fra valgte søgekriterier. Til dette formål benyttes joins. Det følgende kodeeksempel viser princippet bag hvordan data fra to tabeller, Deltager og Sygdom, samles i Java. 105

112 14. Implementering af kommunikation JoinRowSet jrs = new JoinRowSetImpl(); ResultSet rs1 = stmt.executequery("select * FROM Deltager"); CachedRowSet crs1 = new CachedRowSetImpl(); crs1.populate(rs1); jrs.addrowset(crs1, "Deltagernr"); ResultSet rs2 = stmt.executequery("select * FROM Sygdom"); CachedRowSet crs2 = new CachedRowSetImpl(); crs2.populate(rs2); jrs.addrowset(crs2, "Deltagernr"); JoinRowSet er et interface, der samler relaterede data fra forskellige RowSets med en SQL join. Alt data fra tabellen Deltager lægges i et ResultSet, der herefter lægges i et CachedRowSet, som er en type af RowSet, hvor datarækkerne lagres i hukommelsen. Det er derfor muligt at tilgå indholdet i CachedRowSet uden at være direkte forbundet til databasen. Sidst lægges CachedRowSet i JoinRowSet og der angives hvilken attribut, der skal joines i forhold til. I ovenstående eksempel er fællesattributten Deltagernr. Herefter tilføjes data fra tabellen Sygdom, der ligesom tabellen Deltager har Deltagernr, som matchende søjle. Da der ikke er speciceret en bestemt SQL join type, benyttes inner join som standard. Da fællesattributten er speciceret, vil joinet give samme resultat som en NATURAL join. Efter tabellerne er joinet, kan det kombinerede datasæt tilgås som et enkelt RowSet objekt. Som sidste led i metoden udtrækdata() skrives det endelige JoinRowSet til en l. Eksemplet herunder beskriver denne del. JFileChooser filvalg = new JFileChooser(); if (brugervalg == JFileChooser.APPROVE_OPTION){ fil = filvalg.getselectedfile(); String filnavn = fil.getpath()+".csv"; FileWriter writer = new FileWriter(filnavn); while(jrs.next()){ for(int i=0;i<216;i++){ writer.append(jrs.getstring(i)); writer.append(';'); 106

113 14.3. Eksport af data } writer.append('\n'); } writer.flush(); writer.close(); } JFileChooser benyttes til at vælge stien, hvortil len skal gemmes, og giver brugeren mulighed for at navigere rundt i lsystemet vha. dialogbokse. Alle rækker i JoinRowSet bliver løbet igennem og skrives til en l vha. klassen FileWriter. Det vælges, at lens format er af typen csv, da denne type l kan benyttes i adskillige statistikprogrammer, eksempelvis Excel og SPSS. 107

114

115 Del VII Test Test foregår hovedsageligt i Elaborations- og Constructionsfasen, men også i Transitionsfasen. I denne del dokumenteres test af det implementerede databasesystem. Først udføres en enhedstest af de tre undersystemer beskrevet i forrige del. Herefter testes hele systemet ved at opstille et antal test scenarier for hver enkelt use case, som er opstillet i Krav. Disse tests foretages som black-box tests og det beskrives, hvorledes testen foretages, samt resultaterne af hver test.

116

117 Kapitel 15 Test af undersystemer I dette kapitel testes de tre implementerede undersystemer; brugergrænseade, database og kommunikation. Formålet med at teste undersystemer er at vericere, at de fungerer hver for sig, da dette er en forudsætning for at systemet fungerer som helhed. Til hver test præsenteres formål, testudførelse, samt testresultater Test af brugergrænseade Formål Det testes, om undersystemet brugergrænseade fungerer som ønsket. Herunder om der kan navigeres i denne vha. fanebladene og at det der vælges i listerne og skrives i felterne registreres. Det testes også om de pågældende lister fungerer som enten single-selection eller multiple-interval-selection afhængig af, hvad der er deneret. Det testes desuden, at brugeren kun kan gemme data, hvis data har den gældende syntaks og både CPRnr., Deltagernr., Fornavn, Efternavn, Postnr. og By er indtastet. Endvidere testes det, om der fremkommer fejlmeddelelser, hvis der er syntaksfejl i felterne; CPR-nr., Mobilnr., Privatnr. og felterne for datoer. Udførelse Der trykkes på de forkellige faneblade i vilkårlig rækkefølge, og det observeres, hvorvidt de forventede faneblade vises. For at teste registreringen af værdier i lister og felter, skrives der i tilfældige felter og vælges fra tilfældige lister i fanebladene. Det tjekkes i arraylisten, der udskrives i NetBeans, at de valgte værdier er repræsenterede og at de ndes på deres prædenerede pladser. I samtlige lister forsøges det at vælge to eller ere værdier. CPRnr., Deltagernr., Fornavn, Efternavn, Postnr. og By indtastes i brugergrænseaden og det gemmes. Dernæst forsøges det at gemme, hvor en af de re nævnte parametre udelades og sidst skrives med forkert syntaks. 111

118 15. Test af undersystemer Resultater Ved tryk på et faneblad fremkom det forventede faneblad. De valgte og indtastede værdier fandtes i arraylisten, og det blev registreret at deres placering heri stemte. Det var muligt at vælge ere værdier i lister med multiple-interval-selection og begrænset til valg af en enkelt værdi ved lister med single-selection. Hvis enten CPR-nr., Deltagernr., Fornavn, Efternavn, Postnr. eller By blev udeladt ved indtastning blev data ikke gemt, og der blev vist en fejlmeddelelse ved skift til næste faneblad. Ved syntaksfejl i felterne; CPR-nr, Mobilnr., Privatnr., Postnr. og datoer fremkom der ligeledes en fejlmeddelelse. I Tabel 15.1 angives resultaterne for testscenarierne for at give et overblik over test af undersystemet Brugergrænseade. I tabellen angiver et ueben, at resultatet af testen er som forventet. Tabel 15.1: Oversigt over testsenarier indenfor undersystemet Brugergrænseade. Når resultatet af en test er som forventet, er det markeret i tabellen med et ueben. Brugergrænseflade Testscenarie Testscenarie Testscenarie Testscenarie Testscenarie Testscenarie Navigering vha. faneblade Valg i listerne og tekstfelter registreres Lister fungerer som single selection eller multipleinterval selection Gem data med den gældende syntaks Gem data når kontaktoplysninger er indtastet Fejlmeddelser ved syntaksfejl 15.2 Test af database Formål For at vurdere om databasen fungerer som ønsket, testes dennes håndtering af en række funktioner. Det testes, at der kun kan oprettes en deltager, hvis både Deltagernr, CPR-nr og Postnr angives. Der skal kun kunne oprettes én deltager pr. Deltagernr. For at afgøre om fremmednøglen i tabellen PostnrBy virker, skal det ikke være muligt at angive et Postnr, der ikke ndes i databasen. Sidst testes at de ønskede søgninger er mulige og at alder og køn kan inkluderes i søgningen på trods af, at de ikke eksisterer i databasen som attributter. Udførelse I databasen oprettes en deltager med både Deltagernr, CPR-nr og Postnr vha. en SQL forespørgsel. Desuden oprettes en deltager kun bestående af Deltagernr for at afgøre om det er tilladt. Der oprettes også to deltagere med samme Deltagernr. For at teste fremmednøglen ændres postnummeret på en eksisterende deltager, til et postnummer der ikke eksisterer i databasen. En søgning udføres ved at kombinere tabeller vha. joins, der 112

119 15.3. Test af kommunikation svarer til en ønsket søgning, og der udføres beregninger af alder og køn udfra CPR-numre. Resultater En deltager blev oprettet uanset om Deltagernr, CPR-nr og Postnr angives. Ved oprettelse af en deltager med et allerede eksisterende deltagernr. opstod der en fejl, så det var ikke muligt. Det samme skete ved ændring til et ikke-eksisterende Postnr. Desuden var de ønskede søgninger mulige vha. joins, og alder og køn blev beregnet korrekt ud fra CPRnumre. I Tabel 15.2 angives resultaterne for testscenarierne for at give et overblik over test af undersystemet Database. I tabellen angiver et ueben, at resultatet af testen er som forventet, mens et kryds angiver, at resulatet ikke er som forventet. Tabel 15.2: Oversigt over testsenarier indenfor undersystemet Database. Når resultatet af en test er som forventet, er det markeret i tabellen med et ueben, mens et kryds markerer, at resulatet af testen ikke er som forventet. Database Testscenarie Deltager oprettes kun hvis deltagernr., CPR nr. og postnr. indtastes Testscenarie Én deltager oprettes pr. deltagernr. Testscenarie Kun postnumre i databasen kan indtastes Testscenarie Søgning i databasen er mulig Testscenarie Køn og alder kan inkluderes i søgningen 15.3 Test af kommunikation Formål Ved test af kommunikation testes det om, der kan oprettes forbindelse til databasen. Desuden skal der i kommunikation kunne genereres en csv-l indeholdende værdier fra en søgning. I len skal CPR-numre være skjulte. Det testes, at len kan åbnes i programmerne SPSS og Excel. Udførelse Forbindelsen til databasen testes ved, at metoden opretforbindelse() kaldes efterfulgt af en SQL forespørgsel, der indsætter værdier i databasen. Det tjekkes i databasen vha. phpmyadmin, om værdierne er overført. Hvis dette er tilfældet, vurderes det, at der er forbindelse til databasen. Samme test udføres ved deaktiveret internetforbindelse. Der genereres desuden en csv-l ud fra tilfældige værdier, der gemmes på skrivebordet og åbnes i de nævnte programmer, og det tjekkes, om CPR-nr. er skjult. 113

120 15. Test af undersystemer Resultater Værdierne i den genererede SQL forespørgsel blev overført til databasen som ventet, hvilket betyder, der var forbindelse til databasen. Ved samme test, hvor internetforbindelsen var deaktiveret blev en fejlmeddelelse vist for brugeren. Der blev genereret en csv-l, som blev gemt på den valgte lokation. Det var muligt at åbne denne i SPSS og Excel, og CPR-nr. var ikke i len. I Tabel 15.3 angives resultaterne for testscenarierne for at give et overblik over test af undersystemet Kommunikation. I tabellen angiver et ueben, at resultatet af testen er som forventet. Tabel 15.3: Oversigt over testsenarier indenfor undersystemet Kommunikation. Når resultatet af en test er som forventet, er det markeret i tabellen med et ueben. Testscenarie Testscenarie Testscenarie Testscenarie Kommunikation Oprettelse af forbindelse Generering af csv fil med værdier fra søgning Skjul CPR nr. i csv fil csv fil kan åbnes i Excel og SPSS 114

121 Kapitel 16 Test af use cases I dette kapitel udføres systemtest af systemet. Testen udføres på baggrund af de opstillede use cases, beskrevet i Kapitel 6 på side 35. Formålet med at teste systemet er at identicere fejl i koden. Der opstilles specikke instanser af hver enkelt use case for at teste denne. Til hver test beskrives; testudførelse, testdata, forventede resultater, samt testresultater Indtast data Testudførelse Use casen Indtast data testes for, om denne fungerer som ønsket, både ved standardscenarierne og ved uhensigtsmæssige hændelser. Standardscenarierne mellem bruger og databasesystem udføres som vist på Figur 16.1 på den følgende side. De uhensigtsmæssige hændelser skal håndteres, og dette testes ved at indtaste data for en deltager, som allerede eksisterer i databasen, og indtaste et postnr., som ikke eksisterer i databasen, hvorefter der trykkes på knappen OK i fanebladet Gem. 115

122 16. Test af use cases Bruger Databasesystem Vælg Indtast data Vis VelkomstGUI Vis IndtastGUI Indtast Deltagernr Tryk Find deltager? [Ja] Findes deltager? [Nej] [Nej] [Ja] Vis "Gå til Redigér" Indtast data Vis "Deltager findes ikke" Tryk Gem Vis Gem faneblad Tryk OK Gem i database Figur 16.1: Diagram over standardscenarierne for use casen Indtast data. Testdata Samme data benyttes under alle testscenarier, hvor deltagernr., CPR-nr., fornavn, efternavn, postnr. og by skal indtastes. Der benyttes både et deltagernr., der ikke eksisterer og et, der eksisterer for at teste begge standardscenarier på Figur Det postnr. og den by som indtastes skal eksistere i databasen medmindre andet er angivet i testudførelsen. 116

123 16.2. Redigér data Forventede resultater Standardscenarierne forventes at forløbe som vist på Figur 16.1 på modstående side, hvor knappen Find deltager skal kunne benyttes af brugeren til at undersøge, hvorvidt en deltager eksisterer, inden vedkommende begynder at indtaste data for den enkelte deltager. Det vil sige, at der skal vises en meddelelse for brugeren, når der trykkes på knappen. Det forventes desuden, at brugeren informeres om, at det ikke er muligt at indtaste data for en deltager, som allerede eksisterer, når der trykkes på knappen OK. Dette gælder også for indtastning af et postnr., som ikke eksisterer i databasen. Testresultater Standardscenarierne forløb som forventet, og data blev gemt korrekt i databasen. Brugeren blev desuden informeret om, at det ikke var muligt at indtaste data for en eksisterende deltager i databasen eller et ikke-eksisterende postnr.. I Tabel 16.1 angives resultaterne for testscenarierne for at give et overblik over test af use casen Indtast data. I tabellen angiver et ueben, at resultatet af testen er som forventet. Tabel 16.1: Oversigt over testsenarier for use casen Indtast data. Når resultatet af en test er som forventet, er det markeret i tabellen med et ueben. Indtast data Testscenarie Testscenarie Testscenarie Muligt at oprette en deltager Uhensigtsmæssige hændelser håndteres (deltageren eksisterer i databasen) Uhensigtsmæssige hændelser håndteres (postnr. som ikke eksisterer ) 16.2 Redigér data Testudførelse Use casen Redigér data testes for, om denne fungerer, som ønsket ved standardscenarierne. Der mellem bruger og databasesystem udføres som vist på Figur 16.2 på den følgende side. Derudover undersøges det, om det er muligt at slette en eksisterende deltager fra databasen ved at udtrække data fra en specik deltager, trykke på knappen Slet deltager og derefter tjekke samtlige tabeller i databasen for deltagernummeret på den pågældende deltager. 117

124 16. Test af use cases Bruger Databasesystem Vælg Redigér data Vis VelkomstGUI Vis RedigérGUI Indtast Deltagernr. Findes deltager? Tryk Find deltager [Nej] [Ja] Vis "Deltager findes ikke" Tryk OK Vis "Deltagernr og navn" Hent og vis data Foretag ændringer Tryk Gem Vis Gem faneblad Tryk OK Gem i database Figur 16.2: Diagram af standardscenarierne for use casen Redigér data. 118

125 16.3. Udtræk data Testdata Der benyttes to forskellige deltagernumre til at teste de to standardscenarier, et eksisterende og et ikke-eksisterende deltagernr. i databasen. Det eksisterende deltagernr. benyttes også til at teste knappen Slet Deltager. Forventede resultater Standardscenarierne forventes at forløbe som vist på Figur 16.2 på forrige side, hvor knappen Find deltager skal benyttes til at udtrække data fra en specik deltager, som skal redigeres, hvis denne eksisterer. Ellers skal brugeren meddeles om dette. Det forventes desuden, at de redigerede data gemmes i databasen. Når der trykkes på Slet deltager, forventes det, at deltagerens data slettes fra både brugergrænseaden og alle tabeller i databasen. Testresultater Standardscenarierne forløb som forventet, og når en deltager eksisterede og dennes data blev redigeret, blev disse gemt korrekt i databasen. Brugeren blev desuden oplyst om, at en deltager ikke eksisterede, hvis dette var tilfældet, når der blev trykket på knappen Find deltager. Knappen Slet deltager virkede også som ønsket, da en deltager blev slettet fra alle tabeller i databasen efter et tryk på knappen. I Tabel 16.2 angives resultaterne for testscenarierne for at give et overblik over test af use casen Redigér data. I tabellen angiver et ueben, at resultatet af testen er som forventet. Tabel 16.2: Oversigt over testsenarier for use casen Redigér data. Når resultatet af en test er som forventet, er det markeret i tabellen med et ueben. Testscenarie Testscenarie Redigér data Muligt at redigere en deltagers data Slet en eksisterende deltager 16.3 Udtræk data Testudførelse Use casen Udtræk data testes for, om denne fungerer som ønsket ved standardscenarierne. Der mellem bruger og databasesystem udføres som vist på Figur 16.3 på næste side. Desuden undersøges det om den l, der genereres ved udtrækning, kan åbnes i Excel og 119

126 16. Test af use cases SPSS ved at åbne len i begge programmer og sammenligne værdierne med værdier i databasen. Bruger Databasesystem Vælg Udtræk. data Vis VelkomstGUI Vis UdtrækGUIs Vælg søgekriterier Tryk Eksportér Vis Eksportér faneblad Tryk OK Findes søgning? [Ja] [Nej] Vis "Søgning ikke mulig" Vælg sti og navn for fil Vis datamappe Generér og gem fil Figur 16.3: Diagram over standardscenarierne for use casen Udtræk data. Testdata Et antal værdier vælges i forskellige faneblade til udtrækning ved alle testscenarier. Til undersøgelse af standardscenariet, hvor en søgning ikke er mulig, vælges søgekriterier ingen 120

127 16.3. Udtræk data deltagere opfylder. Forventede resultater Standardscenarierne forventes at forløbe som vist på Figur 16.3 på modstående side, hvor det skal meddeles brugeren, hvis en søgning ikke er mulig, når der trykkes på knappen OK i fanebladet Eksportér. Hvis søgningen er mulig, forventes det, at de udtrukne data kan gemmes i en l. Det forventes, at denne l er mulig at åbne i både Excel og SPSS indeholdende samme data som i databasen, hvor samme søgning er foretaget. Testresultater Standardscenarierne forløb som forventet og data blev korrekt udtrukket fra databasen og gemt i en l. Når en søgning ikke var mulig, blev brugeren informeret om dette. De genererede ler kunne åbnes både i Excel og SPSS med korrekte værdier og navne på søjlerne. I Tabel 16.3 angives resultaterne for testscenarierne for at give et overblik over test af use casen Udtræk data. I tabellen angiver et ueben, at resultatet af testen er som forventet. Tabel 16.3: Oversigt over testsenarier for use casen Udtræk data. Når resultatet af en test er som forventet, er det markeret i tabellen med et ueben. Udtræk data Testscenarie Testscenarie Testscenarie Muligt at udtrække data fra databasen Søgning ikke mulig, hvis værdierne ikke er i databasen Muligt at åbne genereret csv fil i Excel og SPSS 121

128

129 Del VIII Syntese I denne del vurderes det færdige databasesystem. Det sker gennem status i forhold til en kravspecikation fra Region Sjællands Befolkningsundersøgelse, diskussion, konklusion og perspektivering. Herunder opsummeres eventuelle fejl og mangler, samt hvilke ændringer og forbedringer, der bør foretages på databasesystemet. Dette er både på det rent tekniske niveau, men også set i forhold til den direkte anvendelse i Region Sjællands Befolkningsundersøgelse.

130

131 Kapitel 17 Status i forhold til kravspecikation fra Region Sjællands Befolkningsundersøgelse I dette kapitel gøres status på det udviklede databasesystem set i forhold til det lagringssystem styregruppen for Region Sjællands Befolkningsundersøgelse ønsker. Efter implementering af databasesystemet er projektgruppen blevet gjort opmærksom på, at styregruppen for Region Sjællands Befolkningsundersøgelse har udarbejdet en kravspecikation, se Bilag A. Da kravspecikationen er modtaget sent i forløbet, imødekommer det udviklede databasesystem ikke specikt disse krav, men de krav, der er givet udtryk for i mailudveksling med styregruppen for befolkningsundersøgelsen Funktionelle krav I det følgende opstilles de funktionelle krav fra styregruppen for Region Sjællands Befolkningsundersøgelse samtidig beskrives det, hvorvidt de er opfyldt. Systemet skal kunne fremnde en specik borger, hente oplysninger om borgere fra DPR/CPR og anonymisere en borgers undersøgelsesresultater Systemet understøtter, at der kan hentes oplysninger om en deltager ud fra et CPRnr.. Dette er opnået ved at implementere en tabel i databasen, der kobler deltagernr. sammen med CPR-nr. og ved at deltagernr. benyttes som nøgle i de resterende tabeller. Dette gør det muligt at fremnde en specik deltager. Desuden er der dermed grundlag for at anonymisere deltagernes spørgeskemabesvarelser, hvilket systemet på nuværende tidspunkt ikke understøtter, da det stadig er muligt at udtrække navn og adresse på deltagerne. Systemet skal stille rådata i databasen direkte til rådighed for andre systemer, f.eks. STATA, SAS, SPSS. Ved hjælp af systemets use case Udtræk data kan rådata fra databasen åbnes i andre systemer som Excel, SPSS, SAS eller STATA som en csv-l. Da kun Excel og SPSS har været til rådighed i projektet er det kun testet, at len kan åbnes i disse programmer. Men 125

132 17. Status i forhold til kravspecikation fra Region Sjællands Befolkningsundersøgelse det formodes, at len ligeledes kan åbnes i de to andre programmer, da disse programmer understøtter csv-ler. Systemet skal vise indkaldelsesstatistik og generere og udskrive indkaldelsesbreve og genindkaldelsesbreve. Systemet kan ikke generere og udskrive indkaldelses- og genindkaldelsesbreve eller vise indkaldelsesstatistik. Der er dog implementeret felter til at indtaste fremmødedato, genindkaldelsesdato samt dato for første og anden indkaldelse. Desuden er der mulighed for at angive dødsfald i databasen. Disse felter i databasen kan benyttes til at skabe de ønskede funktionaliteter angående generering af indkaldelsesbreve og statistik. Systemet skal kunne håndtere borgeres ønske om fravalg af deltagelse eller ønske om senere deltagelse Det er ikke muligt at registrere, om en borger ønsker at deltage, ikke deltager eller først deltager senere. Dette burde implementeres i systemet ved at indføre felter til dette i databasen. Værdierne i disse felter skal så benyttes som betingelser, når der genereres indkaldelsesbreve. Systemet skal indhente data fra scannede vandresedler, spørgeskemaer og samtykkeerklæringer I systemudviklingen har der ikke været adgang til Optical character recognition eller det medicotekniske udstyr, der skal benyttes ved befolkningsundersøgelsen, har det ikke været muligt at implementere use casen Overfør data, og det er dermed ikke muligt at overføre målinger osv. elektronisk. Systemet skal modtage laboratoriesvar gennem webservice og systemet skal understøtte vedligeholdelse af grænseværdier og genere og udskrive svarbreve på baggrund af disse. Det er valgt kun at implementere den del af systemet, der har med data fra spørgeskemaundersøgelsen at gøre, da helbredsundersøgelsen og undersøgelsen af biokemiske data ikke var endelige udformede ved projekt start. Derfor eksisterer håndtering af laboratoriesvar og understøttelse af grænseværdier vedrørende fysiske helbredsparametre ikke. Systemet skal anvendes til undersøgelser på andre geograer Databasesystemet er udviklet således, det kan videreudvikles og udvides, hvorfor det vurderes, at et færdigudviklet system kan bruges på andre geograer. Dette er muligt, fordi systemet er udviklet vha. metoden UP, som netop er en iterativ proces. På Figur 17.1 på modstående side ses en oversigt over de funktionelle krav, der er implementeret i det udviklede databasesystem set i forhold til de opstillede funktionelle krav fra Region Sjællands Befolkningsundersøgelse. På guren angiver et ueben, at det funktionelle krav er implementeret, en pil angiver, at der er fundament for implementering og et kryds angiver, at det ikke er implementeret. 126

133 17.2. Ikke-funktionelle krav Krav fra Region Sjællands Befolkningsundersøgelse Implementeret funktionalitet Funktionelle krav Systemet skal kunne fremfinde en specifik borger Systemet skal hente oplysninger om borgere fra DPR/CPR Systemet skal kunne anonymisere en borgers undersøgelsesresultater Systemet skal stille rådata i databasen direkte til rådighed for andre systemer, f.eks. STATA, SAS, SPSS. Systemet skal generere og udskrive indkaldelsesbreve Systemet skal generere og udskrive genindkaldelsesbreve Systemet skal vise indkaldelsesstatistik Systemet skal kunne håndtere borgeres ønske om fravalg af deltagelse Systemet skal håndtere borgeres ønske om senere deltagelse Systemet skal indhente data fra scannede vandresedler, spørgeskemaer og samtykkeerklæringer Systemet skal understøtte vedligeholdelse af grænseværdier Systemet skal generere og udskrive svarbreve på baggrund af grænseværdier Systemet skal modtage laboratoriesvar gennem webservice Systemet skal anvendes til undersøgelser på andre geografier Figur 17.1: Oversigt over hvad der er implementeret i forhold til de funktionelle krav i kravspecikation fra Region Sjællands Befolkningsundersøgelse. Et ueben angiver, at kravet er implementeret, en pil, at der er skabt fundament for implementering af kravet og et kryds, at det ikke er implementeret Ikke-funktionelle krav Styregruppen har desuden opstillet en række ikke funktionelle krav til systemet, som omhandler bl.a. programmeringssprog, valg af database og adgangskontrol. Disse krav behandles nedenfor. De resterende ikke-funktionelle krav er ikke blevet behandlet i projektet, men de kan evt. læses i Bilag A. Systemet skal udvikles i MS.NET 3.5, C# og systemets database skal baseres på MS SQL 2005 I det foreliggende projekt er størstedelen af systemet implementeret i Java ved brug af programmet NetBeans IDE. Da kravet til udviklingssprog er C#, kan det udviklede databasesystem ikke direkte overføres. Dog kan dokumentationen af systemudviklingen til og med design anvendes. Databasen i det foreliggende projekt er udviklet som en MySQL database, hvorimod databasen til lagring af data fra befolkningsundersøgelsen er planlagt til at være en MS SQL Det udviklede databasesystem er derfor ikke direkte overførbar til brug ved Region Sjællands Befolkningsundersøgelse, men da MS SQL også er en relationel database kan modelleringen af MySQL databasen direkte overføres. Systemet skal overholde gældende lovgivning vedrørende beskyttelse af føl- 127

134 17. Status i forhold til kravspecikation fra Region Sjællands Befolkningsundersøgelse somme persondata, og skal logge alle pålogninger og pålogningsforsøg. Det er en vigtig udvidelse af systemet at implementere adgangskontrol, da lovgivningen kræver en nøgle, der kobler data med en bestemt deltager. I systemet, udviklet i det foreliggende projekt, er deltagernes CPR-numre adskilt fra de resterende data med deltagernr. som nøgle, hvormed der er basis for at anonymisere data. På nuværende tidspunkt er al data tilgængelige for samtlige brugere, da log ind funktionen ikke er indbygget. Adgangen til data kan tilpasses den enkeltes rettigheder vha. forskellige log inds, hvormed den nødvendige sikkerhed opnås. En mulig løsningsmodel er at adgangen til databasesystemet sker gennem det oentlige digitale certikat, betegnet digital signatur, samt igennem et lukket netværk. Dermed kan brugernes adfærd, pålogninger og pålogningsforsøg også logges. På Figur 17.2 ses en oversigt over de ikke-funktionelle krav, der er implementeret i det udviklede system set i forhold til de opstillede krav fra Region Sjællands Befolkningsundersøgelse. På guren angiver et kryds, at ikke-funktionelle krav ikke er implementeret. Krav fra Region Sjællands Befolkningsundersøgelse Ikke funktionelle krav Implementeret funktionalitet Systemets database skal baseres på MS SQL 2005 Systemet skal udvikles i MS.NET 3.5, C# Systemet skal overholde gældende lovgivning vedrørende beskyttelse af følsomme persondata, og skal logge alle pålogninger og pålogningsforsøg. Figur 17.2: Oversigt over hvad der er implementeret i forhold til de ikke-funktionelle krav i kravspecikation fra Region Sjællands Befolkningsundersøgelse. Et kryds angiver, at det ikke er implementeret. 128

135 Kapitel 18 Diskussion Formålet med det foreliggende projekt er at analysere, designe og implementere et databasesystem bestående af en grunddatabase og en brugergrænseade til brug ved Region Sjællands Befolkningsundersøgelse. Designet af databasesystemet er sket på baggrund af et subjektivt spørgeskema sendt til borgerne i Næstved Kommune, samt projektgruppens egne overvejelser. Databasen er modelleret ud fra en standardmetode kaldet ER-modellering. Programmeringssproget Java bruges til at implementere brugergrænseaden, hvorfor udviklingsmetoden UP anvendes, da den understøtter den objektorienterede udvikling. Til at dokumentere UP anvendes modelleringssproget UML. Resultatet er, at brugeren vha. databasesystemet har mulighed for at oprette en deltager og indtaste data relateret til denne, samt redigere data. Desuden er det muligt at udtrække data ud fra valgte søgekriterier. Databasesystemet er udviklet på baggrund af mailudveksling med styregruppen for Region Sjællands Befolkningsundersøgelse. Det har vha. denne metode været muligt at kontakte styregruppen, så snart spørgsmål er opstået. Det har været en fordel med mails fremfor telefonopkald, da projektgruppen efterfølgende har kunnet læse disse mails. Der er dog den ulempe, at der kan opstå misforståelser, når der korresponderes over mail i stedet for at mødes ansigt til ansigt. Det kunne især have været fordelagtigt med et møde i begyndelsen af projektperioden, hvor projektgruppen kunne have udvekslet ideer med og modtaget informationer fra styregruppen, hvilket ville tildele projektgruppen en væsentlig baggrundsviden allerede fra begyndelsen. Der er i slutningen af udviklingen af databasesystemet udført tests på både undersystemer og use cases. Det er undersøgt, om undersystemerne fungerer som ønsket og at alle funktionaliteter i use casene virker efter hensigten. Disse tests viser, at det med databasesystemet er muligt at udføre alle de funktionaliteter, som er designet og implementeret. Det er dog muligt at oprette en deltager uden deltagernr., CPR-nr., navn, postnr. og by i undersystemet database, hvorfor disse begrænsninger er udviklet i brugergrænseaden. Databasesystemet er designet med henblik på anvendelse af forskere og klinikere. Lo-Fi prototypen af brugergrænseaden er ikke testet på disse brugere, men systemet er forsøgt designet således, det er intuitivt, og det i sin basale form har samme opbygning som 129

136 18. Diskussion adskillige almene computerapplikationer. Der er ikke udført en accepttest af databasesystemet, da databasesystemet endnu ikke er udviklet til det formål, styregruppen ønsker. En accepttest burde senere udføres af styregruppen for Region Sjællands Befolkningsundersøgelse for at vericere, at databasesystemet opfylder deres krav. Der diskuteres i det følgende på resultater opnået gennem det foreliggende projekt. Brugergrænseaden er designet ud fra det udleverede spørgeskema, der er inddelt i kategorier bestemt af styregruppen. Spørgeskemaet indeholder få spørgsmål, der ikke umiddelbart passer ind under kategorierne. Alligevel har styregruppen placeret disse i en kategori. For eksempel indeholder kategorien Sygdom spørgsmål omhandlende bloddonor, vægt ved fødsel og vægt som 20-årig. Denne opdeling virker ikke logisk, da det at være bloddonor ikke kan betegnes som en sygdom. Ligeledes kan vægten på en person ikke beskrives som en sygdom, men som en mulig medvirkende årsag til en sygdom. Databasesystemet er alligevel udarbejdet på baggrund af spørgeskemaet, da det vurderes at fremtidige brugere kan drage fordel af dette. En anden overvejelse er, at forskerne bør være opmærksomme på, at data indsamlet fra spørgeskemaerne er subjektive og folk kan have tendens til at give mere positive svar. Der er nogle funktionaliteter i brugergrænseaden, som i visse tilfælde ikke skal kunne lade sig gøre. Eksempelvis bliver en deltagers data slettet fuldstændig ved frameldelse af befolkningsundersøgelsen. Men dette bør kun ske i de tilfælde en deltager har oplyst dette på samtykkeerklæringen, ellers skal kun personhenførbare oplysninger slettes fra databasen. Databasesystemet er designet, så brugeren har mulighed for at indtaste og udtrække en enkelt værdi i hver liste eller samtlige værdier i ere lister. Denne funktionalitet er uhensigtsmæssig i forhold til udtrækning af data, hvor det tit vil være fordelagtig at kunne vælge ere værdier i en liste. For eksempel at udtrække både økologiske grøntsager og overvejende økologiske grøntsager. Udtrækningsfunktionaliteten er implementeret således, at når en bruger vælger de ønskede søgekriterier, fremndes de deltagere, der opfylder disse, og foruden de fælles værdier gemmes deltagernes andre værdier også i en l. Dermed kan andre ukendte fællestræk opdages, hvis alle værdier medtages. Omvendt er det uhensigsmæssigt i det tilfælde, at brugeren kun vil foretage analyse på de valgte søgekriterier, hvorved denne er nødsaget til at slette de resterende værdier manuelt. Databasesystemet er som nævnt udviklet på baggrund af mailudveksling med styregruppen for Region Sjællands Befolkningsundersøgelse, hvorfor ere af de ønskede funktionelle og ikke-funktionelle krav fra styregruppen til databasesystemet ikke er opfyldt. Derfor er brugergrænseaden i sin nuværende form sandsynligvis ikke brugbar for styregruppen. 130

137 Det betyder at de dele af projektet, der kan overføres til Region Sjællands Befolkningsundersøgelse er use cases, aktivitetsdiagrammer, analyse og design af databasesystemet, herunder analyse og modellering af databasen. 131

138

139 Kapitel 19 Konklusion Ved Region Sjællands Befolkningsundersøgelse skal der i første omgang opsamles data fra deltagere. Det betyder, der skal benyttes et system til lagring og udtrækning af data. Disse data består samlet i data fra subjektive spørgeskemabesvarelser, data fra objektive helbredsundersøgelser, samt biokemiske data. Formålet hermed er på længere sigt at give et datagrundlag, der kan bidrage med viden om sundhedstilstande, risikofaktorers indvirkning på sygdomme og arveligheden af kroniske sygdomme. Denne viden skal være med til forbedre forebyggelsen af sygdomme. Som løsning er et databasesystem udviklet, som består af en grunddatabase og en brugergrænseade, hvorigennem databasen kan tilgås. Grunddatabasen er udviklet i MySQL og modelleret vha. metoden ER-modellering og brugergrænseaden er udviklet i Java vha. den iterative metode UP, som er realiseret igennem sproget UML. Udviklingen er gennemgået ved en række forskellige workows. Der er først blevet opstillet krav til databasesystemet, derefter er der lavet en analyse af disse krav for at denere databasesystemets funktionaliteter. Dernæst er tre use cases, Indtast data, Redigér data og Udtræk data, blevet designet og implementeret. Som evaluering af dette arbejde er der foretaget en række tests af databasesystemet. Tests af det færdige databasesystem er opstillet på baggrund af testscenerier for hver use case, som viser, at databasesystemet fungerer som ønsket. Brugeren kan vha. det udviklede databasesystem håndtere data fra en udvalgt del af det subjektive spørgeskema. Spørgeskemaet blev valgt, da de to andre områder ikke var endeligt denerede fra styregruppens side ved projektstart. Databasesystemet er udviklet, så det kan udbygges til at håndtere alle oplysninger fra spørgeskemaet og de to andre områder pga. metoden UP. Databasesystemet understøtter, at brugeren indtaster deltagernes data manuelt i databasesystemets brugergrænseade. Data lagres herefter i en relationel database, der er opdelt i 9 tabeller. Styregruppen ønsker elektronisk overførsel af data fra spørgeskema vha. et scanningsprogram. Dette har der, i det foreliggende projekt, ikke været adgang til, hvorfor denne integrering ikke er implementeret. 133

140 19. Konklusion Databasesystemet understøtter, at brugeren henter en deltagers data frem i brugergrænse- aden ved at søge på et deltagernr. og det er muligt at ændre, slette eller indtaste y- derligere data. Data udtrækkes fra databasen ved, at brugeren udvælger specikke søgekriterier fra brugergrænseaden. De udvalgte kriterier kombineres og data eksporteres til en csv-l, der kan åbnes i diverse eksterne programmer til videre databehandling. Det udviklede databasesystem skal ikke betragtes som en færdig løsning til Region Sjællands Befolkningsundersøgelse, men som et system, der kan udbygges, således styregruppens krav opfyldes. 134

141 Kapitel 20 Perspektivering Implementering og anvendelse af databasesystemet til Region Sjællands Befolkningsundersøgelse kan betegnes som et realistisk fremtidsmål, men det vil kræve videreudvikling. Sikkerheden ved dataoverførslen skal forbedres ved, at data sendes krypteret mellem k- lient og database. For eksempel ved implementering af en netværksprotokol som Secure Shell eller Secure Sockets Layer. Herved forhindres det, at der opstår man-in-the-middle attack, hvor en anden computer kan læse al information, der sendes over netværket. Yderligere burde et backup-system implementeres, således data ikke kan gå tabt. Når sikkerheden og alle use cases er implementeret i systemet, vil det næste skridt i systemudviklingen være at udføre en accepttest, hvor fx en gruppe klinikere afprøver systemet ved at overføre og redigere data, og lade en gruppe forskere udtrække data for at vericere om systemet opfylder kravene. Testen vil også kunne afsløre anvendeligheden og brugervenligheden af systemet, samt hvordan det vil fungere i praksis. På baggrund af testen kan kravene til systemet efterfølgende modiceres, således at næste iteration af systemet bedre afspejler brugernes behov og ønsker. Med et system, der fungerer som ønsket, kan samme brugergrænseade og database benyttes af samtlige kommuner i Region Sjælland. Dette er muligt, da det er de samme parametre, der skal opsamles for alle deltagere i alle kommuner ved denne befolkningsundersøgelse. Da ere personer kan benytte databasen på samme tid, kan dataopsamlingen foregå parallelt og dermed eektiviseres dataopsamlingen. Et andet område, hvorpå dataopsamlingen kan eektiviseres, er at give deltagerne mulighed for at besvare spørgeskemaet elektronisk. Ved at digitalisere spørgeskemaet kan svarene lagres direkte i databasen samtidig med, at klinikerne undgår at skulle scanne disse ind, hvormed der spares tid. Forskning, der udnytter data fra befolkningsundersøgelser kan bidrage med viden om risikofaktorers indvirkning på kroniske sygdomme, hvormed data fra deltagerne i Region Sjælland benyttes til planlægning og overvågning af sygdomsforebyggelse og sygdomsfremme indenfor regionen. Der kan være geograske forskelle i udbredelsen af risikofaktorer, men da Danmark er et 135

142 20. Perspektivering forholdsvist lille og homogent land, vil national viden om risikofaktorer have betydning for den enkelte kommune. For at undersøge eventuelle ændringer i risikofaktorer over tid vil det være fordelagtigt, at befolkningsundersøgelser er sammenlignelige. Samtidig bør der stadig udføres nye befolkningsundersøgelser, da de forrige befolkningsundersøgelser ikke er designet til samme formål, hvorved der med nye befolkningsundersøgelser belyser nye potentielle risikofaktorer. Opsamlingsparametrenes domæner bør være specikt denerede for at forskellige befolkningsundersøgelser kan sammenlignes eller kombineres og dermed højne kvaliteten af information og øge informationsmængden. Et eksempel herpå er et af spørgsmålene angående tempo ved gang, cykel, løb og anden sport i spørgeskemaet under fysisk aktivitet fra Region Sjællands Befolkningsundersøgelse, hvor deltageren har svarmulighederne langsomt, almindeligt, hurtigt og meget hurtigt. Disse domæner er ikke målbare, da det er en subjektiv opfattelse af, hvad denitionen på fx langsomt er. At standardisere parametrenes domæner kan muligvis gavne forskningen, idet det subjektive bias i resultaterne mindskes og gør forskernes resultater mere sammenlignelige. 136

143 LITTERATUR Litteratur [Database - Advantages & Disadvantages, 2009] Database - Advantages & Disadvantages (2009). Database - advantages & disadvantages. html. 21. februar [Datatilsynet, 2009] Datatilsynet (2009). Lov om private registre m.v. datatilsynet.dk/international/groenland/lov-om-private-registre-mv. 19. februar [Eriksson et al., 2004] Eriksson, H.-E., Penker, M., Lyons, B., and Fado, D. (2004). UML 2 Toolkit. Wiley. [Jensen et al., 2006] Jensen, J. P., Mogensen, F. D., and Zangenberg, P. (2006). Informationsteknologi B/A1. Systime, 1 edition. [Microsoft Developer Network, 2006] Microsoft Developer Network (2006). grid"and increased limits in excel library/aa aspx. 26. maj The "big [Nielsen and Waaben, 2001] Nielsen, K. K. and Waaben, H. (2001). Lov om behandling af personoplysninger. [Nyt fra Danmarks Statistik, 2003] Nyt fra Danmarks Statistik (2003). Danmark har fortsat relativ lav middellevetid. pdf. 1. marts [Osler and Jørgensen, 2004] Osler, M. and Jørgensen, T. (5. april 2004). Befolkningsundersøgelsers bidrag til forskning i folkesygdomme med fokus på danske kohorter. Ugeskrift for læger, 15: [Sharp et al., 2007] Sharp, H., Rogers, Y., and Preece, J. (2007). Beyond Human-Computer Interaction. Wiley. Interaction Design: 137

144 LITTERATUR [Silberschatz et al., 2005] Silberschatz, A., Korth, H., and Sudarshan, S. (2005). Database system concepts. [Sundhedsstyrelsen, 2007] Sundhedsstyrelsen (marts 2007). Rapport: Forebyggelse og sundhedsfremme i kommunen - en vejledning til Sundhedslovens Ÿ119 stk. 1 og 2. [Tomida, 2006] Tomida, G. (2006). Why and when to use a database. http: //e-articles.info/e/a/title/why-and-when-to-use-a-database/. 21. februar [Udvalgene vedrørende Videnskabelig Uredelighed, 2009] Udvalgene vedrørende Videnskabelig Uredelighed (Januar 2009). Rapport: Vejledning i god videnskablig praksis med særlig fokus på sundhedsvidenskab, naturvidenskab og teknisk videnskab. [View, 2009] View, S. (2009). Structure of a database application. net/infosystems/dbms/dbms.html. 6. maj [ architecture.com, 2009] architecture.com (2009). Acid properties. properties.html. 20. maj

145 Appendix

146

147 Appendix A Udspecicering af Entitets-Relationsdiagram I det følgende udspeciceres ER-diagrammet fra Kapitel 5. Dette gøres ved at præsenterer entitetsklasserne med deres tilhørende attributter, hvorefter de normaliserede relationer præsenteres. Følgende entitetsklasser ndes i dette appendix; Læge, Spørgeskema, Kost og drikkevarer, Fysisk aktivitet, Sygdom, Medicin, Ophold i solen, Kvinder, Rygning, Uddannelse, erhverv og bopæl, Trivsel og velbendende, og AP-skema. Dermed skal dette appendix opfattes som et supplement til Kapitel 5 på side 25. En udspecicering af det overordende ER-diagram fra Kapitel 5 vises for hver entitetsklasse, hvormed attributterne er medtaget. Under hver specikation ndes den normaliserede relation for den pågældende entitetsklasse. Attributterne til entitetsklassserne er baseret direkte på de spørgsmål, der er stillet i spørgeskemaet til Region Sjællands Befolkningsundersøgelse, se Bilag C. For eksempel er attributten øko. mælk i entitetsklassen Kost og drikkevarer ikke opdelt i ere slags mælk, da den på spørgeskemaet ikke indgår i spørgsmål vedrørende mælk, men spørgsmål angående økologiske fødevarer. Læge Figur A.1 viser entitetsklassen Læge. Adresse Navn Deltagernr. Antal indlæggelser Læge Antal special lægebesøg Antal skadestuebesøg Antal praktiserende lægebesøg Figur A.1: Udspecicering af ER-diagrammet for Entitetsklassen Læge. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. 141

148 A. Udspecicering af Entitets-Relationsdiagram 1. normaliseringstrin I 1. normaliseringstrin opdeles de attributter, der ikke er atomare, såsom Navn, der kan nedbrydes i Fornavn og Efternavn, samt Adresse, der bliver til Gade, Husnr., Postnr. og By. På Figur A.2, ses overgangen fra oprindelig relation til 1. normalform for entitetsklassen Læge. Læge Oprindelig relation Deltagernr Navn Adresse Antal skadestuebesøg Antal indlæggelser Antal praktiserende lægebesøg Antal speciallægebesøg Læge 1. normalform Deltagernr Fornavn Efternavn Gade Husnr Postnr By Antal skadestuebesøg Antal indlæggelser Antal praktiserende lægebesøg Antal speciallægebesøg Figur A.2: Oprindelig relation for entitetsklassen Læge. 2. normaliseringstrin Relationen er allerede på 2. normalform, da der ikke er partiel afhængighed mellem attributterne. 3. normaliseringstrin I 3. normaliseringstrin sørges for at ingen ikke-nøgle-attributter er afhængige af hinanden, fx er By afhængig af Postnr., hvorfor en ny relation oprettes indeholdende Postnr. og By. Samtidig beholdes den relation, der er på 2. normalform, hvor attributten By fjernes, se Figur A.3 på næste side. For de resterende entitetsklasser gælder at deres oprindelige relationer opfylder alle tre normalformer, hvorfor normaliseringen af disse relationer ikke vises i det følgende. Spørgeskema På Figur A.4 på modstående side ses den udspecicerede entitetsklasse Spørgeskema. 142

149 Læge 2. normalform Deltagernr Fornavn Efternavn Gade Husnr Postnr By Antal skadestuebesøg Antal indlæggelser Antal praktiserende lægebesøg Antal speciallægebesøg PostnrBy 3. normalform Postnr By Læge 3. normalform Deltagernr Fornavn Efternavn Gade Husnr Postnr Antal skadestuebesøg Antal indlæggelser Antal praktiserende lægebesøg Antal speciallægebesøg Figur A.3: Efter 1. normaliseringstrin er relationene allerede på 2. normalform. I tabellen ses overgangen fra 2. til 3. normalform Deltagernr. Dato Spørgeskema Figur A.4: Udspecicering af ER-diagrammet for Entitetsklassen Spørgeskema. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklassen Spørgeskema kan ses på Figur A.5. Normaliseringen Spørgeskema Oprindelig relation Deltagernr Dato Figur A.5: Oprindelig relation for entitetsklassen Spørgeskema. Relationen er allerede på 3. normalform, hvilket vil sige at alle attributter er fuldstændigt afhængige af primærnøglen og ikke-nøgle-attributter ikke afhænger af hinanden. af relationen dokumenteres ikke, da den oprindelige relation overholder kravene om at være på 3. normalform. Kost og drikkevarer Figur A.6 på den følgende side viser entitetsklassen Kost og drikkevarer. 143

150 A. Udspecicering af Entitets-Relationsdiagram Deltagernr. Sødmælk Laktosefri mælk Kærnemælk Øko. ris, pasta Skummetmælk Let-/minimælk Kaffe Thé Øko. fisk Sodavand m. sukker Øko. fisk Sodavand u. sukker Øko. kød Øl Øko. brød, gryn, musli Hvidvin Øko. mælk Rødvin Hedvin/likør Øko. frugt Spiritus Øko. grøntsager Kost og drikkevarer Alkopops Æg Morgenmad Frugt Frokost Grøntsager Aftensmad Feststof v. tilberedning Antal mellemmåltider Fastfood Rugbrød Lam Hvidt brød Okse/kalvekød Fjerkræ Ost Leverpostej Fedtstof på brød Fisk Svinekød Fiskepålæg Kødpålæg Figur A.6: Udspecicering af ER-diagrammet for Entitetsklassen Kost og drikkevarer. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. 144

151 Den oprindelige relation for entitetsklasse Kost og drikkevarer er vist på Figur A.7. Kost og drikkevarer Oprindelig relation Deltagernr Sødmælk Skummetmælk Laktosefri mælk Let-/minimælk Kærnemælk Kaffe Thé Sodavand m. sukker Sodavand u. sukker Øl Hvidvin Rødvin Hedvin/likør Spiritus Alcopops Morgenmad Frokost Aftensmad Mellemmåltider Rugbrød Kost og drikkevarer Fortsat Hvidt brød Fedtstof på brød Kødpålæg Leverpostej Fiskepålæg Ost Okse/kalvekød Svinekød Fjerkræ Fisk Lam Fastfood Fedtstof v. tilberedning Grøntsager Frugt Æg Øko grøntsager Øko frugt Øko mælk Øko brød, gryn, musli Øko kød Øko fisk Øko æg Øko ris, pasta Figur A.7: Den oprindelig relation for entitetsklassen Kost og drikkevarer. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 145

152 A. Udspecicering af Entitets-Relationsdiagram Fysisk aktivitet Den udspecicerede entitetsklasse Fysisk aktivitet ses på Figur A.8. Cykeltempo Løbetempo Tempo under andet sport Transport til og fra arbejde Deltagernr. Antal timers andet sport Gangtempo Aktivitet ved job Tunge løft Antal timers løb Fysisk aktivitet Aktivitet i fritid Antal timers cykling Antal timers gang Aktivitetens lokation Vægtløftning Muskelstyrke bedømmelse Ændringer i motionsvaner Konditionsbedømmelse Figur A.8: Udspecicering af ER-diagrammet for Entitetsklassen Fysisk aktivitet. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklasse Fysisk aktivitet er vist på Figur A.9. Fysisk aktivitet Oprindelig relation Deltagernr Aktivitet ved job Tunge løft Aktivitet i fritid Vægtløftning Aktivitetens lokation Ændringer i motionsvaner Konditionsbedømmelse Muskelstyrkebedømmelse Fysisk aktivitet Fortsat Antal timers gang Antal timers cykling Antal timers løb Antal timer anden sport Løbetempo Gangtempo Tempo under anden sport Cykeltempo Transport til og fra arbejde Figur A.9: Den oprindelig relation for entitetsklassen Fysisk aktivitet. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 146

153 Sygdom Figur A.10 viser entitetsklassen Sygdom. Udsat for støv/svejserøg på arbejde Dyrehårallergi Medicinallergi Lungebetændelse Eksem Åreknuder debut Galdesten Fødevareallergi Astma Pollenallergi Høfeber Åreknuder Deltagernr. Blodprop i hjernen/hjerneblød ning Smerte i et ben/begge ben ved begyndende gang Blodprop uden indlæggelse Smerte i et ben/begge ben efter lidt gang Indlæggelse for blodprop i hjertet Lammelser/Nedsat kraft/styringsbesvær Blodprop i ben Blindhed/ Synstab Arvelig tendens til blodprop Taleforstyrrelser Blodprop i lunge Sygdom Pibende/Hvæsende vejrtrækning uden kendt årsag Smerte i bryst ved let anstrengelse Hoster slim Kræft Pibende/Hvæsende vejrtrækning ved anstrengelse Akut febersygdom/bronkitis/blærebetændelse Ballonudvidelse i hjertet Hoste ved anstrengelse Bypassoperation i hjertet Pibende/Hvæsende vejrtrækning ved forkølelse Højt stofskifte Åndenød i hvile Behov for stop ved eget tempo Forpustet ved travlhed på gaden eller bakke Antal år som bloddonor Antal tapninger bloddonor Vægt som 20-årig Lavt stofskifte Generelt åndenød Vågner pga. åndenød om natten Forpustet ved alm. gang med jævnaldrende Forpustet ved vask/påklædning Bloddonor Sukkersyge Vægt ved fødsel Figur A.10: Udspecicering af ER-diagrammet for Entitetsklassen Sygdom. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. 147

154 A. Udspecicering af Entitets-Relationsdiagram Den oprindelige relation for entitetsklasse Sygdom er vist på Figur A.11. Sygdom Oprindelig relation Deltagernr Blodprop i hjernen/hjerneblødning Smerte i et ben/begge ben i begyndelsen ved gang Smerte i et ben/begge ben efter lidt gang Lammelser/Nedsat kraft/styringsbesvær Blindhed/Synstab Taleforstyrrelser Akut febersygdom/ Bronkitis/ Blærebetændelse Smerte i bryst ved let anstrengelse Indlæggelse for blodprop i hjertet Blodprop uden indlæggelse Bypassoperation i hjertet Ballonudvidelse i hjertet Sygdom Fortsat Forpustet ved travlhed på gaden eller bakke Forpustet ved alm. gang med jævnaldrende Forpustet ved vask/påklædning Behov for stop ved eget tempo Sukkersyge Vågner pga. åndenød om natten Åndenød i hvile Generel åndenød Hoste ved anstrengelse Hoster slim Pibende/Hvæsende vejrtrækning ved forkølelse Pibende/Hvæsende vejrtrækning ved anstrengelse Pibende/Hvæsende vejrtrækning uden kendt årsag Sygdom Fortsat Fødevareallergi Medicinallergi Pollenallergi Dyrehårallergi Høfeber Eksem Astma Udsat for støv/svejserrøg på arbejde Lungebetændelse Vægt ved fødsel Kræft Galdesten Blodprop i ben Blodprop i lunge Bloddonor Antal tapninger bloddonor Antal år som bloddonor Arvelig tendens til blodprop Åreknuder Åreknuder debut Lavt stofskifte Højt stofskifte Vægt som 20 årig Figur A.11: Den oprindelig relation for entitetsklassen Sygdom. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 148

155 Medicin På Figur A.12 ses den udspecicerede entitetsklasse Medicin. Deltagernr. Slankepiller Antal år med blodtrykspiller Antal år med hjertemedicin Piller/dråber mod øjensygdom Antal år med piller/dråber mod øjensygdom Andre piller Antal år med slankepiller Blodtrykspiller Hjertemedicin Antal år med vanddrivende medcin Medcin mod forhøjet kolesterol Antal år med andre piller Vanddrivende medcin Antal år med medcin mod forhøjet kolesterol Antal år med potensmidler Potensmidler Gigtpiller Medicin mod lavt stofskifte Antal år med gigtpiller Antal år med Medicin mod lavt stofskifte Sovepiller Antal år med m edicin mod forhøjet stofskifte Antal år med medicin mod alkoholisme Medicin mod forhøjet stofskifte Medicin mod alkoholisme Antal år med sovepiller Antal år med n ervepiller eller beroligende piller Nervepiller eller beroligende piller Medicin mod mavesyre Antal år med antidepressiv medicin (lykkepiller) Antal år med blodfortyndende (marevan, marcumar, heparin) Antidepressiv medicin (lykkepiller) Blodfortyndende (marevan, marcumar, heparin) Blodfortyndende (magnyl) Medicin Antal år med medicin mod mavesyre Antal år med m edicin mod astma/bronkitis Antal år med insulin Medicin mod astma/bronkitis Insulin Antal år med blodfortyndende (magnyl) Antal år med jern-tilskud Kalk-tilskud Jern-tilskud Antal år med P-piller Anden sukkersyge medicin Antal år med anden sukkersyge medicin P-piller Antal år med kalk-tilskud Medicin mod knogleskørhed Antal år med vitaminpiller Antal år med binyrebarkhormon Binyrebarkhormon Antal år med m edicin mod knogleskørhed Antal år med D-vitamin Antal år med naturmedicin Antal år med smertestillende piller/medicin Hormonbehandling ved menopause D-vitamin Naturmedicin Vitaminpiller Smertestillende piller/medicin Antal år med hormonbehandling ved menopause Figur A.12: Udspecicering af ER-diagrammet for Entitetsklassen Medicin. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklasse Medicin er vist på Figur A.13 på næste side. 149

156 A. Udspecicering af Entitets-Relationsdiagram Medicin Oprindelig relation Deltagernr Blodtrykspiller Hjertemedicin Vanddrivende medicin Medicin mod forhøjet kolesterol Gigtpiller Sovepiller Nervepiller eller beroligende piller Medicin mod mavesyre Medicin mod astma/bronkitis Insulin P piller Anden sukkersyge medicin Binyrebarkhormon Hormonbehandling ved menopause Piller/dråber mod øjensygdom Smertestillende piller/medicin Slankepiller Vitaminpiller Naturmedicin D vitamin Medicin mod knogleskørhed Medicin Fortsat Kalk tilskud Jern tilskud Blodfortyndende (magnyl) Blodfortyndende(marevan, marcumar, heparin) Antidepressiv medicin (lykkepiller) Medicin mod alkoholisme Medicin mod forhøjet stofskifte Medicin mod for lavt stofskifte Potensmidler Andre piller Antal år med medicin mod forhøjet kolesterol Antal år med gigtpiller Antal år med sovepiller Antal år med nervepiller eller beroligende piller Antal år med medicin mod mavesyre Antal år med medicin mod astma/bronkitis Antal år med insulin Antal år med P piller Antal år med anden sukkersyge medicin Antal år med binyrebarkhormon Antal år med hormonbehandling ved menopause Medicin Fortsat Antal år med piller/dråber mod øjensygdom Antal år med smertestillende piller/medicin Antal år med slankepiller Antal år med vitaminpiller Antal år med naturmedicin Antal år med D vitamin Antal år med medicin mod knogleskørhed Antal år med kalk tilskud Antal år med jern tilskud Antal år med blodfortyndende (magnyl) Antal år med blodfortyndende(marevan,marc umar,heparin) Antal år med antidepressiv medicin (lykkepiller) Antal år med medicin mod alkoholisme Antal år medmedicin mod forhøjet stofskifte Antal år med medicin mod for lavt stofskifte Antal år med potensmidler Antal år med andre piller Antal år med blodtrykspiller Antal år med hjertemedicin Antal år med vanddrivende Figur A.13: Den oprindelig relation for entitetsklassen Forældre. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. Ophold i solen På Figur A.14 vises udspeciceringen af entitetsklassen Ophold i solen. Solarium Deltagernr. Skoldning i barndommen Originale hårfarve Ophold i solen Solfaktor Øjenfarve Antal timer i solen i hverdagen Antal timer i solen week/ferie Figur A.14: Udspecicering af ER-diagrammet for Entitetsklassen Ophold i solen. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. 150

157 Den oprindelige relation for entitetsklassen Ophold i solen er vist på Figur A.15. Ophold i solen Oprindelig relation Deltagernr Solarium Original hårfarve Øjenfarve Antal timer i solen i weekend/ferie Timer i solen hverdage Solfaktor Skoldning i barndommen Figur A.15: Den oprindelig relation for entitetsklassen Forældre. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. Kvinder Figur A.16 viser entitetsklassen Kvinder. Menstruation Deltagernr. Ammet Kvinder Spontane aborter Antal fødte børn Alder v. 1. fødsel Figur A.16: Udspecicering af ER-diagrammet for Entitetsklassen Kvinder. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklassen Kvinder er vist på Figur A.17. Kvinder Oprindelig relation Deltagernr Spontane aborter Alder ved 1. Fødsel Ammet Antal fødte børn Menstruationer Figur A.17: Den oprindelig relation for entitetsklassen Kvinder. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 151

158 A. Udspecicering af Entitets-Relationsdiagram Rygning På Figur A.18 ses entitetsklassen Rygning. Deltagernr. Pibetobak Mor ryger under graviditet Cigarer Cerutter Rygestopalder Nikotinerstatning Rygedebut Rygning Cigaretter u. filter År Cigaretter m. filter Ryger Inhalering Røg i hjemmet Passiv rygning Figur A.18: Udspecicering af ER-diagrammet for Entitetsklassen Rygning. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklassen Rygning er vist på Figur A.19. Rygning Oprindelig relation Deltagernr Cigarer Pibetobak Cerutter Nikotinerstatning Cigaretter uden filter Cigaretter med filter Indhalering Passiv rygning Ryger Røg i hjemmet År Rygedebut Rygestopsalder Mor ryger under graviditet Figur A.19: Den oprindelig relation for entitetsklassen Rygning. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 152

159 Uddannelse, erhverv og bopæl Figur A.20 viser udspeciceringen af entitetsklassen Uddannelse, erhverv og bopæl. Brændeovn i hjem Brændeovn i barndomshjem Husstandens samlede indkomst Antal bidragsydere til indkomst Deltagernr. Husdyr Antal skoleår Civilstatus Uddannelse, erhverv og bopæl Fuldført uddannelse Personer i husstanden Husstand Igangværende uddannelse Antal børn Erhvervsmæssig stilling Figur A.20: Udspecicering af ER-diagrammet for Entitetsklassen Uddannelse, erhverv og bopæl. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklassen Uddannelse, erhverv og bopæl er vist på Figur A.21. Uddannelse, erhverv, bopæl Oprindelig relation Deltagernr Antal skoleår Fuldført uddannelse Igangværende uddannelse Erhvervsmæssig stilling Husstand Antal børn Personer i husstanden Civilstatus Husdyr Brændeovn i hjem Brændeovn i barndomshjem Husstandens samlede indkomst Antal bidragsydere til indkomst Figur A.21: Den oprindelig relation for entitetsklassen Uddannelse, erhver og bopæl. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 153

160 A. Udspecicering af Entitets-Relationsdiagram Trivsel og velbendende På Figur A.22 ses entitetsklassen Trivsel og velbendende. Antal personlige kontakter Deltagernr. Glad/godt humør Afslappet Energisk Udhvilet Ønske om mere kontakt Trist/ked af det Kontakt ved venner/bekendte Interesseret i ting Kontakt med ikke samboende familie Trivsel og velbefindende Manglende livslyst Nedsat appetit Manglende energi/kræfter Øget appetit Mindre selvtillid Søvnbesvær Mere stille Rastløs Koncentrationsbesvær Manglende interesse i daglige gøremål Dårlig samvittighed/ skyldsfølelse Figur A.22: Udspecicering af ER-diagrammet for Entitetsklassen Trivsel og velbendende. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklassen Trivsel og velbendende er vist på Figur A.23. Trivsel og velbefindende Oprindelig relation Deltagernr Glad/godt humør Afslappet Energisk Udhvilet Interesseret i ting Trist/ked af det Manglende livslyst Manglende energi/kræfter Mindre selvtillid Dårlig samvittighed/skyldfølelse Trivsel og velbefindende Fortsat Manglende interesse i daglige gøremål Koncentrationsbesvær Rastløs Mere stille Søvnbesvær Nedsat appetit Øget appetit Kontakt med ikke samboende familie Kontakt med venner/bekendte Ønske om mere kontakt Antal personlige kontakter Figur A.23: Den oprindelig relation for entitetsklassen Trivsel og velbendende. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 154

161 AP-Skema Udspeciceringen af entitetsklassen AP-skema ses på Figur A.24. Virkning af nitroglycerin Søgt læge Deltagernr. Nitroglycerin tabletter Smerter i bryst ved gang i alm. tempo AP-skema Smertehyppighed Handling ved brystsmerter Smerte aftagende over tid Smerter ved standsning Figur A.24: Udspecicering af ER-diagrammet for Entitetsklassen AP-skema. Entitetsklassen er repræsenteret ved et rektangel og attributterne ses som ovaler, der er forbundet med entitetsklasserne med en enkelt streg. Den oprindelige relation for entitetsklassen AP-skema er vist på Figur A.25. AP-skema Oprindelig relation Deltagernr Smerter i bryst ved gang i almindeligt tempo Handling ved brystsmerter Smerter ved standsning Smerte aftagende over tid Smertehyppighed Nitroglycerin tabletter Virkning af nitroglycerin Søgt læge Figur A.25: Den oprindelig relation for entitetsklassen AP-Skema. Denne relation er allerede på 3. normalform hvorfor den ikke behandles yderligere. 155

162

163 Appendix B Klassespecikationer for designklasser I dette kapitel beskrives alle designklasser, samt deres attributter og metoder. Disse er desuden illustreret vha. klassespecikationer for hver enkelt klasse. I overensstemmelse med UML-notationen er metoder og attributter, der er erklæret public eller private markeret med henholdvis et '+' eller '-' foran metode- eller attributnavnet. Teksten efter ':' ved attributterne angiver, hvilken type attributten er. Ved metoder angiver teksten efter ':' metodens returtype, mens metodens input er angivet i parentes efter metodenavnet. B.1 Klassespecikationer for GUI-klasserne I dette afsnit beskrives GUI-klasserne, samt deres attributter og metoder. GUI-klasserne sørger for at oprette den unikke brugergrænseade for hver enkelt faneblad og opretter dermed de graske komponenter. Den eneste undtagelse er designklassen ResultatGUI, som indeholder kontrolkode. Desuden vil hver GUI-klasse indeholde metoder, som kaldes, når der trykkes på graske komponenter i dette faneblad, og dermed udføres der forskellige handlinger. GUI-klasserne har metoden initcomponents() og setselectedtoone() til fælles. Derfor vil disse metoder ikke beskrives for hver designklasse. Metoden initcomponents() initierer alle GUI komponenterne. Metoden setselectedtoone() sætter en defaultmarkering i hver liste, således at der altid er en farvning af en værdi i listen, når brugeren åbner det pågældende faneblad. GUI-klasserne har desuden følgende attributter til fælles JButton, JList samt JTextField, der er komponenter i brugergrænseaden. JButton udgør knapperne på brugergrænseaden, JList de lister, der bliver præsenteret i brugergrænse- aden og JTextField udgør de felter, hvor brugeren har mulighed for at indtaste data for en deltager. Data fra brugergrænseaden samles i en arrayliste eksempelvis vha. metoden getsamletarraydeltager() for designklassen DeltagerGUI eller getsamletarraykost- Drikkevarer() for designklassen KostDrikkevarerGUI. Da GUI-klasserne og GUIUdtræk-klasserne stort set har den samme funktionalitet, vælges 157

164 B. Klassespecikationer for designklasser det at beskrive disse samlet i det følgende. VelkommenGUI Formålet med klassen VelkommenGUI er at opsætte et velkomstvindue for brugeren, hvor brugeren har mulighed for at vælge mellem de tre funktionaliteter Indtast data, Rediger data og Udtræk data. På Figur B.1 er klassespecikationen for klassen vist, hvor klassens attributter og metoder er vist. + JButton + Velkommen : JFrame + frameguiref : FrameGUI <<Boundary>> VelkommenGUI + VelkommenGUI() - initcomponents() + main(string args[]) throws UnsupportedLookAndFeelException : void + velkommenguiopsætning() : void - udtrækknapmouseclicked(mouseevent evt) : void - indtastknapmouseclicked(mouseevent evt) : void - redigerknapmouseclicked(mouseevent evt) : void Figur B.1: Klassespecikation for klassen VelkommenGUI med dens attributter og metoder. Klassens attributter består af en instans af klassen FrameGUI, samt en instans af JFrame, velkommen, der bruges, når velkomstmenuen opsættes. Konstruktøren VelkommenGUI() opretter en skabelon for velkomstvinduet. Klassen indeholder main() metoden, der er den første metode, der kaldes, når systemet opstartes. Metoden velkommenguiopsætning() opretter velkomstmenuen, og kaldes derfor i metoden main(). Metoderne udtrækknapmouseclicked(), indtastknapmouseclicked() og redigerknapmouseclicked() bliver kaldt alt efter, hvad brugeren vælger. I det tilfælde, at brugeren vælger at indtaste data, vil indtastknapmouseclicked() kaldes. FrameGUI Denne klasse er skelettet for opsætningen af brugergrænseaden. Klassespecikationen er vist på Figur B.2 på næste side, hvor klassens attributter og metoder er listet. 158

165 B.1. Klassespecikationer for GUI-klasserne <<Boundary>> FrameGUI + flag=0 : int + message : String + vinduetitel : String + velkommenguiref : VelkommenGUI + faneblad : JTabbedPane + kom : Kommunikation + ForældreGUIRef : ForældreGUI + ForældreGUIUdtrækRef : ForældreGUIUdtræk + forældreref : Forældre(ForældreGUIRef,ForældreGUIUdtrækRef ) + FysiskAktivitetGUIRef : FysiskAktivitet + FysiskAktivitetGUIUdtrækRef : FysiskAktivitetGUIUdtræk + fysiskaktivitetref : FysiskAktivitet(FysiskAktivitetGUIRef,FysiskAktivitetGUIUdtrækRef) + SygdomGUIRef : SygdomGUI + SygdomGUIUdtrækRef : SygdomGUIUdtræk + sygdomref : Sygdom(SygdomGUIRef,SygdomGUIUdtrækRef) + KostDrikkevarerGUIRef : KostDrikkevarerGUI + KostDrikkevarerGUIUdtrækRef : KostDrikkevarerGUIUdtræk + kostdrikkevarerref :KostDrikkevarer(KostDrikkevarerGUIRef,KostDrikkevarerGUIUdtrækRef ) + MedicinGUIRef : MedicinGUI + MedicinGUIUdtrækRef : MedicinGUIUdtræk + medicinref : Medicin(MedicinGUIRef,MedicinGUIUdtrækRef ) + deltagerref : Deltager +DeltagerGUIRef : DeltagerGUI(deltagerRef, this, forældreref, ForældreGUIRef, fysiskaktivitetref, FysiskAktivitetGUIRef, sygdomref, SygdomGUIRef, medicinref, MedicinGUIRef, kostdrikkevarerref, KostDrikkevarerGUIRef, kom) + DeltagerGUIUdtrækRef : DeltagerGUIUdtræk + ResultatGUIRef : ResultatGUI(deltagerRef, ForældreGUIUdtrækRef, sygdomref, SygdomGUIUdtrækRef, fysiskaktivitetref, FysiskAktivitetGUIUdtrækRef, kostdrikkevarerref, KostDrikkevarerGUIUdtrækRef, DeltagerGUIUdtrækRef, medicinref, MedicinGUIUdtrækRef, this, forældreref, ForældreGUIRef, SygdomGUIRef, FysiskAktivitetGUIRef, KostDrikkevarerGUIRef, DeltagerGUIRef,MedicinGUIRef,kom); + FrameGUI () : + fanebladsopsætningindtast() : void + fanebladsopsætningrediger() : void + fanebladsopsætningudtræk() : void + opsætningframe() : void + statechanged(changeevent e) : void + vismeddelelser(int valg) : void Figur B.2: Klassespecikation for klassen FrameGUI med dens attributter og metoder. Attributterne er instanser af klasserne med kontrolkode. Dermed kan der opnåes adgang til instanser af klasserne i de andre klasser uden at nye instanser af klasserne skal oprettes. Desuden oprettes instanser af de andre GUI-klasser, da der i designklassen FrameGUI skal oprettes et faneblad til hver GUI-klasse. Attributten Faneblad er af typen JTabbedPane, som er en komponent, som lader brugeren skifte mellem vinduerne ved at klikke på et faneblad. Konstruktøren FrameGUI() opretter en baggrunds-gui, der fungerer som en ramme og 159

166 B. Klassespecikationer for designklasser skabelon for den resterende brugergrænseade. Metoden fanebladsopsætning() tilføjer et faneblad til skabelonen for hver GUI-klasse og tilføjer en titel til hvert faneblad. state- Changed() kalder de metoder, der skal aktiveres, når brugeren foretager sig noget på brugergrænseaden. I dette tilfælge skal der kaldes nogle metoder, når brugeren vælger fanebladet for designklassen ResultatGUI. For at lytte på denne brugerinteraktion implementeres ChangeListener i klassen. Metoden vismeddelelser() kaldes, når brugeren skal informeres om en handling lykkedes eller hvis der opstår en fejl. DeltagerGUI og DeltagerGUIUdtræk Klasserne DeltagerGUI og DeltagerGUIUdtræk har til formål at opsætte fanebladet vedrørende deltageroplysninger for brugergrænseaden. På Figur B.4 ses klassespecikationen for klassen, hvormed attributterne og metoderne er vist. <<Boundary>> DeltagerGUI + JTextField + JList + finddeltager : String + samletarraydatabase : ArrayList<String> + DeltagerGUI(DeltagerDeltagerRef, FrameGUIFrameGUIRef, Forældre ForældreRef, ForældreGUIForældreGUIRef, FysiskAktivitet FysiskAktivitetRef, FysiskAktivitetGUI FysiskAktivitetGUIRef, Sygdom SygdomRef, SygdomGUISygdomGUIRef, Medicin MedicinRef, MedicinGUIMedicinGUIRef, KostDrikkevarer KostDrikkevarerRef, KostDrikkevarerGUIKostDrikkevarerGUIRef, Kommunikation Kom) - initcomponents() : void - FindDeltagerKnapActionPerformed(ActionEventevt) : void - sletknapmouseclicked(mouseeventevt) : void + setfelterdeaktiverrediger() : void Figur B.3: Klassespecikation for klassen DeltagerGUI med dens attributter og metoder + JTextField + JList + DeltagerGUIUdtræk() - initcomponents() : void - setselectedtoone() : void <<Boundary>> DeltagerGUIUdtræk Figur B.4: Klassespecikation for klassen DeltagerGUIUdtræk med dens attributter og metoder Attributten nddeltager er af typen String, hvor værdien af denne er det deltagernr. brugeren indtaster. Attributten samletarraydatabase er af typen ArrayList<String>, der danner et samlet array for de valgte værdier listerne og tekstfelterne efter brugerinteraktion. Klassen indeholder desuden metoden FindDeltagerKnapActionPerformed(), som kaldes, når brugeren har indskrevet et deltagernr. og trykker på en knap for at nde deltagerens data i databasen. Metoden sletknapmouseclicked() kaldes, når brugeren vælger at markere, at en deltagers data skal slettes fra databasen. Klassen DeltagerGUIUdtræks attributter og metoder er tidligere beskrevet og vil derfor ikke beskrives her. 160

167 B.1. Klassespecikationer for GUI-klasserne KostDrikkevarerGUI og KostDrikkevarerGUIUdtræk Klassespecikationen for klasserne KostDrikkevarerGUI og KostDrikkevarerGUIUdtræk er vist på Figur B.6. Klasserne har til formål at opsætte fanebladet for oplysninger om kost og drikkevarer. + JList + KostDrikkevarerGUI() - initcomponents() : void <<Boundary>> KostDrikkevarerGUI + JList <<Boundary>> KostDrikkevarerGUIUdtræk + KostDrikkevarerGUIUdtræk() - setselectedtoone() : void Figur B.5: Klassespecikation for klassen KostDrikkevarerGUI med dens attributter og metoder Figur B.6: Klassespecikation for klassen KostDrikkevarerGUIUdtræk med dens attributter og metoder Klassernes attributter og metoder er tidligere beskrevet og vil derfor ikke beskrives her. SygdomGUI og SygdomGUIUdtræk Klasserne SygdomGUI og SygdomGUIUdtræk opsætter brugergrænseaden for fanebladet Sygdom ved funktionaliteterne indtast, rediger og udtræk data. Klassernes attributter og metoder er vist i klassespecikationenerne, som ses på Figur B.8. + JList + JTextField <<Boundary>> SygdomGUI + SygdomGUI() - initcomponents() : void - vægtfødsellistmouseclicked(focusevent evt) : void - bloddonerlistmouseclicked(mouseevent evt) : void - åreknuderlistmouseclicked(mouseevent evt) : void - fødselfeltmouseclicked(mouseevent evt) : void Figur B.7: Klassespecikation for klassen SygdomGUI med dens attributter og metoder. + JList <<Boundary>> SygdomGUIUdtræk + SygdomGUIUdtræk() - initcomponents() : void - setselectedtoone() : void - bloddonerlistmouseclicked(mouseevent evt) : void - åreknuderlistmouseclicked(mouseevent evt) : void Figur B.8: Klassespecikation for klassen SygdomGUIUdtræk med dens attributter og metoder. Metoderne vægtfødsellistfocusgained() og fødselsfeltfocuslost() i SygdomGUI, har overordnede det samme formål, nemlig at vise deltagerens vægt ved fødsel, hvis denne ikke vides præcist kan et interval indtastes, hvormed at metoden vægtfødsellistfokusgained() udelukker muligheden for at indtaste et præcist tal. Moderne for SygdomGUIUdtræk er tidligere beskrevet, hvorfor disse ikke beskrives. 161

168 B. Klassespecikationer for designklasser ForældreGUI og ForældreGUIUdtræk Klasserne opsætter den graske brugergrænseade for fanebladet Forældre, hvor ForældreGUI opsætter brugergrænseaden for funktionaliteten indtast og rediger data og ForældreGUIUDtræk for udtræk data. Figur B.10 viser klassespcikationenerne, som indeholder attributter og metoder for klasserne. + JList + ForældreGUI() - initcomponents() : void <<Boundary>> ForældreGUI Figur B.9: Klassespecikation for klassen ForældreGUI med dens attributter og metoder. + JList <<Boundary>> ForældreGUIUdtræk + ForældreGUIUdtræk() - initcomponents() : void - setselectedtoone() : void Figur B.10: Klassespecikation for klassen ForældreGUIUdtræk med dens attributter og metoder. Attributterne og metoderen for disse klasser er beskrevet tidligere. MedicinGUI og MedicinGUIUdtræk Klasserne MedicinGUI og MedicinGUIUdtræk opsætter brugergrænseaden for fanebladet Medicin. På Figur B.12 ses klassespecikationerne for klasserne indeholdt attributter og metoder. + JList <<Boundary>> MedicinGUI + MedicinGUI() - initcomponents() : void - medicinlistfocuslost(focusevent evt) : void - setantalårdisable() : void Figur B.11: Klassespecikation for klassen MedicinGUI med dens attributter og metoder. + JList <<Boundary>> MedicinGUIUdtræk + MedicinGUIUdtræk() - initcomponents() : void - setselectedtoone() : void Figur B.12: Klassespecikation for klassen MedicinGUIUdtræk med dens attributter og metoder. Metoden medicinlistmouseclicked() i klassen MedicinGUI kaldes i det tilfælde at deltageren tager medicin, metoden gør det muligt for brugeren at indtaste hvor længe deltageren taget dette medikament. Metoden setantalårdisable() deaktiverer listerne med antal af år for et givet medikament, indtil brugeren vælger det pågældende medikament. 162

169 B.1. Klassespecikationer for GUI-klasserne FysiskAktivitetGUI og FysiskAktivitetGUIUdtræk Ved hjælp af disse klasser opsættes brugergrænseaden for fanebladet fysisk aktivitet. På Figur B.14 vises klassespecikationerne for klasserne, hvor attributter og metoder er vist. + JList <<Boundary>> FysiskAktivitetGUI + FysiskAktivitetGUI() - initcomponents() : void - fysiskaktivitetarbejdelistmouseclicked(mouseevent evt) : void - fysiskaktivitetfritidlistmouseclicked(mouseevent evt) : void + JList <<Boundary>> FysiskAktivitetGUIUdtræk + FysiskAktivitetGUIUdtræk() - initcomponents() : void - setselectedtoone() : void Figur B.13: Klassespecikation for klassen FysiskAktivitetGUI med dens attributter og metoder. Figur B.14: Klassespecikation for klassen FysiskAktivitetGUIUdtræk med dens attributter og metoder. Metoderne fysiskaktivitetarbejdelistmouseclicked() og fysiskaktivitetfritidlistmouse- Clicked() sørger for at aktivere lister alt efter hvad der er valgt. Attributterne og metoderne er beskrevet tidligere, hvorfor disse ikke beskrives her. ResultatGUI Klassen ResultatGUI opsætter brugergrænseaden for fanebladet Resultat, hvor dataansvarliges eller forskernes søgning bliver vist. Figur B.15 på den følgende side viser klassespecikationen for klassen, som har attributter og metoder listet. Desuden indeholder klassen metoder til at gemme data i en l. 163

170 B. Klassespecikationer for designklasser <<Boundary>> ResultatGUI + samletarray : ArrayList<String> + samletarrayudtræk : ArrayList<String> + samletarrayindtast : ArrayList<String> + navnværdiarray : ArrayList<String> + getnavnværdiarray: ArrayList<String> + valgtparametrelistmodel : DefaultListModel + ResultatGUI(Deltager DeltagerRef, ForældreGUIUdtræk ForældreGUIUdtrækRef, Sygdom SygdomRef, SygdomGUIUdtræk SygdomGUIUdtrækRef, FysiskAktivitet FysiskAktivitetRef, FysiskAktivitetGUIUdtræk FysiskAktivitetGUIUdtrækRef, KostDrikkevarer KostDrikkevarerRef, KostDrikkevarerGUIUdtræk KostDrikkevarerGUIUdtrækRef, DeltagerGUIUdtræk DeltagerGUIUdtrækRef, Medicin MedicinRef, MedicinGUIUdtræk MedicinGUIUdtrækRef, FrameGUI FrameGUIRef, Forældre ForældreRef, ForældreGUI ForældreGUIRef, SygdomGUI SygdomGUIRef, FysiskAktivitetGUI FysiskAktivitetGUIRef, KostDrikkevarerGUI KostDrikkevarerGUIRef, DeltagerGUI DeltagerGUIRef, MedicinGUI MedicinGUIRef, Kommunikation Kom) - initcomponents() : void - resultatknapactionperformed(actionevent evt) : void + setvalgteparametreudtræk() : void + setvalgteparametreindtast() : void + getsamletarrayindtast(forældregui ForældreGUIRef, SygdomGUI SygdomGUIRef, FysiskAktivitetGUI FysiskAktivitetGUIRef, KostDrikkevarerGUI KostDrikkevarerGUIRef, DeltagerGUI DeltagerGUIRef, MedicinGUI MedicinGUIRef ) : ArrayList<String> + getsamletarrayudtræk(forældreguiudtræk ForældreGUIUdtrækRef, SygdomGUIUdtræk SygdomGUIUdtrækRef, FysiskAktivitetGUIUdtræk FysiskAktivitetGUIUdtrækRef, KostDrikkevarerGUIUdtræk KostDrikkevarerGUIUdtrækRef, DeltagerGUIUdtræk DeltagerGUIUdtrækRef, MedicinGUIUdtræk MedicinGUIUdtrækRef) : ArrayList<String> + setnavnværdiudtræk() : ArrayList<String> + setnavnværdiindtast() : ArrayList<String> Figur B.15: Klassespecikation for klassen ResultatGUI med dens attributter og metoder. Klassen ResultatGUI indeholder som allerede nævnt kontrolkode, hvilket adskiller den fra de resterende GUI-klasser. Attributten samletarray er en ArrayList, som indeholder et samlet array med data fra de andre klasser. Attributten variableliste er en JList, som kan være en liste fra en af de andre klasser og bruges som argument til metoden getsamletarray(), som samler arrays med data fra de andre klasser til ét array. Metoden setvalgteparametreindtast() og setvalgteparametreudtræk() kaldes for både udtræk og indtast data. Disse metoder kalder henholdvis getsamletarrayindtast() og get- SamletArrayUdtræk(), hvorefter setnavnværdiindtast() og setnavnværdiudtræk() kaldes. Tilsammen sørger disse metoder for at vise brugeren de data vedkommende enten har indtastet, redigeret i eller udtrukket. Metoden okknapactionperformed() kaldes når brugeren vælger at gemme de indtastede data eller vælger at udtrække data fra databasen. 164

171 B.2. Klassespecikationer for de øvrige klasser B.2 Klassespecikationer for de øvrige klasser De øvrige klasser indeholder kontrolkoden, dvs. den kode, der foregår bag brugergrænse- aden, og dermed den del af systemet, som brugeren ikke ser. Klasserne beskrives i det følgende. Databasekommunikation Klassen Databasekommunikation er bindeleddet mellem computer og databasen. På Figur B.16 ses klassespecikationen med attributter og metoder. - url : String - brugernavn : String - adgangskode : String Databasekommunikation - opretforbindelse() : Connection + indsætdata(arraylist<string> værdiarray ) : void + redigerdata(arraylist<string> værdiarray ) : void + udtrækdata(arraylist<string> søgearray ) : void + finddeltager(string deltagernr) : ArrayList<String> + sletdeltager(string deltagernr) : void - genererattributarray () : ArrayList<String> - generertabelarray () : ArrayList<String> Figur B.16: Klassespecikation for klassen Databasekommunikation med dens attributter og metoder. Klassen indeholder tre attributter, der benyttes til at oprette forbindelse til databasen vha. metoden opretforbindelse(). Metoderne genererattribuyarray() og generertabelarray() genererer arrays med henholdsvis navne på alle attributter i databasen og navne på alle tabeller i databasen. Disse arrays benyttes begge i metoden udtrækdata(), som kaldes når data skal udtrækkes fra databasen og gemmes i en l, og i metoden nddeltager(), som benyttes i det tilfælde at der søges på et specikt deltagernr.. Metoderne indsætdata() og redigerdata() gemmer data i databasen, og metoden sletdeltager() sletter en deltagers data fra databasen. Spørgeskema Klassen Spørgeskema er en superklasse, som alle de øvrige klasser nedarver fra pånær klassen Databasekommunikation, hvilket vil sige, at attributter og metoder i klassen Spørgeskema nedarves til andre klasser. Atrributter og metoder vises på Figur B.17 på den følgende side. 165

172 B. Klassespecikationer for designklasser <<Control>> Spørgeskema - deltagerinfo : String + samletarraydatabase : ArrayList<String> + getmultiselectlistinfo(jlist variableliste) : ArrayList<String> + getindtastmultiselectlistinfo(jlist variableliste) : ArrayList<String> + getmultiselectlistinfoindtast(jlist variableliste) : ArrayList<String> + getsingleselectlistinfo(jlist variableliste) : ArrayList<String> + gettextfeltinfo(jtextfield variabelnavn) : ArrayList<String> + getdeltagerinfo(jtextfield deltagernr) : String + setsamletarray(string finddeltager, Deltager DeltagerRef, DeltagerGUI DeltagerGUIRef, FrameGUI frameguiref, Forældre forældreref, ForældreGUI ForældreGUIRef, FysiskAktivitet FysiskAktivitetRef, FysiskAktivitetGUI FysiskAktivitetGUIRef, Sygdom SygdomRef, SygdomGUI SygdomGUIRef, Medicin MedicinRef, MedicinGUI MedicinGUIRef, KostDrikkevarer KostDrikkevarerRef, KostDrikkevarerGUI KostDrikkevarerGUIRef) : ArrayList<String> Figur B.17: Klassespecikation for klassen Spørgeskema med dens attributter og metoder. Klassens attributter er udelukkende deneret i klassens metoder og anvendes derfor kun i disse. Derfor er de valgt ikke at medtages i klassespecikationen. Metoderne getmultiselectlistinfo(), getindtastmultiselectlistinfo(), getmultiselectlistinfoindtast(), getsingleselectlistinfo() og gettextfeltinfo(), kaldes når brugeren vælger fanebladet for ResultatGUI. I metoden ndes de valgte værdier i den JList eller TextField, som brugeren har interageret med. Hvilken en af metoderne som kaldes, afhænger af, om det er tilladt for brugeren af vælge en eller ere værdier i den enkelte liste. Metoden getdeltagerinfo() kaldes, når deltagerens information skal hentes i databasen ud fra et indtastet deltagernr.. Fælles for de resterende kontrolklasser er, at de indeholder metoder med fælles funktionalitet. Metoderne tager den tilhørende GUI-klasses lister eller tekstfelter ind som argument og gemmer disse i ét array. Derfor vil disse metoder ikke beskrives i hver klasse men vil indgå i klassespecikationen til den enkelte klasse. Deltager Klassen Deltager indeholder kontrolkoden til klassen DeltagerGUI, således at når interaktioner fra en bruger registreres, udføres tilhørende handlinger gennem metodekald i denne klasse. Metoderne, samt klassens attributter kan ses på Figur B.18 på næste side. 166

173 B.2. Klassespecikationer for de øvrige klasser <<Control>> Deltager + gemtdeltagerarray : ArrayList<String> + setdeltagerdatabasearray : ArrayList<String> + gemtdeltageroplysninger : ArrayList<String> - validcprlængde=10 : int - cpr : String - validtlflængde=8 : int - tlf : String + gemindtastetdeltagerarray(jtextfield feltdeltagernr, JTextField feltfornavn, JTextField feltefternavn, JList dødsfaldlist, JTextField feltfremmødtdato, JTextField feltgenindkaldelsesdato, JTextField feltdato1invitation, JTextField feltdato2invitation, JTextField feltprivattelefonnr, JTextField feltmobiltelefonnr, JTextField feltgade, JTextField felthusnr, JTextField feltpostnr, JTextField feltby, JTextField feltcprnr, JTextField feltdatospørgeskema, ArrayList<String> gemtalderfralist, ArrayList<String> gemtaldertillist, ArrayList<String> gemtkønlist) : ArrayList<String> + gemudtruknedeltagerarray(jtextfield feltdeltagernr, JTextField feltfornavn, JTextField feltefternavn, JList dødsfaldlist, JTextField feltfremmødtdato, JTextField feltgenindkaldelsesdato, JTextField feltdato1invitation, JTextField feltdato2invitation, JTextField feltprivattelefonnr, JTextField feltmobiltelefonnr, JTextField feltgade, JTextField felthusnr, JTextField feltpostnr, JTextField feltby, ArrayList<String> gemtfeltcprnr, JTextField feltdatospørgeskema, JList alderfralist, JList aldertillist, JList kønlist) : ArrayList<String> + setdeltagerarray(arraylist<string> arraydatabase, DeltagerGUI DeltagerGUIRef) : ArrayList<String> + validercpr(string validcpr) : boolean + validertlf(string validtlf) : boolean Figur B.18: Klassespecikation for klassen Deltager med dens attributter og metoder. KostDrikkevarer Klassen KostDrikkevarer styrer den kontrollerende kode til klassen KostDrikkevarerGUI. Dermed vil interaktioner fra en bruger registreres, og de tilhørende handlinger sker gennem metodekald i denne klasse. Klassens attributter og metoder kan ses på Figur B.19 på den følgende side. 167

174 B. Klassespecikationer for designklasser <<Control>> KostDrikkevarer + element : String + gemtkostdrikkevarerarray : ArrayList<String> + setkostdrikkevarerdatabasearray : ArrayList<String> + gemtmælklist : ArrayList<String> + gemtøkologilist : ArrayList<String> + gemtalkohollist : ArrayList<String> + gemtandetdrikkelselist : ArrayList<String> + gemtfedtstoflist : ArrayList<String> + gemtkødlist : ArrayList<String> + gemtpålægbrødlist : ArrayList<String> + gemtgrøntsagerlist : ArrayList<String> + gemtfrugtlist : ArrayList<String> + gemtfastfoodlist : ArrayList<String> + gemtmellemmåltiderlist : ArrayList<String> + gemtmåltiderlist : ArrayList<String> + KostDrikkevarer(KostDrikkevarerGUI KostDrikkevarerGUIRef,KostDrikkevarerGUIUdtræk KostDrikkevarerGUIUdtrækRef) + gemindtastetkostdrikkevarerarray() : ArrayList<String> + gemudtruknekostdrikkevarerarray() : ArrayList<String> + setkostdrikkevarerarray(arraylist<string> arraydatabase, KostDrikkevarerGUI KostDrikkevarerGUIRef) : ArrayList<String> Figur B.19: Klassespecikation for klassen KostDrikkevarer med dens attributter og metoder. Sygdom Klassen Sygdom består af metoder og attributter, der benyttes ved brugerinteraktion i fanebladet om sygdom, og disse ses på Figur B gemtsygdomarray : ArrayList<String> + setsygdomdatabasearray : ArrayList<String> + element : String + gemtallergilist : ArrayList<String> + gemtblodhjertelist : ArrayList<String> + gemtåreknuderdebutlist : ArrayList<String> + gemtbloddonorårlist : ArrayList<String> + gemtdiverselist : ArrayList<String> + gemtbloddonertapningerlist : ArrayList<String> + gemtvægtfødsellist : ArrayList<String> + gemtvægtfødsel : ArrayList<String> + gemtvægttyveårlist : ArrayList<String> + gemtluftvejelist : ArrayList<String> + gemtbloddonerlist : ArrayList<String> + gemtåreknuderlist : ArrayList<String> <<Control>> Sygdom + Sygdom(SygdomGUI SygdomGUIRef, SygdomGUIUdtræk SygdomGUIUdtrækRef) + gemindtastetsygdomarray() : ArrayList<String> + gemudtruknesygdomarray() : ArrayList<String> +setsygdomarray(arraylist<string> arraydatabase, SygdomGUI SygdomGUIRef) : ArrayList<String> Figur B.20: Klassespecikation for klassen Sygdom med dens attributter og metoder. 168

175 B.2. Klassespecikationer for de øvrige klasser Forældre Klassen Forældre indeholder metoder, der har til opgave at foretage handlinger, når en bruger benytter en grask komponent i fanebladet om deltagerens forældre. Klassespeci- kationen for den pågældende klasse er vist på Figur B gemtforældrearray : ArrayList<String> + gemtlistsygdommor : ArrayList<String> + gemtlistsygdomfar : ArrayList<String> + gemtlistuddannelsemor : ArrayList<String> + gemtlistuddannelsefar ArrayList<String>: + element : String + setforældredatabasearray : ArrayList<String> <<Control>> Forældre + Forældre (ForældreGUI ForældreGUIRef, ForældreGUIUdtræk ForældreGUIUdtrækRef) + gemindtastetforældrearray() : ArrayList<String> + gemudtrukneforældrearray() : ArrayList<String> + getvalgtforældre(jlist variableliste) : ArrayList<String> + setforældrearray(arraylist<string> arraydatabase, ForældreGUI ForældreGUIRef) : ArrayList<String> Figur B.21: Klassespecikation for klassen Forældre med dens attributter og metoder. Medicin Klassen Medicin står for kontrolkoden bag brugergrænseaden indeholdende medicinoplysninger, dvs. hver gang brugeren foretager noget på brugergrænseaden indeholdende fanebladet for medicin er det denne klasse, der sørger for, at det bliver udført. Klassespecikationen for klassen ses på Figur B JList <<Boundary>> MedicinGUI + MedicinGUI() - initcomponents() : void - medicinlistmouseclicked(mouseevent evt) : void - setantalårdisable() : void Figur B.22: Klassespecikation for klassen Medicin med dens attributter og metoder. FysiskAktivitet Klassen FysiskAktivitet indeholder kontrolkoden bag brugergrænseaden for fanebladet Fysisk aktivtitet. Metoder og attributter illustreres på Figur B.23 på den følgende side. 169

176 B. Klassespecikationer for designklasser <<Control>> FysiskAktivitet + element : String + gemtunderarbejdelist : ArrayList<String> + gemtifritidenlist : ArrayList<String> + gemtmotionsvanerlist : ArrayList<String> + gemtfysiskformlist : ArrayList<String> + gemttempolist : ArrayList<String> + gmettransportarbejdelist : ArrayList<String> + gemtfysiskaktivitetarray : ArrayList<String> + setfysiskaktivitetdatabasearray : ArrayList<String> + FysiskAktivitet(FysiskAktivitetGUI FysiskAktivitetGUIRef, FysiskAktivitetGUIUdtræk FysiskAktivitetGUIUdtrækRef) + gemindtastetfysiskaktivitetarray() : ArrayList<String> + gemudtruknefysiskaktivitetarray() : ArrayList<String> + setfysiskaktivitetarray(arraylist<string> arraydatabase, FysiskAktivitetGUI FysiskAktivitetGUIRef) : ArrayList<String> Figur B.23: Klassespecikation for klassen FysiskAktivitet med dens attributter og metoder. 170

177 Appendix C Mailudveksling med styregruppen for Region Sjællands Befolkningsundersøgelse Dette appendix har til formål, at give et overblik over de informationer projektgruppen har modtaget pr. mail fra styregruppen for Region Sjællands Befolkningsundersøgelse. Der opstilles en sammenfatning af de informationer, der er anvendt til at udvikle databasesystemet. Under projektperioden er der blevet udvekslet mails mellem projektgruppen og to af styregruppens medlemmer. Materiale er modtaget fra Christina Ellervik, 1. reservelæge, Ph.D., Klinisk Biokemisk Afdeling, Næstved Sygehus og Palle Pedersen, Cand.Scient, Ph.D., Klinisk Biokemisk Afdeling, Næstved Sygehus og sammenfattes i det følgende. Formålene med befolkningsundersøgelsen er i første omgang at sætte mere fokus på opsporing af diabetes og fedme i den sydlige del af Region Sjælland. Der vil i denne forbindelse foregå en form for intervention, ved at genindkalde nye diabetikere og ikkediabetikere, men familiært disponerede indkaldes til et særligt opfølgningsprogram. Dermed er diabetes det første delprojekt for befolkningsundersøgelsen. Desuden er hensigten at opbygge en biobank med blodprøver, DNA og RNA til senere forskning. Der vil udsendes indkaldelser vha. CPR-registreret 6 gange årligt, hvorefter deltageren har to måneder til frit at komme til helbredsundersøgelsen. Hvis en deltager ikke møder op i denne periode, vil rykkere sendes. Derudover skal det være muligt at registrere eventuelle dødsfald, så der fx ikke sendes breve til enker. For at undgå at skulle indtaste ca. 500 parametre for hver deltager, vil data fra elektronisk udstyr overføres elektronisk. Spørgeskemaer, som er udfyldt manuelt, vil skulle overføres og scannes ind vha. Optical character recognition softwaren Readsoft, som er indkøbt til dette formål. Dermed er der ikke behov for manuel indtastning i den initiale fase medmindre, der opdages fejl ved valideringen af overført data. Overførslen vil blive gemt i komma-separerede ler (csv ler). Det er dog ikke muligt for projektgruppen at få adgang til Readsoft eller enkelte dataler genereret af Readsoft. Selvom styregruppen bruger Readsoft vil der alligevel være behov for at indskrive da- 171

178 C. Mailudveksling med styregruppen for Region Sjællands Befolkningsundersøgelse ta manuelt ved gravide og deltagere med pacemaker, da disse ikke må få foretaget en bio-impedansmåling pga. elektriske impulser, og dermed skal have beregnet Body Mass Index. Bio-impedansmåling understøtter elektronisk overførsel. Yderligere kan målinger fra blodtryksapparatur, handgrip, CO-måling, vægt, iltmætning, puls og højde ikke overføres elektronisk. 172

179 Appendix D Databaseteori Formålet med dette appendix er at beskrive de anvendte elementer i databasesytemet. Først introduceres relationelle databaser, dernæst DBMS og sidst SQL. På Figur D.1 illustreres en oversigt over den fysiske opbygning af databasen. De relevante elementer i databasesystemet beskrives ud fra denne gur. Den enkelte bruger kan tilgå databasens indhold igennem en applikation, i dette projekt en brugergrænseade. Vedkommende har mulighed for at foretage ændringer i data på brugergrænseaden, som derefter videreføres til databasen og omsættes i databasen vha. SQL og DBMS. Database DBMS SQL Brugergrænseflade Figur D.1: Oversigt over den fysiske opbygning af databasen, hvor en bruger via en applikation fx en brugergrænsade tilgår databasen. Brugerens ændringer i brugergrænseaden indskrives i databasen vha. SQL kommandoer, hvor DBMS'et gemmer eller henter fra databasen. Modiceret ud fra Systems View [View, 2009]. 173

180 D. Databaseteori Relationelle databaser Relationelle databaser er den mest anvendte form for databaser og består af en samling af tabeller, der repræsenterer både data og relationer derimellem. Hver tabel har et antal søjler, og hver søjle har et unikt navn. En række i en tabel repræsenterer en association mellem et sæt af værdier. Yderligere har rækkefølgen, hvormed rækker optræder i en tabel ingen betydning, da en tabel er et sæt af rækker. Hver søjle i en relationel database har en søjle-header, der er navnet på den enkelte søjle, og disse headers kaldes atributter. For hver attribut er der deneret et sæt af tilladte værdier, hvilket kaldes attributtens domæne. Det er muligt for attributterne at have samme domæne. Domæneværdien null er indeholdt i alle domæner, hvilket betyder, at værdien er ukendt eller ikke eksisterer. [Silberschatz et al., 2005] Database management system Et DBMS er et sæt af programmer, der gør det muligt at tilgå data i en database. Formålet med et DMBS er at gemme og hente datainformtion hurtigt og nemt. Derudover er DBMS'er vigtige, når det gælder beskyttelse af data, da der her kan laves log ind funktioner og opsættes regler for, om de indtastede data er af korrekt format. [Silberschatz et al., 2005] MySQL er et relationel DBMS, der benyttes ved dette projekt. ACID egenskaber ACID står for Atomicity, Consistency, Isolation og Durability. Disse egenskaber sikrer at databasens transaktioner forløber pålideligt og fuldstændigt. Når ere brugere skal tilgå samme data på samme tid, skal kun en applikation af gangen kunne redigere i data. Alle ændringer i data vil blive udført i en korrekt rækkefølge i en transaktion. [ architecture.com, 2009] Det vil sige at ACID egenskaber sørger for konsistens i data ved ere brugere. I det følgende beskrives de re betegnelser. Atomicity refererer til DBMS'ets evner til at sikre at alle opgaver i en transaktion udføres, og i det tilfælde at dette ikke er muligt udføres ingen af opgaverne. Atomicity betyder at alle transaktioner følger princippet alt eller intet. Hvis ikke hele transaktionen kan udføres, bliver intet af den udført. [ architecture.com, 2009] Consistency betyder at data i databasen er konsistent før og efter en transaktion, selvom transaktionen ikke nødvendigvis er succesfuld. Consistency betyder også, at kun valid data skrives i databasen. Hvis der indføres ikke-valid data i databasen, stoppes transaktionen, og data i databasen returneres til sin tidligere sammnehængende tilstand. Hvis en 174

181 transaktion derimod er succesfuld, antager indholdet i databasen en ny sammenhængende tilstand. [ architecture.com, 2009] Isolation anvendes når der sker ere transaktioner samtidig. Ændringerne for hver transaktion skal isoleres, således hver transaktion behandles hver for sig. Ændringerne forårsaget af en transaktion ses først når den er gennemført. [ architecture.com, 2009] Durability betyder, at en transaktion ikke kan laves om efter brugeren er informeret om, at transaktionen er foretaget succesfuldt, medmindre brugeren selv vælger en ny transaktion, der påvirker den gamle. Ved systemnedbrud gemmes databasens indhold og igangværende transaktioner gennemføres. [ architecture.com, 2009] Structured Query Language For at gøre data fra en relationel database tilgængeligt for den enkelte bruger, skal det deneres hvilket query language, der skal anvendes. Det mest anvendte query language er SQL. SQL er et deklarativt sprog, hvilket betyder, at der i stedet for at programmere en ønsket begivenhed, deklareres hvad der ønskes gjort, og serveren udfører det for en. Sproget består af sprogene data denition language og data manipulation language, som skal forstås som dele af det samlede databasesprog, i dette tilfælde SQL. [Silberschatz et al., 2005] Data denition language bidrager med denitioner, der kan benyttes til at denere og modicere en databases schema. Sproget bidrager desuden med kommandoer til denition af views. Views deneres som relationer, der indeholder resultatet af en forespørgsel, og kan benyttes til fx at gemme unødvendig data og til at samle data fra mere end en relation til et enkelt view. [Silberschatz et al., 2005] Sproget data manipulation language gør det muligt at tilgå eller manipulere data. De forskellige muligheder for tilgang er at hente data fra en database, at indsætte ny data i en database, at slette data fra en database og at modicere data i en database. [Silberschatz et al., 2005] 175

182

183 Bilag

184

185 BILAG A IT-afdeligen Alléen Sorø [email protected] 13. marts 2009 Kravspecifikation vedr. IT understøttelse af Region Sjællands Befolkningsundersøgelse Region Sjællands Befolkningsundersøgelse er en befolkningsundersøgelse for i første omgang borgere i Næstved kommune, som iværksættes fra efteråret 2009 og frem til Næstved Kommune er samarbejdspartner i projektet. Projektet forventes udvidet til at omfatte Lolland Kommune, Guldborgsund kommune, Vordingborg kommune og Slagelse Kommune i de kommende 10 år. Omfanget er således vidtrækkende, systemet skal være fleksibelt og skal kunne implementeres på andre geografier når undersøgelsen i Næstved er færdig. Tidsramme - minimum 20 år. IT Region Sjælland skal bidrage med etablering af IT infrastruktur. Desuden skal IT levere et system, der understøtter de arbejdsgange, der er relateret til indkaldelsesprocedurer samt dataopsamling. På baggrund af et antal møder med kunden og et antal opsamlingsmøder internt i ITafdelingen er udarbejdet nedenstående oplæg til systemets funktion: Funktionelle krav: Systemet skal generere og udskrive indkaldelsesbreve Systemet skal hente oplysninger om borgere fra DPR/CPR Systemet skal generere og udskrive genindkaldelsesbreve Systemet skal vise indkaldelsesstatistik Systemet skal anvendes til undersøgelser på andre geografier* (se bemærkning under forbehold ) Systemet skal kunne anonymisere en borgers undersøgelsesresultater Systemet skal kunne håndtere borgeres ønske om fravalg af deltagelse Systemet skal kunne fremfinde en specifik borger Systemet skal understøtte vedligeholdelse af grænseværdier Systemet skal generere og udskrive svarbreve på baggrund af grænseværdier Systemet skal håndtere borgeres ønske om senere deltagelse Systemet skal modtage laboratoriesvar gennem webservice Systemet skal indhente data fra scannede vandresedler, spørgeskemaer og samtykkeerklæringer Systemet skal stille rådata i databasen direkte til rådighed for andre systemer, f.eks. STATA, SAS, SPSS. Systemet skal indhente data fra følgende medicotekniske udstyr: - Basal iltoptagelse - Biometri - EKG - Spirometri - Handgrip - Pulstrace Side 1 af 12

186 BILAG A - Pulseoximeter - OCR (Readsoft) Ikke funktionelle krav: Systemet skal fungere i Region Sjællands infrastruktur Systemet skal afvikles på MS Windows 2003 SP2 Systemets database skal baseres på MS SQL 2005 Systemet skal udvikles i MS.NET 3.5, C# Systemet skal udvikles med en lagdelt arkitektur, herunder: - GUI - Forretningslogik - Datalag (udvikles med LinQ) Systemet skal sikkerhedsmæssigt integreres med MS AD: - Authentification baseres på MS Windows logon - Autorisation sker på baggrund af sikkerhedsgrupper I MS AD Adgang til databasen gennem for systemet eksterne programmer (SPSS/SAS) sker med integreret Windows sikkerhed, som i infrastrukturen. Systemet skal overholde gældende lovgivning vedrørende beskyttelse af følsomme persondata, og skal logge alle pålogninger og pålogningsforsøg. Forbehold Det skal systemet ikke: Kunden ønsker at systemets opsætning og database genetableres på ny, ved gennemførelse af en ny undersøgelse på anden lokation/geografi end Næstved. * Systemet omfatter alene undersøgelsen i Næstved Kommune. Systemet vil efterfølgende kunne anvendes på andre geografier, dog under forudsætning af, at designet af undersøgelsen som helhed ikke ændres. Efterfølgende undersøgelser i andre områder eller ændring i designet af undersøgelsen (ændring i undersøgelserne eller udstyr) vil ske gennem normal ændringshåndtering i forhold til den specifikke geografi samt tilknyttet udstyr. Systemet skal ikke stille statistiske beregningsmetoder til rådighed (andre produkter anvendes af kunden til dette formål med direkte opslag i databasen, eks. SAS) Kunden har fravalgt systemets understøttelse af funktionalitet til Biobank. Forudsætninger: Kunden har ansvaret for at vedligeholde de til enhver tid gældende grænseværdier Ansvaret for at medicoteknisk udstyr leverer data korrekt kan ikke garanteres i leverancen. Leverancen omhandler indlæsning af korrekt leverede data i rigtigt format. Kunden skal udarbejde skabelon(er) til: Spørgeskema Vandreseddel Indkaldelsesbrev Genindkaldelsesbrev (samme som indkaldelsesbrev, dog med ændret fremmødeperiode) og Side 2 af 12

187 BILAG A Svarbrev(e) Uafklaret: Forventer kunden, at IT indlæser et initielt load af grænseværdier? hvis ja skal IT have grænseværdier leveret og det er kundens ansvar, at de indlæste data kvalitetssikres! De 2 moduler Den IT-mæssige understøttelse af kravene til systemet er for overskuelighedens skyld, valgt opdelt i 2 moduler. Et indkaldelsesmodul og et undersøgelsesmodul (dataopsamling). For at blive så præcis som muligt, i overensstemmelse med kunden, vedrørende kravene til IT understøttelsen, er valgt at anvende metoden use case. Der har i den forbindelse været afholdt et antal workshops med kunden. Disse har resulteret i følgende beskrivelser, udarbejdet af IT-afdelingen: Side 3 af 12

188

189 Region Sjællands Befolkningsundersøgelse med optageområde for Sygehus Syd Ansøgere Styregruppen for Region Sjællands Befolkningsundersøgelse: Hovedansøger er: 1. reservelæge Ph.D. Christina Ellervik, Klinisk Biokemisk Afdeling, Næstved Sygehus Øvrige ansøgere er: - Overlæge, dr.med. klinisk forskningslektor Jan Kvetny, Medicinsk Endokrinologisk Afdeling, Næstved Sygehus - Overlæge dr.med. Arne Bremmelgaard, Klinisk Biokemisk Afdeling, Næstved Sygehus - Ledende overlæge i Klinisk Biokemi Sygehus Syd Region Sjælland, Ph.D. Lise Bathum - Cand.Scient. Ph.D. Palle Pedersen, Klinisk Biokemisk Afdeling, Næstved Sygehus - Ledende overlæge for Forskningsenheden i Sygehus Syd Region Sjælland, dr.med Steen Boesby - Sygehusdirektør for Sygehus Syd Region Sjælland Svend Skov Jensen -Sundhedschef i Næstved Kommune, Dorthe Berg Rasmussen Baggrund Mange forhold er af betydning for udviklingen af folkesygdomme som blandt andet cancer, lungesygdomme, stofskiftelidelser, kredsløbssygdomme, sukkersyge og allergi. Der er tale om et kompliceret samspil mellem individuelle livsstilsfaktorer og psychosociale forhold og arv. Formål: 1. at lave en generel helbredsundersøgelse af den generelle befolkning svarende til Sygehus Syd i Region Sjælland med henblik på opsporing af ikke-erkendte sygdomme (sukkersyge, åreforkalkning, for højt/lavt stofskifte etc.), og at kortlægge risikofaktorer og sundhedsstilstanden hos borgerne. 2. at etablere en biobank med henblik på opbevaring af data (spørgeskemaundersøgelse, fysisk helbredsundersøgelse, blodprøver) til senere forskningsformål. Materiale Materiale (blod, spørgeskemaundersøgelse og helbredstest) fra borgere, som i forbindelse med en generel helbredsundersøgelse har givet samtykke til at deres data og blod må anvendes til forskning. Borgerne er fra optageområdet for Region Sjællands Sygehus Syd: Næstved, Lolland, Guldborgsund, Slagelse, og Vordingborg kommuner. Deltagerne er udvalgt gennem CPR-registret. Ca borgere vil blive inviteret. Det er realistisk at forvente en deltager-procent på ca. 65%, hvilket bygger på erfaringer fra en tidligere mindre undersøgelse i Næstved Kommune samt erfaringer fra Østerbroundersøgelsen. Med en deltagerprocent på 65% vil omkring møde frem, hvilket er tilstrækkeligt til at opnå den nødvendige videnskabelige kvalitet. For de aldersgrupper hvor ikke 100 % inviteres til undersøgelsen, inviteres lige dele mænd og kvinder med samme aldersfordeling. 1

190 Inklusionskriterier Deltagere Bopæl Mænd og kvinder 20 år. Gravide inkluderes (graviditeten registreres). Optageområde svarende til Region Sjælland Sygehus Syd Deltagere, skal selv kunne forstå den givne information og være i stand til at give et informeret samtykke. Eksklusionskriterier Voksne inhabile personer med værge. Tabel. Antal borgere over 20 år, antal inviterede borgere, og antal borgere ved 65% fremmøde Antal borgere* Antal inviterede borgere** 65% fremmøde Lolland Næstved Slagelse Vordingborg Guldborgsund Total Tallene er afrundede. *Antal borgere over eller lig med 20 år pr , Danmarks Statistik. **25% af og alle over 30. Metoder Blodprøver: DNA: Anerkendte molekylærbiologiske metoder som bla. PCR, gen-sekventering, microarray og high resolution melt. mrna studier: standardiserede metoder til gen ekspressions studier Standard biokemiske analyser: på standard laboratorieudstyr Følgende data, tests og undersøgelser vil blive indhentet fra hver deltager: Spørgeskema: Information om kardiovaskulær sygdom (bl.a. WHO-angina), tilstedeværelse af sygdom (herunder: lungesygdom, diabetes mellitus, cancer, venøs tromboemboli, thyroidea sygdomme), arvelige multifaktorielle sygdomme i familien(herunder: kardiovaskulær sygdom, lungesygdom, diabetes mellitus, cancer, venøs tromboemboli, thyroidea sygdomme), tobaksforbrug, kostvaner, forbrug af alkohol, kaffe, te og soft drinks, medicinforbrug, fysisk aktivitet, sol-eksposition, uddannelse, erhverv, indkomst og andre socioøkonomiske og psykosociale forhold (WHO-5 trivsel, MDI-danish for depression). Spørgeskemaet er desuden valideret ved brug i Østerbroundersøgelsen. Enheden For Brugerundersøgelser vil teste spørgeskemaet i foråret/sommeren Fysisk helbredsundersøgelse: Arm- og ankel-blodtryk, elektrokardiogram, perifer åreforkalkning målt med ultralyd, højde og vægt, lungefunktion, forureningsgrad af lunger, perifer iltmætning, 2

191 puls, hofte og talje mål, basal iltoptagelse, bioimpedansmåling til vurdering af kropssammensætning (dog ikke på gravide og deltagere med pacemaker), og hand grip. Biokemi: koagulationsudredning, hæmofiliudredning, nyrefunktion, leverfunktion, inflammationsmarkører, elektrolytter, proteiner, rødt og hvidt blodbillede, blod glukose, jern-status, hormoner, HbA1c, vitaminer, lipider, lipoproteiner, D-vitamin, kalk. Ekstra blod vil blive nedfrosset til -80 o C med henblik på senere analyser af andre potentielle risikofaktorer (100 ml), samt til: DNA: Ekstra fuldblod vil blive nedfrosset til -20 o C m.h.p. DNA-isolering. Dette giver mulighed for senere studier af enhver mutation i det humane genom. I alt ca. 40 ml. blod MessengerRNA: Ekstra fuldblod tilsat opbevaringsmedium vil blive nedfrosset til -80 o C m.h.p messengerrna isolering. Dette giver mulighed for senere studier af ekspression af gener. Ca. 10 ml. blod. Alle blodprøver (biokemi, DNA, og RNA) vil for de flestes vedkommende kunne tages i samme indstik. Undtagelsesvist kan man risikere at skulle stikke flere gange hvis ikke blodet løber så godt ud i glassene; men ønsker deltageren ikke flere indstik, respekteres dette. Alle blodprøver er ikkefastende. Statistik Konventionelle statistiske analyser vil blive anvendt. M.h.p. risikoberegning drejer det sig først og fremmest om Cox regressionsanalyser og logistiske regressionsanalyser. En population på i første omkring deltagere giver en stor statistisk styrke til: 1) finde selv små variationer i de undersøgte risikofaktorer 2) finde sjældne genvarianter 3) vekselvirkning mellem risikofaktorer (synergisme) 4) specielle subgrupper. Perspektiver En befolkningsundersøgelse af denne størrelse vil gøre det muligt for forskere de næste år internationalt at være absolut længst fremme i studiet af arveligheden af multifaktorielle befolkningssygdomme. Dette vil uden tvivl gavne danske patienter, pga. den øgede forståelse af hvem der vil få, og hvem der ikke vil få disse store multifaktorielle befolkningssygdomme. Den største fordel i befolkningsundersøgelsen i forhold til andre forskere er, at vi vil kunne undersøge effekter i almindelige mennesker i den almindelige danske befolkning (hvorimod de fleste andre forskere bruger patienter og kontroller), at befolkningen i undersøgelsen er meget vel karakteriseret, og at vi vil komme til at arbejde med en af de hidtil største grupper af deltagere (i verden) med DNA tilgængelig. Den største begrænsning i en befolkningsundersøgelse vil være for lidt statistisk power. Det er derfor af den absolut største betydning at befolkningsundersøgelsen i Region Sjælland Sygehus Syd etableres med de ca deltagere. % % % 3

192 Befolkningsundersøgelsen skal være longitudinel, dvs. med opfølgning med 5-10/15 års intervaller fremover. Den generelle befolkningsundersøgelse vil gøre det muligt at: 1. beskrive ændringer i niveauet i risikofaktorer over tid. 2. undersøge effekten af disse ændringer på udvikling (incidensen) af en lang række væsentlige sygdomme. 3. identificere nye risikofaktorer for sygdom, inklusiv genetiske ændringer og ændringer i specifik gen ekspression for både multifaktorielle sygdomme og sjældnere sygdomme. 4. undersøge effekten af konventionelle og nyere erkendte risikofaktorer i specielle sammenhænge og subpopulationer i form af interaktion (analyser af vekselvirkning). 5. kortlægge prævalensen af risikofaktorer og sygdom til sammenligning med resten af landet i øvrigt. Fremtidig forskning vil blandt andet blive: 1) At gennemføre en tværsnitsundersøgelse af den generelle befolkning med henblik på kortlægning af sygdoms- og sundhedsprofiler. 2) Opfølgende undersøgelser af den generelle befolkning forventes med 5-10/15 års intervaller. Man vil til den tid søge om tilladelse til fornyet dataindsamling via en tillægsprotokol. Man vil da igen indhente fornyet samtykke til den nye undersøgelse. 3) Case kontrol studier med andre etablerede patientgrupper som cases og den generelle befolkning som reference. 4) Prospektive studier med indhentning af oplysninger om sygdom og død via blandt andet Landspatientregisteret, Dødsårsagsregisteret, Cancerregistret, Medicin statistik registret med hensyn til opståen af sygdomme såsom: lungesygdom, kredsløbssygdomme, cancer, stofskiftelidelser, og andre sygdomme. Indhentning af disse oplysninger vil ca. ske en gang årligt. Såvel positive som negative resultater vil blive forsøgt offentliggjort i videnskabelige tidsskrifter. Udvælgelse, invitation og undersøgelser Forsøgspersonerne i den generelle befolkningsundersøgelse vil blive inviteret efter oplysninger om vitalstatus (i live og ikke død) og bopæl i CPR-registeret. Deltagerne vil i rækkefølge efter CPRnummer blive inviteret til undersøgelsen indenfor bestemte datoer. I tilfælde af udeblivelse inviteres på ny skriftligt. Undersøgelsen for Næstved Kommune finder sted på Klinisk Biokemisk Afdeling på Næstved Sygehus. Undersøgelserne for de øvrige kommuner finder sted på tilsvarende klinisk biokemiske afdelinger på de tilsvarende sygehuse beliggende i de enkelte kommuner. Deltagerne bedes udfylde et spørgeskema inden undersøgelsen. Den fysiske helbredsundersøgelse og blodprøvetagning vil blive udført af paramedicinsk personale. Undersøgelseskapaciteten er gennemsnitligt 50 deltagere per dag. Gennemførligheden af de anvendte metoder er vist i blandt andet Østerbroundersøgelsen, som er gentaget 4 gange. Næstved Kommune er den første som vil blive inviteret. Næstved Kommune undersøgelsen forventes påbegyndt medio 2009 og afsluttet når alle inviterede i Næstved Kommune er undersøgt (ca. 4 år efter, men dette vil afhænge af økonomi og ressourcer i øvrigt). 4

193 kontrolleret. Alle data vil løbende blive overført til et elektronisk medium og validitets- Indhentelse af informeret samtykke Den skriftlige information gives i deltager-informationen som udsendes før undersøgelsen. Deltager-informationen er den første kontakt til forsøgspersonen. Den mundtlige information gives af paramedicinsk personale ved den fysiske helbredsundersøgelse på undersøgelsesstedet, og gives således efter den skriftlige information. Dette overholder således retningslinierne i Videnskabsetisk Komites vejledning Retningslinier for mundtlig deltagerinformation : Det er den forsøgsansvarlige, der har ansvaret for informationen, men informationen kan gives af en person, som har de faglige forudsætninger for at kunne informere om forskningsprojektet og som har direkte tilknytning til dette, jf. 7, stk. 2 i informationsbekendtgørelsen. Retningslinierne skal gælde for den person, som i praksis giver informationen, dvs. den informerende sundhedsperson. Det sikres at informationssamtalen foregår uforstyrret i et aflukket rum. I invitationsbrevet fremgår at forsøgspersonen får mulighed for at få en bisidder med ved informationssamtalen. Såfremt forsøgspersonen ikke kommer til undersøgelsen, vil forsøgspersonen få tilsendt endnu et brev med invitation til eventuel deltagelse. Forsøgspersonen kan når som helst trække sit samtykke tilbage. Samtykket indhentes lige inden den fysiske helbredsundersøgelse begynder og efter den mundtlige information er givet. Risici, bivirkninger og ulemper Risici, bivirkninger og ulemper ved blodprøvetagningen er der informeret om i deltagerinformationen til forsøgspersonen. Blodprøvetagningen kræver et lille prik i armen og er ikke forbundet med nogen risiko, men i sjældne tilfælde kan der opstå et blåt mærke, som forsvinder efter få dage. Gravide og folk med pacemakere må ikke deltage i bioimpedansmålingen, i stedet vejes disse på en almindelig vægt. Den basale iltoptagelses-måling indebærer, at man ligger på en briks med en gennemsigtig glaskuppel over hovedet. På glaskuplen sidder en slange så man frit kan trække vejret ind og ud under undersøgelsen. Målingen består i at bestemme iltoptagelsen i hvile. Nogle deltagere vil finde denne undersøgelse ubehagelig (klaustrofobi etc.). Men der er intet farligt i undersøgelsen eller noget som gør ondt. Anmeldelse af projektet til Datatilsynet Projektet anmeldes til Datatilsynet. Oplysning om økonomisk støtte Ansøgerne har ingen kommercielle interesser. Forsøgspersonerne får intet vederlag. På ansøgningstidspunktet er projektet bevilget knap 2 millioner kroner fra diverse fonde. Såvel private som offentlige forskningsmidler vil i øvrigt blive søgt til finansiering. 5

194 Udtagning og opbevaring af biologisk materiale I forbindelse med projektet etableres en forskningsbiobank og en forskningsdatabase med biokemiske data, spørgeskemaoplysninger, data fra fysisk helbredsundersøgelse, samt data om sygdomsendepunkter indhentet fra bl.a. Landspatientregistret, Dødsårsagsregistret og Cancerregistret, Medicin statistik registret. Etik Forsøgspersonerne anmodes om mundtligt og skriftligt informeret samtykke til opbevaring af blodprøver og data til forskning. Opbevaring af blodprøver samt data vil finde sted i henhold til gældende regulativer fra Datatilsynet. Deltagelse i undersøgelsen er frivillig. Enhver forsøgsperson vil blive informeret i tilfælde af uventede fund, som måtte have helbredsmæssig betydning, medmindre forsøgspersonen tydeligt på samtykke-arket har markeret at han/hun ikke ønsker information om dette. Der er til undersøgelsen defineret såvel henvisningsgrænser (se bilag 1) som ringegrænser (bilag 2). Henvisningsgrænser er grænser for biokemiske variable, som umiddelbart måles på deltagerens blod inden det fryses ned, og hvor der er begrundet mistanke om eventuel ikke-akut underliggende sygdom, som der bør undersøges for. Deltageren vil få tilsendt et brev herom (bilag 3). Såfremt der er mistanke om sygdom, som der akut bør udredes for (eksempelvis leukæmi) ringes forsøgspersonen op såfremt forsøgspersonen har udtrykt ønske herom på samtykke-arket. Disse procedurer er også implementeret i andre befolkningsundersøgelser. Persondata bliver ikke anonymiseret i moder-databasen den database som kun styregruppen og de data-ansvarlige har adgang til (se Udtagning og opbevaring af biologisk materiale). Det er vigtigt og alt afgørende for projektet at kunne finde personnummeret igen af flere årsager: 1. for at kunne linke til forskellige registre 2. ved gen-indkaldelse til undersøgelse ved de førnævnte 5-10/15 års-intervaller. 3. såfremt man finder anledning til at måtte kontakte personen igen, hvis denne ønsker det (jf.samtykke-ark), ved væsentlige nye undersøgelses-fund. Der vil være en nøgle med personhenførbare data, der kobler forskningsdatabasen med deltagerne; men en forsker i et konkret projekt vil aldrig få oplyst denne nøgle. Anvendelse af nøglen må kun ske for styregruppens medlemmer og en data-ansvarlig. På baggrund af ovenstående beskrivelse af forsøget vurderes det, at den forventede gevinst for folkesundheden samt en minimal risiko ved deltagelse berettiger projektet. Fordelene for forskningen ved etablering af en generel befolkningsundersøgelse er der redegjort for i detaljer ovenfor. Vi mener projektet overholden "Lov om et videnskabsetisk komitésystem og behandling af biomedicinske forskningsprojekter", kap 5: Informeret samtykke Biomedicinske forskningsprojekter, der berører myndige personer 6

195 16. Komiteen kan kun meddele tilladelse til at indlede og fortsætte et biomedicinsk forskningsprojekt, hvis den myndige forsøgsperson har afgivet informeret samtykke. Forsøgspersonerne giver informeret samtykke Stk. 2. Komiteen kan kun meddele tilladelse til at indlede og fortsætte et biomedicinsk forskningsprojekt, hvis forsøgspersonerne, der deltager i projektet, skriftligt og mundtligt vil få oplysninger om projektets indhold, forudselige risici og fordele, og at der vil blive indhentet og givet informeret samtykke. Forsøgspersonerne har fået skriftlig og mundtlig information om projektets indhold, forudsigelige risici og fordele, og der er indhentet informeret skriftligt samtykke Stk. 3. Såfremt et registerforskningsprojekt, der skal anmeldes efter 8, stk. 3, for den enkelte forsøgsperson ikke indebærer sundhedsmæssige risici eller på anden måde efter omstændighederne i øvrigt kan være til belastning for den pågældende, kan komiteen bestemme, at projektet ikke er omfattet af stk. 1 og 2 eller 17, stk. 1 og 2. Komiteen kan endvidere bestemme, at et anmeldelsespligtigt registerforskningsprojekt ikke er omfattet af stk. 1 og 2 eller 17, stk. 1 og 2, hvis indhentning af informeret samtykke er umulig eller uforholdsmæssig vanskelig. Vi mener ikke at projektet et anmeldelsespligtigt registerforskningsprojekt (en spørgeskemaundersøgelse, registerforskningsprojekt, udtagelse af biologisk materiale, samt helbredstest) - indebærer sundhedsmæssige risici eller på anden måde kan være til belastning for de pågældende forsøgspersoner. Tværtimod vil det være i folkesundhedens interesse at få opklaret hvilke risikofaktorer, som disponerer til store befolkningssygdomme. Der er desuden indhentet informeret samtykke fra starten til forskning på samtykke-arket, hvor forsøgspersonerne kan markere, at de er indforstået med dette. Stk. 4. Komiteen kan kun meddele tilladelse, hvis det klart fremgår af informationen, at forsøgspersoner på ethvert tidspunkt kan tilbagekalde samtykket efter stk. 1. Dette fremgår af samtykke-arket. Stk. 5. Komiteen kan kun meddele tilladelse, hvis forsøgspersonen afgiver informeret samtykke, når personens væv i forbindelse med et konkret forskningsprojekt udtages med henblik på opbevaring i en forskningsbiobank. Forsøgspersonen giver informeret samtykke, når personens blod i forbindelse med projektet udtages med henblik på opbevaring i en forskningsbiobank. Vi mener med ansøgningen at opfylde hvad der ligger i begrebet et biomedicinsk forskningsprojekt jf. vejledningen fra Videnskabsetisk Komité: 2.1 Definition af et biomedicinsk forskningsprojekt. Et biomedicinsk forskningsprojekt defineres i komitélovens 7, som et projekt der indebærer forsøg på: 1. Levendefødte menneskelige individer 2. Menneskelige kønsceller, der agtes anvendt til befrugtning, menneskelige befrugtede æg, fosteranlæg og fostre 3. Væv, celler og arvebestanddele fra mennesker, fostre og lignende 4. Afdøde Ved et biomedicinsk forskningsprojekt forstås en aktivitet, der er tilrettelagt efter videnskabelig metode, og som tilsigter at frembringe ny, værdifuld viden om menneskets biologiske og psykologiske processer enten i forhold til raske mennesker eller for at forebygge, erkende lindre, behandle eller helbrede sygdom, sygdomssymptomer og smerter, herunder at påvirke legemsfunktioner. Biomedicinsk forskning er primært forskning inden for de lægevidenskabelige fag, den kliniske og den socialmedicinsk-epidemiologiske forskning. Begrebet omfatter, udover forskning af de 7

196 somatiske sygdomme, tillige de psykiatriske og de klinisk-psykologiske sygdomme og tilstandsformer. Herudover inddrages tilsvarende odontologisk og farmaceutisk forskning under begrebet. For projektets gennemførlighed er det vigtigt at understrege at samtykke til fremtidige forskningsprojekter uanset art er indhentet på undersøgelsestidspunktet som led i en helbredsundersøgelse. Samtykket er differentieret, således at man har mulighed for selv at vælge om blodet må gemmes til forskning eller ej. Dette er vigtigt af hensyn til videre analyse af data om morbiditet og mortalitet, idet det at skulle indhente samtykke efter indsamlingen af data ville introducere en betydelig bias, idet det jo kun ville være de raske eller overlevende som ville kunne give et informeret samtykke. Således ville prospektive studier blive upålidelige og værdiløse, og et projekt som dette ville være omsonst. Desuden ville årsager til potentielt dødelige sygdomme (herunder blandt andet brystkræft) aldrig kunne undersøges. Og det er netop muligheden for prospektive undersøgelser på sigt samt projektets størrelse, der her er styrken. 8

197 Figur 1. Styrkeberegning. Figuren viser det antal personer, der er nødvendigt i en befolkningsundersøgelse for at kunne finde givne risiko-estimater (x-aksen) ved forskellige genvariationer (Single Nucleotide Polymorphisms (SNP)) på 1%, 3%, og 10%. Forudsætningen for alle beregningerne er p=0,05, 80% power (styrke), og en sygdoms hyppighed (incidens) på 10%. Se også figur 2 med en sygdomshyppighed på 1 %. Number of participants Assumptions: p= % power, disease frequency 0.10 SNP frequency Hazard ratio 9

198

199 Region Sjællands Befolkningsundersøgelse - i Næstved SPØRGESKEMA Nr.: (skal ikke udfyldes) Vi vil bede dig besvare nogle spørgsmål, der først og fremmest drejer sig om dit helbred og livsstil. Du bedes besvare alle spørgsmål. Spørgsmålene besvares ved at sætte kryds i den rubrik, der passer bedst. Alle svar bliver behandlet fortroligt. Skal ikke udfyldes - Navn Adresse Postnummer & by Telefon nr. Praktiserende læges Navn Adresse Postnummer og by Svarene fra spørgeskemaet bliver skannet ind på en maskine; så alle tal og kryds skal være nemme at tolke som vist i nedenstående eksempler: 1

200 Fysisk aktivitet 1. Angiv din FYSISKE AKTIVITET UNDER ARBEJDET indenfor det sidste år (udfyldes også af hjemmegående, studerende og for tiden arbejdsledige, mens pensionister uden egentligt erhvervsarbejde bedes gå til spørgsmål 61.) (Sæt kun ét kryds) I. Overvejende siddende arbejde f.eks. skrivebordsarbejde, hjemmegående uden børn og med hushjælp II. Siddende eller stående, af og til gående f.eks. ekspedient, lærer. Hjemmegående, som selv vasker og gør rent, uden mindreårige børn III. Gående, af og til løften f.eks. postbud, plejepersonale. Hjemmegående, som selv vasker og gør rent, med ét eller flere mindreårige børn IV. Tungt kropsarbejde f.eks. flyttemand, jord/betonarbejder Hvis kryds ved III eller IV: Løfter du ofte tunge byrder? ja nej 2. Angiv din FYSISKE AKTIVITET I FRITIDEN (herunder transport til og fra arbejde) indenfor det sidste år (Sæt kun ét kryds) I. Næsten helt fysisk passiv eller let fysisk aktiv i mindre end 2 timer pr. uge f.eks. læsning, fjernsyn, biograf II. Let fysisk aktiv fra 2-4 timer pr. uge f.eks. spadsereture, cykelture, let havearbejde, let motionsgymnastik III. Let fysisk aktiv i mere end 4 timer pr. uge eller mere anstrengende fysisk aktivitet i 2-4 timer pr. uge f.eks. hurtig gang og/eller hurtig cykling, tungt havearbejde, hård motionsgymnastik, hvor man sveder eller bliver forpustet IV. Mere anstrengende fysisk aktivitet i mere end 4 timer pr. uge eller regelmæssig hård træning og evt. konkurrencer flere gange pr. uge Hvis kryds ved III eller IV: Indgår der vægtløftning eller tungere styrketræning? Ja Nej ja nej 3. Foregår din fysiske aktivitet i FRITIDEN hovedsageligt: indendørs udendørs 2

201 4. Har du inden for det sidste år ændret dine motionsvaner markant? ja nej Hvis Ja: Til mere motion Til mindre motion 5. Hvorledes bedømmer du din fysik i forhold til dine jævnaldrende? Kondition: Samme Bedre Dårligere Muskelstyrke: Samme Bedre Dårligere 6. Anfør antal timer du i gennemsnit sommer/vinter går, cykler, løber eller dyrker anden sport? GANG pr. dag Cykling pr. dag LØB pr. uge Anden sport pr. uge Aldrig < ½ time ½ - 1 time 1-2 timer 3-4 timer > 4 timer 7. Hvad er dit tempo? GANG CYKEL LØB Anden sport Langsomt Almindeligt Hurtigt Meget hurtigt 8. Kommer du til og fra arbejde (gerne flere krydser): til fods på cykel i bil/bus/tog andet 3

202 Sygdom 9. Får du smerter eller trykken i brystet, når du skynder dig, eller når du går på trapper? ja nej 10. Har du nogensinde været indlagt på hospital pga. blodprop i hjertet? ja nej 11. Har du nogensinde haft blodprop i hjertet uden at være indlagt på hospital? ja nej 12. Har du fået foretaget en by-pass operation i hjertet? ja nej 13. Har du fået foretaget en ballonudvidelse af hjertets kranspulsåre? ja nej 14. Bliver du forpustet, når du skynder dig på gaden eller går op ad bakke? ja nej 15. Bliver du forpustet ved at følges med dine jævnaldrende ved almindelig gang? ja nej 16. Må du undertiden standse op for at få vejret, når du går på gaden i dit eget tempo? ja nej 17. Vågner du undertiden om natten pga. åndenød/besværet vejrtrækning? ja nej 18. Bliver du forpustet, når du vasker dig eller klæder dig på? ja nej 19. Har du åndenød, når du sidder stille/i hvile? ja nej 20. Er du ofte generet af åndenød? ja nej 21. Hoster du af og til i forbindelse med anstrengelse? ja nej 22. Hoster du slim op (om morgenen eller i løbet af dagen)? ja nej Hvis ja: hvor mange måneder i træk per år? 23. Har du i lange perioder af dit arbejdsliv været udsat for støv/svejserøg? ja nej 24. Har du af og til pibende eller hvæsende vejrtrækning? ja nej Hvis ja: I forbindelse med forkølelse? I forbindelse med anstrengelse? Uden kendt årsag? ja nej ja nej ja nej 25. Har du allergi overfor: ja nej a) fødevarer? ja nej b) medicin? ja nej 4

203 c) pollen? ja nej d) dyrehår? ja nej 26. Har du høfeber? ja nej Hvis ja: hvor mange år har du haft høfeber? 27. Har du eksem? ja nej Hvis ja: hvor mange år har du haft eksem? 28. Har du astma? ja nej Hvis ja: Hvor mange år har du haft astma? 29. Har du inden for de sidste 10 år haft lungebetændelse, som har medført lægebesøg og/eller sygefravær fra arbejdet? Nej Ja, 1-5 gange Ja, 6-10 gange Ja, mere end 10 gange 30. Har du nogensinde haft blodprop i hjernen eller hjerneblødning? ja nej 31. Har du inden for de sidste 10 år haft: a) lammelser, nedsat kraft eller styringsbesvær af ansigt, arme eller ben? ja nej b) blindhed eller synstab for et eller begge øjne? ja nej c) taleforstyrrelser, besvær med at finde eller udtale ordene? ja nej Ja Nej 32. Får du smerter i ét eller begge ben: a) når du begynder at gå? ja nej b) når du har gået et stykke? ja nej Hvis ja: Må du standse, når du har gået lidt? ja nej Hvis ja: Forsvinder smerterne da, hvis du standser? ja nej 33. Har du haft akut febersygdom, bronkitis eller blærebetændelse indenfor de sidste 4 uger? ja nej 34. Har du sukkersyge? ja nej 5

204 Hvis ja: Hvor gammel var du, da det blev konstateret? Alder: år 35. Har du eller har du haft kræft? ja nej Hvis ja: hvor gammel var du da kræften blev konstateret? Alder: år 36 Har du eller har du haft galdesten? ja nej Hvis ja: hvor gammel var du da galdestene blev konstateret? Alder: år 37. Har du haft en blodprop i benet? ja nej Hvis ja: hvor gammel var du da det blev konstateret? år 38. Har du haft en blodprop i lungen? ja nej Hvis ja: Hvor gammel var du da det blev konstateret? år 39. a) Er du bloddonor? ja nej b) Hvis NEJ: Har du været bloddonor? ja nej Hvis ja til enten 39a eller 39b: Hvor mange år har du været donor? Hvis ja til enten 39a eller 39b: Hvor mange tapninger har du fået foretaget per år? flere : skriv 40. Har en læge fortalt dig, at du har arvelig tendens til at danne blodpropper? ja nej 41. Har du (sæt kun et kryds): åreknuder på kun det ene ben? åreknuder på begge ben? Ja Nej ingen åreknuder? Hvis du har åreknuder: Hvor gammel var du, da du fik de første åreknuder? år 42. Har en læge fortalt dig, at du har: a) for højt stofskifte? ja nej b) for lavt stofskifte? ja nej 43. Hvor meget vejede du cirka, da du var 20 år? KG 44. Hvor meget vejede du, da du blev født? angiv i gram 6

205 Jeg kender ikke min fødselsvægt nøjagtigt, men jeg mener, jeg vejede: Mindre end 2500 gram? 2500 gram-4500 gram? Mere end 4500 gram? Jeg ved ikke, hvad jeg vejede, da jeg blev født? Kun for kvinder - Mænd bedes gå til spørgsmål Er dine menstruationer holdt op? ja nej Hvis ja: Hvor gammel var du, da menstruationerne holdt op? Alder: år 46. Hvor mange børn har du født? 47. Hvis du har født børn, har du da ammet? ja nej Hvis ja: hvad er det samlede antal måneder du har ammet i alt? 48. Hvis du har født børn, hvor gammel var du da dit første barn blev født? alder år 49. Har du haft en spontan abort (dvs. hvor aborten ikke blev gjort medicinsk eller kirurgisk)? ja nej Hvis ja, hvor mange spontane aborter har du haft indtil nu? Rygning 50. Ryger du? ja nej Hvis nej: Har du da tidligere røget? ja nej Hvis du aldrig har røget bedes du gå til spørgsmål Hvor mange år har du røget? år 52. Hvor gammel var du, da du begyndte at ryge? år 53. Hvis du har røget, hvor gammel var du, da du holdt op med at ryge? år 54. Hvis du ryger eller har røget, hvor stort er/var dit gennemsnitlige forbrug af: Cigaretter med filter Antal pr. dag: 7

206 Cigaretter uden filter Antal pr. dag: Cerutter Cigarer Antal pr. dag: Antal pr. dag: Pibetobak Antal pk. á 40/50 g pr. uge: 55. Inhalerer/inhalerede du? ja nej 56. Bruger du nikotin-erstatning (tyggegummi, plaster, skrå eller lignende)? ja nej Hvis ja: Hvor mange år har du brugt det? år 57. Røg en eller begge dine forældre i dit barndomshjem? ja nej 58. Røg din mor, da hun var gravid med dig? ja nej 59. Hvor mange timer pr. dag er du udsat for passiv rygning (dvs.tobaksrøg fra omgivelserne)? Kost og drikkevarer 60. Hvor meget mælk eller mælkeprodukt drikker/spiser du i gennemsnit per uge (også inklusiv det du bruger på havregryn, cornflakes, i mad og lignende): Sødmælk: glas Skummetmælk: glas Let-/minimælk: glas Kærnemælk: glas Laktosefri mælk: glas 61. Hvor meget drikker du i gennemsnit per uge: Kaffe: kopper Sodavand med sukker: á ½ L Øl: flasker Rødvin: glas Thé: kopper Sodavand uden sukker: á ½ L Hvidvin: glas Hedvin/likør: glas Spiritus (ikke alco-pops): genstande 8

207 Alco-pops (dvs. mixede drinks med en alkohol-procent på ca. 5%; eks.barcadi Breezer): flasker 62. Spiser du hver dag eller næsten hver dag: a) Morgenmad? ja nej b) Frokost? ja nej c) Aftensmad? ja nej Hvor mange mellemmåltider spiser du normalt pr. dag? Hvor mange stykker rugbrød spiser du normalt i løbet af en dag? Hvor mange stykker hvidt brød spiser du normalt i løbet af en dag? (Et stykke brød = 1 stk. franskbrød, 1 stk. knækbrød el. 1/2 bolle) 66. Hvilket fedtstof bruger du for det meste på brød? (kun ét kryds) Ingenting Smør Blandingsprodukter Plante- margarine Minarine Olie Andet 67. Hvor mange gange spiser du nedenstående former for pålæg i gennemsnit per uge? (eksempel: ost 2 gange hver dag i 7 dage: 14 ) Kødpålæg: Leverpostej: Fiskepålæg: Ost: 68. Hvor mange gange spiser du nedenstående former for varm mad i gennemsnit per uge? Okse/kalvekød: Svinekød: Fjerkræ: Fisk: Lam: Fastfood: 69. Hvilken form for fedtstof bruger du for det meste ved tilberedning af varm mad? (kun ét kryds) (*blandingsprodukt: eks. Kærgården eller Bakkedal) Intet Smør Blandingsprodukt* Stegemarg. Plantmarg. Minarine Olie Andet 9

208 70. Hvor mange gange spiser du grøntsager (eksempelvis som mellemmåltid, del af morgenmad el. frokost, eller større ingrediens i den varme mad) per uge? (eksempel: 4 gange dagligt hver dag i en uge: 28 ) 71. Hvor mange gange spiser du frugt (eksempelvis som mellemmåltid, del af morgenmad el. frokost, eller dessert) per uge? (eksempel: 4 gange dagligt hver dag i en uge: 28 ) 72. Hvor mange hele æg spiser du per uge (hele æg, som pålæg, spejlæg, røræg, og lignende)? 73. Hvilke af følgende fødevarer spiser du økologisk eller ikke-økologisk (et kryds per række)? Økologisk Overvejende økologisk Overvejende ikkeøkologisk Ikke økologisk Spiser ikke fødevaren Grøntsager (inkl.kartofler) Frugt Mælk Brød, gryn, musli Kød Fisk Æg Ris, pasta Uddannelse, erhverv, bopæl 74. Hvor mange år har du gået i skole? (folke-, realskole, gymnasium, studenter-/ HF-kursus): 75. Hvilken uddannelse har du fuldført, siden du forlod skolen? (kun ét kryds) Ingen uddannelse Erhvervsfaglig eller tilsvarende uddannelse (1-3 år) (eks. Lægesekretær, barneplejerske, landmand med grønt bevis, laborant, social- og sundhedsassistent, sygehjælper, teknisk tegner, frisør gartner) Kort videregående uddannelse (indtil 3 år) (Eks.Apoteksassistent, børnehave- og fritidspædagog, maskintekniker, merkonom, politibetjent, socialpædagog) 10

209 Mellemlang videregående uddannelse (3-4 år) (eks. Folkeskolelærer, ergoterapeut, sygeplejerske, journalist, HA- og HDuddannelse, socialrådgiver.) Lang videregående uddannelse/universitetsuddanelse (5-6 år) (eks. Civilingeniør, jurist, cand.mag., læge, arkitekt, tandlæge) 76. Hvilken uddannelse er du i gang med? (kun ét kryds) Ingen uddannelse Erhvervsfaglig eller tilsvarende uddannelse (1-3 år) Kort videregående uddannelse (indtil 3 år) Mellemlang videregående uddannelse (3-4 år) Lang videregående uddannelse/universitetsuddanelse (5-6 år) 77. Hvad er din erhvervsmæssige stilling? (ét kryds) Beskæftigede Selvstændig erhvervsdrivende Lønmodtager Medhjælpende ægtefælle Anden beskæftigelse Arbejdsløs Arbejdsløs eller i aktivering Uddannelsessøgende Lærling Studerende Skoleelev Pensionister Alderspensionist Førtidspensionist Efterlønsmodtager Andre Hjemmegående husmor/husfar Værnepligtig I revalidering 78. Bor du: Sammen med ægtefælle/samlever Alene Med andre 79. Hvor mange børn har du? Langtidssyg (3 mdr. eller mere) På kontanthjælp, bistandshjælp Andet 80. Hvor mange personer omfatter husstanden inkl. dig selv? 81. Har du husdyr (hund, kat, fugl, gnaver eller andet)? ja nej 11

210 82. Bruger du brændeovn som varmekilde i dit hjem? ja nej 83. Blev brændeovn brugt som varmekilde i dit barndomshjem? ja nej 84. Er du: Gift/samlevende Ugift Separeret/fraskilt Enke/enkemand 85. Hvad var din husstands samlede indkomst før skat sidste år? (sæt kun ét kryds) Mindre end kr. Mellem kr. og kr. Mellem kr. og kr. Mellem kr kr. Mellem kr. og kr. Mellem kr. og kr. Mellem kr. og kr. Mellem kr. og kr. Mellem kr. og kr. Over/lig med kr. Ønsker ikke at svare 86. Hvor mange personer i husstanden bidrog til den samlede indtægt? 1 2 flere Trivsel og velbefindende 87. Nedennævnte spørgsmål handler om hvordan du har haft det gennem de sidste 2 uger. I de sidste 2 uger Hele tiden Det meste af tiden Lidt over halvdelen af tiden Lidt under halvdelen af tiden Lidt af tiden På intet tidspunkt a. har jeg været glad og i godt humør b. har jeg følt mig rolig og afslappet c. har jeg følt mig energisk d.er jeg vågnet frisk og udhvilet e. har min dagligdag været fyldt med ting, der interesserer mig 12

211 88. Nedennævnte spørgsmål handler om hvordan du har haft det gennem de sidste 2 uger. Hvor stor en del af tiden: Hele tiden Det meste af tiden Lidt over halvdelen af tiden Lidt under halvdelen af tiden Lidt af tiden På intet tidspunkt a. Har du følt dig trist til mode, ked af det? b. Har du manglet interesse for dine daglige gøremål? c. Har du følt at du manglede energi og kræfter? d. Har du haft mindre selvtillid? e. Har du haft dårlig samvittighed eller skyldfølelse? f. Har du følt, at livet ikke var værd at leve? g. Har du haft besvær med at koncentrere dig, f.eks. læse avis eller følge med i fjernsyn? h. Har du følt dig rastløs? i. Har du følt dig mere stille? j. Har du haft besvær med at sove om natten? k. Har du haft nedsat appetit? l. Har du haft øget appetit? 89. Hvor ofte har du kontakt - inklusiv telefonkontakt - med nedennævnte personer: Den del af familien, som du ikke bor med: Venner og bekendte: Hver dag Hver uge Hver måned Sjældnere Aldrig Har ingen Hver dag Hver uge Hver måned Sjældnere Aldrig Har ingen Hvor ofte ville du ønske, du havde mere kontakt med andre mennesker: Hver dag Hver uge Hver måned Sjældnere Aldrig Hvor mange har du, du virkelig kan tale 13

212 med om noget personligt: Ingen Mange Ophold i solen 90. Hvilken hårfarve har du? angiv den farve der kommer nærmest en af nedenstående valg (hvis du er gråhåret, hvidhåret eller har farvet hår, angiv da din oprindelige hårfarve) (kun et kryds) blond rød brun sort 91. Hvilken øjenfarve har du? angiv den farve der kommer nærmest en af nedenstående valg (kun et kryds) blå brun grøn grå 92. I løbet af sommermånederne, hvor mange timer opholder du dig dagligt i direkte sol mellem klokken i weekender eller ferie? aldrig mindre end 1 time 1 time 2 timer 3 timer 4 timer 93. I løbet af sommermånederne, hvor mange timer opholder du dig dagligt i direkte sol mellem klokken på hverdage? aldrig mindre end 1 time 1 time 2 timer 3 timer 4 timer 94. Hvor ofte blev du skoldet af solen i barndommen (kun et kryds) Aldrig mindre end 1 gang årligt 1 gang om året flere gange hvert år 95. Bruger du solcreme, når du opholder dig i solen? ja nej Hvis ja: Hvilken solfaktor bruger du hyppigst? 96. Har du nogensinde anvendt et solarium? ja nej Hvis ja, hvor mange gange i dit liv har du været i solarium? Mindre end 10 gange gange Mere end 50 gange 97. Hvilken uddannelse har/havde dine forældre (biologiske)? Mor Far Ingen uddannelse 14

213 Erhvervsfaglig eller tilsvarende uddannelse (1-3 år) Kort videregående uddannelse (indtil 3 år) Mellemlang videregående uddannelse (3-4 år f.eks. lærer, sygeplejerske e.l.) Lang videregående uddannelse (Universitetsuddannelse, 5-6 år) 98. Har dine forældre (biologiske) haft: Din Mor Din Far Ja Nej Ved ikke Ja Nej Ved ikke Blodprop i hjertet? Blodprop i hjernen/hjerneblødning? Blodprop i lungen/benet? Astma? Allergi? Sukkersyge? Forhøjet blodtryk? Forhøjet kolesterol i blodet? Kræft? Galdesten? Depression? Blødersygdom? 99. Har du indenfor de sidste 12 måneder søgt: Hvis ja, hvor mange gange: Praktiserende læge? Praktiserende speciallæge? Været på skadestue eller ambulatorium? Været indlagt på hospital? ja nej ja nej ja nej ja nej 15

214 100 Tager du daglig eller næsten daglig Hvis ja: Hvor mange forskellige Ja Nej præparater? Antal år i behandling flere a Blodtrykspiller b Hjertemedicin c Vanddrivende medicin d Medicin mod forhøjet kolesterol e Gigtpiller f Sovepiller g Nervepiller eller beroligende piller h Medicin mod mavesyre i Medicin mod astma/bronkitis j Insulin k Anden sukkersyge medicin l P-piller m Binyrebarkhormon n Hormonbehandling ved menopause o Piller/dråber mod øjensygdom p Smertestillende piller/medicin q Slankepiller r Vitaminpiller s Naturmedicin t D-vitamin u Medicin mod knogleskørhed v Kalk-tilskud w1 Jern-tilskud w2 Blodfortyndende (magnyl) x Blodfortyndende(marevan,marcumar,heparin) y Antidepressiv medicin (lykkepiller) z Medicin mod alkoholisme æ Medicin mod forhøjet stofskifte ø Medicin mod for lavt stofskifte å1 Potensmidler å2 Andre piller 16

215 AP - SKEMA nr. : A. Får de smerter eller ubehag i brystet, når De går i almindeligt tempo på gaden? ja nej B. Hvad gør De, hvis De får smerter og ubehag i brystet, når De går? Standser De eller sætter De farten ned? Går De videre i samme tempo? F C. Hvis De standser, hvad sker der så? Svinder smerterne? Svinder smerterne ikke? F D. Hvor hurtigt svinder smerterne? På 10 min.? På 10 min.? F E. Hvor ofte får De smerterne? Flere gange dagligt? Flere gange om ugen? Få gange om måneden? Meget sjældent? F. Tager De eller har De taget nitroglycerintabletter? Hvis nej, gå til H ja nej G. Hvor hurtigt virker nitroglycerin? På < 5 min.? På > 5 min.? Virker ikke? H. Har De søgt læge for Deres brystsmerter? ja nej Mange tak for hjælp med besvarelsen af spørgeskemaet! 17