PIM PERSONAL INFORMATION MANAGER. Århus Universitet Institut for informations- og medievidenskab

PIM PERSONAL INFORMATION MANAGER Århus Universitet Institut for informations- og medievidenskab Eksamensopgave i digitale modeller 2. semester Juni 2010 Christine Risager Kaja Ravn Cramer Michael Christensen Vejleder: Pär-Ola Zander

Indholdsfortegnelse Indledning... 3 Projektbeskrivelse... 3 Metode... 5 Kildekritik... 5 UP... 6 Inception fasen... 7 Vision... 7 Glossary... 7 Risks... 9 Use case model... 9 Domænemodel... 10 Status efter inception fasen... 10 Fokus for 1. iteration... 11 Elaboration fasen... 12 1. iteration... 13 Vision... 13 Glossary... 13 Risks... 14 Domænemodel... 14 UML Klassemodel... 14 UML Designmodel... 14 Use case model... 15 GRASP... 15 Den kodemæssige proces... 17 Status efter 1. iteration... 17 Fokus for 2. iteration... 17 2. iteration... 19 Vision... 19 Glossary... 19 Risks... 19 GRASP... 20 Polymorphism... 20 Pure Fabrication... 21 Indirection... 21 Protected Variations... 22 Den kodemæssige proces... 22 Status efter 2. iteration... 23 Fokus for 3. iteration... 24 3. iteration... 25 Vision... 25 Side 1 af 41

Glossary... 25 Risks... 25 UML Designmodel... 25 Den kodemæssige proces... 26 Status efter 3. iteration... 27 Fokus for 4. iteration... 27 4. iteration... 29 Vision... 29 Glossary... 29 Risks... 30 Designmodel... 30 Use case... 30 Den kodemæssige proces... 30 Status efter 4. iteration... 31 Den kodemæssige arkitektur... 32 Model-View-Controller... 32 Refleksion... 36 GUI ets brugervenlighed... 36 Udvidelser... 36 Valg af udviklingsmetode... 37 Konklusion... 38 Litteraturliste... 40 Tegn indeholdt i opgaven: 61.123 Opgaven er skrevet af: 20094441 Christine Risager (s. 3-4, 10-11, 15-16, 19-20, 25, 29-30, 36-37) 20094840 Kaja Ravn Cramer (s. 6-9, 12-15, 20-22, 32-33) 20093645 Michael Christensen (s. 17-18, 22-24, 26-28, 30-31, 34-35) I parenteserne er angivet, hvilke sider de enkelte er ansvarlige for. Vi har sammen udformet forside, indholdsfortegnelse, indledning, metode, konklusion og litteraturliste. Vedlagt denne opgave er en CD-ROM med vores kode. Side 2 af 41

Indledning Denne opgave tager afsæt i vores afslutningsprojekt; Personal Information Manager (PIM). Det centrale i opgaven omhandler, hvorledes vi har valgt at strukturere arbejdsprocessen i konstruktionen af PIM. Opgaven tager forhold i den teori, vi har lært på kurset Digitale Modeller, og her vil der laves redegørelser, refleksioner og dokumentation over arbejdsprocessen samt argumentationer for programmets opbygning. På denne måde viser vi, at have forstået princippet bag objektorienteret programmering, og hvordan det har været mest hensigtsmæssigt at arbejde sig igennem processen. Vi har afgrænset teorien ved at vælge den væsentlige teori ud, som vi selv har benyttet os af, så vi dermed formidler det essentielle. I det følgende vil vi give en kort beskrivelse af projektet PIM. Projektbeskrivelse PIM er en forkortelse for Personal Information Manager, som er et system, der kan holde styr på information i form af f.eks. kontaktpersoner og huskesedler. Vores PIM er til personligt brug og forudsætter, at brugeren kender til computerens grundlæggende funktioner. Nedenunder forekommer en liste over, hvilke typer information brugeren kan indtaste i vores PIM: Research (videnskabeligt arbejde med halvfærdige ideer og inspirationsmateriale) - Beskrivelse af case Appointments (aftaler) - Beskrivelse af aftale - Start og slut dato for aftale - Start og slut klokkeslæt for aftale - Kalenderfunktion Contacts (kontakter) - Navn på kontakt - Adresse på kontakt Side 3 af 41

- Postnummer på kontakt - By på kontakt - Land på kontakt - Mobilnummer til kontakt - Telefonnummer til kontakt - Mail til kontakt - Bemærkninger om kontakt Diary (dagbog) - Titel på dagbogs-indlæg - Dato for dagbogs-indlæg - Selve indlægget Notes (huskesedler) - Titel på note - Selve noten Indenfor alle typer information er det muligt at oprette, ændre og slette, hvilket gøres ved at trykke på de dertil indrettede knapper. Derudover er det muligt at vælge mellem, eksempelvis, de forskellige oprettede kontaktpersoner, som vil være at finde på en liste, for at se den information, som tidligere er givet om disse. Som basisfunktion skal systemet blot kunne huske den givne information, så længe programmet kører, men starter altså forfra, hver gang programmet har været lukket ned. Det vil sige, at alle felter nulstilles og al tidligere information dermed slettes. Det optimale vil selvfølgelig være, at information gemmes, til trods for at programmet lukker ned, men dette er ikke krav. Vi har skabt en gennemtænkt systemarkitektur, hvor GUI-design med knapper o.a. tilgodeser den travle bruger, hvilket betyder at opbygningen er simpel og klassisk i udseende. Side 4 af 41

Metode Vores PIM s udviklingsfase er bygget over en iterativ udviklingsmodel, som vil blive beskrevet i afsnittet UP og i de efterfølgende beskrivelser af faserne. Opgaven er opbygget således, at vi starter med en gennemgang af inceptionfasen. Derefter vil vi komme ind på elaborationfasen, hvorunder de gennemgåede iterationer uddybes. Det er i både inception- og elaborationfasen, at vores udvikling af selve programmet vil blive beskrevet. Til at overskueliggøre, hvor vi befinder os i faserne og iterationerne, har vi visualiseret dette med pile, hvor en rød pil indikerer, hvor i projektets forløb læser er kommet til. Efter inception- og elaborationfasen, vil vi komme ind på den kodemæssige arkitektur, som beskriver vores fremgang i selve kodekonstruktionen samt arkitekturen af vores Personal Information Manager (PIM). Denne proces vil blive gennemgået vha. uddybelse af den specifikke software i form af modeller og diagrammer. I afslutningsfasen vil vi, i et reflekterende afsnit, komme med positive og negative overvejelser omkring systemet og hele arbejdsprocessen, hvor vi også vil komme ind på brugen af UP, samarbejdet og eventuelle udvidelser. Slutteligt vil vi runde af med et konklusionsafsnit. Herudover har vi også forsøgt at styre vores kodemæssige arkitektur i forhold til GRASP principperne og Model-View-Controller, som vil blive uddybet i afsnittende om de forskellige iterationer og den kodemæssige arkitektur. Disse teorier kommer fra bøgerne Applying UML and patterns af Craig Larman og UML distilled af Martin Fowler, som er anerkendte teorier. Kildekritik Til vores opgave har vi brugt bøger omhandlende software udvikling. Denne slags litteratur adskiller sig noget fra andre faglitteratur bøger ved ikke at være overvejende akademiske i argumentationen. Der er ikke den store rygdækning i bøgerne, og det kan give visse svage punkter samtidig med, at forfatteren ikke forholder sig kritisk til alle vinkler i bogen. F.eks. lovpriser Larman og Fowler den iterative UP metode og er ikke kritiske overfor metoden, hvorimod vandfaldsmetoden bliver sat i et dårligt lys. Dermed har vi, for også at have en kritisk vinkel, søgt materiale, som nævner ulemper ved UP. Side 5 af 41

I vores programmerings proces har vi, til tider, benyttet kode udgivet på internettet. Der kan være komplikationer og fælder ved at benytte kode fra internettet, da det ofte kommer fra ukendte kilder, hvorfor fejlfri og rigtig kode ikke kan garanteres. Derudover er der ingen sikkerhed for, at udgiveren selv har skrevet koden, da han i princippet kan have kopieret koden fra en helt tredje udgiver. Vi har derfor måttet være ekstra påpasselige med brug af kode fra internettet og set kritisk på denne. UP UP står for Unified Process, som er en iterativ udviklingsproces til opbygningen af objekt orienterede systemer. UP projekter organiserer arbejdet og iterationerne over fire faser: inception, elaboration, constuction og transition. 1 Vi har i vores projekt valgt at tage udgangspunkt i denne proces, men vil først og fremmest koncentrere os om de to førstnævnte faser, inception og elaboration. Dette gør vi, fordi størrelsen og tidsrammen på vores projekt ikke er stor nok til også at komme omkring de to sidste faser. 1 Larman (2005), s. 18 Side 6 af 41

Inception elaboration 1. iteration 2. iteration 3. iteration 4. iteration Inception fasen Inception fasen er den første fase i udviklingsforløbet. I denne fase har vi udtænkt en vision for projektet og udviklet artefakterne use case og domænemodel. Derudover har vi haft fokus på glossary og risks. Vi har afslutningsvis gjort status over arbejdet med inception fasen, og sat et fokus for vores mål med 1. iteration i næste fase, elaboration fasen. Nedenfor ses beskrivelse af vores arbejde med de forskellige artefakter. Vision Vores vision med systemet er, at brugeren får et velfungerende system, hvori han/hun kan skrive informationer om sit liv og sine omgivelser. Vi ønsker, at systemet skal indeholde informationstyperne contacts, notes, appointments, research og diary. Et velfungerende system, i vores øjne, indebærer, at systemet kan gemme nedskrevne data, selvom programmet lukkes ned, således at brugeren kan finde tidligere information frem, når der er brug for det. Vi vil gøre det let for brugeren at udfylde tekstfelterne i systemet. Dette gøres ved f.eks. kun at tillade tal i feltet til mobilnummer og kun tillade bogstaver i feltet til navn. Brugeren skal ydermere kunne indsætte billeder. Tanken omkring visionen er, at vi hele tiden vil have den i baghovedet og gå målrettet efter den. Dog vil vi tage den op til revision under hver iteration, i tilfælde af at målene bliver for urealistiske at nå eller i modsat fald kan udstykkes. Glossary Glossary er en liste med interessante termer fra systemet og projektet som helhed samt definitioner af disse termer. Dette kan være for at lette kommunikationen, da termer oftest opfattes forskelligt, afhængig af hvilken stakeholder, der gennemgår projektet. I inception fasen skal glossary primært fungere som et simpelt dokument, men kan i elaboration fasen udvides og fungere som en decideret Side 7 af 41

data ordbog. 2 Da vores PIM ikke umiddelbart er fyldt med svære gloser, er vores glossary ikke svært avanceret, men kan, som nævnt, udvides i elaboration fasen. Derfor har vi, i første omgang, lavet en simpel gennemgang af de forskellige typer information, som vores PIM kan indeholde, således at disses betydninger klargøres. Contacts: Her kan brugeren holde styr på sine kontakter og information om disse, i form af navn, adresse, telefonnummer, mobilnummer, email og andre bemærkninger. Det er muligt at tilføje kontakter, redigere i kontaktoplysningerne og slette kontakter. For at gøre det lettere for brugeren, at indskrive korrekt data i de enkelte felter, har vi lavet kode, der gør, at der kun kan indtastes bestemte tegn i bestemte felter. Typen Name kan kun bestå af bogstaver. Typen Address er opdelt i tre felter, hvor address og city kun kan bestå af bogstaver, og zip code kun kan bestå af tal. Typen Telephone no. og Mobile no. kan ligeledes kun bestå af tal. Slutteligt kan typerne Email og Notes bestå af både bogstaver, tal og andre tegn, som f.eks. @ (snabel a). Notes: Her kan brugeren holde styr på sine huskesedler ved at navngive dem med f.eks. indkøbsseddel, lektier osv. Igen er det muligt at tilføje nye sedler, redigere dem og slette dem. Notes består af et navn og et tekstfelt, hvori der både kan skrives bogstaver, tal og diverse andre tegn. Appointments: Her kan brugeren holde styr på sine aftaler. Igen ved at give aftalerne navn og ydermere tilføje en dato til hver aftale. Der er mulighed for at oprette aftaler, redigere dem og slette dem. Appointments består af et navn, en dato og et tekstfelt, som alle kan bestå af bogstaver, tal og diverse andre tegn. Research: Her kan brugeren holde styr på sit arbejde med forskellige cases. På den måde er det hele tiden muligt for brugeren at skrive noter osv. til forskellige cases, og på den måde skabe et overblik. Igen er der mulighed for at oprette, redigere og slette cases. Denne type information er den, der appellerer mest til at bruge slet-funktionen. Når brugeren afslutter et case, kan han/hun slette caset, hvilket hele tiden vil give brugeren struktur og overblik over, 2 Larman (2005), s. 115 Side 8 af 41

hvor mange cases der arbejdes med. Research består af et navn og et tekstfelt, som begge kan bestå af bogstaver, tal og diverse andre tegn. Diary: Her kan brugeren nedskrive sine daglige erindringer. Selvom det måske ikke vil være så aktuelt, er det her også muligt at redigere og slette nedskrivninger. Hvis brugeren gør dette, vil det dog ødelægge en del af princippet med en dagbog. Diary består af et navn, en dato og et tekstfelt, som alle kan bestå af bogstaver, tal og diverse andre tegn. Risks I inception fasen har vi ikke nedskrevet nogle kodemæssige risks. Det har været for tidligt for os, at overveje nogle specifikke risks, da vi knap nok har vist, hvilke klasser der skal implementeres, og hvordan disse skal opstilles. Derfor er dette et punkt, som først udvides i elaboration fasen, hvor den egentlige kodning begynder. Use case model Use case er en teksthistorie, som beskriver en actors brug af systemet til at understøtte et specifikt mål. Det er en samling af detaljerede successcenarier og fejlscenarier samt andre vigtige forudsætninger for, at målet kan nås. 3 Vores første use case er ikke særlig fyldestgørende, men er lavet primært for at skabe overblik. Vi har indsat grundlæggede information, så som primary actor, stakeholders og success guarantees, og har også overvejet en række successcenarier og problemer, der vil kunne opstå undervejs. Et sådant use case kaldes for et brief use case. Det er en kortfattet opsamling, som er god at bruge i opstartsfasen, hvor krav, emne og omfang fastsættes. 4 Vores mål er, at videreudvikle dette use case i 1. iteration, hvor et bedre overblik over forløbet, forhåbentlig vil være aktuelt. Se bilag M: Use Case Inception fasen. 3 Larman (2005), s. 63 4 Larman (2005), s. 66 Side 9 af 41

Domænemodel Domænemodellen er den første model vi har tegnet, for på den måde at få vores primære tanker ned på papir. En domænemodel skal tænkes som en kilde af inspiration til videre udvikling. Det er en visuel fremstilling af virkeligheden, ikke af systemet eller softwaren. 5 Vi er enige om, at de forskellige typer information hver skal tegnes for sig, samt at disse alle skal forbindes til centrum i form af Information. Derudover har vi også tegnet View, da det rent logisk er nødvendigt med en visuel grænseflade, hvis systemet skal gøre gavn for brugeren. Figur 1 viser vores første simple domænemodel. Figur 1: Domænemodel Inception fasen Status efter inception fasen Efter inception fasen er vi klar til for alvor at gå i gang med projektet. Vi har fået ord og modeller på vores ideer, så vi har et godt grundlag for næste fase. Vi har lavet en blog, hvorpå alle disse ord og modeller er sat op, så vi hele tiden har kunnet følge processen og tænke fremad. Arbejdet med bl.a. domænemodel og use case har fået os til at se PIM opgaven fra andre vinkler end de umiddelbare, og vi har derfor fundet det fornuftigt at få skelettet til disse modeller på plads, inden selve kodningsarbejdet er begyndt. 5 Larman (2005), s. 135 Side 10 af 41

Fokus for 1. iteration Efter en veloverstået inception fase, føler vi os klar til at begive os ind i elaboration fasen og 1. iteration. Her vil vi i gang med at implementere de enkelte klasser fra domænemodellen i Flex og derefter gå i gang med selve kodningsarbejdet. Samtidig vil vi udbygge domænemodellen og tegne den ind på computeren, så den fremstår mere professionel. Vi vil ydermere tegne en klassemodel, så vi kan få sat attributter og funktioner på de enkelte klasser. Slutteligt vil vi igen se på use case, vision, glossary og risks, for at se om disse skal udvides og/eller ændres. Side 11 af 41

Inception Elaboration 1. iteration 2. iteration 3. iteration 4. iteration Elaboration fasen I en iterativ udviklingsmodel, som elaborationfasen er, bygges der på, at udviklingen til et færdigt produkt bliver organiseret i korte serier af miniprojekter kaldet iterationer. Ved at arbejde i miniprojekter, begrænses man til kun at sætte mål for udviklingen frem til næste iteration. Man kan lave iterationerne timeboxed, dvs. at længden af iterationerne er fastlagte, hvilket gør det muligt at have et præcist mål for hver iteration. Vi har valgt, at hver af vores fire iterationer skal have en varighed svarende til tre-fire arbejdsdage. I arbejdet med timeboxed iterationer er det vigtigt aldrig at forkorte eller forlænge en deadline, men hellere at overdrage opgaver fra eksempelvis 1. til 2. iteration, hvis ikke alle opgaver og mål er nået. 6 Arbejdet med iterationer giver os mulighed for ofte at drage nye refleksioner og komme med tilføjelser, hvilket gør os fleksible til at agere efter givne problemer og dermed konstant at være på rette kurs. Vha. struktur, klare mål og deadlines, sikrer vi, at vi altid har noget at sigte efter, og vi forhindrer derved mulighederne for at udskyde problemer. Som kontrast til den iterative udviklingsmodel, står vandfaldsmodellen. Ved brug af denne model, fastsættes projektets mål fra første dag, hvorefter dette mål bliver styrepinden for resten af processen, uden at kunne medtage yderligere refleksioner og restriktioner. Vi finder ikke denne model hensigtsmæssig, da vi har brug for de enkelte iterationer til konstant at kunne tilpasse os projektets situation ved f.eks. at ændre målsætninger. 6 Larman (2005), s. 22-23 Side 12 af 41

Inception Elaboration 1. iteration 2. iteration 3. iteration 4. iteration 1. iteration I 1. iteration har vi brugt en del af tiden på at få det grundlæggende på plads. Vi har udviklet og computertegnet modeller som domænemodel, klassemodel, use case og designmodel, hvilket har givet os en fast ramme at arbejde ud fra. De tre begreber vision, glossery og risks er blevet gennemtænkt, således at vi hele tiden er bevidste om vores mål og om de eventuelle problemer, der kan opstå undervejs. Det er vores ide, at holde fat i disse fire begreber gennem alle iterationer, så vi på den måde bevarer overblikket og hele tiden ser med nye øjne på vores situation. Rent kodemæssigt har vi implementeret alle klasserne fra klassemodellen samt de klasser, der udgør MVC. Dertil har vi haft fokus på nogle GRASP principper, som skal hjælpe os til at beherske objekt orienteret programmering samt at tildele ansvar i koden. Vision Visionen, beskrevet i inception fasen, har ikke ændret sig. Vi vurderer, at vi ikke er kommet langt nok i forløbet endnu til at konkludere, om visionen er sat for højt eller for lavt. Dette formoder vi vil være lettere og mere hensigtsmæssigt at se nærmere på i 2. iteration, hvor vi forhåbentlig er nået længere med projektet, både kodemæssigt og rapportmæssigt. Glossary Som nævnt i inception fasen, er det, i elaboration fasen, muligt at udbygge sit glossary med henblik på at lave det til en decideret data ordbog. En sådan ordbog kan indeholde kaldenavne, forbindelser mellem elementer og beskrivelser af en række værdier og valideringsregler, herunder med indblanding af systemets adfærd. 7 Vi finder det dog unødvendigt at lave en sådan data ordbog, da vi ikke har svære gloser i koden. Derfor forbliver glossary i 1. iteration magen til det fra elaboration fasen. 7 Larman (2005), s. 115 Side 13 af 41

Risks Risks for første iteration, er mest gået på at få implementeret klasser og funktioner i Flex Builder. Grundet tidligere erfaringer, kan startprocessen ofte være vanskelig, da man sidder med et helt nyt projekt og en masse tomme klasser. Vi har erfaret, at det er godt at få en sikker start, hvor koden er korrekt, og hvor man formår at vælge den korrekte og mest hensigtsmæssige vej. Derudover har vi set det som en ekstra udfordring at indføre MVC og hele tiden bevare denne model, som en grundlæggende del af projektet. Slutteligt har vi ikke arbejdet med opdaterende funktioner før, hvilket selvfølgelig har fået os til at stille spørgsmålstegn om, hvorvidt vi kan finde en løsning på sådanne. Domænemodel Vores domænemodel har været det første skridt på vejen mod udførelsen af PIM. Vi har haft en simpel tegnet model fra inception fasen, som vi nu har tegnet på computeren. Ud fra eksamensvejledningen er det stort set bestemt, hvilke typer information vi skal inddrage, hvilket gør det forholdsvis simpelt at lave domænemodellen. Domænemodellen består af de fem informationstyper: Research, Appointments, Contacts, Diary og Notes samt den overordnede klasse Information, som alle informationstyperne er forbundet til. Derudover består selve grænsefladen af et View, som brugeren kan interagerer med. Domænemodellen er at finde i bilag O: Domænemodel. UML Klassemodel Da domænemodellen er på plads, har vi været i gang med at sætte attributter og funktioner på de forskellige klasser, således at vi kan skabe os en klassemodel. En klassemodel har til formål, at illustrere klasser, grænseflader og associationer mellem dem 8. Dette har givet os en mere detaljeret idé om, hvordan projektet skal opbygges, og hvilke variabler og funktioner vi skal have implementeret. UML klassemodellen er at finde i bilag P: Klassemodel. UML Designmodel Når en klassemodel bruges i et softwareperspektiv, bruges begrebet designmodel. Her indskrives 8 Larman (2005), s. 249 Side 14 af 41

attributter og funktioner, præcis som i klassemodellen, blot som en total visuel præsentation af den kodemæssige opbygning og med kodemæssige termer. 9 Da vi stadig er så relativt tidlig i processen, vil vores designmodel kun være en foreløbig model, da den inddrager klasser, attributter og funktioner fra nuværende kode, som ikke er færdigudviklet endnu. Dog er der, i forhold til klassemodellen, især fokus på MVC, så denne tydeliggøres i modellen. Tankerne om implementeringen i forhold til MVC kan læses i afsnittet omhandlende den kodemæssige arkitektur. Vores designmodel er at finde i bilag Q: Designmodel. Use case model Udformningen af vores use case har først for alvor fundet sted efter, at klassemodellen er kommet på plads. Udformningen har sat en masse tanker og overvejelser i gang, som har givet mere struktur og en større bredde på opgaven. Vi har talt om risici, specifikke scenarier osv. I forhold til use caset fra inception fasen, er dette use case noget mere fyldestgørende, og det giver nu mere mening, hvorfor vi har lavet det. Vi er altså gået fra at have et brief use case til at være godt på vej mod et fully dressed use case. Her er alle variationer og tanker skrevet ned i detaljer, og vi kommer godt omkring forskellige scenarier. 10 Vi har kaldt vores use case for version 1.0, da vi regner med, at vi én eller flere gange inden projektet slutter, vil lave nyt use case, så vi kan lave sammenligninger. Slutteligt i rapporten, forventer vi, at kunne præsentere et udførligt fully dressed use case, hvor alle steps er overvejet og beskrevet. Vores nuværende use case er at finde i bilag R: Use Case. GRASP Selvom vi, i denne iteration, ikke er kommet langt kodemæssigt og derfor ikke har kunnet indbygge GRASP i koden, har vi alligevel tænkt over de forskellige principper omkring ansvarsfordeling. GRASP står for general responsibility assignment software patterns og via fokus på GRASP, har vi mulighed for at holde fast på nogle guidelines for ansvarsfordelingen i vores systems kodeopbygning. På nuværende tidspunkt finder vi de nedenfor skrevne principper mest relevante. Vi forventer dog senere en udbygning, hvor flere principper vil inddrages. 9 Larman (2005), s. 251 10 Larman (2005), s. 67 Side 15 af 41

Creator: Afgørelse af, hvilken klasse, der skal have ansvar for at oprette en anden klasses objekter. Ved et overvejet valgt af Creator ansvar, kan dette understøtte princippet Low Coupling, som beskrives længere nede. 11 Information Expert: Betyder, at man tildeler klasserne ansvar i forhold til, hvor ansvaret vil være mest relevant med henblik på klassens information. Dette kan give en fordel i, at klasser ikke er tæt forbundne til hinanden, hvilket giver et mindre komplekst kodeomfang, hvori der lettere kan redigeres. Dertil bliver relevante klasser til en specifik opgave også kun taget i brug, under programmets kørsel, hvilket giver høj samhørighed, som også er et GRASP princip. 12 Low Coupling: Betyder, at klasserne er lavt koblede til hinanden således, at hvis der ændres i én klasses kode, skal det ikke have stor indflydelse på de andre klassers funktionalitet. Den lave afhængighed klasserne imellem giver også mulighed for genbrug af klasser og udvidelse/fornyelse af systemet uden indviklede komplikationer. 13 High Cohesion: Cohesion er en måling for hvor stærkt relateret og fokuseret ansvarsfordelingen er for et element. Et element med høj samhørighed (High Cohesion) har højt relateret ansvar, men sætter ikke en enorm mængde arbejde i gang, når elementet køres. At dele et program op i klasser og subklasser er et eksempel på en aktivitet, som øger samhørigheden i et system. Fordelen ved høj samhørighed er bl.a., at det bliver lettere at vedligeholde og forbedre koden. 14 Controller: Dette princip tilkobles bl.a. når, der er fokus på MVC metoden, hvilket vi har intentioner om. Controlleren modtager og koordinerer systemoperationer i softwaren og sørger for kommunikationen mellem Model og View. Controller princippet vil blive gået nærmere i dybden under afsnittet om Model-View-Control. 15 Vi vil gennem beskrivelserne af vores kommende iterationer nævne brugen af GRASP 11 Larman (2005), s. 291-294 12 Ibid., s. 294-299 13 Ibid., s. 299-302 14 Ibid., s. 314-318 15 Ibid., s. 302-314 Side 16 af 41

principperne. Den kodemæssige proces I 1. iteration er vores risks blevet synliggjorte, i og med kodningen af vores PIM er påbegyndt. Der har været en række startproblemer, da vi startede kodeprocessen med en forkert opsætning. I farten med at få den første kode stablet på benene, var vi tæt på at glemme essensen af implementeringen, nemlig klassemodellen. Vi havde ikke fået implementeret alle klasserne fra klassemodellen, og havde derfor alt for mange funktioner og variabler fordelt på kun to klasser. Dette viste sig hurtigt at blive for løst og ustruktureret, og gjorde det tilmed svært for vores instruktorer at hjælpe os, når vi sad fast. Med startproblemerne løst, fik vi dog skabt god struktur og overblik over koden. Vi har implementeret alle klasserne fra klassemodellen, hvilke vi har udfyldt med den mest basale information, så som navn, id, variabler, og funktioner, således at det overordnede skelet er på plads. Dette har givet os mere overblik over, i hvilken retning vi skal gå. Første kodeskridt på vejen til vores PIM har været at få knapperne til at virke. Vi har hurtigt fået knapperne til at trace den data, der skrives i textinputtet, men har ikke kunne få denne data opdateret til listen. Næste større problem vi har haft, har været at skabe en funktion til opdatering af de forskellige informations-felter. Dette problem er noget mere komplekst end nødvendigt, grundet en konstant tankegang om, at have MVC en som fundament i hele systemet. Update funktionen er et emne, som vi tager med over i 2. iteration, hvor vi forventer dette problem, endelig løst. Status efter 1. iteration Med første iteration i elaboration fasen, har vi fået skabt en god forbindelse til inception fasen. Vi har bygget videre på artefakterne i takt med, at koden har udviklet sig og er blevet mere kompleks. Som en vigtig virkning heraf, har vi sat MVC i forhold til både kodning og designmodel, hvilket har givet en god struktur på systemet og en bedre forståelse af, hvad der sker. Derudover har udformningen af et mere detaljeret use case fået os til at overveje forskellige mulige scenarier, risici mv., som har givet os et mere nuanceret billede af projektet. Fokus for 2. iteration I 2. iteration forventer vi, at nå et markant skridt med koden såvel som rapportskrivningen. Side 17 af 41

Rent kodemæssigt vil vi færdigudvikle note funktionen, dvs. gøre det muligt at tilføje, slette og vise notes. Dermed forventer vi, at få den opdaterende funktion til at virke, som har voldt os mange problemer i denne iteration. Rapportmæssigt ønsker vi at udforme en opgavestruktur, således at vi har et overblik over, hvordan opgaven skal struktureres. Vi vil fortsat benytte os af princippet med pilot og co-pilot, således at den sidste person udelukkende skriver på rapporten. I rapporten kan udformningen af metode, inceptionfasen og elaboration fasen så småt begynde, og vi kan ydermere opskrive de kodemæssige op- og nedture, der har og vil opstå undervejs. Derudover vil vi igen se på de forskellige artefakter, samt på vision, glossary og risks, og derved afgøre om disse skal udvides eller ændres. Side 18 af 41

Inception Elaboration 1. iteration 2. iteration 3. iteration 4. iteration 2. iteration Som beskrevet i foregående afsnit, ønsker vi, i 2. iteration, at færdigudvikle note funktionen. Ved tilføjelse af note, menes at indtastet data gemmes og vises i en liste. Ønsker brugeren den tilføjede note slettet, skal denne specifikke note kunne markeres på listen og derefter fjernes. Ønsker brugeren derimod at se den tilføjede note igen, dvs. se de tidligere indtastede data, skal denne specifikke note kunne markeres på listen og derved vises i informations-felterne igen. Når denne del af programmet er færdigudviklet, formoder vi, at det vil være forholdsvis nemt at videreføre fremgangsmåden til de øvrige informationstyper. Derudover vil vi, hvis nødvendigt, opdatere alle artefakterne og igen se på glossary, vision og risks. Vision Vi har reduceret visionen en anelse ved at skære ønsket om en save funktion samt indsættelsen af billeder fra. Altså ønsker vi ikke længere, at systemet kan gemme nedskrevne data, hvis programmet lukker ned, ej heller ønsker vi, at brugeren skal kunne indsætte billeder. I stedet har vi valgt, at indsætte nogle standard data, som altid står fast i systemet, når brugeren åbner det. Dette vil gøre det lettere for brugeren og for stakeholders at teste systemet, og således hurtigt give en fornemmelse af, om systemet har den passende funktionalitet. Beslutningen om at fjerne disse funktioner fra visionen, er taget i samarbejde med vores instruktorer. Da funktionerne ikke er et krav i systemet, er vi blevet enige om, at det er bedre at fokusere på udførslen af et fejlfrit system og en fuldt gennemført rapport, i stedet for at bruge tid på en funktion, som vi ikke nødvendigvis får til at virke alligevel. Glossary Vores glossary i 2. iteration bevares stort set uændret, dog med en rettelse i informationstypen Research. Denne rettelse kan ses i bilag S og uddybes i afsnittet omhandlende kodeprocessen. Risks Ser man på potentielle risks i 2. iteration, kan nævnes: Side 19 af 41

De objekter vi nu har fået tilføjet vores arraycollection, skal vi have vist i en liste i viewet. Herefter skal vi kunne slette objekterne fra denne liste, og dermed også fra vores arraycollection. Når et objekt vælges fra listen, skal de data der er gemt i det pågældende objekt fremvises i vores input felter. GRASP I denne iteration har vi haft fokus på de, i foregående iteration, redegjorte principper: Creator, Information Expert, Low Coupling, High Cohesion, Controller. I forhold til Information Expert har vi i koden sørget for at lave controllere til PIM ens forskellige funktionalitet; note, research, appointments, diary og contacts. Dermed har vi fordelt ansvaret på flere forskellige klasser, således at f.eks. NoteController sørger for at holde styr på note, i stedet for at al funktionalitet ligger i én klasse med navnet note. Ved at lave forskellige Controller klasser til PIM ens funktionalitet, sørger vi også for at opretholde High Cohesion. Vi har igennem hele opbygningen af koden fokuseret på at have så lavt koblede klasser så muligt, således at vi i et fremtidsperspektiv vil have mulighed for at ændre i koden uden komplikationer. F.eks. kan det ses at note klassen, i vores kode, kun kender sig selv og ingen andre. Dertil kan note kun oprettes af NoteController klassen, og dermed bliver NoteController creator for klassen Note. I 1. iteration præsenterede vi GRASP og gjorde brug af fem ud af de ni GRASP-principper: Information Expert, Creator, High Cohesion, Low Coupling and Controller. I 2. iteration udvider vi vores brug af GRASP, og gør dermed også brug af de sidste fire principper: Polymorphism, Pure Fabrication, Indirection, og Protected Variations. Polymorphism Designprincippet polymorphism siger, at når relaterede alternativer eller opførsler varierer efter type (klasse), skal der fastsættes ansvar for opførslen, hos de typer som den varierer hos. Dette princip bygger altså på, at der ikke skal testes for en bestemt type af et objekt og ikke skal gøres brug af conditional logic, når der fremstilles varierende alternativer. 16 I stedet for klassers brug af nedarvning af funktioner og metoder fra en superklasse, foreslås det, at superklassen laves {abstract}. Derudover bruges der ikke if og if-else statements, da disse vil gøre det svært at ændre 16 Larman (2005), s. 416 Side 20 af 41

og tilføje i et system. I tilfælde af en ny variation i en klasse, vil en if statement ofte kræve, at der ændres på koden flere steder, hvorimod en klasse med individuelle metoder, kun kræver ændringer i selve klassens kode. Vi har grundlæggende gjort stor brug af Polymorphism i koden, hvilket var et valg vi tog i starten af processen. Her havde vi i tankerne, at sætte alle metoderne i klassen Information, således at informationstyperne i form af de øvrige klasser, blot kunne nedarve herfra. Dette kom vi dog hurtigt fra igen, da det viste sig, at de enkelte metoder varierede en smule fra type til type, og da vi ved brug af Polymorphism indså, at muligheden for ændringer og eventuelle tilføjelser blev nemmere. Pure Fabrication Pure Fabrication er en strategi, som bruges, når der skal gives ansvar til et objekt, hvor Information Expert ikke har nogle mulige løsninger. Strategien har fokus på opretholdelsen af High Cohesion og Low Coupling, vha. introduktion af nye objekter. Disse nye objekter er ikke direkte relateret til det fabrikerede og repræsenterer ikke et problemkoncept, men er kunstigt fremstillet klasser. Klasserne tildeles ansvar som opretholder disse principper, således at fremstillingen af fabrikationer fremstår rene, hvoraf navnet Pure Fabrication kommer. 17 Vi gør brug af Pure Fabrication i arbejdet med MVC, hvor vi bevidst har oprettet objekter som fungerer med MVC-modellen. Vi har skabt tre klasser, der udgør henholdsvis Model, View og Controller, og samtidig sørget for en ansvarsfordeling, som f.eks. tager højde for Low Coupling. Gennem hele processen med kodningsarbejdet har MVC ligget i vores bagtanker, hvorfor objekter, funktioner og ansvar konstant er tilpasset vores ønsker. Arbejdet med MVC er uddybet i afsnittet omhandlende den kodemæssige arkitektur. Indirection Indirection er princippet om at undgå direkte kobling mellem to objekter ved at indsætte et mellemliggende objekt og tildele dette objekt ansvar. Ansvaret kan bestå i at formidle information mellem komponenter eller services, så to objekter ikke er direkte koblet til hinanden. 18 Dette princip ses også i MVC, hvor Controller introduceres som mellemled mellem data i form af Model og repræsentationen i form af View. Denne ansvarsfordeling forklares yderligere i afsnittet omhandlende den kodemæssige arkitektur. 17 Larman (2005), s. 421 18 Larman (2005), s. 426 Side 21 af 41

Protected Variations Princippet Protected Variations beskytter elementer fra eventuelle variationer af andre elementer. Dette gøres ved at indkapsle fokus på usikkerheden med et interface og ved at bruge Polymorphism. 19 Som tidligere nævnt, har vi benyttet os af Polymorphism, hvor hver enkelt klasses ansvar er tæt koblet til klassen og kan redigeres i dennes kode. Dette sikrer Low Coupling. Den kodemæssige proces I arbejdet med opbygningen i den kodemæssige proces, har vi bl.a. haft en del fokus på GRASP og MVC. Vi har flere gange omrokeret koden, således at de rigtige klasser har fået det tiltænkte ansvar i forhold til MVC. Heriblandt har vi været nødt til at se på Information Expert princippet, som kan bruges som guideline, når ansvaret skal fordeles. Dette har endvidere givet os problemer med høj kobling mellem klasserne, fordi ansvaret er fordelt på en bestemt måde. Den høje kobling gør det svært for os at ændre i andre klasser, hvilket kan være et problem, hvis vi f.eks. ønsker at ændre i viewet eller andet. Dette vil vi tilstræbe at ændre, således at vi får lavt koblede klasser. I arbejdet med at få den opdaterende funktion til at virke, har vi oprettet en ny knap i systemet, kaldet update, således, at der nu er fire knapper i vores view. Denne ændring var nødvendig i arbejdet med at få funktionen til at virke. Med den opdaterende funktion på plads, har vi færdigudviklet informationstypen note. Med den fuldt udbyggede note, har vi også forsøgt at færdigudvikle informationstyperne diary og contacts. Vi har umiddelbart anset denne udbygning af disse to informationstyper som værende let, eftersom at de benytter sig af den samme kodestruktur og har den samme funktionalitet, som note typen har. Vi er dog rendt ind i uforudsete problemer, som ikke umiddelbart lader sig løse. Ved programmets runtime, får vi en null object reference fejl på de ny udbyggede diary og contacts. En gennemlæsning af den nye kode har ikke umiddelbart ført til noget svar eller nogen løsning på vores fejl, og derfor tages denne fejlretning med over i den 3. iteration. Status for note typen er ellers, at man nu kan tilføje, slette, opdatere og nulstille de forskellige inputfelter. Listen med de oprettede objekter er endvidere sorteret henholdsvis alfabetisk. 19 Larman (2005), s. 427 Side 22 af 41

Som nævnt i Glossary, er layoutet i typen Research ændret, således at den skiller sig ud fra de resterende typer. I stedet for muligheden for, at have flere cases i gang på samme tid, er det nu kun muligt med ét case ad gangen. Research består nu af ét stort felt, hvilket vi mener, giver bedre mulighed for brugeren til at arbejde som en rigtig researcher. Til feltet er der tilkoblet muligheden for at ændre farve, størrelse og skrift på teksten, således at researcheren kan understrege eller farvesortere de vigtigste emner. Dette giver en ny måde at arbejde på, hvilken vi finder mest hensigtsmæssig, da typen er udviklet til et sådant research arbejde. Desuden giver det variation i forhold til de andre typer. Sidst men ikke mindst, er vi startet på implementeringen af kodeværktøjet FlexLib i informationstypen Appointments. FlexLib er en kalenderfunktion, som skal gøre det muligt for brugeren, at se sine aftaler i et kalender-layout. Det er et værktøj, som vi ikke tidligere har arbejdet med, hvorfor det forvolder os en del besvær. Appointments er altså den eneste informationstype, som ikke på nuværende tidspunkt har den fulde funktionalitet. Udarbejdelsen af koden i den 2. iteration, har fulgt den iterative proces. Dette vil sige, at vi har udbygget vores program funktion for funktion, og efterfølgende overført de fungerende funktioner til andre dele af programmet. Således har vores kode udbygget sig stille og roligt i starten, hvor der kun blev tilføjet én ny funktion ad gangen. Men med udfærdigelsen af én af vores informationstyper, har koden kunne ekspanderer kraftigt, idet de næste par typer stort set skulle indeholde den samme kode. Dette viste sig dog, som nævnt, at forvolde nogle problemer. Status efter 2. iteration I 2. iteration har vi været produktive og er kommet langt både kodemæssigt og rapportmæssigt. Kodemæssigt har vi færdigudviklet note funktionen. Dette har ført til yderligere udvikling af funktionerne contacts og diary, der dog mangler nogle fejlretninger, som tages med over i den 3. iteration. Sidste funktion, appointments, er stadig under udvikling, grundet problemer med implementeringen af FlexLib. Det grundlæggende layout er forandret en anelse siden start, hvor vi eksempelvis er gået fra at have tre knapper på stage, til at have fire. Dette er gjort for at få den opdaterende funktion til at fungere. Derudover er Research funktionen blevet anderledes, da det nu kun er muligt at køre ét case af Side 23 af 41

gangen. Denne ændring vil skabe ændringer i klasse- og designmodellen, da nogle af variablerne og funktionerne fra Research klassen skal fjernes. Disse omfangsrige ændringer i modellen, vil dog først blive foretaget i 3. iteration. Rapportmæssigt har vi fået skrevet processen med 1. iteration færdig, samt et godt stykke af 2. iteration. Vi har fået lavet en indledning, større metodeafsnit, uddybning af vision og risk osv.. Fokus for 3. iteration I 3. iteration forventer vi at blive færdige med størstedelen af kodningsarbejdet og dermed have en velfungerende software, som kan benyttes af en bruger. Som følge af den sene udmelding om kravet til implementering af FlexLib, er vores fokus i denne iteration bl.a. rettet imod at få FlexLib til at fungere optimalt. Dertil har vi bestemt at flex scheduling framework skal anvendes i klassen calendarcontroller samt klassen calendar. Derudover skal vi have lavet et mere udførligt UML designmodel, som beskriver attributterne og funktionerne i hver enkelt klasse, så snart FlexLib er implementeret og fungerer. Side 24 af 41

Inception Elaboration 1. iteration 2. iteration 3. iteration 4. iteration 3. iteration 2. iteration er næsten forløbet som forventet, og vi har nået de fleste af de mål, som vi har opstillet. Dermed kan vi gå videre til 3. iteration, ved kun at trække ét mål med fra 2. iteration. Dette er nogle compiler problemer, som vi er begyndt at løse i 3. iteration. Det har lykkes os at omgå fejlene ved at tilgå Viewets elementer direkte. Dette vil beskrives yderligere i senere afsnit om kodningsprocessen. Derudover har vi optimeret enkelte elementer i vores View, således at man i feltet zipcode kun kan skrive tal og ikke andre tegn. Ligeledes kan man i feltet med mobil nr. og telefon nr. kun skrive tegnet + og tal. Samtidig har vi opdelt vores kode i flere controller klasser, således at koden er blevet mere struktureret. Kodestrukturen kan ses i bilag A-L. Desuden er kravet til FlexLib kommet i slutningen af 2. iteration og dermed er fokus videre i 3. iteration at få implementeret FlexLib i softwaren, således at det fungerer optimalt. Vision Visionen, videreudviklet i 2. iteration, forbliver uændret. Glossary Glossary, videreudviklet i 2. iteration, forbliver uændret. Risks Vores risks for denne iteration er, at få Flex Scheduling Framework til at virke optimalt. UML Designmodel Vi har, som afslutning på 3. iteration, opdateret vores designmodel med alle eksisterende attributter og funktioner. Denne designmodel kan ses i bilag T: Designmodel 3. iteration. Side 25 af 41

Den kodemæssige proces Vores tidligere nævnte runtime fejl skyldes, at Flex ikke har kunnet assigne så mange variabler ved start, som vi har haft oprettet. Vi har, i et forsøg på at forenkle vores kode, skabt variabler for hver af Viewets elementer. Vi har forsøgt at oprette variablerne lidt efter lidt, som programmet er compilet, men dette har ikke hjulpet. For at omgå denne fejl, har vi ydermere forsøgte at tilgå Viewet direkte via direkte henvisninger til Viewets elementer, hvilket har vist sig at være løsningen på vores fejl. Vi finder dog ikke denne løsning helt optimal, eftersom en ændring i Viewet nu kræver, at koden skal rettes til i mange forskellige linjer og dermed øger kodens kompleksitet og fleksibilitet. Men eftersom Flex Builder tilsyneladende ikke kan håndtere så mange variabler på én gang, ser vi ingen anden løsning, end at tilgå vores View direkte. Med denne løsning, er udbygningen af informationstyperne, notes, contacts samt diary nu færdig. Således har alle tre typer den samme funktionalitet, nemlig at tilføje, slette, opdaterer samt at nulstille inputfelterne. De respektive informationstypers lister er desuden også sorteret efter henholdsvis navn og dato. Sorterings funktionen er ikke en funktion, vi umiddelbart selv har kunnet udarbejde. Vi har forsøgt først at skifte vores list elementer ud med elementet datagrid, men dette har ikke fungeret, og vi er har derfor rettet fokus tilbage på list. Vi er endt med at inkorporere en sorterings funktion, som er at finde på en ActionScript udviklernes hjemmeside. 20 Efter vejledning har vi besluttet os for at omstrukturere vores kode. Før har vores kode været struktureret som vist i bilag Q, med et view, en controller, en informationsklasse samt en klasse til hver af informationstyperne. Således har funktionaliteten været lagt ud i de enkelte informationstyper, hvor controlleren således kun har stået for tolkningen af brugerinputs. Vores omstrukturering af koden fremgår af bilag T. Heraf ses det, at vores kode nu består af et view, en informationsklasse, samt en controller og en klasse for hver informationstype. Således er det nu den enkelte controller, der besidder funktionaliteten til at ændre i modellen. Således er koden nu blevet mere fleksibel, og det er dermed lettere at udskifte elementer i vores program. 20 [3] Flex Exampels, sorting an arraycollection, http://blog.flexexamples.com/2007/08/05/sorting-an-arraycollectionusing-the-sortfield-and-sort-classes/ Side 26 af 41

Vi har, i løbet af 3. iteration, også integreret Flex Scheduling Framework. Eftersom der ikke umiddelbart er nogen dokumentation eller opstartshjælp til brugen af FlexLib, har vi fundet inspiration i koden fra de eksempler, som folkene bag FlexLib har lavet. 21 Ved hjælp af denne kode, har vi således fået udbygget vores informationstype klasse calendar, således at man kan zoome ind og ud på tidslinjen, gå til det nuværende tidspunkt samt til det markerede element i tidslinjen. Vi har selv udviklet funktionerne til at tilføje nye elementer samt at slette elementer igen. Netop det, at slette elementer igen, har været det, der har voldt os allermest besvær. Vi har forsøgt, i første omgang, at bruge samme fremgangsmåde til at slette på, som vi har gjort brug af i de øvrige informationstyper. Men her er vi stødt på to problemer. For det første har det vist sig, at FlexLib ikke tildeler elementerne på viewet et index. Dette har skabt problemer for os, eftersom vi har forsøgt at lave vores slettefunktion på samme måde som i de tidligere informationstyper, nemlig ved at slette det valgte index. Vi har forsøgt, som løsning herpå, at slette ud fra aftalens navn. Her har det dog vist sig, at FlexLib ikke tillader, at man skriver til eller læser attributten label. Rent tilfældigt, har vi også forsøgt at slette ud fra aftalens starttidspunkt, og her er løsningen på vores problem. Vi har ikke kunne finde ud af netop, hvorfor denne starttid er unik, da to aftaler, oprettet til samme tidspunkt, har samme start tid, men ikke desto mindre virker det efter hensigten. Status efter 3. iteration Vi har i 3. iteration opnået at få FlexLib implementeret, og programmet opfylder nu kravene fra opgavestillingen. Udover FlexLib har vi også udvidet programmet til, at brugeren nu f.eks. kun kan skrive tal i tekstfeltet zipcode samt kun tal og + i tekstfelterne phone og mobile. Med kravet til FlexLib er det grundlæggende GUI layout også ændret. Vi valgte at placere funktionaliteten af FlexLib under appointments, således at bruger kan se en aftales varighed samt dato. Slutteligt har vi lavet en designmodel over det nuværende programs funktioner og attributter. Fokus for 4. iteration Da vi efter 3. iteration sidder tilbage med et færdigudviklet system, forventer vi igen at ændre visionen i 4. iteration. Da vi er i overskud af tid, vil vi benytte muligheden for alligevel at forsøge at 21 [4] Google Code, FlexLib, http://code.google.com/p/flexlib/source/browse/trunk/examples/flex3/schedulingframework/scheduleviewer7_sample.mxml Side 27 af 41

gennemføre den vision, vi udtænkte i starten af hele processen. Vores fokus for 4. iteration er derfor at få udvidet PIM ens funktionalitet til at kunne gemme data. Dette bliver vores fokus, da vi mener, at vi med en sådan funktionalitet, har udviklet et fuldt funktionsdygtigt program. Derudover vil vi afslutningsvis lave sekvensdiagram, designmodel og use case diagram over den endelige opbygning. Dertil vil vi rette fejl og tilpasse kodearkitekturen samt måske rette GUI designet til. Side 28 af 41

Inception Elaboration 1. iteration 2. iteration 3. iteration 4. iteration 4. iteration Ved begyndelsen til 4. iteration, står vi tilbage med et færdigudviklet system, som har opfyldt vores vision. Med udsigten til en hel iteration, bestående af tre dage, har vi besluttet at udvide visionen ved stort set at ændre den tilbage til den oprindelige. Vi fornemmer et overskud af tid, som derved giver os mulighed for at opnå det fulde funktionsdygtige program, som vi gik efter fra starten. Dvs. at det kodemæssige fokus for 4. iteration bliver, at udvide PIM ens funktionalitet til at kunne gemme data. Derudover vil vi lave et sekvensdiagram, som bl.a. kan være med til at understøtte arbejdet med MVC og andre dele af den kodemæssige opbygning. Vi vil færdigudvikle vores use case, så den tilpasses det system, vi ender ud med. Dette vil ligeledes blive gjort med designmodellen, således at alle attributter og funktioner indskrives. Dertil vil vi rette fejl og tilpasse kodearkitekturen samt eventuelt rette GUI designet til. Slutteligt vil vi i 4. iteration færdiggøre rapportskrivningen, hvor refleksion og konklusion vil være i centrum. Vision Da dette er sidste iteration, kommer der her en endelig udformning af visonen: Vores vision med systemet er, at brugeren får et velfungerende system, hvori han/hun kan skrive informationer om sit liv og sine omgivelser. Vi ønsker at systemet skal indeholde informationstyperne contacts, notes, appointments, research og diary. Et velfungerende system i vores øjne indebærer, at systemet kan gemme nedskrevne data, selvom programmet lukkes ned, således at brugeren kan finde tidligere information frem, når der er brug for det. Vi vil gøre det let for brugeren at udfylde tekstfelterne i systemet. Dette gøres ved f.eks. kun at tillade tal i feltet til mobilnummer og kun tillade bogstaver i feltet til navn. Glossary Glossary fra 2. iteration forbliver uændret og ender altså som det endelige glossary. Side 29 af 41

Risks Vores risk for den 4. iteration, er at få programmet til at gemme data i form af et sharedobject. Designmodel Designmodellen er nu fuldt opdateret, således at den passer til det færdigudviklede system. Designmodellen er udbygget med to klasser, nemlig ResearchController og Research, således at data herfra også vil kunne gemmes i et sharedobject. Designmodellen for 4. iteration kan ses i bilag V. Use case Vores use case er nu fuldt opdateret, således at det passer til det færdigudviklede system, se bilag U. Den kodemæssige proces Efter to dages arbejde må vi erkende, at visionen alligevel ikke lykkes og, at gemmefunktionen altså ikke bliver en realitet. I løbet af iterationen har vi haft flere problemer med vores sharedobject. I første omgang lykkedes det os at få gemt vores data i et sharedobject. Vi havde dog problemer med, at vores sharedobject gemte data som objekter, og altså ikke som ønsket af f.eks. typen note. Vi troede i første omgang, at dette skyldtes en manglende tostring funktion på vores sharedobject, men en gennemlæsning af sharedobject viste, at denne altid bliver gemt i et tekst format, og dermed altid vil indsættes som typen object. Vores løsnings forsøg på dette problem blev, at oprette endnu en arraycollection, som skulle indeholde objekterne fra vores sharedobject. Fra denne arraycollection skulle objekterne så tilføjes til vores oprindelige arraycollection ved at konventer objekterne om til den korrekte type, f.eks. note. Det er dog ikke lykkes os at få dette til at fungere, hvorfor vi har valgt at udelade denne funktionalitet fra iterationen. I stedet har resten af iterationen været brugt til at skabe kodedokumentation samt at rette kritiske fejl i koden. En af disse fejlrettelser har været i vores scheduleviewer. Her har det hidtil været muligt for brugeren at indtaste en slut dato, der ligger før en start dato, hvilket ikke giver mening. ScheduleViewer angiver ikke selv nogle fejl ved en sådan indtastning, og derfor har vi først opdaget fejlen så sent. Fejlen er rettet ved, at slut datoens tilladte dato skal være lig den fra start datoen eller større. I forbindelse hermed har det også været nødvendigt at deaktivere slut datoen, så længe der ikke er indtastet nogen start dato. Side 30 af 41

Status efter 4. iteration Vi har i den 4. iteration måtte sande, at vi ikke kunne opnå vores vision om at kunne gemme data. Som tidligere nævnt, skyldes dette komplikationer med sharedobject. Til gengæld har den 4. iteration udmøntet sig i forbedret kodedokumentation samt fejl retninger. Vi har således også fået udarbejdet en designmodel over vores endelige program, se bilag V. Hermed er udviklingen af vores PIM afsluttet. Side 31 af 41

Den kodemæssige arkitektur Dette afsnit omhandler den kodemæssige arkitektur, dvs. processen med at indføre klasser, variabler og funktioner fra klassemodellen til programmeringsprogrammet Flex Builder. Denne proces er uafhængig af den iterative udviklingsproces, og omhandler begrundelser for valg af kode, beskrivelser af kodefunktionalitet og detaljerede redegørelser for specifikke kodeafsnit. Herunder vil vi komme ind på de tidligere nævnte GRASP-principper, samt Model-View-Controller (MVC). Formålet med afsnittet er, at vise vores forståelse for kodningsarbejdet og betydningen af de valg, vi har foretaget omkring kodestrukturen i et kodenært perspektiv. Som det ses i designmodellen (bilag V), har vi implementeret alle klasserne fra klassemodellen, hvilket vil sige, at hver type af information har fået sin egen klasse i kodningen. Det har givet god struktur og overblik, at hver type information har en selvstændig klasse. I disse klasser er der indsat variabler og funktioner, præcis som set i klassemodellen, hvilket giver et parallelt forløb mellem klassemodellen og kodningen. Designmodellen minder altså meget om klassemodellen, hvilket giver os et hint om, at koden ikke ligger langt fra den oprindelige model. Model-View-Controller Udover de fem typer af information, repræsenteret af hver deres klasse, er der implementeret yderligere tre klasser. Disse tre klasser udgør Model-View-Controller, forkortet MVC. MVC er et designmønster, som ofte bruges i udformningen af systemer med en brugergrænseflade. Kort og godt, bidrager MVC til en opdeling af systemet i tre dele, bestående af en model, en præsentation og en kontrollør. 22 Den første klasse, Information, forbindes med de fem typer information, med hvem den tilsammen udgør Model. Model håndterer domænets data og adfærd, ved f.eks. at reagere på instrukser om at ændre tilstanden (ofte fra Controller). Der kan kun gives instrukser og udføres ændringer gennem et Figur 2: Model-View-Controller 22 [2] Javabog, kapitel 19, Model-View-Controller, http://javabog.dk/vp/kapitel19.jsp Side 32 af 41