Java kodning

Jeg har en relativ nem opgave i java, som jeg glædeligt betaler for at få lavet. jeg betaler 500 for kode og dokumentation. jeg mailer opgave teksten er som følger:


Handelshøjskolen i København                               
DØK 1. år, E04


DØK-studiets modul 1:

Programudvikling


Godkendelsesopgave G1

        1.    Indledning                            2

        2.    Problemstillingen og opgaven                2
        2.1 Regler for G- og U-opgaver                2
        2.2 Identifikation af opgaver og studerende            2
        2.3 Krav til systemets funktionalitet            2
       
        3.    Tekniske krav til løsningen                3
            3.1 VRegistrering                    3
            3.2 Brugergrænseflade                    3
            3.3 Indlæsning                        3
            3.4 Udskrift                            4
            3.5 Udvidbarhed, generalitet og klassestruktur        4
            3.5 Programmerinmgssprog m.v.                4

        4.     Centrale faglige emner                    4
                                   
        5.    Besvarelsen                        5
            5.1    Løsningsovervejelser                    5               
            5.2    Vedligeholdelsesvejledning                6
            5.3    Vægtning                        7           
            5.4    Godkendelseskriterier                    8

        6.    Praktiske oplysninger                    8

        Bilag A – data til initialisering                9





d. 29.10.2004   
Uffe Kofod

1. Indledning

Dette er godkendelsesopgaven på DØK 1. år, modul 2 "Programudvikling", efterårssemestret 2004.
Opgaven løses individuelt.

2. Problemstillingen og opgaven

Opgaven handler om et system til at understøtte registrering af aflevering og godkendelse af obligatoriske ugeopgaver (U-opgaver) og godkendelsesopgaver (G-opgaver) på DØK 1. år. I kan altså forestille jer, at systemet kan benyttes af jeres instruktorer til løbende registrering af status for hver enkelt opgave for hver enkelt studerende efterhånden som opgaverne stilles og besvarelser afleveres - og når semestret er slut til at afgøre hvilke studerende, der er berettiget til at gå til eksamen iflg. reglerne.

2.1 Regler for G- og U-opgaver

Godkendelse af G- og U-opgaver er en formel forudsætning for at være berettiget til at gå til eksamen i de enkelte fag efter flg. regler:

For G-opgaver gælder, at alle stillede opgaver i et fag skal godkendes.

For U-opgaver gælder, at 75% af alle stillede opgaver i et fag skal godkendes. (Hvis 75% ikke giver et helt antal, rundes ned til nærmeste hele antal).

Alt i alt skal i et givet fag alle G-opgaver være godkendt og 75% af alle U-opgaver være godkendt for at man er berettiget til at gå til eksamen i det pgl. fag. 

2.2 Identifikation af opgaver og studerende

En opgave identificeres entydigt ved 1) det fag, opgaven stilles i og 2) den betegnelse, opgaven har i ugeskemaet. Altså f.eks.: Erhvervsøkonomi, opgave U2.

Af opgavebetegnelsen kan ses, om der er tale om en godkendelsesopgave (G) eller en obligatorisk ugeopgave (U).

Som en forenkling lægges der ikke op til, at der skal gemmes nogen form for historik i systemet. Alle opgaver, der er registreret i systemet, er altså knyttet til det indeværende studieår.

En studerende identificeres entydigt ved sit cpr-nr.

2.3 Krav til systemets funktionalitet

Systemet skal kunne understøtte flg. funktioner:

1.    en givet opgaves aktuelle status (ikke afleveret/afleveret/godkendt/ikke godkendt) skal kunne registreres for en givet studerende

2.    der skal kunne udskrives en status for alle opgaver for en givet studerende

3.    der skal for en given opgave kunne udskrives en besvarelsesstatistik, dvs. en oversigt over hvor mange studerende der har afleveret den pågældende opgave og hvor mange der har fået den godkendt hhv. ikke godkendt

4.    der skal for et givet fag kunne udskrives en liste over de studerende, der iflg. reglerne i afsn. 2.1 er berettiget til at gå til eksamen i det pgl. fag


3. Tekniske krav til løsningen

Opgaven går ud på at udvikle en simpel prototype af systemet. Senere, når prototypen er gennemprøvet, kan det endelige system så færdigudvikles (men det er ikke en del af denne opgave!). Det giver os mulighed for nogle forenklinger.

3.1 Registrering

I praksis ville det være oplagt at registreringen foregik i en database eller i en eller flere filer på harddisken. Men i prototypen skal blot benyttes datastrukturer i RAM-lageret, f.eks.  arrays el. lign.

For at undgå at skulle indtaste alle data hver gang programmet startes, skal der laves en initialiseringsmetode, der opretter 20 studerende med hver deres opgavestatus hver gang programmet startes. Disse data skal være "hardkodet" i initialiseringsmetoden. Dataene findes i bilag A.

3.2 Brugergrænseflade

Brugergrænsefladen skal være en simpel, tekstorienteret brugergrænseflade. Det eneste krav, der stilles til den, er at den skal være menustyret. Det betyder, at brugeren skal se alle systemets valgmuligheder som en liste, f.eks. sådan:

    1.    Registrering af opgave
    2. Opgavestatus for studerende
    3.    Besvarelsesstatistik for opgave
    4. Liste over studerende, der kan gå til eksamen
   

    Indtast valg:

Hvis brugeren nu f.eks. indtaster '4' og trykker enter, bliver der udskrevet en liste over de studerende, der er berettiget til at gå til eksamen i et givet fag . Når dette er gjort, vendes der igen tilbage til ovenstående liste af valgmuligheder.

Udover dette krav, lægges der ingen vægt på brugergrænsefladens udformning. Specielt skal det nævnes, at der i Java ikke er nogen enkel måde at "rense skærmen" på, men det spiller heller ingen rolle. Lad være med at bruge tid på spidsfindigheder som dette!

3.3 Indlæsning

Til indlæsning fra tastaturet kan benyttes klassen InputReader fra TechSupport-eksemplet i kap. 5. i OFJ. Den indeholder metoden getInput(), der returnerer en linie fra tastaturet som en tekststreng (typen String). Se evt. nærmere i klassens interface (= JavaDoc-dokumentation).

3.4 Udskrift

I det endelige system vil det være naturligt, hvis der kunne udskrives direkte på en printer eller på en fil. Men i prototypen, som denne opgaven handler om, skal al udskrift simpelthen foregå på skærmen.

3.5 Udvidbarhed, generalitet og klassestruktur

I praksis ville det være oplagt, at systemet var en del af et større system, og at det blev udviklet så det var let at udvide det med flere faciliteter. Ved løsning af opgaven skal systemet blot ses som et isoleret system, der er begrænset til lige præcis den ovenfor beskrevne funktionalitet.

Det betyder for systemets klassestruktur, at der kun skal medtages de klasser, der direkte kan relateres til den beskrevne funktionalitet. Som en ”tommelfingerregel” kan man sige, at der ikke er brug for en klasse, hvis den kun indeholder et enkelt felt og tilsvarende get- og setmetoder.

Eksempel: der er ikke noget i beskrivelsen af systemets funktionalitet, der lægger op til en klasse Hold. Selvom man ønskede at kunne lave en opgavestatistik pr. hold, kunne dette opnås ved simpelthen for hver studerende at registrere hvilket hold, vedkommende gik på. Kun hvis der i kravene til funktionaliteten indgik flere informationer, der var knyttet til det enkelte hold (f.eks. instruktor, lokale osv.), ville en klasse være berettiget.

Omvendt skal løsningen stadig være objektorienteret – dvs. være baseret på de klasser, der forekommer ”naturlige” ud fra problemstillingen. Hint  i denne opgave kan løsningen baseres på 3 klasser: Opgave, Studerende og ListeAfStuderende. Det er ikke noget krav at følge dette hint.

3.6 Programmeringssprog m.v.

Systemet skal programmeres i Java. I må frit benytte klasser og metoder fra Javas standardbibliotek og klasser fra lærebogen (OFJ).

I må også gerne benytte klasser og metoder, I har set andre steder (f.eks. noter, OH’er, andre bøger o.s.v.), men den fulde kildetekst skal så vedlægges og følge reglerne for kildetekst som senere beskrevet.

Det er ikke afgørende, hvilket Java-værktøj, I vælger at benytte under programmeringen. Det eneste krav er:

Der skal med besvarelsen leveres en CD eller diskette med en kildetekst (=et antal javafiler), der kan oversættes af JDK’s compiler (javac).

Hvis I benytter BlueJ, vil det være en fordel at downloade den nyeste version 2.0.2 fra http://www.bluej.org/download/download.html. Nogle af de problemer, mange har konstateret med version 1.3.5 (eller tidligere) er her løst.

4. Centrale faglige emner

Der er to formål med en godkendelsesopgave:

1.    I får lejlighed til at arbejde sammenhængende med en lidt større problemstilling og får dermed mulighed for at lære og forstå nogle ting bedre og mere grundlæggende.

2.    I skal overfor os (skolen) med jeres løsning dokumentere, at I har forstået en række faglige emner og kan bruge dem hensigtsmæssigt.

Det er derfor vigtigt at gøre sig klart, hvilke faglige emner, der er centrale i den aktuelle opgave.

Efter ca. 2 måneder af studiet forventer vi, at forståelsen og beherskelsen af de mere elementære emner som variable, oprettelse af objekter, kald af metoder osv er på plads. De centrale emner i den aktuelle opgave er derfor flg.:

•    samspillet mellem flere klasser i en lidt større problemstilling
•    brug af datastrukturer
•    unit testing (se senere)

Ved vurderingen af besvarelsen er det altså disse emner, der især vil blive lagt vægt på.

5. Besvarelsen

Besvarelsen skal formuleres som en rapport mindst bestående af flg. 2 kapitler:

                - Løsningsovervejelser
                - Vedligeholdelsesvejledning

Herudover kan der evt. være en afslutning/konklusion, ét eller flere bilag o.s.v. Kapitler kan være opdelt i afsnit. Kapitler og afsnit skal være nummererede på sædvanlig vis (f.eks. kap. 2, afsn. 2.3).

Rapporten skal vedlægges en CD eller diskette med systemets kildetekst. Rapporten må af praktiske grunde ikke afleveres i et ringbind.

Programmets kildetekst skal desuden vedlægges som bilag.

Rapporten må maksimalt fylde 30 sider (programmets kildetekst samt øvrige bilag ikke medregnet). Der gøres opmærksom på, at bilag ikke nødvendigvis gennemlæses i sin helhed af opgaveretteren.

Rapporten incl. bilag skal være genempagineret, dvs. siderne (incl. bilag) skal være fortløbende nummereret med rapportens forside som s. 1.

Rapporten skal have en indholdsfortegnelse, der omfatter alle kapitler og afsnit. Specielt skal der i indholdsfortegnelsen være en henvisning til de enkelte dele af kildeteksten: klasser og væsentlige metoder (altså f.eks. ikke konstruktorer og set/get-metoder).

Hvis jeres besvarelse indeholder elementer, der er kopieret fra andre kilder, skal der udtrykkeligt henvises til de pågældende kilder.

I det følgende ses nærmere på hvad rapportens 2 dele indeholder.


5.1 Løsningsovervejelser

I dette afsnit skal I dokumentere de væsentlige overvejelser I har gjort jer, og de væsentlige valg I har truffet i forbindelse med udviklingen af systemet. Formålet med dette er at sætte andre i stand til at forstå systemet og dets virkemåde til bunds med henblik på en evt. senere revision af
de principper, systemet baserer sig på.

Det kan ikke siges præcist, hvornår en overvejelse eller et valg er så væsentligt, at den/det skal dokumenteres - dette må bero på en vurdering i hvert enkelt tilfælde. Erfaringen viser dog, at der er nogle typiske tilfælde, hvor en dokumentation ofte er relevant:

-    Valget af klasser og disses relationer bør begrundes.

    -    Hvis der er flere oplagte løsningsmuligheder på et problem eller et delproblem iøvrigt,
        bør løsningsmulighederne kort skitseres, og udvælgelsen af én af dem begrundes.

    -    Hvis en løsning på et problem eller et delproblem er vanskelig eller ikke oplagt, bør                 løsningen dokumenteres med de overvejelser, I har gjort jer og det princip, der er                 valgt.

    -    Hvis I vurderer, at der i beskrivelsen af problemstillingen er manglende eller
        modstridende oplysninger, bør I definere og dokumentere nogle forundsætninger som             opgaven så løses ud fra. Dette vil ofte være tilfældet i en tænkt problemstilling som i                 denne opgave, hvor I jo kun har beskrivelsen at holde jer til - men ingen brugere at
        interviewe.

    -    Hvis I vurderer, at det er nødvendigt at foretage visse afgænsninger af opgaven,
        for at den realistisk kan løses, bør disse begrundes og dokumenteres.

Dette må dog kun opfattes som en ufuldstændig liste med nogle "tommelfingerregler". Det bedste er, at holde sig formålet med dokumentationen for øje: systemets virkemåde skal kunne forstås af andre.

I må ikke opfatte listen som udtryk for en rækkefølge, I skal følge - vælg den rækkefølge, I vurderer som værende mest naturlig for læseren.


5.2 Vedligeholdelsesvejledning

Vedligeholdelsesvejledningen skal dokumentere systemet, sådan at andre kan finde rundt i det og løbende vedligeholde det - d.v.s. rette småfejl, lave småændringer og -tilføjelser o.s.v.

Vedligeholdelsesvejledningen skal indeholde følgende:

    1.    Kørselsomgivelser
        Systemets krav til den maskine, der skal køre det: lagerkapacitet, programmel o.s.v.

    2.    Klassediagram
Det endelige klassediagrammer med klasserne og deres relationer. Til klassediagrammerne kan benyttes notationen i OFJ (se f.eks. fig. 5.2, s. 115) - eller hvis nogen foretræker det: egentlig UML-notation.

3.    JavaDoc dokumentation
        En JavaDoc-genereret dokumentation af klasserne.

    4.    Systemets kildetekst
        Selve programteksten. Af praktiske grunde skal den vedlægges som bilag.
        Linierne i programteksten skal være fortløbende nummererede indenfor hver javafil.
       
        Kildeteksten skal være forsynet med passende kommentarer efter behov. Med ”passende”
        kommentarer menes:
           
            - en kort forklaring af hver klasse
- en kort forklaring af hver attribut og metodes formål med mindre dette er
        indlysende
            - indenfor hver metode en kort forklaring af de programsætninger, der er væsentligst
              for metodens virkemåde

        Pas på ikke at ”overkommentere”! I behøver ikke at forklare noget, I vurdererer
        oplagt eller selvforklarende.

        Et godt bud på god programmeringsskik i øvrigt findes i LL appendix G: ”Java Coding
        Guidelines”.

    5.    Afprøvningsdokumentation
    Én af klasserne i løsningen skal afprøves med JUnit test som beskrevet i OFJ afsn. 6.4.      Denne     afprøvning skal dokumenteres med
    1) et skema over de testtilfælde, der afprøves
    2) selve den udviklede testklasse, der tester disse testtilfælde
    3 et     skærmdump af en testkørsel (som fig. 6.4 i OFJ).

6. Kørselsdokumentation
    Normal kørsel med systemet skal dokumenteres med repræsentative skærmdumps ved     udførelse af alle systemets funktionaliteter.

    7.    Systemets status
        En beskrivelse af det afleverede systems status: virker det 100%, delvist, slet ikke. Hvis             systemet kun virker delvust, skal det specificeres, hvad der virker, og hvad der ikke                 virker.
    En liste over fundne fejl og evt. forslag til, hvordan brugeren kommer uden om dem, og
    hvordan de kan rettes.    

5.3 Vægtning

Jeres besvarelse vil blive vurderet med henblik på at afgøre, om den kan godkendes eller ikke. Vurderingen gælder den arbejdsindsats og forståelse, besvarelsen vidner om. Da dissee kan svinge fra den ene del af besvarelsen til den anden, vurderes de i de enkelte dele og udtrykkes for hver del som et antal points mellem 0 og 100. For at kunne finde frem til en samlet vurdering, vægtes de enkelte dele på flg. måde:

    1.    Løsningsovervejelser                25 %
    2.    Vedligeholdelsesvejledning            60 %
            2.1    Kørselsomgivelser                *)
            2.2    Klassediagram                    10 %           
            2.3     JavaDoc dokumentation                10%
            2.4    Systemets kildetekst                25 %
            2.5    Afprøvningsdokumentation            15 %
            2.6     Kørselsdokumentation                *)
            2.7    Systemets status                     *)

    Helhedsindtryk                    15 %


*) vurderes ikke selvstændigt, men indgår i helhedsindtrykket.

Med "helhedsindtryk" menes overskueligheden, sproget, "ordenen", konsistensen. Til inspiration vedr. dette kan læses et udsnit af Jacob Heiberg: Rapportskrivning (Borgen 1994).

Det er især vigtigt, at der er sammenhæng –  f.eks. skal klassediagrammet svare præcist til det program, der aflleveres, det samme gælder afprøvningsdokumentationen.

5.4 Godkendelseskriterier

For at få godkendt en besvarelse skal den opfylde 2 kriterier:

    1.    Det samlede, vægtede resultat for hele besvarelsen skal være mindst 50 points.

    2.    Alle punkter nævnt i afsn. 5.3 skal indgå i besvarelsen. I skal
        m.a.o. have ydet en væsentlig indsats på alle punkter.


6. Praktiske oplysninger

aflevering

Rapporten skal afleveres senest fredag d. 12.11. kl. 12.00 i DØK-sekretariatet.

Der skal afleveres 2 eksemplarer – det ene vedlagt CD eller diskette.


udleveringsforelæsning

Der kan stilles spørgsmål til opgaven

mandag d. 1.11. kl. 8.00 i SP216 (Solbjerg Plads)



hjælp i opgaveperioden

Spørgsmål kan i opgaveperioden stilles som email til lærerne og/eller instruktorerne.

Bilag A – data til initialisering

Navn    Cpr    Dat                                        EØ            Org                Sam           
        U1    U2    U3    U4    U5    U6    U7    U8    G1    G2    U1    U2    U3    U1    U2    U3    U4    U1    U2    U3    U4
Ib    1    g    g        g    g    g            g    g    g    g    g    g    g    g        i    g    g    g
Bo    2    g    g    g    g    g    g    g        g    g    i    g    g    g    g    g        g    g    g   
Eva    3    i    g    g        i    g    g        g    g    i    g    i    g    g    g    g    g    g        i
Hans    4        i    g    g    g    i    i        i    i    i            g    g    g        i    g       
Per    5    g    g        g        g    g        g    g    g    g    g    g    g    g    g    i    g       
Jan    6    g    i    i        g    g    g        g    g    g    g    i    g    g    g    g    g    g    g   
Lis    7                i    g    i            i                    g                i           
Ulla    8            i                        g        g    i        g                i           
Sys    9    i    g    g    g    i    g            g    g    i            g    g        g    g    g    g   
Lars    10    i    g    g    g        g    i        g        i            g    i            g    g    i    i
Ove    11    g    i    g    i    g    g    g        g    g    g    g    g    g    g    g        g    i    g    g
Ole    12    g    g    g    g                    g        i    g    g    g    g    g        g    i    g   
Lise    13    g    g        g    g    g    g        g    g    i    g    i    g    g    g        g    g    g   
Per    14    g        g        g    i    g        i    i    g    i    g    g    i    g    g    i           
Jakob    15        i    g    g    g    i    i        i    g    g    g    g    g    i    g        i    g    g    g
Sven    16    g    i    i    g    g    g    g        g    g    g    g    g    g    g    g        g    g    i    g
Tina    17    g    i    g    i    g    g    i        g    g    g    i    i    g    g    g        i    g    i   
Tove    18    g    g        g    i    i    g        g    g    g    g    g    g    g    i    i    g        g    g
Tom    19    i    g    g    g    g    g    g        g    g    g    g    g    g    g    g        g    g        g
Hans    20    g        i    g    g    g    g        g    g    g    g    g    g    g    g        g    i    g    i

Symboler:

g: afleveret og godkendt
i: afleveret og ikke godkendt
blank: ikke afleveret

Som det ses er det af hensyn til indtastningsmængden valgt at forenkle både navne og cpr-numre. Det spiller ingen rolle for datasættets brugbarhed i opgaven.

Opfat ovennævnte status som gældende lige før den sidste U-opgave er stillet (U8 i datalogi).