Oversigt over artefakter

Transkript

1 Oversigt over artefakter Disciplin Artefakt Inception Elaboration Henvisning Afgrænsning og forståelse Design Implementering Vision s u Bilag 1 Feltnotater fra interviews s Use Cases s u Bilag 2 Use Case diagram s Bilag 3 Systemsekvensdiagrammer s Bilag 4 Operationskontrakter s Bilag 5 Liste til domænemodel s Bilag 6 Domænemodel s u Bilag 7 Papirsprototyper s Bilag 8 Interaktionsdiagrammer s Bilag 9 Klassediagram s Bilag 10 Javaprogram s Bilag 11* Dokumentation s * * findes også på vedlagte cd-rom og på: s = start, u = udvikling Side 1 af 18

2 Indledning Denne opgave er en opsamling og præsentation af den proces, som vi igennem de sidste tre måneder har gennemgået i forbindelse med udviklingen af et træningsprogram til maratonløbere. Opgaven vil især afspejle, hvordan vi har brugt forskellige systemudviklingsmetoder, men selve processen har også budt på mange timers programmering, som er resulteret i version 1.0 af din personlige træner, som er vedlagt på cd-rom. Arbejdet med projektet har først og fremmest været en læreproces, hvor vi har afprøvet de metoder, som er blevet behandlet i undervisningen. Vi har især forsøgt at lægge vægt på den objektorienterede tankegang i forbindelse med den iterative udviklingsproces. Derfor har det primære mål ikke været at udvikle det bedste system mest effektivt, men at få erfaringer med systemudvikling. Teori og metode Unified Process Processen har overordnet været struktureret efter principperne bag Unified Process, præsenteret af Craig Larman. Denne metode bygger på en iterativ udviklingsproces, hvor systemet udvikles og forfines igennem mange iterationer, som hver indeholder elementer af både analyse, design og implementering. Disse iterationer kan inddeles i forskellige faser, som det fremgår af dette skema (fra Larman s. 20): Inception: Opstartsfase: go/no go til hele projektet Elaboration: Udbygningsfase, de mest risikable elementer implementeres Construction: De resterende dele af systemet implementeres Transition: Test og frigivelse af systemet Hver af ovenstående faser (undtagen Inception) består af en række iterationer, i vores projekt har vi gennemgået inception samt to iterationer i elaboration. Systemet er derfor heller ikke på nogen måde færdigt endnu men skal udbygges over flere iterationer. Styrken ved den iterative udviklingsproces er, at man ved at behandle de mest risikable elementer ved systemet i de første iterationer undgår at bygge videre på et forkert grundlag. I den klassiske systemudviklingsmodel, vandfaldsmodellen, udførte man først al analysearbejdet, dernæst design og til sidst implementering. Hvis der så viste sig problemer med et afgørende element under implementeringen, kunne man risikere, at meget af design- og analysearbejdet skulle laves forfra. Det undgår man i iterativ udvikling, idet man kun laver analyse og design af det, som skal implementeres i den pågældende iteration. Side 2 af 18

3 Som supplement til Larman og Unified Process har vi inddraget Contextual Design (Beyer og Holtzblatt), som fokuserer på forståelse af brugeren, hvilket er udgangspunktet for at analysere og designe et system. Det er et aspekt, som Larman ikke behandler så grundigt, idet han forudsætter at der er en veldefineret ramme for projektet. Dette kommer vi tilbage til i afsnittet om Contextual Design. Begrebsdefinitioner Hver iteration kan opdeles efter forskellige discipliner, og vi har i den forbindelse valgt at anvende nogle af begreberne fra den metode som er præsenteret af Mathiassen et. al. (metoden benævnes fremover OOA&D). Efter den indledende inceptionfase, hvor der bliver givet startskud for projektet, indledes analysen, hvor anvendelses- og problemområdet undersøges. Anvendelsesområdet betegner det felt, hvor interaktionen mellem bruger og system finder sted, og problemområdet betegner det felt, som systemet administrerer, overvåger eller styrer (Mathiasen et. al. s. 6). I vores projekt er anvendelsesområdet brugerens interaktion med systemet i forbindelse med planlægning og evaluering af træning, og problemområdet er selve træningen og de træningsmuligheder, der er. Både Larman og OOA&D skelner mellem analyse og design. I analysen beskæftiger vi os med fastlægning af krav til systemet, altså hvad systemet skal kunne, samt forståelse af problemområdet. Efter det er slået fast, hvad systemet skal kunne, skal der i designdelen besluttes hvordan systemet skal gøre dette. Opgavens opbygning Distinktionen mellem analyse og design afspejles også i opgaven, hvor første del beskæftiger sig med use cases og domænemodel, som er analyse af henholdsvis anvendelses- og problemområdet. Analyseværktøjerne præsenteres nærmere i de enkelte afsnit. Derefter gennemgås designprocessen med vægt på, hvordan man ved hjælp af mønstre kan forvandle arbejdet fra analysen til et godt objektorienteret design, som gør det muligt at videreudvikle systemet i de kommende iterationer. Vi har valgt ikke at bygge opgaven helt kronologisk op, idet vi i selve udviklingsarbejdet har gennemgået analyse- og designfasen en gang for hver iteration, hvilket ikke vil blive gjort i opgaven. Afsnittene skal således ses som et sammenkog af hver disciplin i de enkelte iterationer. Krav og analyse Vi havde i den indledende fase til dette projekt en ide om at udvikle et træningsprogram til løbere. Vi ville med andre ord lave et træningsprogram, der skulle være dynamisk og fleksibelt, så det kunne tilpasses den enkelte brugers træning. Det betød, at vi først måtte undersøge, om der overhovedet var et marked til et program af den type. Dette svarer meget til den proces, som ifølge Beyer og Holtzblatt forløber i en marketingsafdeling: Marketing needs to understand what people Side 3 af 18

4 will buy and how people make buying decisions 1. Til at undersøge om der var et behov samt få bekræftet, om vores ide var bæredygtigt, tog vi kontakt til en løbeklub 2 og institut for idræt ved Århus universitet. Denne kontakt blev skabt ved hjælp af omdelte flyers, opslag i klubhuset og en konstrueret hjemmeside, 3 hvor vi præsenterede vores idé til projektet. Man kan umiddelbart sige, at starten af projektforløbet ikke er det, man normalt forstår ved systemudvikling, idet vi selv skulle finde på ideen, vi skulle selv definere, hvad systemet skulle kunne, og retfærdiggøre, hvorfor man skulle bruge tid på at udvikle det. I den virkelige verden vil dette ofte være gjort i forvejen, enten fordi man har nogle brugere, som vil betale for et system, eller fordi man får en opgave stillet af marketingsafdelingen. Denne fase vil derfor ofte være adskilt fra systemudvikling, da indsamlingen af data omhandler markedet og ikke fokuserer på kundens arbejde, og hvordan dette udføres. 4 Efter at have fået bekræftet, at et computerbaseret træningsprogram ville være af interesse for løbere, ændrede vi vores tilgang til brugerne fra at undersøge behovet til at undersøge, hvordan brugerne træner, og hvordan de vil kunne bruge systemet. Contextual Inquiry Til at afgrænse og forstå problemområdet er der taget udgangspunkt i Contextual Inquiry, der ud fra af en fænomenologisk tilgang opstiller nogle kvalitative metoder til at reducere kompleksiteten af problemområdet og forstå brugeren. Der gælder overordnet, at man skal interagere med brugerne og involvere dem i udviklingen, hvilket skal forstås ud fra det syn: at de er eksperter, og at det er dem, man udvikler systemet til (Beyer og Holtzblatt, s. 29). Gennem vores indledende research fik vi kontakt med tre løbere fra Århus 1900 samt en idrætsstuderende ved Århus universitet. Vi fandt denne gruppe dækkende for vores problemområde, da løberne kunne bidrage til at give os indsigt i deres træning og den måde de strukturer det på. Endvidere fandt vi det relevant at inddrage en idrætsstuderende med teoretisk baggrund for, hvordan man træner optimalt. Han er til dagligt også vant til at træne folk og kunne derfor være med til at forklare den viden, som for løberne selv er uartikuleret på grund af indgroede rutiner. Contextual Inquiry bygger på fire principper: kontekst, partnerskab, fortolkning og fokus, som vil blive forklaret nærmere nedenfor. Kontekst Contextual Inquiry lægger meget op til, at man skal observere kunden under arbejdet og i de situationer, hvor beslutningerne bliver taget (Beyer og Holtzblatt, s. 47), hvilket for vores vedkommende har været svært. Det skyldes, at løb er en meget individuel sport, hvor folk løber på forskellige tidspunkter, samt at de beslutninger der tages i forhold til træningen er meget spontane 1 Contextual Design (CD), Hugh Beyer & Karen Holtzblatt s Århus 1900 (en løbeklub i Århus) Beyer og Holtzblatt, s. 31. Denne distinktion mellem marketing og systemudvikling kan betragtes ud fra en henholdsvis kvantitativ og en kvalitativ tilgang, hvilket vi ikke kommer nærmere ind på her. Side 4 af 18

5 og afhængige af mange faktorer lige fra helbred til humør 5. Disse mentale beslutningsprocesser kalder Contextual Inquiry for henholdsvis intermittent, dvs. processer der forgår i kort tid og hvor det ikke er muligt at være til stede, og internal, dvs. interne beslutningsprocesser, som ikke kan observeres (Beyer og Holtzblatt, s ). At vi ikke var til stede under deres træningen afspejler sig også i vores interviews, idet vi stillede retrospektive spørgsmål for at få dem til at forklare, hvad de tænker når de løber og forbereder træning. Fokus Vi valgte en open ended tilgang for at være så åbne overfor deres træningsmetoder og overvejelser herom som muligt 6. Det viste sig flere gange under interviewet, at vi måtte stille sonderende spørgsmål samt bede dem forklare en træningspraksis fra start til slut. Dette blev gjort med henblik på at opnå mere konkrete data, da de havde en tendens til at abstrahere fra det fokus, vi havde med interviewene. Partnerskab Man kan til dels sige, at der under interviewene opstod et mester/lærlinge-forhold, hvor de forklarede os om deres erfaringer og ideer til et system. Dette forhold bygger især på, at vi indledningsvis motiverede dem ved at sige: at de var vores eksperter, og at vi for at kunne udvikle et program var afhængig af deres viden. Til at understøtte dette partnerskab, havde vi udviklet en hjemmeside, hvor de har mulighed for at følge projektets udvikling, samt skrive til os hvis de havde indvendinger. Dette gensidige tillidsforhold og samarbejde fremhæver Contextual Inquiry som værende vigtigt for at få dem til selv at bidrage til udviklingen ved at komme med feedback og hjælpe til vores forståelse (Beyer og Holtzblatt, s ). Fortolkning Vi stillede under interviewet fortolkende spørgsmål til løberne med henblik på at få afklaret betydningen ude ved løberne samt sikre os, at vi forstod dem rigtigt. Desuden har det udover afklaring medført, at vi har hjulpet løberne til selv at se og kortlægge disse mønstre, hvilket betød, at løberne flere gange under interviewene begyndte at sondere og fortolke på, hvorfor de trænede som de gjorde. Dette har spillet en vigtig rolle i både analyse- og designfasen, da vi generelt har haft lettere ved at forholde os til, hvordan de tænker og handler, idet vi har delt vores fortolkninger af dataene med dem. Contextual Inquiry beskriver det som vigtigt for at udvikle et sandfærdigt system, som bygger på kundens opfattelse: design is built upon interpretation of facts so the interpretation had better be right. (Beyer og Holtzblatt, s. 58). At fortolkningen er så vigtig for tilskrivelsen af den rigtige opfattelse har gjort, at vi i projektgruppen har brugt en del tid på sammen 5 Mange beslutninger sker ofte hjemme hos løberne selv, og vi følte ikke at vi kunne tillade os at trænge på ved dem privat. 6 Dette bunder til dels også i, at vi på daværende tidspunkt havde et meget bredt fokus. Side 5 af 18

6 at fortolke de rå data for at se, om der var nogle fælles mønstre, som kunne være med til at generalisere undersøgelsen og skabe grobund for ideer til systemets udformning. Refleksion over Contextual Inquiry Grundlæggende for denne undersøgelsesfase har det været svært at bruge Contextual Inquiry, da metoden er bygget op omkring observation af kundens arbejde. Alligevel har interviewene med vores brugere været af uundværlig værdi, idet det har givet os et indblik i brugernes artikulerbare og uartikulerbare viden. For at få en endnu bedre forståelse for træningsforløbet, samt lave en opsamling på de mange data fra interviewene, forslår Contextual Design, at man bruger forskellige work models, men dette har været svært at bruge i vores projekt af flere årsager. For det første er mange af modellerne ikke brugbare på intermittent og internal arbejde, som udføres af en enkelt person. Således giver kultur- og flowmodellen kun mening, hvis der er flere personer til stede. Sekvensmodellen har vi heller ikke fundet særlig brugbar, da den ville den være temmelig kort og ikke give ny indsigt. Den fysiske model giver ikke så meget mening, da man så skulle tegne forskellige huse og løberuter, som er vidt forskellige. Artefaktmodellen er den eneste, som giver mening i vores projekt, og den har spillet en vigtig rolle under hele projektforløbet. Vi fik nemlig mulighed for at studere deres træningsdagbøger, hvilket har været stor inspiration til udvikling af prototyper, men også under interviewforløbet blev de brugt til at eksplicitere deres personlige overvejelser og træningsmønstre. Som eksempel kan det siges, at en af løberne brugte smileys til at udtrykke om det havde været en god eller dårlig træning. Desuden har vi også studeret forskellige hjemmesider med logbøger og forslag til, hvordan man skal tilrettelægge sin træning. En anden grund til at de forskellige work models ikke er brugt i så stort et omfang er, at vi i gruppen ikke har haft et behov for at eksplicitere og kommunikere vores viden, da vi alle har deltaget i interviewene. Contextual Design s work models henvender sig nok mere til større projektgrupper, hvor man skal have videregivet sin forståelse af arbejdet til andre i gruppen. Som beskrevet i teoriafsnittet behandler Larman ikke den del af systemudvikling, hvor man indgår i tæt samarbejde med brugerne for at opnå den bedste forståelse for de omgivelser og brugere, som man ønsker at udvikle et system til. Contextual Inquiry har været en stor hjælp til at forstå og undersøge, hvad der er muligt at udvikle. Side 6 af 18

7 Use Case Model Use Cases Visionen giver et overordnet fokus og billede af systemet, men den siger ikke noget præcist om, hvad systemet skal kunne. For at kunne gå videre i analyse- og designfaserne er det vigtigt at slå fast, hvad systemet skal kunne; der skal fastlægges krav til systemet. 7 Til dette formål bruges Use Cases, som er små narrativer, der beskriver aktørernes interaktion med systemet og dermed fastlægger systemet funktionelle krav. En aktør kan i denne forbindelse både være en person og et computersystem. Use casene viser forskellige scenarier fra de situationer, hvor en bruger vil interagere med systemet. En use case kan således bestå af flere scenarier, og man vil oftest have et hoved successcenario, hvor målet med use casen bliver opfyldt. Der kan så være variationer og undtagelser fra dette scenario, hvilket anføres efterfølgende (i vores use cases hedder det Udvidelser ). Use cases kan skrives i forskellige formater, alt efter hvor detaljerede man ønsker dem (Larman s. 49): Brief: kort beskrivelse af hoved successcenariet Casual: Lidt længere beskrivelse, som også dækker alternative scenarier og undtagelser Fully dressed: udtømmende beskrivelse af hvert enkelt trin, ofte efter en skabelon, som definerer layout og hvilke elementer, der skal medtages. Nedenfor præsenteres use casene i dette projekt, som det ser ud ved slutningen af 2. iteration i elaboration (selve use casene findes i bilag 2. I bilag 3 findes også et diagram over samtlige use cases): Aktør Mål Se og tilpas træningsprogram Se og tilpas dagbog Løber Opret og ret profil Identificér bruger Den aktør som planlægger træningen Se statistik Tilrettelæg træningsprogram Evaluer træningsprogram Som det fremgår ovenfor, er use casene struktureret efter aktørernes mål. Det vil sige, at use casene afspejler handlinger, som aktøren foretager for at opnå et bestemt mål, f.eks. er målet for løberen i den første use case at se og tilpasse træningsprogrammet. Larman argumenterer for, at en use case skal afspejle et mål, som er værdiskabende for brugeren (Larman s. 48). De mål, som umiddelbart er værdiskabende, er de to første og de to sidste 7 I det virkelige liv vil kravene ofte samtidig have den funktion, at de danner grundlag for en eventuel kontrakt mellem systemudviklere og kunde. Side 7 af 18

8 i ovenstående tabel samt Se statistik. Både Opret profil og Identificér bruger er ikke direkte værdiskabende for brugeren, de er kun medtaget fordi de er en betingelse for de andre. 8 En af pointerne og styrkerne ved at bruge use cases er, at de kun fastlægger, hvad systemet skal gøre, og ikke hvordan. Man opretholder således stadig distinktionen mellem analyse og design, hvilket er vigtigt, idet use casene skrives tidligt i processen, hvor man som systemudvikler måske endnu ikke har en fuld forståelse af problem- og anvendelsesområdet. Selvom man selvfølgelig ofte vil have en idé om, hvordan man kunne designe systemet, er det afgørende at black boxe systemet, så det kun er interaktionen mellem system og bruger, som bliver fastlagt. Use cases som struktur for iterationerne Use cases har i Unified Process den funktion, at de bruges til at strukturere iterationerne. Før man starter på en ny iteration, udvælges en bestemt use case, som skal implementeres i den efterfølgende iteration. Man kan også nøjes med kun at vælge en del af use casen, hvis det tager for lang tid at implementere det hele, eller man kan vælge flere use cases, hvis de ikke er så tidskrævende. 9 Den use case, som man vælger at implementere, bliver så styrende for det videre arbejde både i analysen og design. På den måde reducerer man kompleksiteten i resten af processen, idet man kun skal beskæftige sig med det, som har med den specifikke use case at gøre, resten gemmes til senere. Især i starten er det dog vigtigt at arbejde ud fra en overordnet idé om hele systemet, så det overordnede design gør det muligt at implementere de senere use cases. En medvirkende faktor til at muliggøre videre udbygning af systemet er dog også et sundt objektorienteret design, hvilke vi kommer tilbage til senere i opgaven. Prioritering af use cases Men hvilke use cases skal man så vælge at implementere først? Larman opstiller tre parametre, som kan bruges til at prioritere, i hvilken rækkefølge use casene skal implementeres (Larman, s. 111 og 576): Hvor høj risiko er der forbundet med implementeringen? Det kan være både høj teknisk kompleksitet, usikkerhed omkring krav, usikkerhed omkring brugervenlighed. Det er meget forskelligt fra projekt til projekt, hvad der er mest risikofyldt Dækning: Hvis use casen indbefatter en stor del af systemet, skal den prioriteres højt, da det er afgørende at få den overordnede arkitektur på plads. Hvor afgørende er use casen for hele systemet? Hvad er systemets kernekompetence? Det gælder om at få implementeret de mest risikofyldte og afgørende use cases først, og samtidig er det vigtigt at starte med den overordnede arkitektur. Det er netop styrken ved iterativ udvikling, at 8 Man kan så diskutere, om det overhovedet er relevant at have dem med, men Larman påpeger, at man godt kan medtage såkaldte subfunction Use Cases, så længe use casene ikke bliver for uoverskuelige (Larman, s. 62). 9 Der kan dog også findes andre krav, som ikke er indskrevet i use cases, men som alligevel skal implementeres, det kunne f.eks. være en funktion, som skal logge alle aktiviteter i systemet. Disse opstilles i Supplementary Specifications. Side 8 af 18

9 man kan gribe fat i disse dele af systemet først, da de kan have stor indflydelse på resten af udviklingsarbejdet. Ud fra ovenstående parametre har vi foretaget en foreløbig prioritering af use casene: 10 Aktør Mål Prioritet Kommentar Løber Den aktør som planlægger træningen Se og tilpas træningsprogram Se og tilpas dagbog Opret og ret profil 3 Identificér bruger 4 Se statistik 6 Tilrettelæg træningsprogram Evaluer træningsprogram Vitalt for programmets funktion og brugervenlighed. Dækker det meste af systemet. Forholdsvis simpel at implementere. Dækker kun lille del af systemet. Forholdsvis simpel at implementere. Lille indvirkning på resten af systemet. Teknisk kompleksitet rimelig høj. Ikke kritisk for funktionaliteten. Dækker kun dagbogen. Teknisk kompleksitet er høj. Stor usikkerhed omkring krav. Afgørende for funktionaliteten. Dækker kun træningsprogrammet. Ekstra-feature, som måske kan genbruge noget fra Tilrettelæg træningsprogram. I kolonnen med kommentarer er der argumenteret for prioriteringen ud fra de tre parametre. Det meste af use casene med prioritet 1 er implementeret i den første iteration, så det blev muligt at se træningsprogrammet samt læse og skrive i dagbogen. I anden iteration blev det også muligt at tilpasse træningsprogrammet. I tredje iteration vil opgaven være at få implementeret use casen med prioritet 2, især fordi der er stor usikkerhed om, hvordan det skal lade sig gøre at få tilrettelagt et træningsprogram, og fordi den er afgørende for systemets funktionalitet. Fra starten var det den overordnede idé, at systemet selv skulle kunne tilrettelægge et træningsprogram ud fra brugerens personlige oplysninger. På baggrund af de data, som vi havde indsamlet ved hjælp af principperne bag Contextual Inquiry, måtte vi dog ændre denne idé. Det viste sig nemlig, at det ikke kunne lade sig gøre at formalisere trænerens overvejelser bag 10 Det skal pointeres, at på trods af at man prioriterer alle use cases fra starten, så betyder det ikke at man har fastlagt indholdet af alle iterationer. Det vurderes efter hver iteration, hvad der skal implementeres, og der kan i den forbindelse godt ske omprioriteringer af use casene. Side 9 af 18

10 tilrettelægningen af et træningsprogram. Der var simpelthen alt for mange faktorer, der spillede ind: alder, køn, vægt, kondition, kropsbygning, erfaring med løb og desuden spørgsmål om, hvor mange gange om ugen man skal træne, hvor lang tid der er til man skal løbe maraton og hvor ambitiøs man er omkring den forventede løbstid. Alt i alt en masse faktorer som påvirker hinanden gensidigt, og som ikke umiddelbart kan opstilles på en formel. Hvis man skulle lave et system med så mange parametre, ville det kræve at man gennemførte en række målinger og forsøg, hvilket vi mente var udenfor projektets ramme. 11 Derfor besluttede vi os for at ændre konceptet, så systemet i stedet kommer til at fungere som bindeled mellem en løber og en træner, hvor træneren så lægger et program, som bliver lagt ind i vores system, som løberen så kan bruge. Det vil samtidig give mulighed for, at løberen kan sende sine data tilbage til træneren til nærmere evaluering. Dette system kunne eksempelvis bruges i en klub eller som en web-service, hvor folk mod betaling kunne få tilrettelagt deres træningsprogram ud fra personlig indtastede data. Disse overvejelser er dog ikke endelige, det er først i næste iteration, at vi for alvor vil arbejde med tilrettelæggelsen af programmet, men vi mener at vi har lavet et design, som gør det let at videreudvikle systemet med Tilrettelæg træningsprogram. Bliver use case lavet for tidligt? Arbejdet med at skrive use cases er noget af det første, som man tager fat på allerede i Inceptionfasen, og det betyder at man allerede på det tidspunkt skal have et nogenlunde overblik over systemets anvendelsesområde. Det er ikke noget problem ved velafgrænsede systemer, hvor der er en organisation, som ved hvad der skal bruges. Men som beskrevet i afsnittet om Contextual Inquiry er et system som dette forholdsvist nyt og henvender sig til et marked i stedet for til en bestemt kunde, hvilket gør det svært at sige fra starten, hvilket behov systemet skal dække. Det skulle vi først selv definere. Denne ulempe ved at lave use cases meget tidligt i projektet skal dog opvejes mod de fordele, det giver. For eksempel er det en kæmpe fordel, hvis ikke en nødvendighed, at have fastlagt krav til systemet, inden man går i gang med selve udviklingsarbejdet. Det vil højst sandsynligt også være påkrævet, hvis der skal aftales en pris på et system. Ydermere betyder den iterative udviklingsproces, at skaderne ved at have defineret systemkrav for tidligt i processen, før man vidste hvad det egentlige behov var, bliver minimerede, idet man kun har spildt forholdsvis kort tid på at arbejde ud fra et forkert grundlag. Systemsekvensdiagram og operationskontrakter Ud fra use casene kan man klarlægge input og output fra systemet ved hjælp af systemsekvensdiagrammer (System Sequence Diagrams), som opstilles for hvert scenario i use 11 Spørgsmålet er, om det overhovedet er muligt at opstille denne slags mentale beslutningsprocesser som algoritmer i et computerprogram? Dette spørgsmål er analogt til noget af kritikken af AI fra bl.a. Dreyfuss ifølge Wackerhausen (1989). Side 10 af 18

11 casen. 12 Disse gør det tydeligt, hvilke interaktioner, der er mellem aktøren og systemet. Nedenstående eksempel er fra use casen Se og tilpas træningsprogram (se flere systemsekvensdiagrammer i bilag 4): Bruger System setræningsprogram(dato) visbeskrivelse flyttræning(datofra/datotil) Respons (+/- godkendt) Systemsekvensdiagrammerne kan suppleres med operationskontrakter (Operation Contracts), som specificerer, hvilken virkning input fra aktøren har. Det forklarer kort sagt tilstandsændringer i domænemodellen 13 i forbindelse med input fra aktøren. Disse tilstandsændringer beskrives i postconditions, som er det vigtigste element i operationskontrakter. Her er et eksempel på en operationskontrakt (flere findes i bilag 5): Operation: Cross references: Preconditions: Postconditions: setræningsprogram(dato) Use Case: se og tilpas træningsprogram Man er logget ind. Træningsprogrammet er blevet associeret med en bestemt dato i Kalenderen. (Brugergrænsefladen bliver opdateret). Læg mærke til, at der ikke er nogen operationer mellem pre- og postconditions. Der er ikke beskrevet, hvordan man kommer fra den ene tilstand til den anden, så systemet er stadig en black box: der er kun beskrevet, hvad der kommer ind og ud. 12 Det er ikke nødvendigt at lave system sekvensdiagrammer for så simple use cases som vores, men vi har brugt det som en øvelse. 13 Domænemodellen præsenteres først i næste afsnit, så det er nok ikke muligt helt at forstå operationskontrakterne uden at have læst dette. Operationskontrakterne ligger dog i forlængelse af system sekvensdiagrammer og use cases, så derfor bliver de allerede beskrevet her, selvom domænemodellen endnu ikke er behandlet. Side 11 af 18

12 Kravene fastlagt Med operationskontrakterne er kravene til systemet specificeret ud i mindste detalje, og de ydre påvirkninger af systemet er fastlagt for den use case, der implementeres. Dermed er anvendelsesområdet behandlet, så man i designfasen har en eksakt viden om, hvilke krav, systemet skal imødekomme i den igangværende iteration. Domænemodel Domænemodellen er på samme måde som use cases en afspejling af den virkelige verden efter systemet er blevet lavet. Det er i processen omkring udarbejdelsen af denne model der lægges struktur over problemområdet, og den færdige model består af et diagram over de relevante konceptuelle klasser identificeret heri. I use casene og system sekvens diagrammerne beskæftigede vi os med anvendelsesområdet, og fik fastlagt hvad systemet skal kunne. Det er nu tid til at se på hvordan den virkelige verden ser ud, og hvordan den skal struktureres så der bliver en høj overensstemmelse mellem det faktiske problemområde og systemet model af det (Mathiasen et.al. s. 7). Argumentationen for at starte med at se på anvendelsesområdet frem for problemområdet er, at arbejdet omkring anvendelsesområdet giver os viden om hvilke del af problemområdet, der er relevant at arbejde med, idet man vælger at implementere en bestemt use case. Der er altså sket en kompleksitetsreducering af problemområdet. Første skridt i udarbejdelsen af domænemodellen er at identificere de konceptuelle klasser, hertil præsenterer Larman to teknikker (Larman s. 133). Den første er at lave en liste over kategorier som klasserne kan ligge indenfor, og ud fra denne finde frem til dem. Den anden er at finde navneord i det materiale man hidtil har lavet. Vi valgte at søge efter navneord i vores use cases og i de interviews vi havde lavet efter Contextual Inquiry principperne, og fik på den måde en liste (se bilag 6). Ud fra denne liste snakkede vi, på baggrund af vores use cases, os frem til hvilke klasser der var relevante i forhold til brugen af et træningsprogram. Det var ikke alle klasserne der endte med at blive som vi først forestillede os. For eksempel forestillede vi os i første omgang at vi kunne have en klasse der hed Den specifikke løbetur, men måtte indse at der var to forskellige muligheder for en løbetur i vores problemområde. Nemlig en Planlagt løbetur som er indeholdt i træningsprogrammet, og en Løbet løbetur som er den løberen rent faktisk har løbet. Efter identificeringen endte vi med i alt otte klasser. (Se bilag 7.) Hvordan disse klasser skulle associeres 14 forekom ganske logisk, og det var ikke nødvendigt at lave Common Association List 15 som Larman nævner som en mulighed. Strukturen omkring klasserne forklares nedenfor. For at give et mere nuanceret billede af strukturen benyttes begreber fra OOA&D: Ordet association bruges i OOA&D (Mathiasen et. al. s. 67) som navn for en speciel form for struktur, i modsætning til Larman (s. 153), hvor association er den eneste betegnelse for struktur. 15 En liste hvor man finder eksempler på associationer inden for forskellige kategorier. (Larman s ) Side 12 af 18

13 Generalisering: Ved en generel klasse forstås en overordnet klasse som er specialiseret af en række subklasser. Dette findes omkring Planlagt løbetur og Løbet løbetur der begge bliver generaliseret af Træningstype. En klynge er en samling af klasser, som er indbyrdes forbundne (OOA&D s. 72) og begrebsligt ligger tæt på hinanden. Dette er der dog ikke nogle eksempler på i vores diagram. Associering er sammenhæng mellem objekter der ikke har nogen definerende egenskab ved hinanden. Dette ses omkring Kalender der ikke på nogen måde definerer træningen, men blot er et hjælpemiddel til at se hvornår hvad skal løbes. Aggregering betyder at et objekt udgøres af objekter fra andre klasser. Et eksempel på dette har vi omkring Træningsprogrammet der består af Forklaring og Planlagt løbetur (Mathiasen et.al. s ). Det anbefales af Larman at man medtager attributter for at huske dem, men kun medtager de mest simple, da de større ofte kan defineres som en klasse for sig (Larman s ). Der er ikke mange attributter i vores model, dog har Kalender attributten dato, og Træningstype attributterne tid og puls. I udvikling af større systemer er det almindeligt at videreudvikle domænemodellen under de første iterationer for at beholde den fælles forståelse af problemområdet. Dette har vi ikke gjort da vi over iterationerne har opnået den fælles forståelse gennem vores daglige samarbejde. Dog er domænemodellen blevet tilpasset i løbet af første iteration sideløbende med at vi har fået en større forståelse for problemområdet. Design De foregående afsnit har været rettet mod analyse af problem- og anvendelsesområdet. Vi har beskæftiget os med at modellere og undersøge systemet og dets omgivelser udefra. Dette har resulteret i udarbejdelsen af domænemodel og use case model. I designfasen betragtes systemet indefra, og det betyder, at de mange fastlagte krav skal sættes i relation til systemet, så det senere hen kan blive implementeret. Denne fase i systemudvikling kan være svær at strukturere, da det er en cocktail af mange overvejelser om, hvordan system skal se ud, og hvordan komponenterne skal spille sammen. Nogle af de værktøjer, som vi bruger til at bevæge os fra analyse til design er: prototyper, mønstre, use case model, domænemodel og interaktionsdiagrammer. Prototyper Som start på designdelen gik vi i gang med at lave prototyper på systemets brugergrænseflade. Ved hjælp af teknikkerne beskrevet i Contextual Design fik vi udviklet en papirprototype (se bilag 8), som vi testede og rettede til. Som inspiration brugte vi kalenderen fra Microsoft Outlook, da det er en kalender, som de fleste genkender og derfor vil have let ved at bruge. Desuden kiggede vi på en 16 Ifølge Larman består domænemodellen kun af konceptuelle klasser, mens OOA&D skelner mellem klasser og objekter. Side 13 af 18

14 elektronisk træningsdagbog på Ved at bruge principper fra andre programmer skulle vores system gerne blive mere brugervenligt. Der var tre hovedgrunde til at lave prototyper: 1. Vi fik en konkret model, som vi kunne bruge, da vi skulle i gang med implementeringen. Vi udbyggede senere prototypen med nøjagtige mål i pixels, hvilket var en stor hjælp, da vi ikke har brugt kodegenererende udviklingsværktøjer og derfor har indtastet alle placeringer og størrelser på skærmen manuelt. Grunden til, at vi selv har kodet det grafiske er, at der var mange elementer på skærmen, som kunne placeres ved hjælp af løkker, hvilket mindskede størrelsen på klasserne. 2. Internt i gruppen fik vi diskuteret og afklaret funktionaliteten igen. Det førte blandt andet til, at vi bestemte os for, at både dagbog og program skulle vises på den samme dag, uanset om det var tilbage eller frem i tiden. 3. Ved at teste prototypen fik vi involveret brugerne i designet, og på den måde bliver det endelige resultat forhåbentlig bedre. Som udvikler er det meget svært at sætte sig i brugerens sted, og derfor er prototyper et fremragende værktøj til at få lavet et design, der passer til brugeren. Selvom papirprototyper har den indlysende fordel, at de er hurtige at lave, og at de giver brugeren bedre mulighed for at være med-designer, så er den dog ikke så realistisk som et rigtigt program, og derfor lægger både Larman og Contextual Design da også op til, at man iterativt skal videreudvikle rigtige prototyper, så man også for hver iteration tester systemet. Det er netop en af pointerne ved en iterativ udviklingsproces, at man på den måde kan opfange fejl og uhensigtsmæssigheder tidligt i forløbet. Allerede i første iteration havde løberne mulighed for at se grundtrækkene i vores system, og derfor fik vi respons på, hvad der skulle laves om, inden vi fortsatte i næste iteration. På den måde kom vi ikke til at bygge videre på noget, som grundlæggende var forkert. Modellering af arkitektur og komponenter Til at illustrere den proces, som har fundet sted i designfasen, tages udgangspunkt i vores operationskontrakter og systemsekvensdiagrammet, der definerer de krav, der er som udgangspunkt. Vi har fundet det hensigtsmæssigt at beskrive dette forløb ved hjælp af et eksempel, da vi mener at det giver et indblik i, hvordan vi er nået frem til vores klassediagram, og hvilke overvejelser der ligger til grund for designbeslutningerne. Vores illustration bygger på UML s interaktionsdiagram, der afspejler den kommunikation og ansvarsfordeling, der er mellem objekterne. Interaktionsdiagrammet er første skridt hen imod at lave et klassediagram, som er det diagram, hvor alle systemets klasser indgår og sættes i relation. Fra operationskontrakt til interaktionsdiagram Kontrakteksemplet setræningsprogram indledes som beskrevet i use casen med, at brugeren vælger en dato. Ud fra vores prototyper vil handlingen starte i kalenderen, og derfor er det nærliggende at oprette et kalenderobjekt. Dette objekt beskæftiger sig udelukkede med den grafiske Side 14 af 18

15 brugergrænseflade for kalenderen. Det, der ligger til grund for dette valg, er mønsteret høj samhørighed, som vi vil komme tilbage til i næste afsnit. Ud fra use casen er det næste skridt, at resten af brugergrænsefladen skal opdateres, det vil sige, at oplysninger fra de indtastede data i dagbogen og beskrivelserne i træningsprogrammet skal vises på skærmen. Til at vise disse data opretter vi et objekt af typen EnkeltDag, som ligesom kalenderobjektet kun varetager oprettelse og opdatering af brugergrænsefladen, hvilket er valgt ud fra mønstre ligesom ved kalenderobjektet. De data, som vises af EnkeltDag, hentes fra objekterne dagbog og program, som afspejler både prototyper og domænemodel. Grunden til at vi har valgt at oprette to objekter stedet for at placere data fra både træningsprogram og dagbog i et objekt er, at de skal afspejle problemområdet, hvor dagbog og træningsprogram begrebsmæssigt er to forskellige ting. Desuden ville klassen blive meget stor og uoverskuelig. Idet vi har flere forskellige objekter, som skal opdateres, giver det mening at oprette et directorobjekt ud fra dirigentmønsteret, som beskrives senere. Dette objekt varetager kommunikationen mellem de forskellige objekter i grænsefladelaget og sørger i dette eksempel for at sende datoen rundt til alle relevante objekter (se pilene i interaktionsdiagrammet). De overvejelser, som er blevet præsenteret i eksemplet med denne operationskontrakt kan overføres til de andre kontrakter og use cases, og dermed afspejler det den designproces, hvor vi har modelleret interaktionsdiagrammer og til sidst endt op med et færdigt design. I det følgende vil vi behandle principperne omkring lag og mønstre nærmere. Mønstre Dette afsnit omhandler, hvordan man tildeler ansvar til objekter. Det gøres med udgangspunkt i fem mønstre, som bygger på generelle erfaringer fra succesfulde objektorienterede designs, hvor de samme strukturer gentagne gange har vist sig som gode løsninger på bestemte problemer. I det Side 15 af 18

16 følgende vil vi præsentere fem af de mest benyttede mønstre, som Larman præsenterer som GRASP patterns (General Responsibility Assignment Software Patterns). At kaldet fra Kalender går igennem Director understøttes af dirigentmønstret (Controller), som går ud på at have en objekt, der modtager anmodninger og dirigerer dem ud til de passende objekter. Vores Director modtager anmodninger fra grænsefladelaget i dette tilfælde Kalender- og delegerer opgaver ud til andre objekter. Director udfører således ikke noget arbejde selv, men delegerer det ud til andre, hvilket medfører, at man i princippet kan udskifte en af klasserne fra grænsefladelaget, uden at det behøver at betyde ændringer i de andre. Ved at bruge Director som dirigent opnår man lav kobling og høj samhørighed. At lave en lavt koblet klassestruktur betyder, at de forskellige objekter er så lidt afhængige af hinanden som muligt, og med Director opnår man, at objekterne sender deres argumenter hertil, og derfor bliver de ikke koblet og afhængige indbyrdes på kryds og tværs. Objekterne er på den måde kun afhængige af, at kunne få argumenterne fra Director. Høj samhørighed betyder, at de enkelte klasser rent funktionelt tager sig af de samme typer opgaver, og at der i hver enkelt klasse ikke blandes forskellige lag, hvilket beskrives nedenfor. At lave et system med lav kobling og høj samhørighed skaber en større fleksibilitet og gør det lettere senere hen at videreudvikle systemet. Et eksempel herpå er fra 2. iteration, hvor vi implementerede Fodspor, som er endnu en grafisk klasse, som henter oplysninger fra program og som liegsom EnkeltDag også får besked fra Director, når der bliver valgt en dato. Det var simpelt at implementere denne klasse, da den eneste tilpasning af andre klasser var i Director, hvor der blot skulle tilføjes et par linier kode for at oprette og kalde til et fodspor-objekt. Et fjerde mønster er informationsekspert, som vi har brugt i overvejelserne omkring hvilket objekt der skulle være ansvarlig for at søge efter datoer, når man klikker ind på en ny dag og skal have data ud fra programmet og dagbogen. Valget står mellem enten EnkeltDag eller Dagbog/Program. Ud fra informationsekspert mønstret skal dette ansvar tildeles Program og Dagbog, da disse objekter har den information, som man leder efter. Et andet eksempel er omkring hvilket objekt, der skal have ansvaret for at flytte rundt på træningsdagene. Enten er det Fodspor, som opfanger brugerens handling, eller også er det Program, som indeholder selve træningsdagene, der skal have ansvaret. Ifølge informationsekspert er det Program, idet denne klasse indeholder den relevante information, nemlig information om hvilken træning der er planlagt (se opdaterflytning i Program-klassen). Det sidste af de fem GRASP mønstre er skabermønstret. Dette mønster bruges flere steder i opgaven, for eksempel i spørgsmålet om, hvem der skal være ansvarlig for at oprette Program. Når Program bliver oprettet, skal det bruge de informationer, som er indeholdt i Profil. Disse informationer bliver givet videre til Director, som vi har valgt skal være ansvarlig for oprettelsen. Grunden til, at det ikke bliver oprettet i Profil (som det jo skulle, hvis vi havde taget udgangspunkt i informationsekspert), er at Program også skal være synligt for EnkeltDag og Fodspor. Det er også grunden til, at det ikke kan oprettes i EnkeltDag, da både Fodspor og Figur også skal kunne se Side 16 af 18

17 Programmet. Man kunne argumentere for, at man så bare kunne forbinde Fodspor og Figur med EnkeltDag, men det ville medføre høj kobling til EnkeltDag. Lag Når vi taler om de forskellige lag, henviser vi til modellaget, kontrollaget og grænsefladelaget. Modellaget er det nederste lag, som også kaldes domænelaget, og det er i dette lag den grundlæggende struktur lægges, og dette lag er en afbildning af problemområdet. I OOA&D defineres et funktionslag, som er det lag, hvor opdateringsfunktionerne, som ændrer tilstanden i domænelaget, ligger. Vi har i stedet kaldt det kontrollaget og givet det en anden betydning, nemlig som det lag, hvor kontrolfunktionerne ligger. Det sidste lag er grænsefladelaget, som giver systemet dets udseende i form af GUI (Graphical User Interface) eller forbinder systemet til andre systemer (Mathiasen et. al. s. 10). Et eksempel på en klasse i grænsefladelaget er EnkeltDag, der indeholder en masse grafisk samt en metode til at opdatere grænsefladen med den aktuelle dato og metode, som kaldes fra Director, når der trykkes på bestemte knapper. Denne klasse er lavet ud fra overvejelser omkring vores prototyper, hvor vi havde besluttet os for, at dagbog og program skulle vises på én dag, uanset om det var tilbage eller frem i tiden. Efter denne beslutning var truffet, var det logisk at de skulle have samme GUI, og derfor kunne vi have deres GUI i en fælles klasse, som blev til EnkeltDag. I vores klassediagram (bilag 10) er indtegnet i alt tretten klasser. Heraf tilhører Fodspor, Kalender, Vindue, Figur, Teori og EnkeltDag grænsefladelaget. Kontrollaget består af Go og Director, mens domænelaget er Dagbog, Program, Redigeringsregler og Loebstyperne. Overordnet kan det siges, at det vigtige mønster høj samhørighed hænger godt sammen med opdelingen i forskellige lag, da lagopdelingen jo netop betyder, at man får de forskellige ansvar fordelt på klasserne. Afslutning Status ved afslutningen af anden iteration af elaboration er, at to af de vigtigste use cases er implementeret og har passeret en brugertest uden de store ændringer. 17 Designet af arkitekturen er på plads, og der skulle være gode muligheder for at videreudvikle systemet med mulighed for også at tilrettelægge træningsprogrammet. Ved at adskille klasserne i lag, opretholde høj samhørighed i de enkelte klasser og i det hele taget at gøre stor brug af mønstre, er det forholdsvist ukompliceret at tilføje nye dele til systemet. Som skrevet i indledningen var det vigtigste formål at få anvendt metoderne fra undervisningen og få erfaring med systemudvikling, og det mener vi også er lykkedes i høj grad. Bortset fra dele af Contextual Design har vi benyttet alle metoder og værktøjer, hvilket har været særdeles lærerigt, 17 Test er en meget vigtig del af systemudvikling, men idet dette projekt har haft til formål at anvende teorien fra pensum, har vi ikke brugt så meget tid på det. Side 17 af 18

18 selvom nogle har været mere betydningsfulde end andre. Vi har igennem hele processen arbejdet som et samlet udviklingsteam, det vil sige at interviews, arbejdet med use case model, domænemodel og hele designdelen er sket i fællesskab. Også under implementeringen har vi gjort brug af udvidet pair programming, hvor vi alle tre har siddet ved skærmen og haft indflydelse på det færdige resultat. Litteraturliste Beyer, Hugh og Holtxblatt, Karen: Contextual Design, Academic Press Larman, Craig: Applying UML and Patterns, Prentice Hall PTR Mathiasen, Lars et.al.: Objektorienteret analyse og design, Marko Riley, David D.: The Object of Java, Addison Wesley Wackerhausen, Steen: Mennesket i computerens billede, Philosophia 18, Side 18 af 18

19 Indholdsfortegnelse Oversigt over artefakter... 1 Indledning... 2 Teori og metode... 2 Unified Process... 2 Begrebsdefinitioner... 3 Opgavens opbygning... 3 Krav og analyse... 3 Contextual Inquiry... 4 Kontekst... 4 Fokus... 5 Partnerskab... 5 Fortolkning... 5 Refleksion over Contextual Inquiry... 6 Use Case Model... 7 Use Cases... 7 Use cases som struktur for iterationerne... 8 Prioritering af use cases... 8 Bliver use case lavet for tidligt? Systemsekvensdiagram og operationskontrakter Kravene fastlagt Domænemodel Design Prototyper Modellering af arkitektur og komponenter Fra operationskontrakt til interaktionsdiagram Mønstre Lag Afslutning Litteraturliste Side 19 af 18