InfoPartner. - software til ældreplejen. Synopsis:

InfoPartner - software til ældreplejen Synopsis: Denne rapport dokumenterer resultatet af udviklingsarbejdet i forbindelse med softwaresystemet InfoPartner. Denne software er beregnet til brug i plejesektoren, og mere specifikt på plejehjem. InfoPartner er en del af innovationskonsortiumet IntelliCare, som ønsker at løse problemstillinger i plejesektoren ved hjælp af ny teknologi. Rapportens formål er at finde en brugbar arkitektur, der er fleksibel og simpel, for InfoPartner. Den valgte arkitektur for InfoPartner er dokumenteret gennem rapporten, og der er redegjort for fordele og ulemper ved den valgte arkitektur. Det udviklede system, InfoPartner, benytter sig af et Blackboard-mønster. InfoPartner, er lavet som en prototype, hvor tre simple komponenter er implementeret. Det være sig et kommunikations komponent, en simpel webbrowser, samt en netværkskontrollør. Engelsk titel: InfoPartner - software for the elder care Udarbejdet af: Emil Holmegaard - 090387-2497 [emhol07@student.sdu.dk] Vejleder: Kasper Hallenborg [hallenborg@mmmi.sdu.dk] Undervisningsinstitution: Syddansk Universitet - Det Teknisk Fakultet Mærsk McKinney Møller Instituttet Kursus: RB-BAP6-E1: Bachelorprojekt Projektperiode: 01-02-2010-01-06-2010

Indhold I Forord iv II Læsevejledning III Ordliste v vi 1 Indledning 1 1.1 Problemstillinger.................................. 1 1.2 Problemformulering................................ 2 1.3 Problemafgrænsning................................ 2 1.4 Mål med projektet................................. 2 2 Overvejelser 3 2.1 Desktop-baseret applikation............................ 3 2.2 Web-baseret applikation.............................. 3 2.3 Sammenligning og valg af programmeringsplatform............... 4 2.4 Delkonklusion på valg af softwareløsning..................... 5 3 Komponenter til InfoPartner 6 3.1 Komponentkatalog................................. 6 3.1.1 Login.................................... 6 3.1.2 PatientJournal............................... 6 3.1.3 Personlig status............................... 7 3.1.4 Underholdning............................... 7 3.1.5 Kommunikation.............................. 8 3.1.6 Kalender.................................. 8 3.2 Plug and play software............................... 8 3.3 Delkonklusion for fleksibelt software....................... 9 4 Arkitektur 10 4.1 Brugbare og ikke-brugbare arkitekturer..................... 10 4.2 Blackboard..................................... 10 4.3 Serviceorienteret Arkitektur............................ 11 4.4 GUI arkitektur................................... 12 4.5 Delkonklusion på arkitektur............................ 13 5 Produktet 14 5.1 Arkitektur...................................... 14 5.2 Implementerede komponenter........................... 15 5.2.1 Netværkskontrollør............................. 15 5.2.2 Webbrowser................................. 15 5.2.3 Kommunikation.............................. 16 5.3 GUI......................................... 16 i

5.4 Skype eksempel................................... 17 5.5 Delkonklusion for produktet............................ 20 6 Anvendte teknologier 21 6.1 Hardware benyttet til InfoPartner........................ 21 6.1.1 Fremtidige muligheder........................... 21 6.2 Windows Presentation Foundation - WPF.................... 22 6.3 ClickOnce...................................... 23 6.4 Skype........................................ 23 6.5 Delkonklusion anvendte teknologier........................ 24 7 Fremtidige muligheder med InfoPartner 25 7.1 Bruger tilvalg af komponenter........................... 25 8 Epilog 26 8.1 Konklusion..................................... 26 8.2 Perspektivering................................... 26 A Klassediagram B Oversigt over vedlagt cd a b C Referenceliste c C.1 Bøger........................................ c C.2 PDF......................................... c C.3 Hjemmesider.................................... c ii

Figurer 4.1 Blackboard mønsteret, i sin traditionelle form. Kilde: [Shacklette] s.[15].... 11 4.2 Serviceorienteret Arkitektur (SOA), hvor der er fire systemer, A,B,C,D. Kilde: forelæsning med Ingo Nielsen den 18. maj kl. 12.30-14 i D116, Niels Bohrs Alle 1............................................ 12 5.1 Pakkestrukturen i InfoPartner........................... 14 5.2 Skærmbillede af GUI en som den er lavet i prototypen. De grå bokse, indikere de forskellige frame-elementer............................ 16 6.1 Model View View-Model arkitekturen bag WPF. Kilde: [hugeonion.com] 25/05 2010.......................................... 22 6.2 Interaktion mellem Skype og InfoPartner. Kilde: [W.J.Campbell05] s.[6].... 23 A.1 Klassediagram for InfoPartner........................... a Tabeller 2.1 Sammenligning i kort form mellem en web-baseret applikation og en desktop applikation................................ 4 6.1 Specifikationer for EeeTop PC(Kilde: [asus.com], 08/02 2010 ), hvor InfoPartner ønskes afviklet på......................... 21 iii

I. Forord Denne rapport er en teknisk rapport, med fokus på softwareudvikling. Rapporten er skrevet i forbindelse med bachelorprojketet InfoPartner - software til ældreplejen. Der er primært benyttet viden fra kurserne Systemudvikling og programmering, Statistik i programudvikling, samt dele af kurset XML, Web Service Technologies and Web Services. Målgruppen for denne rapport er primært, personer med interesse i softwareudvikling og velfærdsteknologi. Jeg vil gerne takke vejleder Kasper Hallenborg for samarbejdet i projektperioden. iv

II. Læsevejledning Rapporten er en teknisk rapport omkring udviklingen af en software applikation, og vil derfor være opbygget på følgende måde. Der vil først og fremmest være en indledning til problemstillingen, dernæst følger to kapitler, som vil fungere som en slags krav- og analyse-diciplin som den er kendt fra Unified Process, derefter følger to kapitler som vil fungere som designog implementations-disiplin, hvorefter der vil være et kapitel omkring den anvendte teknologi og slutteligt en konklusion. Forord, læsevejledning samt ordliste vil være nummereret med romerske tal i kapitel og sidetal vil være romerske tal som ikke er i kapital. Hovedrapporten vil være nummereret med tal og sidetal vil også være tal. Bilag vil være nummereret med store bogstaver og sidetal vil være små bogstaver. På side vi er en ordliste, med forklaringer på ord som vil optræde i rapporten. Fodnoter vil blive brugt til litteraturhenvisninger, samt uddybende forklaringer eller udskrivning af forkortelser. Fodnoter vil starte fra 1, ved ny kapitelstart. Litteraturhenvisninger vises på følgende måde, [forfatter+udgivelsesår] kap:[kapitel der henvises til] s.[sidetal der henvises til]. Et eksempel kunne være [MacDonald08] kap.[1] s.[1], hvor der henvises til Matthew MacDonald s Pro WPF in C# 2008 - Windows Presentation Foundation with.net 3.5 kapitel 1 på side 1. Når der henvises til en hjemmeside vil det være på følgende måde, [domænenavn], dd/mm yyyy. Et eksempel kunne være [intellicare.dk], 20/03 2010, hvor der henvises til intellicare.dk hvor siden er besøgt den 20/03 2010. På cd en er vedlagt de PDF-filer som der henvises til. En fuld referenceliste er i kapitel C på side c. Oversigt over indholdet på den vedlagte cd, kan ses i kapitel B på side b. v

III. Ordliste Ord API Avatar Forklaring Application Programming Interface, en grænseflade som stilles til rådighed, således at applikationsudviklere kan se hvilke services der kan benyttes, samt hvordan. Grafisk repræsentation af en person eller figur på nettet. C# eller C-sharp Et programmeringssprog udviklet af Microsoft. GPU GUI Middleware.NET RFID RFID-tag Smartphone XAML XML Grapics Processing Unit, grafikkortets enhed til at håndtere beregninger brugt til 3D og 2D grafik. Graphical User Interface, på dansk grafisk brugergrænseflade. Software som stiller en service til rådighed, men som ikke er en del af operativsystemet. Middleware skal stille et API til rådighed, således der er mulighed for at benytte servicen korrekt. Det miljø, som C# skrives i..net er et abstraktionslag over operativsystemet, hvilket betyder at services kan benyttes, selvom det ikke er den samme version af operativsystemet, der benyttes. Radio-Frequency Identification En lille chip, som modtager et radio signal, der sendes tilbage sammen med et id fra chippen. Advanceret mobiltelefon som kan håndtere emails, internet browsing, GPS med mere. extensible Application Markup Language, som er det beskrivende sprog der benyttes i Windows Presentation Foundation, til at beskrive grafiske elementer. extensible Markup Language, et sprog til at strukturere informationer. vi

1. Indledning Dette projekt omhandler et underprojekt under Intellicare, nemlig InfoPartner. IntelliCare er et innovationskonsortium, der ønsker at løse problemstillinger i plejesektoren med teknologi. IntelliCare består af 17 partnere, hvoraf Syddansk Universitet (SDU) er en af dem. IntelliCare har tre hovedområder indenfor plejesektoren, hvor de ønsker at hjælpe, disse tre områder er 1 : Frihed/mobilitet - forbedre de ældres livskvalitet gennem større frihed. Information - øge de ældres tryghed i form af nem adgang til information samt lette plejepersonalets håndtering af information. Knappe ressourcer - optimere brugen af ressourcer i dagligdagen fx gennem brug af servicerobotter. InfoPartner er en informationsskærm, hvor ældre og plejepersonale skal kunne tilgå den information der søges. InfoPartner er ikke kun tiltænkt ældreplejen, men også på sygehuse, hvor personalet skal kunne tilgå den elektroniske plejejournal. InfoPartner kan i fremtiden hjælpe plejepersonale på sygehuse og plejehjem, da den tænkes som et supplement til alarmsnoren. Hvis der benyttes en computer med tilhørende webkamera, vil det give mulighed for at se hvad patienten har brug for. Det kunne være at en patient ønsker et glas vand, men ikke kan komme op af sengen, og personalet kan på baggrund af videosamtalen vurdere, hvor hurtigt de skal reagere. På den måde vil plejepersonalet bedre kunne disponere deres resourcer. InfoPartner vil kunne bruges til mange forskellige opgaver i plejesektoren, for eksempel vil den kunne bruges til at tilgå en patients journal, hvor det vil være muligt at ændre og eller tilføje informationer i journalen mens plejepersonalet er hos patienten. Det vil også være muligt at vise en patients aftaler på skærmen, således at patienten kan blive informeret, når vedkommende har en aftale. InfoPartner vil også kunne bruges til underholdning, såsom film og tv, samt interaktiv underholdning, som spil. Der er blevet arbejdet med InfoPartner blandt flere af IntelliCares partnere, blandt andet Teknologisk Institut, projekterne er endt op med flere prototyper, hvor man har vist hvad der er muligt med InfoPartner. De forskellige projekter er blevet udviklet på forskellige programmeringsplatforme og med forskellige arkitekture. 1.1 Problemstillinger InfoPartners primære brugere er ældre mennesker, hvilket vil sige det er en generation som ikke er opvokset med IT og computere. Dette giver nogle udfordringer, i form af at systemet skal være meget intuitivt og enkelt at bruge. Den sekundære bruger er plejepersonalet, ligeledes her gælder det om, at systemet er intuitivt at bruge, således at plejepersonalet ikke bruger unødvendig tid på at håndtere systemet. For at gøre systemet nemt at bruge, kan der sættes restriktioner på navigationsdybden, eller at layoutet skal være ensartet. På den måde vil systemet blive mere overskueligt og nemmere at bruge. I forbindelse med at InfoPartners primære brugere kan være svækkede eller svagsynet kan der være et behov for at vise informationer forskelligt til den enkelte bruger. Der kan altså være behov for at tilpasse systemet efter hver enkelt slutbruger. InfoPartner skal kunne håndtere mange forskellige opgaver, det være sig redigering af patientjournaler til at vise tv. Det betyder at arkitekturen for systemet ikke er ens for alle opgaver, og der kan ske ændringer med de opgaver der ønskes løst med InfoPartner. Det betyder dels at der skal findes en måde hvorpå InfoPartner kan opdateres på klienterne fra et centralt sted. 1 Kilde [intellicare.dk], 20/03 2010 1

Det betyder også at arkitekturen bør være simpel, således at den grundlæggende arkitektur ikke sætter begrænsninger for de komponenter der ønskes udviklet og implementeret til InfoPartner. Da InfoPartner skal kunne bruges i plejesektoren samt på sygehuse, vil der være forskellige komponenter, afhængigt af hvilket miljø InfoPartner placeres i, dog vil der være mange ligheder. Det vil derfor være en fordel hvis der er mulighed for at tilføje og fjerne komponenter efter behov. Derudover vil det være praktisk at man, når der er udviklet nye komponenter kan tilføje disse til InfoPartner. 1.2 Problemformulering Hvilke muligheder er der for at lave en arkitektur til InfoPartner, som kan løse de i problemstillingen nævnte problemer? Af problemstillingen kan uddrages følgende krav til systemet: Nemt for brugeren Individuel tilpasning Fleksibilitet Simpel arkitektur Disse krav skal danne grundlaget for den arkitektur der ønskes til InfoPartner. Dette projekt har til formål at finde en brugbar arkitektur for InfoPartner. Udover disse krav, bør de tidligere projekter med InfoPartner studeres, således styrker og svagheder fra disse projekter kan medvirke til en god arkitektur. 1.3 Problemafgrænsning Da dette projekt er af et større omfang, end hvad der kan nåes indenfor dette projekts tidsrammer, afgrænses problemet. For ikke at skulle fokusere alt for meget på den grafiske brugergrænseflade(gui), er de to første punkter i kravene fra problemformuleringen tildels undladt, det være sig Nemt for brugeren og Individuel tilpasning. Dog er kravene ikke fuldstændigt undladt, da der er bygget et proof of concept af brugergrænsefladen. Projektet vil undersøge hvordan der kan laves en arkitektur til InfoPartner som gør det muligt at tilføje komponenter fleksibelt, samtidigt med at arkitekturen er simpel. 1.4 Mål med projektet Dette projekt skal ende op med en brugbar arkitektur for InfoPartner, som gør det muligt at udvikle nye komponenter til InfoPartner uden at skulle lave om på det eksisterende system. Derfor vil de tidligere projekter blive studeret, og taget med i overvejelserne. Der vil blive lavet en liste med komponenter, der ønskes udviklet til InfoPartner. 2

2. Overvejelser For at kunne lave en arkitektur for systemet, må et valg af programmeringsplatform træffes. Herunder hvordan systemet kan opdateres og vedligeholdes. Overvejelser omkring mere system specifikke opgaver såsom adgangsforhold og pasistensforhold vil ikke blive beskrevet her. 2.1 Desktop-baseret applikation Ved at lave en desktop applikation, bør laves en overvejelse om programmeringssproget, skal være uafhængigt af hvilket operativsystem klienten bruger, eller ej. Af programmeringssprog kan nævnes Java og C#, hvor Java er operativsystem-uafhængigt og hvor C# kun kan afvikles på et Windows operativsystem. Begge programmeringssprog er objekt-orienterede, og der er derfor ikke den helt store forskel, dog kan det nævnes at der i programmeringssproget C# er mulighed for at bruge Windows Presentation Foundation(WPF) som benytter DirectX til at afvikle grafik 1, hvilket kan udnytte grafik-hardware til afvikling af grafik elementer. Dette giver mere processor-kraft til at afvikle forretningslogik. Læs mere om WPF i kapitel 6.2 på side 22. En ulempe ved at lave en desktop applikation, er når programmet skal installeres på mange computere eller skal opdateres, da det ofte er nødvendigt at være fysisk tilstede for at installere og opdatere. Ved brug af Java, har Sun 2 udviklet et system til at udrulle og opdatere software skrevet i Java, systemet hedder Java Web Start 3. Ligeledes har C# også et system til at udrulle og opdatere software udviklet i C#, dette system hedder ClickOnce 4. Læs mere om ClickOnce i kapitel 6.3 på side 23. Hvad angår vedligeholdelse af en desktop applikation, afhænger det af hvordan softwaren er skrevet fra start. Hvis arkitekturen for softwaren er skrevet som en åben og løs arkitektur, kan det ofte være svært at vedligeholde et system, da afhængigheder mellem de enkelte klasser kan være svære at gennemskue 5. Det vil sige at vedligeholdelsen afhænger af hvilken form for arkitektur udvikleren har valgt fra starten af softwareudviklingen på systemet. De udvidelsesmuligheder der er for en desktop applikation, kan være den hardware som softwaren afvikles på, samt de evner som softwarearkitekten og softwareprogrammøren har. Med andre ord er udvidelsesmulighederne nærmest ubegrænsede. Ydeevnen for en desktop applikation, afhænger ofte af den hardware hvor softwaren afvikles på. Ydermere afhænger det af hvor godt programmet er skrevet, men denne faktor kan være på alle former for software. 2.2 Web-baseret applikation En web-baseret softwareløsning, er ikke krævende fra klientens side, da der kun skal benyttes en internetforbindelse og en internet-browser på klientens side. I og med der kun skal benyttes en internet-browser, kan denne løsning antages for at være uafhængig af hvilket operativsystem som klienten benytter. Ved opdatering af løsningen, skal denne opdatering kun foretages én gang på den web-server som benyttes til at hoste løsningen. I forbindelse med at vedligeholde en web-baseret løsning, kan det ofte være besværligt, da en web-løsning ofte ikke er struktureret, det vil sige man ikke har noget klart overblik, over hvilke filer, der har hvilket tilhørsforhold. 1 [MacDonald08] kap.[1] s.[2] 2 Sun Microsystems er udviklerne bag Java. 3 Kilde: [java.sun.com], 15/02 2010 4 Kilde: [msdn.com], 15/02 2010 5 [Maciaszek et al.] kap.[9.1.9] s.[273] 3

En web-baseret løsning har visse begrænsninger når ydeevnen skal findes. Der er en begrænsning i form af klientens internetforbindelse, derudover kan der være en flaskehals i form af den, eller de, web-servere som løsningen skal afvikles på. En måde hvorpå en del af problemet med flaskehalse ved web-servere, er ved at benytte AJAX 6, som giver mulighed for at arbejde med det data, der er hentet fra web-serveren, uden at skulle vente på svar fra web-serveren. Hvad angår udviklingsmulighederne, kan en web-baseret løsning virke en smule begrænset, da programmeringssprogene PHP og JavaScript fx. ikke er i stand til at håndtere filer på klient siden. Dog har Mozilla Foundation 7 ansøgt om at man i den næste version af JavaScript får mulighed for at lave en begrænset tilgang til filer på klientens computer 8. Bag et andet forslag er at man gerne vil kunne tilgå hardwareenheder såsom oplysninger om computerens strømforsyning, netværkets båndbredde, tilgængelige lyd- og videocodecs samt mere specielle hardware enheder såsom temperatur og trykmåler mm. 9. Disse forslag kommer fra chip producenten Intel og Opera 10. Hvis disse forslag accepteres, giver det større muligheder med en web-baseret løsning, men disse forslag skal undersøges, således de ikke vil kunne bruges som en sikkerhedstrussel mod klienten. 2.3 Sammenligning og valg af programmeringsplatform For at kunne afgøre hvilken applikationsform der bør benyttes til InfoPartner, er det nødvendigt at have en sammenligning på nogle væsentlige punkter. Disse punkter er valgt på baggrund af [Bruegge et al.], hvor der i kapitel 6 beskrives nogle væstentlige designmål og overvejelser for design af software. Ud fra disse, er formuleret nogle punkter til at vurdere de to forskellige former for applikation. Operativsystem Web-baseret applikation Desktop-baseret applikation Uafhængigt Afhængigt(C#) Uafhængigt(Java) Udrulning af software Ikke nødvendigt Nødvendigt Opdatering af klient software Ikke nødvendigt Nødvendigt Vedligeholdelse af software (software maintenance) Begrænsninger for udvidelses muligheder Begrænsninger for ydeevne Uhåndterbart / besværligt Håndterbart / ukompliceret Kan ikke tilgå klient hardware Hardware understøttelse, forældet hardware Internetforbindelse og server hardware Klient hardware Største begrænsning Kan ikke tilgå hardware Hardware på klient Tabel 2.1: Sammenligning i kort form mellem en web-baseret applikation og en desktop applikation. Som det fremgår af tabel 2.1, har en web-baseret løsning mange fordele, såsom at være 6 AJAX - Asynchronous JavaScript and XML 7 Udviklerne af internet-browseren Firefox. 8 Kilde: [arstechnica.com], 01/03 2010 9 Kilde: [version2.dk/../javascript], 01/03 2010 10 Udviklerne af internet-browseren Opera. 4

uafhængigt af operativsystemet, og at det ikke er nødvendigt at opdatere software på de klienter som er tilmeldt systemet. Tilgengæld er der også nogle store begrænsninger ved at vælge en web-baseret løsning, da en web-baseret løsning ikke kan tilgå klientens hardware. Den begrænsning vil vise sig, hvis man vil lave en integreret TV-løsning, da man så er nødt til at levere TV-signalet gennem en internetforbindelse. Hvis et HDTV-signal 11 skal sendes over en internetforbindelse, kræves der en internetforbindelse på minimum 8Mbit/s 12 for at sende formatet 720p/50 13. Dette betyder at der kræves meget af internetforbindelsen, for at opnå en god kvalitet af TV-signalet. En af ulemperne ved at lave en desktop applikation, vil være i forbindelse med opdatering af systemet, da det kræver at hver klient opdateres individuelt. Dette er der fundet en løsning på, i form af Windows ClickOnce som er en del af.net-miljøet. Ligeledes kan ClickOnce benyttes til udrulning af software. En af fordelene ved en desktop applikation, er at softwaren kan benytte klientens hardware til at udføre opgaverne, hvor en web-baseret løsning vil kræve stigende regnekraft fra servere hvor applikationen afvikles, hvis antallet af brugere er stigende. 2.4 Delkonklusion på valg af softwareløsning Med de fordele og ulemper der er ved at vælge den ene løsning frem for den anden, vælges at lave en desktop applikation. Desktop applikationen vil kunne benytte klientens hardware, og dette vil give en bedre mulighed for at udvide systemet med flere brugere. Programmeringssproget vil blive C# med brug af WPF og ClickOnce. 11 High Definition TeleVision 12 [Tuxen09] s.[2] 13 Progressivt format med 720 billedlinjer og 50 helbilleder pr. sek. 5

3. Komponenter til InfoPartner For at kunne designe en softwarearkitektur, laves ofte krav-, og analysearbejde inden, jævnfør Unified Process(UP), dette arbejde udføres for at finde frem til forretningslogikken. I dette kapitel vil der være en form for analyse, som kan bruges som baggrund for et design af arkitekturen for InfoPartner. Analyse-delen vil ikke være som ved almindelig UP eller anden kendt softwareudvikling, da der i denne analyse ses på fællestræk ved komponenter som tænkes brugt i forbindelse med InfoPartner. Dette kapitel vil også indeholde et katalog over komponenter, der vil kunne implementeres til InfoPartner. 3.1 Komponentkatalog Herunder vil en del af de komponenter der kan udvikles og implementeres til InfoPartner blive listet. 3.1.1 Login Alle systemer har brug for et login system, nogle mere komplicerede end andre, afhængigt af hvilke oplysninger der kan opnås adgang til. På InfoPartner vil den primære bruger ikke umiddelbart skulle logge ind, da det ikke forventes, at der vises personfølsomme oplysninger på skærmen. Den sekundære bruger, altså plejepersonalet, vil derimod være nødt til at logge ind, da den sekundære bruger skal kunne tilgå patientjournal med mere, som indeholder personfølsomme oplysninger. Login komponenten vil kunne opbygges som to mindre systemer, et system til at identificere brugeren som logger ind, og et til at verificere adgangskontrollen. Hvis komponenten deles på denne måde, vil det i fremtiden være nemmere at skifte måden hvorpå man logger ind. En måde at identificere sig på, kunne være ved hjælp af et RFID-tag. Til at starte med kan det være, at det er nok kun at benytte RFID-tags, således at tag ets ID også bruges som adgangskontrol, hvis det findes i databasen over ID er med adgang. På et senere tidspunkt vil man så gerne øge sikkerheden, ved for eksempel at skrive under på skærmen. I dette tilfælde vil det være nemmere, kun at skulle skifte det system, som verificere adgangskontrollen, frem for at skulle skrive hele komponenten om. Med tiden bliver RFID-tags billigere, og kan indeholde mere data, hvilket betyder at man kan lægge oplysninger om ejeren af RFID-tagen ned i selve chippen 1. Hvis oplysninger om ejeren ligger på chippen, vil man kunne undgå at lave kald til databasen for at få disse oplysninger. Her vil det være systemet som identificere brugeren, som skal laves om, hvis man vælger at benytte nogle RFID-tags med mere hukommelse på et tidspunkt. Komponentens opgave vil være at identificere brugeren, herunder at angive hvilke adgangsforhold brugeren har, samt oplysninger om brugeren som navn, stilling, afdeling med mere. Derudover skal komponenten kunne verificere adgangskontrollen, for eksempel i form af kodeord, genkendelse af tegning på skærmen eller anden form for kontrol. 3.1.2 PatientJournal En af de vigtigste komponenter, til InfoPartner når den skal bruges på sygehuse, vil være PatientJournal. Denne komponent skulle gerne kunne effektivisere stuegangen på de danske sygehuse. Komponenten vil gøre det muligt at læse, skrive og ændre i den elektroniske patientjournal. Hvilket betyder at en læge ikke skal læse en journal inden stuegang, under stuegang skrive en notits, og efter stuegang tilføje denne notits til patientens journal. Hvis InfoPartner 1 Kilde: [rfid-specialisten.dk], 20/05 2010 6

tilbyder en komponent, som kan tilgå patientjournalerne, vil processen lettes. Denne komponent vil gøre brug af en række andre komponenter, såsom CPR-registeret for at kunne finde en journal som passer til patienten. Som default kunne patientjournalen for den primære bruger(beboeren/patienten) vises, men det skal selvfølgelig være muligt at tilgå andre patientjournaler også, da det kunne tænkes at en læge ikke blev helt færdig ved en given patient. For at kunne lave ændringer i journalerne, skal komponenten også kunne benytte en texteditor, der bør ligge som en komponent for sig selv, i det tilfælde at patientjournalerne skifter til et andet tekstformat. En anden mulighed er at benytte en talegenkendelses komponent, som kan lave tale om til tekst, således lægen ikke har berøring med skærmen, som kan have bakterier på sig. Ligeledes kunne der være mulighed for at få læst en patientjournal op, ved hjælp af en tekst-til-tale komponent. Denne komponent bør også kunne tilgå det elektroniske receptsystem, således en læge kan ordinere medicin til patienten. Denne komponent er i høj grad afhængig af login komponenten, da det er vigtigt at alle ikke kan tilgå patientjournalerne. I dette system bør der også tages højde for at dele af personalet må læse journaler, men måske ikke har beføjelser til at ordinere medicin. Patientjournaler på InfoPartner, er afdækket i projektet Interaktiv elektronisk patient journal(epj) med undertitlen FORK af Michael Sørensen. 3.1.3 Personlig status For at hjælpe en patient til at kunne se hvordan vedkommendes egen status er, kan udvikles en komponent, hvor man kan overvåge motion, ernæring og medicin. En sådan komponent, vil kunne give besked til patienten, hvis bestemte værdier er faldende, det kan være at der er et faresignal om at patienten ikke får nok motion. Det kan også være at patienten har glemt at tage sin medicin. Hvis en beboer selv kan være opmærksom på om vedkommende får nok motion, vil det hjælpe på helbredet, da motion er vigtigt for at holde kroppen vedlige 2. Hvis en beboer selv kan holde styr på om vedkommende får nok motion, kan det være med til at beboeren holder sig igang. For at kunne registrere hvor meget motion en beboer laver, kræves nogle skridttællere eller anden form for anordning til måling af motion, som kan kommunikere med komponenten. For at denne komponent kan få en virkning, kræver det en form for udstyr som kan registrere ændringer i nogle af de ønskede forhold. Det kunne være RFID-tags, som kan benyttes til at registrere om medicin er fjernet fra en beholder. En mulighed kunne også være at tilslutte måleudstyr til InfoPartner, såsom en bloktryksmåler, og benytte skærmen til dels at vise en værdi, men også behandle data, og generere nogle skemaer, som kan gemmes sammen med patient journalen. Personlig status på InfoPartner er afdækket i bachelor projektet Velfærdsteknologisk PlejeJournal (VPJ) af Hans Skytte og John Bojsen, samt i bachelor projektet IntelliCare: Personlig Status af Kristian Kremmer Davidsen, Daniel Bjerring Jørgensen og Thomas Bisgaard Laursen. 3.1.4 Underholdning Udover at kunne afhjælpe personalet, og hjælpe den ældre, vil InfoPartner også kunne bruges til underholdning. Det kan ikke siges at være en komponent, men nærmere flere komponenter, men under samme kategori. Underholdnings-komponenterne vil kunne bruge nogle af de andre komponenter, såsom tekst-til-tale komponenten, der kan benyttes til at læse avisen op for svagtseende. At få læst avisen op, kunne også ske af en avatar. InfoPartner kunne også bruges 2 Kilde: [videnscenterfordemens.dk], 09/02 2010 7

som tv, dog kræver dette at der installeres en tv-tuner. I USA har der været stor interesse for Nintendo Wii på plejehjemmene 3, hvor ældre har afholdt konkurrencer i forskellige spil. Disse konkurrencer har givet nye venskaber og sammenhold blandt de ældre, hvilket er positivt. Derfor kunne det måske tages med i udviklingen af InfoPartner, at benytte en Wii-remote og implementere nogle af Wii-spillene i InfoPartner. Mulighederne for underholdning på InfoPartner er stort set ubegrænsede. 3.1.5 Kommunikation Hvis InfoPartner skal kunne supplere alarmsnoren på sygehuse og plejehjem, er der brug for en komponent, der kan kommunikere med personalet. I takt med at smartphones bliver mere udbredt 4, vil muligheden for videotelefoni på smartphones også blive mere udbredt. Det giver en mulighed for at plejepersonalet kan udstyres med smartphones, og på den måde se hvilket behov en patient har, det være sig om patienten kræver akut behandling, eller om patientens behov kan udsættes et par minutter. En komponent som denne, vil kunne gøre brug af Skype s API 5, som tilbyder services beregnet til telefoni over internettet. Komponenten kunne laves som flere små systemer, således det er muligt at sende og modtage beskeder(sms). Derudover bør komponenten kunne ringe op og modtage kald. På den måde vil komponenten kunne bruges til at kommunikere til personallet, hvis en bruger ønsker at bestille mad, drikke etc., men også til at kommunikere med familie og venner. 3.1.6 Kalender Mange af komponenterne vil vise nogle informationer, som har forbindelse til dato og tid, derfor kan der med fordel implementeres en kalender komponent. De komponenter som kunne gøre brug af denne, kunne være i forbindelse med at påminde en patient om at tage medicin, det kan også være en aftale med en læge. 3.2 Plug and play software Som det kendes fra hardware, man kan tilslutte en hvilken som helst pc, og få sekunder efter virker den - plug and play - hvor man ved hjælp af operativsystemet får tildelt ressourcer og hardwaren selv konfigurerer sig. På den måde ville det være brugbart at man kan komme med sin applikation og få den til at virke med en eksisterende applikation. Det er dog ikke så enkelt, da software kan ændre sig, og der er derfor nødt til at være nogle grænser, det være sig i form af interfaces. Når flere applikationer skal arbejde sammen, kan det hurtigt ende med at blive en spaghetti arkitektur, hvor der er forbindelser mellem alle applikationerne på kryds og tværs. Derfor bør laves et fælles sted hvor man udveksler oplysninger, det kunne være et bus-system, eller delt hukommelse. Da det er software, vil det være et objekt som er delt mellem de forskellige applikationer. Om det er forskellige applikationer eller forskellige komponenter, har ikke den store betydning, da der gerne skal være så lav kobling som muligt. Det er vigtigt at koblingen er lav, hvis man på et tidspunkt ønsker at ersatte et givent komponent, eller applikation, for ikke at skulle ændre en stor mængde referencer. 3 Kilde: [berlingske.dk], 20/05 2010 4 Kilde: [business.dk], 21/05 2010 5 Kilde: [skype.com], 03/02 2010 8

3.3 Delkonklusion for fleksibelt software I dette kapitel er beskrevet nogle af de komponenter, der kan implementeres i InfoPartner. Når der skal udvikles komponenter til InfoPartner, er det vigtigt at udvikle komponenterne, således de har flere små services, som andre komponenter kan gøre brug af. Et eksempel kunne være login-komponenten, som kan bestå af en verifikations- og identifikationsservice. Derudover er der skrevet lidt omkring plug and play software, som der vil være mere om i kapitel 4 på den følgende side. Det er vigtigt at designe en arkitektur med lav kobling, da udvalget af komponenter i InfoPartner ikke er statisk. 9

4. Arkitektur Dette kapitel vil ommhandle nogle af de muligheder, der vil kunne benyttes som arkitektur for InfoPartner. Dette kapitel vil på mange områder ligne design diciplinen i UP, dog med en blanding af analyse diciplinen. Der vil blandt andet være et afsnit om hvad en brugbar arkitektur bør indeholde, for at kunne benyttes til InfoPartner. Derudover vil to specifikke arkitekture blive gennemgået. 4.1 Brugbare og ikke-brugbare arkitekturer InfoPartner skal kunne have mange forskellige komponenter, som det fremgår af kapitel 3.1 på side 6, hvor en del af de muligheder er beskrevet. Når systemet skal kunne håndtere mange forskellige komponenter, bør en arkitektur hvor der er lav kobling mellem komponenterne vælges, for ikke at ende med en spaghetti arkitektur 1. For at undgå at komponenterne har kendskab til hinanden, bør laves en struktur, som komponenterne skal overholde og der bør være et fælles objekt som kan dele informationer mellem komponenterne. I undervisningen omkring softwareudvikling på Robotteknologi/Datateknologi-uddannelsen, har været gennemgået nogle forskellige arkitekturer, hvor den primære softwarearkitektur har været PCMEF+ 2 (Presentation Controller Mediator Entity Foundation). Derfor vil mulighederne med denne arkitektur blive gennemgået her. PCMEF+ arkitekturen bygger på en lagdelt struktur, hvor der ønskes en top-down afhængighed, det vil sige at de øverste lag bruger de services som de underliggende lag tilbyder. For at have et stabilt system ønskes lav kobling(low coupling) og stor samhørighed(high cohesion) 3. Topdown afhængighed hjælper til at have lav kobling, og lagdelingen hjælper med samhørigheden. WPF benytter Model View View-Model arkitekturen, se kapitel 6.2 på side 22, og det kan derfor være svært at få PCMEF+ arkitekturen til at passe sammen med, samt at overskueligheden kan forsvinde. 4.2 Blackboard Når man gerne vil kommunikere noget ud i et fælles forum, benyttes ofte en tavle, hvor man kan skrive sine meninger. Hvis flere grupper arbejder på et projekt, kan det på samme måde, være smart at skrive mellemresultater op på en tavle, for at andre grupper kan benytte disse resultater. Det er netop det, blackboard-mønsteret er blevet udviklet til. Blackboard-mønsteret er blevet lavet, for at have flere måder at finde og dele matematiske resultater, blandt andet i forbindelse med talegenkendelse og realtids signalbehandling 4. Som det ses af figur 4.1, består blackboard-mønsteret af ét Blackboard-objekt, et Controllerobjekt og en række KnowledgeSource-objekter(KS-objekter). Blackboard-objektet holder de mellemresultater, som KS-objekterne lægger på Blackboardet, samt en liste med KS-objekter, der gives besked til, når informationer opdateres. Controller-objektet har en metode til at løbe alle KS-objekterne igennem, og finder ud af hvis tur det er, til at opdatere data på Blackboardet. 1 [Jain et al.] kap.[6] s.[178-179] 2 [Maciaszek et al.] kap.[9] s.[248-293] 3 [Maciaszek et al.] kap.[9.1.3] s.[253-254] 4 [Shacklette] s.[5-8] 10

Figur 4.1: Blackboard mønsteret, i sin traditionelle form. Kilde: [Shacklette] s.[15]. Ved at have resultaterne liggende i Blackboard-objektet, og at KS-objekterne kan se resultaterne der, opnås der lav kobling mellem de enkelte KS-objekter. Dog kan der være lidt problemer med at typerne af resultater kan variere, det kan være et KS-objekt regner med double og et andet KS-objekt regner med int, det vil altså sige at der bliver en afhængighed på hvilken type resultat de enkelte objekter kan tilbyde. Blackboard-mønsteret bygger på Observer-mønsteret 5, hvor Blackboard-objektet bruges som Subject, derved bliver Observer-objekterne afhængige af et fælles objekt, fremfor at være afhængig af flere forskellige Subject-objekter. 4.3 Serviceorienteret Arkitektur Hvis man har flere eksisterende systemer, som man gerne vil have til at kommunikere sammen, kan det være en fordel at benytte en Serviceorienteret Arkitektur(SOA). Ofte er de eksisterende systemer man ønsker at forbinde, placeret på forskellige servere og udviklet på forskellige programmeringsplatforme. Dette giver nogle udfordringer, dels fordi der er tale om et distribueret system, samt at der er brug for et fælles sprog. Derfor indføres noget middleware, i form af en Enterprise Service Bus(ESB), som vist på figur 4.2. Denne ESB benyttes til at håndtere de metodekald som en service gerne vil lave til en anden service, det kunne være en service på system A, som gerne vil benytte en service på system B. ESB en virker som et netværk, hvor data fra de forskellige systemer transporteres, ofte sendes data i et fælles format såsom XML. Grunden til at XML er valgt, er at stort set alle programmeringsplatforme kan håndtere XML, og XML-schemas kan bruges til at fortolke dokumenterne. ESB en bør indeholde services til at håndtere at metodekald til services kommer rigtigt frem og tilbage. Det betyder at der bør være services til fejlhåndtering. Som det ses på figur 4.2, er der nogle adaptore, disse omsætter de services et system tilbyder, til nogle services de øvrige systemer kan benyttes, samt parser data til den rigtige XMLstruktur. Softwareudviklerens opgave, når man ønsker at benytte SOA, er at forstå de eksisterende systemer, og omsætte dem til nogle services som kan bruges i det fælles system. Det vil sige udvikle adaptorene, samt at udvikle ESB en. SOA bruges ofte når mange, store og små 5 [Bishop07] kap.[9 s.[210-211]] 11

Figur 4.2: Serviceorienteret Arkitektur (SOA), hvor der er fire systemer, A,B,C,D. Kilde: forelæsning med Ingo Nielsen den 18. maj kl. 12.30-14 i D116, Niels Bohrs Alle 1. systemer skal forenes til et system. Det betyder at man som softwareudvikler ofte ikke kan have ret meget genbrug af kode og arkitektur. Dog kan dele af ESB en genbruges, samt den overordnede struktur vil på sin vis kunne genbruges. 4.4 GUI arkitektur Som det fremgår af tabel 6.1 på side 21, vil den hardware som InfoPartner skal afvikles på, være udstyret med en trykfølsom skræm, dette har betydning for hvordan GUI en bør se ud. En god retningslinje for knapper på en trykfølsom skærm, er at størrelsen som minimum bør være 2x2 cm og at der som minimum er 3 mm mellem knapper 6. Dette bør overholdes, i designet af GUI. Da InfoPartner skrives som en WPF-applikation, vil GUI en blive skrevet i XAML, jævnfør kapitel 6.2 på side 22. I WPF er der to muligheder for at opbygge brugerfladen, enten ved hjælp af Windows eller ved hjælp af Pages. Et Window, indeholder to områder, et område til indhold og et område til titellinje samt kant, området til titellinje og kant administreres af operativsystemet 7. En Page virker på sin vis som en html-side, hvor man kan vise indhold. En Page kan hostes enten i et NavigationWindow, i en Frame i et Window, eller i en anden Page, det betyder der er mange muligheder med Page. Ved at opbygge GUI en som et Window med flere Pages til at holde menuer og indhold, er det nemt at skifte mellem de forskellige Page. Det vælges at benytte Page til at holde indhold, hvilket også betyder at hvert komponent skal tilbyde en Page, hvis komponenten har indhold, som ønskes vist på skærmen. I prototypen er valgt at lave en struktur på GUI en, hvor der er en menu i venstre side af skærmen, en menu til Skype kontakter i bunden af skærmen og resten af skærmen benyttes til indhold fra de forskellige komponenter. Det vil sige opbygningen af skærmen minder om en almindelig struktur for en hjemmeside. Efter et møde den 7. april på Niels Bohrs Alle 1, med Kasper Hallenborg og Daniel Bjerring Jørgensen, er det bestemt at GUI en skal have en navigation som den kendes fra Apple s itunes, se eksempel herpå [youtube.com]. Det vil sige at skærmen viser en liste af kompo- 6 Kilde: [sapdesignguild.org], 20/02 2010 7 [MacDonald08] kap.[8] s.[215] 12

nenter, som når der trykkes derpå, åbner. Overvejelser omkring GUI er overladt til Daniel Bjerring Jørgensen fra Teknologisk Institut. 4.5 Delkonklusion på arkitektur Det oplagte vil være at vælge SOA, da dette giver mulighed for at integrere mange af de eksisterende systemer, såsom den elektroniske patient journal. Dog vil der også være en del fordele i at benytte Blackboard-mønsteret, da dette giver mulighed for at lave en simpel arkitektur, som understøtter en lang række komponenter. Der vil blive arbejdet videre med Blackboard-mønsteret, dels fordi viden omkring SOA blev opnået sent i projektperioden, og dels fordi SOA kræver stor indsigt i de eksisterende systemer. 13

5. Produktet Dette kapitel omhandler produktet, som er udviklet i forbindelse med InfoPartner. Her vil arkitekturen for systemet blive beskrevet, de implementerede komponenter vil blive beskrevet. Derudover vil et kode eksempel vise hvordan Skype komponenten er lavet. 5.1 Arkitektur Den overordnede arkitektur for InfoPartner vil være Model View View-Model(MVVM), da en WPF-applikation benytter denne opbygning, mere herom i kapitel 6.2 på side 22. Laget Model, som indeholder forretningslogik, vil blive præget af Blackboard-mønsteret, beskrevet i kapitel 4.2 på side 10. Det betyder at KnowledgeSource-objekterne, vist på figur 4.1 på side 11, vil være de komponenter som er i InfoPartner. Det er derfor valgt at lave en abstrakt klasse, som definerer hvilke metoder en komponent skal have. Derudover er der valgt at lave en struct, BlackboardData, til at definere de data som kan lægges på Blackboard. En struct er et letvægts objekt, det vil sige at det minder om en almindelig klasse, men kan lidt mindre 1. Når det omtales at lægge data på Blackboard, menes at en reference til et BlackboardDataobjekt gemmes i et Dictionary-objekt som Blackboard-objektet har. Der er valgt at lave denne BlackboardData, for at have et fælles format af objekter på Blackboard. BlackboardData skal have et navn, samt et objekt med data. Der er valgt at datatypen skal være Object, hvilket vil sige at alle slags data kan lægges ind i et BlackboardData-object. Fordelen ved at gøre dette er, at komponenterne kan lægge alt på Blackboard, dog er ulempen at de komponenter som henter data fra Blackboard, skal caste indholdet af BlackboardData-objektet til den type de forventer at modtage. «namespace» InfoPartner «namespace» Blackboard (from InfoPartner) «namespace» WebBrowser (from InfoPartner) «namespace» SkypeComponent (from InfoPartner) «namespace» NetworkController (from InfoPartner) Figur 5.1: Pakkestrukturen i InfoPartner. Der er valgt en pakkestruktur i InfoPartner som den ses på figur 5.1. Det betyder at den overordnede pakke, eller rettere det overordnede namespace, er InfoPartner hvorunder Blackboard, og de øvrige komponenter vil være. Denne pakkestruktur er valgt, for at undgå at to klasser med samme navn vil give problemer. Der er yderligere indført en mappe til hvert namespace, da dette giver et bedre overblik over de enkelte filer. I forskel til Java, hvor en mappe angiver hvilken pakke en klasse tilhører, er dette ikke nødvendigt i C#, da namespaces sørger for adskillelsen mellem de enkelte klasser 2. Klassediagram over Model-klasser ses på figur A.1 i bilag A. Som det ses af figuren, implementerer komponenterne AbstractComponent, og har alle en reference til Blackboard-klassen. Det er kun NetworkController-klassen, som benytter BlackboardData, da denne komponent er den eneste komponent som lægger data ind i Blackboard-objektet. Controller-klassen, har 1 [Liberty et al.] kap.[7] s.[127] 2 [Liberty et al.] kap.[2] s.[11] Anders And (Andeby) 14

metoden Loop, der løber komponenterne, som er tilmeldt Blackboard igennem, for at kontrollere om de har noget at lægge på Blackboard. Den måde hvorpå komponenterne kan signallere at de ønsker at lægge data på Blackboard, er ved at sætte den boolske værdi cancontribute. Når Controller-objektet finder en komponent, hvor cancontribute er true, benyttes execaction-metoden på den givne komponent. Når en komponent har lagt data på blackboard, gives besked til alle tilmeldte komponenter, hvor en liste med de BlackboardDatanavne der tilgængelige sendes med. Controller-objektets metode Loop køres hvert sekund, her benyttes en DispatcherTimer, som er en timer der kan tilgå user interface tråden 3. Det betyder at hvis en komponent vil opdatere noget i brugerfladen, er det muligt. Som det ses på figur A.1 i bilag A, er arkitekturen meget simpel. Ved at have denne simple arkitektur, er det til at forestille sig hvordan systemet vil se ud, med 20 komponenter, selvom der kun er vist tre komponenter. 5.2 Implementerede komponenter I dette afsnit vil de implemterede komponenter blive beskrevet. Der vil blive lagt vægt på hvilken måde Blackboard benyttes. De implementerede komponenter er valgt, for at kunne lave en prototype, hvor det er tydeligt at informationer deles mellem komponenterne. 5.2.1 Netværkskontrollør Denne komponent registrerer hvis en netværksforbindelse ændre tilstand. Når netværksforbindelsen ændre tilstand, lægger komponenten en boolsk værdi på Blackboard. På den måde kan andre komponenter få at vide at netværkstilstanden er ændret. Måden hvorpå komponenten får at vide at der er sket en ændring med netværket, er NetworkAvailabilityEventArgs, som ligger i System.Net.NetworkInformation namespacet, som rejser en event ved ændringer. Sådan som komponenten er implementeret på nuværende tidspunk, kunne de komponenter som vil kende til netværksændringer selv se på NetworkAvailabilityEventArgs. Men ved at tilføje nogle informationer, såsom hvilken netværksforbindelse der er sket en ændring på, hvad årsagen kan skyldes, hvilket tidspunkt ændringen skete med mere, kunne informationerne fortælle mere, og et lognings komponent ville kunne gemme oplysningerne, fremfor at komponenten på nuværende tidspunkt sætter en boolsk værdi. På nuværende tidspunkt er det lavet, for at demonstrere at data gemt på Blackboardet kan deles mellem komponenter. 5.2.2 Webbrowser Komponenten er en simpel webbrowser, som ser på Blackboard efter netværks kontrollørens data. Det vil sige hvis netværket ændre tilstand fra at være tilgængeligt, til ikke at være tilgængeligt, vil web browseren sørge for at det ikke er muligt at indtaste en webadresse i indtastningsfeltet. På samme måde hvis det er den omvendte ændring, vil indtastningsfeltet blive tilgængeligt igen. WPF har en control som hedder WebBrowser, som kan benyttes til at lave en simpel webbrowser. WebBrowser control en gør brug af en Internet Explore COM wrapper til at vise html 4. Denne komponent kunne integreres med en komponent til at læse tekst op. Et sådant komponent, kunne gøre brug af Sara et tekst-til-tale produkt fra Prolog Development Center 3 [MacDonald08] kap.[21] s.[730] 4 [MacDonald08] kap.[13] s.[389] 15

A/S. I forhold til hardwaren som InfoPartner afvikles på, er der ikke tænkt over en løsning med tastatur. Det vil sige det kan blive et problem at indtaste en webadresse, hvis ikke Eee Top PC ens indbyggede skærmtastatur er synligt samtidigt med InfoPartner. 5.2.3 Kommunikation Denne komponent benytter Skype, til at foretage og modtage opkald. Komponenten gør brug af den information som netværks kontrolløren lægger på Blackboard. Det vil sige, hvis netværket er nede, får brugeren en besked, om at det ikke er muligt at benytte komponenten. Måden hvorpå et opkald foretages, er ved at trykke på en Skype kontakt, som vises i bunden af InfoPartner. Hvis brugerens Skype-kontakter har et profil-billede benyttes dette, ellers benyttes et standard billede. I kapitel 6.4 på side 23, er beskrevet hvordan Skype kan tilgås fra en applikation som InfoPartner, samt hvilke problemer der opstod ved brug af Skype s API. I kapitel 5.4 vil blive beskrevet hvordan Skype-kontakternes billede bliver hentet, og vist i InfoPartner. 5.3 GUI Den grafiske brugerflade, er opbygget af WPF-elementet Grid, som er opdelt med to rækker, hvoraf den første række har to koloner og den sidste række har en kolone. Det vil sige der er tre celler til indholdet, en celle bruges til en menu, en bruges til kommunikations komponenten og den sidste bruges til indholdet af de øvrige komponenter. Denne opdeling kan ses på figur 5.2. Figur 5.2: Skærmbillede af GUI en som den er lavet i prototypen. De grå bokse, indikere de forskellige frame-elementer. Applikationen starter med et opstartsvindue, hvorefter man åbner et fuldskærmsvindue. Opstartsvinduet er tænkt til at man kunne lave en form for login til den primære bruger. Disse oplysninger kunne bruges til at logge på brugerens Skype-klient, samt at opsætte hvilken bruger, der er den defaulte i den elektroniske patientjournal. For at have en simpel struktur, er valgt et StackPanel til at holde knapper i menuen. Et StackPanel-element placerer elementer, såsom knapper, i en stak enten horisontalt eller vertikalt 5. Denne struktur er også valgt, til at holde Skype-kontakter i kommunikationskomponenten. Som vist på figur 5.2, benyttes Frame-elementet til at holde indhold af komponenter i Content- Frame, samt kommunikations komponenten i BottomMenuFrame. Frame-elementet bruges til at vise Page-elementer. 5 [MacDonald08] kap.[4] s.[78] 16

5.4 Skype eksempel I dette afsnit vil metoden findcontacts, som bruges til at opsætte Skype-kontakter i InfoPartner blive gennemgået. Dele af koden er fjernet, da denne kode kun har betydning for størrelse, farve og placering af et grafisk element. Der hvor der er fjernet kode, vil være markeret med..., samt en kommententar. 1 public void f i n d C o n t a c t s ( ) 2 { 3 foreach ( User u s e r in skype. Friends ) 4 { 5 Button btn = new Button ( ) ; 6... // Opsætning a f s t ø r r e l s e mm. på btn. 7 btn. DataContext = u s e r ; 8 btn. C l i c k += b t n C l i c k ; 9 10 Image i = new Image ( ) ; 11... // Opsætning a f s t ø r r e l s e mm. på i. 12 i. Source = p r o f i l e P i c t u r e ( user, skype ) ; 13 14 TextBox t = new TextBox ( ) ; 15... // Opsætning a f s t ø r r e l s e mm. på t. 16 t. Text = profilename ( u s e r ) ; 17 18 Grid g r i d = new Grid ( ) ; 19... // Opsætning a f s t ø r r e l s e mm. på g r i d. 20 g r i d. Children. Add( i ) ; 21 g r i d. Children. Add( t ) ; 22 btn. Content = g r i d ; 23 24 i f ( u s e r. OnlineStatus == TOnlineStatus. o l s O f f l i n e ) 25 { 26 btn. IsEnabled = f a l s e ; 27 } 28 else 29 { 30 btn. IsEnabled = true ; 31 } 32 33 c o n t a c t L i s t. Children. Add( btn ) ; 34 } 35 } Kodeudsnit 5.1: Uddrag af metoden findcontacts fra filen SkypePage.xaml.cs. For at benytte Skype API et, skal der oprettes en instans af Skype, dette gøres på følgende måde: Skype skype = new Skype(). Denne instans bruges i findcontacts, som det ses på linje 3 i kodeudsnittet 5.1. På instansen af Skype-objektet, er der nogle felter, som kan tilgås, et af dem er Friends, der giver en liste med Skype-kontakter af typen User. Som det ses på linje 3, består findcontacts af en foreach-løkke, som løber skype.friends igennem. Denne løkke finder brugerens Skype-kontakter, samt Skype-kontakternes profilbillede, og navn. På linjerne 5-8 i kodeudsnittet 5.1, oprettes en knap. Denne knap får en reference til det userobjekt, den repræsenterer. Databinding er brugbart, når man har flere ens objekter, i dette tilfælde knapper, som skal reagere forskelligt 6. Ved at lave en databinding med user-objektet, kan alle knapper benytte den samme event-handler, her btn Click. På linjerne 10-12, oprettes et image-objekt i, hvor Skype-kontaktens billede findes ved metoden profilepicture, denne metode er vist på kodeudsnit 5.2. Ligeledes oprettes et TextBoxobjekt t, til at indeholde Skype-kontaktens navn, på linjerne 14-16. Skype-kontaktens navn 6 [MacDonald08] kap.[16] s.[503] 17

findes ved hjælp af metoden profilename, denne metode er vist i kodeudsnit 5.3. For at samle Skype-kontaktens profilbillede og navn, og derefter sætte dette på knapper, oprettes et grid-objekt, til at holde de to elementer, dette sker på linjerne 18-22. På linjerne 24-31 i kodeudsnitet, kontrolleres om den givne Skype-kontakt er offline eller ej, hvis Skype-kontakten er offline sættes knappen til ikke at være brugbar. Det vil sige attributen IsEnabled sættes til false. Til sidst tilføjes knappen, og dermed user-objektet, til et StackPanel kaldet contactlist. 1 private BitmapImage p r o f i l e P i c t u r e ( User user, Skype skype ) 2 { 3 string path = @ c : \ a v a t a r s ; 4 try 5 { 6 i f ( D i r e c t o r y. E x i s t s ( path ) ) 7 { 8 //Do nothing 9 } 10 else 11 { 12 D i r e c t o r y I n f o d i = D i r e c t o r y. C r e a t e D i r e c t o r y ( path ) ; 13 } 14 } 15 catch ( Exception e ) 16 { 17 MessageBox. Show( e. ToString ( ), Der s k e t e en f e j l, ved indlæsning a f kontaktpersoner.. ) ; 18 } 19 20 Command cmdskype = new Command( ) ; 21 cmdskype. Blocking = true ; 22 cmdskype. Timeout = 2000; 23 string c u r F i l e = c : / a v a t a r s / + user. Handle +. jpg ; 24 string a l t F i l e =.. / Graphics / a l t e r n a t i v e. png ; 25 cmdskype. Command = GET USER + user. Handle + AVATAR 1 + c u r F i l e ; 26 cmdskype. Expected = USER + user. Handle + AVATAR 1 + c u r F i l e ; 27 skype. SendCommand( cmdskype ) ; 28 29 F i l e I n f o f = new F i l e I n f o ( c u r F i l e ) ; 30 BitmapImage b i = new BitmapImage ( ) ; 31 32 i f ( cmdskype. Reply == cmdskype. Expected f. Length > 0) 33 { 34 b i. B e g i n I n i t ( ) ; 35 b i. UriSource = new Uri ( c u r F i l e ) ; 36 b i. EndInit ( ) ; 37 } 38 else 39 { 40 b i. B e g i n I n i t ( ) ; 41 b i. UriSource = new Uri ( a l t F i l e, UriKind. R e l a t i v e ) ; 42 b i. EndInit ( ) ; 43 } 44 45 return b i ; 46 } Kodeudsnit 5.2: Metoden profilepicture fra filen SkypePage.xaml.cs. På linje 1 i kodeudsnit 5.2, kan metode signaturen for profilepicture ses. Som det ses, tager profilepicture to parametre, i form af et user-objekt og skype-objektet. user-objektet indeholder oplysninger om Skype-kontakten. skype-objektet er instansen af Skype, som er det 18

objekt der muliggør kommunikation med Skype API et. Grunden til at user-objektet er med, er for at kunne finde Skype-kontaktens profilbillede. Grunden til at skype-objektet er med, er for at kunne udføre en Command-operation til Skype API et. De profilbilleder som Skype-kontakterne har, skal gemmes et sted, derfor kontrolleres om mappen avatars på placeringen c:\ findes. Hvis ikke mappen findes, oprettes denne. Når der forsøges oprettet en mappe, kan der ske en exception, hvis ikke det er muligt, derfor er koden omgivet af en try-catch blok. Det er hvad der sker på linjerne 3-18 i kodeudsnit 5.2. I det følgende vil det blive gennemgået, hvordan man bruger Command, som er den måde, hvorpå man kan lave Message/Response direkte til Skype-klienten. På linje 20 i kodeudsnit 5.2, oprettes et Command-objekt ved navn cmdskype. På den efterfølgende linje, sættes feltet Blocking til true, dette betyder at der skal komme et svar på kommandoen før koden kan fortsætte 7. Derefter sættes en Timeout-værdi, som angiver hvor længe der skal blokkeres, denne er sat til 2000 ms. På linje 23 sættes en string, med stien til det ønskede profilbillede. På linje 23 bruges user.handle, som angiver brugernavnet for den givne Skype-kontakt. På linje 24 sættes en string, med stien til et alternativt billede, som bruges hvis Skype-kontakten ikke har noget profilbillede, dette kontrolleres længere nede i koden. På cmdskype benyttes Command, som sættes til den kommando der ønskes udført, dette sker på linje 25. Den kommando der ønskes udført, er: find brugeren med user.handle som brugernavn, gem vedkommendes profilbillede på placeringen curfile. På linje 26 angives det svar man forventer at modtage. På linje 27 i kodeudsnit 5.2 udføres metoden SendCommand på skype-objektet. På linje 29 i kodeudsnit 5.2 oprettes et nyt FileInfo-objekt, hvor stien til filen gives med som parameter. På den efterfølgende linje oprettes et nyt BitmapImage-objekt, som er det objekt metoden profilepicture returnere. På linjerne 32-43 i kodeudsnit 5.2 kontrolleres om svaret på cmdskype-objektet er som forventet, eller at filen er større end nul. Grunden til at der spørges på om filen er større end nul, er fordi der gemmes en fil med filstørrelsen nul, selvom Skype-kontakten ikke har noget profilbillede. Hvis svaret er som forventet, bruges den hentede fil, og bi-objektet initaliseres. Hvis ikke svaret er som forventet benyttes det alternative billede. 1 private string profilename ( User user ) 2 { 3 i f ( u s e r. FullName!= ) 4 { 5 return u s e r. FullName ; 6 } 7 else i f ( u s e r. DisplayName!= ) 8 { 9 return u s e r. DisplayName ; 10 } 11 else 12 { 13 return u s e r. Handle ; 14 } 15 } Kodeudsnit 5.3: Metoden profilename fra filen SkypePage.xaml.cs. Det som metoden profilname, vist i kodeudsnit 5.3 har til formål at gøre, er at vise det navn på brugeren som er mest sigende. På Skype-kontakt objektet user er der tre felter, som kan angive kontaktens navn, der er FullName, DisplayName og Handle. Feltet FullName returnere fornavn og efternavn på kontaken. Feltet DisplayName returnere et felt der kan defineres af kontakten. Feltet Handle returnere kontaktens brugernavn. Det navn som giver mest mening, må være FullName, da man bør kende sine kontakters navn og efternavn. 7 Kilde: [skype.com/../command vbs], 25/05 2010 19

5.5 Delkonklusion for produktet I dette kapitel er blevet gennemgået, hvordan produktet er blevet udviklet, samt nogle af produktets funktionaliteter er blevet detaljeret beskrevet. Der er blevet arbejdet med at implementere et Blackboard-mønster, og dette virker, dog er mønsteret ikke blevet testet ved hjælp af en unit test. Det betyder at produktet kan indeholde fejl, som ikke er blevet fundet. Som produktet er lavet, på nuværende tidspunkt, er det ikke muligt at håndtere indgående opkald fra produktet, dette er der en forklaring på i kapitel 6.4 på side 23. 20

6. Anvendte teknologier I dette kapitel vil de teknologier, der er blevet anvendt i projektet blive beskrevet. Derudover vil den hardware som InfoPartner tænkes afviklet på blive beskrevet, samt hvilke fremtidige teknologier der kan anvendes. 6.1 Hardware benyttet til InfoPartner Den PC hvor InfoPartner ønskes afviklet på, er en EeeTop PC, med specifikationerne anvist i tabel 6.1. LCD 15.6 16:9 Wide Panel OS Genuine Windows R XP Home Touch Screen Single Touch CPU + Chipset Intel Atom N270 + 945 GSE Memory DDR 1GB HDD 160G SATA 5400rpm Graphics On board graphics Built-in Camera 1.3M pixel Web camera Mic Array Mic LAN 10/100/1000 Mbps Wireless 802.11 n Audio 4W Hifi speaker x 2 + SRS Premium Sound System Side IO port USB 2.0 x 2, card reader (SD/MMC/Memory Stick) IO port 3 audio ports for 5.1 channel : a. Microphone port in β > Center/Bass b. Line in β > Sur R/L c. Line out β > Front - Gigabit LAN x 1, - USB 2.0 x 4, Power Supply 19Vdc, 3.42A, 65W power adaptor Battery N/A Net Weight 4.3KG Tabel 6.1: Specifikationer for EeeTop PC(Kilde: [asus.com], 08/02 2010 ), hvor InfoPartner ønskes afviklet på. 6.1.1 Fremtidige muligheder I dette afsnit vil nogle af de fremtidige muligheder blive beskrevet, det vil være de muligheder der er i form af hardware, der kan tilføjes til EeeTop PC en. InfoPartner vil ikke være et program som kræver meget af hardwaren, da der ikke er ret meget forretningslogik, som skal afvikles. I og med der ikke ret meget forretningslogik, vil der ikke være nogle tunge beregninger og der vil ikke være store databaser som lægger på computeren. Det betyder at det som computeren skal yde, er i forbindelse med visning af de grafiske elementer. Derfor ville det være en fordel med et dedikeret grafikkort, da WPF netop udnytter GPU en. Da EeeTop PC en har touch screen, vil en naturlig opdatering være at tilføje multitouch, som vil gøre det muligt at trykke på skærmen flere steder samtidigt. 21

RFID-reader For at have en så nem og hurtig login for læger og plejepersonalet, vil det være optimalt at bruge en RFID-tag til at indentificere sig, da dette ikke kræver fysisk kontakt med skærmen. Derfor bør computeren have en RFID-reader, det kan være en læser som sættes til via usb eller integreres i selve computeren. Som det fremgår af kapitel 3.1 på side 6, vil enkelte komponenter også have brug for en RFID-reader. Tv-tuner Som supplement til hardwaren, kunne være en digital tv-tuner, således InfoPartner både kan bruges som informations skærm, men også som fjernsyn på plejehjem og sygehuse. Tv-tuneren kunne være som et tilkøb eller integreret, hvis det er et tilkøb kommer de ofte med en DLL-fil 1, som gør det muligt at kommunikere med hardwaren. 6.2 Windows Presentation Foundation - WPF WPF benytter en Model View View-Model(MVVM) arkitektur, se figur 6.1, som har nogle fordele, i forhold til andre kendte programmeringsplatforme. En fordel med WPF er at præsentationslaget kan laves som en prototype med de funktionaliteter man ønsker, og efterfølgende sendes til en grafisk designer, som kan gøre præsentationslaget flottere og mere lækkert at se på 2. Dette kan lade sig gøre, da View skrives i XAML, som er en XML-lignende struktur, som kan benyttes til at beskrive grafiske elementer. View er det man normalt vil kalde præsentations-laget, dog skiller det sig lidt ud fra andre programmeringsplatforme, da præsentationslaget er skrevet i et beskrivende sprog, som kun beskriver de grafiske elementer. Det vil sige, at View ikke kan udføre nogen opgaver, men at der skal bruges et lag, til at håndtere event-styring og data-binding. Figur 6.1: Model View View-Model arkitekturen bag WPF. Kilde: [hugeonion.com] 25/05 2010. Laget som håndtere events, og data-binding er View-Model, dette lag kan skrives i et hvilket som helst.net-sprog, i dette projekt er valgt C#. Det sidste lag, er Model, som er det lag som indeholder forretningslogikken også kaldet domænelogik. En anden fordel ved WPF er at GPU en benyttes til at vise al grafik. Dette frigiver CPU en til 1 DLL står for Dynamic-Link Library og er systemfiler der benyttes på kryds og tværs af forskellige programmer. 2 [MacDonald08] kap.[2] s.[21] 22

at håndtere forretningslogikken, og dermed opnå hurtigere svartider. Måden hvorpå hastighedsforøgelsen kan opnås, er fordi WPF benytter DirectX til at håndtere grafiske elementer. DirectX blev oprindeligt udviklet for spiludviklere, således at 3D spil kunne benytte grafikkortet, for at opnå bedre grafik. DirectX understøttes af mange grafikkort, og tilbyder en fælles måde at håndtere grafik på. Dette betyder at hardwaren kan give hastighedsforøgelse til spil og programmer, og dette udnytter WPF 3. 6.3 ClickOnce Opdatering af software er ofte besværlig, da det kræver at det kørende system lukkes, en ny version lægges over på computeren, og denne installeres. Derfor har Microsoft lavet ClickOnce som kan hjælpe med at lægge nye versioner ud. Der er mange måder at benytte ClickOnce på, men en oplagt mulighed vil være at benytte en web-server, hvor slutbrugeren vil få besked, når der er en ny version af softwaren. En anden mulighed er at lave en traditionel installations cd, hvor man første gang installere softwaren, vil blive tilmeldt en service, som holder styr på hvilken version af softwaren der er den aktuelle 4. Der er ikke i dette projekt taget højde for hvilken model af ClickOnce der bør anvendes. 6.4 Skype Til kommunikations komponenten, er benyttet Skype, som stiller et API til rådighed. Det betyder at man kan gøre brug af de funktionaliteter som programmet Skype har. Skype kan blandt andet bruges til internettelefoni 5, telefoni fra computer til almindelig fastnet telefon, samt sms og videotelefoni. For at opnå adgang til Skype s API, kan benyttes en Component Object Model(COM) wrapper, som gør det muligt at benytte API et fra forskellige programmeringssprog 6. COMwrapperen for Skype hedder Skype4COMLib.dll, og kan betragtes som middleware. Det som Skype4COMLib gør, er at omsætte de metodekald der laves fra InfoPartner, eller anden applikation, til metodekald som overholder Message/Response kommunikationen til Skype API et, som vist på figur 6.2. Figur 6.2: Interaktion mellem Skype og InfoPartner. Kilde: [W.J.Campbell05] s.[6]. For at kunne benytte Skype klienten, fra en anden applikation, er man nødt til at give tilladelse i Skype klienten, til at den anden applikation må benytte Skype klienten. Dette er lavet for at sikre Skype klienten mod at ondsindede programmer udnytter Skype klienten. Denne sikkerhedskontrol har ikke været mulig at fjerne. 3 [MacDonald08] kap.[1] s.[2] 4 [MacDonald08] kap.[27] s.[967] 5 VOIP - Voice Over IP. 6 [W.J.Campbell05] s.[5-6] 23