Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
23. april - <strong>2012</strong> Robert Nogal<br />
24. maj - <strong>2012</strong> <strong>Carletti</strong> Projekt <strong>2012</strong> Emil Thygesen<br />
Mads Pedersen<br />
samme multiplicitet, som den sidst beskrevet komposition mellem Opskrift og Portion. Det inkluderer de<br />
samme krav for en gyldig implementation, i form af en ændring på konstruktorens access-modifyer, samt<br />
metode til oprettelse af objekter af typen Proces. Valget af collections i denne klasse er igen af typen<br />
ArrayList af den simple grund, at det skulle være muligt at få fat på den sidst tilføjede proces i listen over<br />
processer oprettet af den pågældende portion. Dette betød at Set ikke ville kunne benyttes da dette<br />
interface ikke indeholder implementering, som giver mulighed for at udtage specifikke elementer i henhold<br />
til et givent indeks.<br />
For at afslutte gennemgangen af valg af Collections skal der ses på associationen mellem Opskrift- og<br />
BehandlingsIndeks-klassen. Denne association vil resultere i, at der skal være en form for Collection i<br />
Opskrift-klassen over de BehandlingsIndeks-objekter som udgør den rækkefølge af behandlinger en portion<br />
skal igennem. Denne Collection kunne godt have været, uden problemer, af typen Set. Dog kom udviklerne<br />
ud for at dette var sværere at teste på under udviklingen af model-pakken. Et andet argument for at det<br />
kunne have været af typen Set var at lige præcis Opskrift-klassen indeholder en metode til at tilføje<br />
BehandlingsIndekser til listen. Dette kunne medføre at et objekt af denne klasse kunne blive tilføjet to<br />
gange, hvilket ikke vil give mening, da der så vil være to behandlingsindekser med den samme værdi for<br />
deres indeks attribut.<br />
Polymorfi<br />
I denne implementering er der næsten ikke benyttet polymorfi. Og her understreges ”næsten”. I denne<br />
implementering har man, som man kan se af design klasse diagrammet, valgt at have en superklasse –<br />
Behandling som også er en abstrakt klasse. Denne klasse har to subklasser som i teorien ville nedarve alle<br />
dens egenskaber. Men eftersom der her er valgt, at Behandling-klassen ikke har skullet have nogen<br />
egenskaber, hverken attributter eller metoder, men blot være der for at man kunne skabe en liste som både<br />
indeholdte objekter af typen Toerring samt Dragering, nedarver de to subklasser derfor ikke nogen<br />
egenskaber.<br />
JavaDoc<br />
Som en fast del af udviklingen af software systemer er det vigtigt at kommentere alle de metoder og svære<br />
logiske valg man har lavet inde i fx en metode. Dette har derfor resulteret i, at der i source-koden er blevet<br />
kommenteret for alle de metoder som ikke gav sig selv ud fra metodenavnet. Det skal derfor forstås på den<br />
måde at trivielle gettere og settere ikke er blevet kommenteret, da dette kun vil gøre source-koden<br />
linjemæssig længere.<br />
Måden der er blevet kommenteret på er ifølge en generel skabelon, som kan beskrives ud fra dette<br />
eksempel:<br />
Side 40 af 75
Change language