Indhold. Side 2 af 26

Transkript

1 Tema Design Design, Programmering og test af Adressebog Fra d. 17 april til 20 april 2012 Vejledere: Gunhild Marie Andersen Kis Boisen Hansen Gruppe B Deltagere Side 1 af 26

2 Indhold Indledning Kodestandard... 4 Kodestandard for projektet... 4 Fullydressed (DVD oprettelse)... 5 Fremgangsmåde for design... 5 Beskrivelse af UseCase... 6 Beskrivelse af Systemsekvensdiagrammer (SDD)... 8 Beskrivelse af Interaktion diagrammer... 8 Beskrivelse af designklassediagram... 9 Beskrivelse af Unit test udført på AddressBookCtr Beskrivelse af Unit test udført på DVDCtr Beskrivelse af Unit test udført på RentCtr Beskrivelse af Unit test udført på klasser i ModelLayer Konklusion Bilag Side 2 af 26

3 Indledning. Vi har fået til opgave at fremstille et DVD-udlejnings system til en privat kunde. Selve opgaven så vi som spændende og udfordrende både i forhold til udarbejdelse af kode og selve beskrivelsen. Vi vil i gruppen tage udgangspunkt i den givne problemstilling og udarbejde en rapport og kildekode dertil som opfylder de krav der i opgaven er blevet stillet. Vi vil gøre det ved brug af kendte værktøjer og fremgangsmåder, så strukturen og designet af tekst og kode holder den røde tråd og er tro imod sproget. Vi forventer at kunne vise et simpelt og funktionelt system som er fuldt operationelt indenfor de rammer som er blevet stillet os. Derved at det efter test og gennemgang vil kunne implementeres direkte i praksis. Med denne opgave forventer vi at blive presset i alle aspekter, både teoretisk og praktisk. Vi får rig mulighed for at udnytte vores evner indenfor at kode i sproget Java, da der skal oprettes flere forskellige klasser som skal kommunikere på tværs af hinanden. Dette stiller både krav til konstruktionen af softwaren men også selve designet af systemet. I domænemodellen har vi undladt at bruge koblingen mellem person og udlån (rent i rapporten). Forklaring følger. Side 3 af 26

4 Kodestandard En kodestandard har til formål at være gøre det nemmere for andre programmører at forstå et projekt, samt selvfølgelig for personen som har lavet koden. En kodestandard skal giver større forståelse, og det skal gøre programmer mere læselig og forhindrer fejl i at opstå. Det er vigtigt at programmøren sikrer en fælles struktur på koden, da hver programmør har sin egen metode og stil. En virksomhed kan specificere en bestemt stil i sin kodestandard. Et vigtigt ting for programmøren er at tilføje kommentarer, fordi gode kommentarer kan øge forståelsen af koden. Det er op til hver projektleder/gruppe at bestemme hvilket sprog man skriver i koden, men i fleste tilfælde bruger engelsk sprog så det kan læses af alle. Kodestandard for projektet I gruppen har vi aftalt at vores kodestandard skal skrives på engelsk, hvor vi forholder sig til kodestandard mht. stort og lille bogstaver i begyndelse af ordnerne. Variablerne startes med lille bogstav og gives et logisk navn, metoderne skal ligeledes være logiske. Vi skriver kommentarer til alle metoder i modellaget, bortset fra set og get-metoder. Dette gælder ikke UI- og Controller-klasserne, da en stor del af metoderne der er selvindlysende. Vi bruger konsekvent det lille forbogstav af et objekt til at repræsentere en lokal instans af et objekt. F.eks. Person p, Rent r etc. Side 4 af 26

5 Fullydressed (DVD oprettelse) Primær aktør: Ekspedient Interessenter: Ekspedienten ønsker et program, til udlån af DVD er som skal indeholde alle vigtigt oplysninger om DVD erne. Kunden er interesseret i, at få præsenteret de vigtigste informationer om udlåners regler. Ekspedienten ønsker at have en funktion, der holder systemet ajour mht. hvilke DVDer der er udlånet, og hvilke er tilbage i butikken, samtidig har styr på dato for at overholde lejeperioderne. Førtilstand: Ekspedienten Succeskriterier (postcondition): DVD information er oprettet, med de informationer som ekspedienten har indtast i forbindelse med oprettelse en ny DVD. Hovedsuccesscenariet: 1. Ekspedient i DVD butikken, får til opgave at oprette en ny DVD. 2. Ekspedienten starter en ny oprettelse. 3. Ekspedienten indtaster informationer (id, title, kunstner, udgivelsesdato). 4. Systemet registrer DVD s og returnere. 5. Ekspedienten taster kunden navn, adresse, tlf.nr. 6. Systemet valideret oplysninger. 7. Ekspedienten afslutter ordren. 8. Ekspedienten beder om ordreseddel og faktura. 9. Systemet udskriver en bekræftelse. Fremgangsmåde for design Der tages udgangspunkt i kravene dvs. domænemodel, SSD og kontakter Først findes de relevante designklasser, som indgår i designet af use casen med udgangspunkt i 3 lags arkitekturen og domænemodellen UIklasser en per use case KontrolKlasser en per use case Side 5 af 26

6 Modelklasser relevante fra domæneklasser samt evt. tilføjelse af containerklasser (indeholder ArrayList) Dernæst designes interaktionen mellem de involverede objekter Endelig udarbejdes et designklassediagram Beskrivelse af UseCase Use-Case fortæller en dialog eller en historie mellem en aktør bruger et system, og illustrerer de funktionelle krav gennem den historie, med andre ord er en beskrivelse af hvad brugeren skal have IT systemet til at udføre. I dette projekt er et Use-case for hele systemet, som fortæller historie mellem ekspedienten i, en DVD forretning, som har flere opgaver skal udfør gennem et nyt IT system. Use Case illustrer historie mellem ekspedienten når han skal opret en ny DVD, opret kopi af DVD, og mens kunden skal udlej, og aflevere DVD. Use-Case scenario Opret ny DVD: En ekspedient åbner IT system, og klikker på opret en ny DVD, derefter skal han udfylde alle oplysninger som tilhører DVD erne, kort sagt id, kunstner, titel, udlånsdato, samtidig skal han udfylde data, om hvor mange kopier har han i butikken ved, at oplyse serienummer, prisen for DVD, og dato. Use-Case scenario vælger DVD: En ekspedient åbner systemet, klikker på vælger en DVD, tilføjer alle oplysninger som tilhører DVD dvs. (id, titel, kunstner, osv.) find DVD. Use-Case scenario Delete DVD: En ekspedient åbner systemet klikker på delete DVD, vælger den bestemte DVD der skal slettes og sletter den, systemet printer en bekræftelse om aflevering af DVD. Side 6 af 26

7 Use-Case scenario Rented DVD: En kunde vil låne en DVD, ekspedienten finder den frem til systemet, vælger låne DVD udfylder alle oplysninger om DVD dvs. (id, titel, kunstner osv.) finder personen på systemet ved at taste alle oplysninger om personen dvs. (id, adress, navn, osv.) og afslutter med at printe en bekræftelse om udlån med tilhørende dato for aflevering. Use-Case scenario Deliver DVD: En kunde har på et tidspunkt lånt en DVD, og kommer på den aftalte dato for aflevering, ekspedienten finder frem til systemet, klikker på afleverer DVD, finder kundens oplysninger frem i systemet og DVDens oplysninger, og afslutter med at printe en bekræftelse om at DVD er afleveret samt afleverings dato. Use-Case scenario opret Kopi DVD: En ekspedient skal oprette en kopi om en bestemt udgave af en DVD, ekspedienten klikker på opret kopi, udfylder DVD oplysninger, og afslutter operationen ved at gemme. Use-Case scenario find kopi af DVD: En ekspedient klikker på find kopi, taster alle DVD oplysninger i skema, og afslutter med at gå videre til den næste trin med opdaterer kopien. Use-Case scenario Delete kopi af DVD: En ekspedient er i gang med at oprette en kopi af DVD, og efter ekspedienten finder kopierne, så skal han opdaterer oplysningerne derfor klikker ekspedienten på opdater kopi, og afslutter med at vælge gem oplysninger. Use-Case scenario Delete kopi af DVD: En ekspedient finder frem til systemet, klik på delete kopi, vælge den bestemt kopi af DVD skal han delete, udfylder alle oplysninger om DVD erne bekræftelse operation delete og lukke systemet. Se bilag 1. Side 7 af 26

8 Beskrivelse af Systemsekvensdiagrammer (SSD) Systemsekvensdiagrammer SSD er et vigtigt dele af kraverne fordi samt med domænemodel, er udgangspunkt af design. Systemsekvensdiagrammer SSD, er en illustration af input og output hændelser til systemet, som detaljering af et gennemløb af en Use-Case. I projektet har vi et SSD for hele systemet, som beskriver de systemoperationer der skal udføres i, og de data, der behandles, samtidig har det givet besked er aktuelle parameter som indgår i operationskontrakt. Se bilag 2. Beskrivelse af Interaktion diagrammer Interaktion diagram er en kommunikation diagram for et bestemt operation, som identificeres sammenhængen mellem de valgte designklasser ud fra krav om synlighed, hvor attributter overføres fra domænemodel, herefter tilføjes metoderne på klasserne. I projektet har vi tre interaktion diagrammer, et diagram for hver Iteration. Interaktion diagram for opret Person. Diagrammet for opret person henter input fra klassen AdressMenuUI, som giver adgang for ekspedienten til opret en person med tilhørende (id, name, zipcode, city, phone), derefter oplysninger bliver gemt i klassen AdressBook Ctr og kan bruges igen i forbindelse med opret en ny klasse person, så bruger ekspedienten metode vælge person som bliver alle oplysninger som output og gemmes i klassen AdressBook. Interaktion diagram for opret DVD. I den diagram har vi fire metoder, input kommer fra klassen DVDUI, ekspedienten starter metode opret DVD, som skal udfylde alle de oplysninger man har bruge for dvs. DVD (id, title, director, Side 8 af 26

9 releasedate ), oplysninger bliver gemt i DVDCtr, den næste metode er vælge DVD fra klassen DVD collection. Interaktion diagram for opret Eks. I den diagram har vi tre metoder, som stadigvæk ekspedienten skal brug input fra DVDUI klassen, men mening her at han skal opret en ny kopi med de interessenter oplysninger, hvor det bliver gemt i DVDCtr, den sidste metode han skal vælge kopi af DVD. Interaktion diagram for udlån DVD. Ekspedienten er i gang med en metode til udlån DVD, igen input kommer fra klassen Rented DVDUI, hvor kan ekspedienten vælge, og hent DVD fra klassen RentCtr derefter skal han også vælge person, og systemet gøre det ved at hent oplysninger om personen fra klassen adressbook, ekspedienten skal vælge nu metode for opret udlån og her er vigtigt at udfylde de tilhørende oplysninger for metoderne og det er nemlig personen ID, DVD ID, udlånes dato, status og her menes at hvis denne r i huset eller den er udlånet, når han er færdig med udlån systemet sender ham automatisk til ny så den er klar til næste operation. Interaktion diagram for returen DVD Ekspedienten vælger og bruge input fra klassen RentedDVDUI, så skal han bruge metode og hent person, han søger efter person ved at bruge personen ID, og vælge og delete DVD hvor output bliver i DVDCollection klasse. Se bilag 3 Beskrivelse af designklassediagram Klassen Person Side 9 af 26

10 Denne klasse repræsenterer en person, og består af de følgende attributter: Et unikt id af typen long Et navn af typen String En adresse af typen String Et postnummer af typen integer Et bynavn af typen String Et telefonnummer af typen integer Derudover består klassen af en konstruktør samt de obligatoriske get/set metoder for samtlige attributter. Disse elementer går igen i samtlige klasser, og derfor vil det ikke blive nævnt fremover. Klassen AddressBook Denne klasse fungerer som containerklasse for person-objekter. Det betyder altså at AddressBook aggregerer Person, hvorfor der er parameter-synlighed imellem de to klasser. Da vi altid skal være sikre på at arbejde på den samme person-liste er AddressBook sat op til at udnytte Singleton-mønstret. Det sikrer at instansen af AddressBook er statisk, og derfor kan der kun eksistere en. Klassens instansvariabler er altså: En ArrayList<Person> benævnt persons, der opbevarer de oprettede person-objekter. AddressBook instance, det er det statiske objekt at AddressBook som andre klasser arbejder med. AddressBook indeholder de følgende metoder: addperson(p : Person) denne bruges til at tilføje en person til arraylisten, og tager til parameter et objekt af typen Person. getperson(id) anvendes til at hente en specifik person ud af arraylisten, baseret på den persons unikke id. deleteperson(id) bruges til at slette en person fra arraylisten, igen baseret på personens unikke id. Side 10 af 26

11 updateperson(id, name, address, zipcode, city, phone) kan bruges til at opdatere de oplysninger der er registreret om en person. Id et bruges kun til at finde personen (vha. getperson(id)), mens de resterende opdaterer de oplysninger som er givet med som argumenter. ListAllPersons() returnerer arraylisten, og kunne derfor lige så vel være kaldt getpersons(). Kan bruges såfremt man ønsker en komplet liste over lagrede personer. De øvrige containerklasser har en tilsvarende funktion. Det kan ses af DesignKlasseDiagrammet, og vil ikke blive nævnt igen. De første fire metoder er generelt benævnt CRUD, dvs: Create, Read, Update, Delete. Alle vores container- og kontroller-klasser indeholder disse fire typer metoder, og de vil fremover kun blive nævnt hvis de afviger fra standard formlen, eller blot bruges i en anden sammenhæng end de som allerede er beskrevet. AddressCtr Denne klasse agerer som controllerklasse for AddressBook, dvs. den indeholder metoder der modsvarer de som findes i AddressBook. Derudover har den attributten addressbook, hvilket vil sige at den eneste mulige instans af AddressBook er opbevaret her. På grund af dette har klassen en attribut-synlighed til AddressBook, og da de metoder der opbevares i klassen tager parametre der svarer til klassen Person s attributter har AddressCtr en lokal synlighed til denne klasse. Iteration 2 Til iteration 2 har vi identificeret de følgende klasser og sammenhænge mellem samme. Disse klasser har ingen bindinger til de forgående. Klassen Copy Side 11 af 26

12 Denne klasse repræsenterer et enkelt eksemplar af en dvd. Den eksisterer fordi det gør det muligt for systemet at håndtere mere end et eksemplar af den samme film. Et objekt af klassen Copy har følgende attributter: Et serienummer, der agerer som eksemplarets unikke id. En integer der repræsenterer datoen hvor eksemplaret er anskaffet En integer der angiver eksemplarets købsværdi Et objekt af typen DVD, således at dvd og eksemplar er knyttet sammen. Klassen har ingen metoder udover get/set. Klassen DVD Denne klasse abstraherer konceptet dvd, og adskiller sig fra Copy-klassen ved at indeholde relevante oplysninger om den pågældende film generelt. Eksemplet kunne være at en butik ejer 3 eksemplarer af filmen Titanic. Her ville DVD-klassen indeholder de oplysninger der gælder for alle 3 eksemplarer, mens Copy ville indeholde oplysninger om hvert specifikt eksemplar. Vi har udvalgt de følgende attributter til at repræsentere en DVD: En ArrayList<Copy> som kan indeholde de eksemplarer som brugeren har til rådighed af hver film. Et unikt id af typen integer En titel af typen String Navnet på instruktøren af typen String Datoen hvor filmen er udkommet givet ved en integer Da DVD-klassen er container for Copy, indeholder den dennes CRUD metoder, der ikke væsentligt afviger fra de som er beskrevet under AddressBook Ansvaret er givet DVD klassen jf. Controllerprincippet som det er beskrevet i GRASP. Tildel klassen B ansvaret for at oprette en instans af klassen A, såfremt en af disse er sande : 1. B indeholder A 2. B aggregerer A Side 12 af 26

13 3. B har initialiseringsdata for A 4. B optager A 5. B bruger i høj grad A Her er både 1 og 2 sande. Og af samme grund er der i øvrigt parameter-synlighed mellem de to klasser. DVDCollection DVDCollection er containerklasse for DVD-klassen. Den indeholder dennes CRUD metoder, og er i øvrigt statisk af de samme årsager som AddressBook DVDCtr Kontroller-klasse for både Copy og DVD-objekter. Den har en dvdcollection som attribut, hvilket giver attribut-synlighed til DVDCollection. Via parametrene i dens CRUD metoder får den lokal synlighed til Copy og DVD-klasserne. Klassens eneste interessante metode er createcopy(serialno, accdate, accprice, d) der opretter et nyt object af typen Copy, og til brug herfor tager et objekt af typen DVD, for herefter at lagre eksemplaret i DVD klassen. Da der ingen steder står skrevet at objektet d ikke må være det samme flere gange, opnår man altså med den manøvre at kunne knytte flere eksemplarer, med forskellige serienumre, til den samme dvd. Iteration 3 & 4 Til iteration 3 udvalgte vi klassen Rent til at repræsentere et udlån, derudover har den naturligvis en containerklasse, kaldet RentCollection. Kravene til iteration 4 krævede ingen nye klasser, men udnytter de allerede eksisterende metoder, og klasser, til at opnå gældende mål. Klassen Rent Denne klasse repræsentere et udlån, den består af de følgende attributter: Et unikt id af typen integer Side 13 af 26

14 En udlånsdato af typen integer En afleveringsdato af typen integer En status, altså om hvorvidt udlånet er aktivt eller ej, af typen boolean Et person-objekt der tilknytter udlåneren til lånet Et copy-objekt der tilknytter et dvd-eksemplar til lånet En dato der markerer den reelle afleveringsdato. Klassen RentCollection. I lighed med de øvrige containerklasser er den implementeret som Singleton, har en arrayliste af typen Rent, og har dermed parameter-synlighed til Rent-klassen. Klassen RentCtr Kontrollerer Rent-objekter. Den indeholder attributten rentcollection hvilket giver attributsynlighed til RentCollection. Desuden adskiller den sig fra de øvrige controllerklasser ved at indeholde instanser af DVDCtr og AddressBookCtr. Det skyldes at visse af klassens metoder kræver oplysninger som nemmest skaffes ved at udnytte de metoder som ejes af disse to controllere. Mest interessant er metoden: createrent Den tager argumenterne id, pid, did, rentdate, duedate, status, returndate. id et bliver til rent-objektets unikke id, pid er en persons unikke id, did er en dvd s unikke id, rentdate og duedate er hhv. udlejnings og afleveringsdato, Status sættes automatisk til True når man opretter et udlån, for at signalere at lånet er aktivt. returndate får også en standardværdi ved oprettelsen, men er i øvrigt ikke relevant før udlånet afsluttes. For at omsætte pid og did til de relevante objekter udnytter vi de get-metoder der allerede eksistere. Af den grund er DVDCtr og AddressCtr tilknyttet klassen som attributter. Såfremt vi havde undladt det ville vi åbne op for synlighed fra DVDCtr og ned til de enkelte klasser. Det ville være give en langt højere kobling i systemet, hvilket ville kunne lede til mere besværlig vedligeholdelse af systemet, og i øvrigt ville underminere ideen i at bruge Side 14 af 26

15 controllere til at starte med. Hvis en anden end en klasses designerede controller har adgang til dens oplysninger, så kan man ikke længere tale om at den er kontrolleret. I så fald kunne man lige så vel holde sig til UI- og Model-lag Efter at have fundet de relevante objekter sender metoden argumenterne videre til Rentkonstruktøren i RentCollection-klassen. Udover den ovennævnte er updaterent-metoderne også specielle. De er teknisk set CRUDmetoder som i de andre klasser. Men her bruger vi dem både til at opdatere et udlån, og til at afslutte det med: updaterent(id, duedate), der finer et lån baseret på lånets unikke id, og giver mulighed for at ændre afleveringsdatoen. updaterent(id, status, returndate), hvor man kan sætte status til afsluttet, samt indtaste datoen hvor filmen er returneret. Den sidste unikke metode i klassen er: getpersonalrent(pid) der kan bruges til at finde samtlige udlån som en person har foretaget. Aktive såvel som afsluttede. Se bilag 4 Beskrivelse af Unit test udført på AddressBookCtr Vi metoden createperson(id, name, ) til, at oprette tre personer. Denne metode opretter et personobjekt og tildeler det de værdier, som bliver indtastet ved oprettelse, og tilføjer dernæst personobjektet til en Arraylist. Vi brugte metoden getperson(id) til at finde og returnere et personobjekt. Denne metode finder et personobjekt baseret på personens id, og returnerer personobjektet. Vi brugte metoden updateperson(id, name, ) til at opdatere en person. Denne metode opdaterer et personobjekts attributter ved først, at finde personobjektet via dens id, hvorefter man indtaster ændringer til dettes attributter. Her skal dog noteres at hvis man ikke Side 15 af 26

16 ønsker at ændre i de felter af typen int, skal der skrives 0, hvorimod String felterne skal udfyldes med. Vi brugte metoden deleteperson(id) til at slette en person. Denne metode fjerner en et personobjekt fra vores Arrayliste, baseret på personobjektets id. Vi brugte metoden listallpersons() til at returnerer en ArrayList over personerne vi har oprettet. Denne metode returnerer en Arraylist med alle vores tilføjede personobjekter i. Beskrivelse af Unit test udført på DVDCtr Vi brugte metoden createdvd(id, title, ) til at oprette tre dvd er. Denne metode opretter et DVDobjekt og tildeler det de værdier, som bliver indtastet ved oprettelse og tilføjer dernæst DVDobjektet til en Arraylist. Vi brugte metoden getdvd(id) til at finde en dvd. Denne metode finder et DVDobjekt, baseret på dvd ens id og returnerer DVDobjektet. Vi brugte metoden updatedvd(id, title, ) til at opdatere en dvd s oplysninger. Denne metode opdaterer et DVDobjekts attributter ved først at finde objektet, baseret på dets id, i Arraylisten og dernæst tilskrive eventuelle ændringer til objektets attributter. Vi brugte metoden deletedvd(id) til at slette en DVD. Denne metode finder et DVDobjekt baseret på id og fjerner det fra Arraylisten. Vi brugte metoden createcopy(serialno, DVD d, ) til at lave en copy af en dvd. Denne metode opretter et copyobjekt, og tildeler den de værdier, som bliver indtastet, samt et DVDobjekt. Dernæst tilføjes dette copyobjekt til det tildelte DVDobjekts Arrayliste. Denne metode har vi testet ved at indspecte den instance af DVDCtr vi har lavet og tilføjet forskellige dvd er og dernæst inspecte om det copyobjekt som vi har created er blevet associeret rigtigt med det dvdobjekt det skulle associeres til. Vi brugte metoden updatecopy(id, DVD d, ) til at opdatere oplysninger på en copy. Denne metode opdaterer en copyobjekts attributter ved at finde objektet på den serialno (ID), og dernæst tilskrive den, eventuelle ændringer indtastet. Side 16 af 26

17 Beskrivelse af Unit test udført på RentCtr Vi brugte metoden createrent(id, pid, did, ) til at oprette et Rentobjekt. Vi bruger metoden getrent(id) til at finde et Rentobjekt. Vi bruger metoden updaterent( ) til to ting, den første er hvis man skal udskyde afleveringsdatoen. Den anden er når vi skal aflevere filmen. Vi bruger metoden deleterent(id) til at slette et Rentobjekt. Alle metoderne i AddressCtr, DVDCtr og RentCtr virker som de skal. Beskrivelse af Unit test udført på klasser i ModelLayer Vi har udført Unit tests på samtlige klasser, som indgår i modellaget. Da de fleste af disses test er CRUD tests har vi ikke valgt at skrive disse med i rapporter. De er udført på samme måde som med klasserne i ControllerLayer. Alle metoder i ModelLayer virker som de skal. Side 17 af 26

18 Konklusion. Vi kan konkludere at efter vi har arbejdet med denne opgave i den sidste uge, har vi fået udarbejdet en rapport og en kildekode som i et vidst omfang opfylder alle krav til den problemstilling vi fik stillet. Vi har muliggjort udlejning af DVD er, registrering af brugere og oprettelse af nye brugere. Der er forskellige udfordringer i forhold til at registrere de udlånte dvd er som endnu ikke er overkommet. På samme måde er der heller ikke endnu implementeret en metode til at fjerne Copy-objektet fra et udlån, efter lånet er afsluttet. Det vil sige at der ikke foregår en reel flytning fra eksemplarcontaineren til udlånet, eller tilbage igen. Under normale omstændigheder ville det kategoriseres som en A-klasse bug, som skal rettes før udgivelse. Her nøjes vi med at nævne at vi er opmærksomme på problemstillingen. Vi har afveget fra den på forhånd udleverede domænemodel på et enkelt punkt. I vores system er der ingen synlighed imellem udlån- og person-klasser. Vi mente ikke at den kobling var nødvendig i forhold til løsning af opgaven, og at det kun medførte udnødvendigt højt koblingsniveau. I stedet havde vi til hensigt at bruge den controller der styrede person-objekterne. Vi anvender dette i praksis under oprettelsen af Rent-objekter. Om det er bedre eller værre end det forslåede er endnu uafklaret. Ligeledes er der visse skønhedsfejl i UI et, der kan gøre det til en udfordring at bruge systemet på en måde så det ikke smider exceptions. Sagt på en anden måde er det småt med fejlhåndteringen, og på den baggrund er systemet hverken stabilt eller intuitivt at bruge. Omvendt er dette ikke krav til løsningen af opgaven. Det er selvsagt at en færdig udgave af systemet skal kunne håndtere fejlindtastninger mv. Vi har igennem kodningen af systemet fået bedre indsigt i sproget Java, diverse metoder og ikke mindst de faldgrubber der forbundet ved design af et system. Til næste gang vil vi formentlig være Side 18 af 26

19 mere opmærksomme på værdien af at få beskrevet samtlige use cases, før implementeringen af systemet går i gang. Side 19 af 26

20 Bilag Bilag 1 Side 20 af 26

21 Bilag2 Side 21 af 26

22 Side 22 af 26

23 Bilag 3 Side 23 af 26

24 Side 24 af 26

25 Side 25 af 26

26 Bilag4 Side 26 af 26