1. Indledning

Denne rapport er en beskrivelse af vores 2. prototype, præsentationen af denne for kunden og en beskrivelse af de begivenheder der gik forud for det færdige produkt.

Vort projekt går som bekendt ud på at udvikle et system til abonnement og lagerstyring for en mindre tegneseriebutik (Stribeladen) i Århus.
Vi har ikke ændret i vor oprindelige opfattelse af problemområdet, så følgende er taget direkte fra Delaflevering 1:

Stribeladen har et begrænset abonnemtssystem. På nuværende tidspunkt har de et edb-system, der ikke lever op til deres ønsker. Dette bevirker at halvdelen af abonnementssystemet styres af Michael.
Abonnenter kan være aktive, inaktive eller dårlige afhentere. Det sidste betyder at deres abonnement stopper.
Abonnenten kan abonnere på enkelte tegneserier, hele serier eller crossovers. Crossovers er et afgrænset antal tegneserier, der eksempelvis kan bestå af Batman nummer 7 til 9 og Superman nummer 12 til 20. En crossover har tillige et navn, f.eks. Batman vs Superman.
På nuværende tidspunkt håndteres crossovers dårligt vha. et hack.
Butikken har et lager af tegneserier. Disse tegneserier er registreret i det nuværende system, men bruges ikke til noget.
Bestilling af nye tegneserier foregår ved at udskrive en abonnementsliste og ved at kigge på hvad butikken bestilte måneden i forvejen. Dette modificeres så af Michael.
Hver abonnent har en pose. Heri lægges de tegneserier han/hun har bestilt, når de kommer ind af døren. En liste over hvilke tegneserier, der skal i hvilke poser genereres af det nuværende system. Dette virker næsten perfekt, dog er der nogle ekstra tegneserier, der fordeles af Michael, ud fra specielle ønsker fra kundens side.

2. Ændring i forhold til 2. delaflevering

Der er ikke skete nogle store ændringer m.h.t. strukturen af klasse systemet som var beskrevet i 2. delaflevering. Strukturdiagrammet fra delaflevering 2 er vedlagt (Bilag 1) da det ved en fejl ikke blev inkluderet i 2. delaflevering. Vores endelig struktur diagram, som blev producert ved reverse engineering i Freja kan ses i Bilag 1b. Disse strukturdiagrammer er iøvrigt ens, bortset fra at der vises flere detalger i Bilag 1b.

Adfærdsdiagrammet har på den anden side set nogle større ændringer på grund af en kombination af tidspres og evaluering af hændelsernes relevans. Vi har vedlagt de gamle adfærdsdiagrammer som henholdsvis bilag 2a og bilag 2b.
Vi fandt det ikke nødvendigt at lave nye hændelsesdiagrammer. idet samtlige ændringer fremlægges herefter:
Følgende hændelser blev derfor ikke implementeret pga. tidspres:

  1. ændre abonnement, dvs. antal bestilt,til,fra
  2. fjerne enkelt nummer fra serie og crossover
  3. alt funktionalitet der drejer sig om Forlag.
Det er faktisk vigtigt at man kan oprette et forlag, ændre dets distributør, og tilknytte et forlag til et enkelt nummer, men vi kunne desværre ikke forstå hvordan option buttons virker, og vi havde ikke tid til at ændre ret meget i brugergrænsefladen. Vi betragter den som en større fejl i systemet da udskrivning af bestillingslister er stærkt afhængige af hvilket forlag udgiver et enkelt nummer eller serie. Det er derfor kun muligt at udskrive en bestillingsliste baseret på vores meget begrænsede testdatabase.

Den sidste store ændring er at det er umuligt at slette abonnenter, serier, enkelte numre og crossovers. Vi havde oprindeligt inkluderet "slet" som en hændelse på disse klasser, da vi mente der skulle være en vis balance i at man skulle kunne både oprette og slette objekter. Men under forløbet af projektet kom vi til at se at det ville være for vanskeligt at slette objekter fordi der er for mange forbindelser mellem abonnenter og de tre tegneserie former(via abonnementer), og det vil være for svært at sørge for at slette disse forbindelser samtidigt med at slette objektet. Desuden er "slet" ikke særligt nødvendigt i tegneserieverdenen, da en tegneserie, der en gang er annonceret vil eksistere som begreb for evigt (også selvom den aldrig bliver trykt).

Vi har beskrevet ændringer i brugergrænsefladen på bilag 3a til 3k.

3. Sammenhæng mellem OOA/D-model og persistence

Vores OOA-model (Se Bilag 1) har vi gemt i en fil med det meget sigende navn globalpatterns.bet. Heri har vi lagt definitionerne på de forskellige klasser i strukturdiagrammet. Alle disse klasser er puttet i respektive containere, som så gemmes i persistence store.
Eftersom patterns i globalpatterns.bet svarer nøje til vores OOA-model, og da denne model er gennemgået i tidligere afleveringer, ser vi ingen grund til vorer uddybning af sammenhængen.

4. Sammenhæng mellem persistence og brugergrænseflade

Alle vore vinduer er beskrevet på bilag 3a til bilag 3k. På hvert bilag står der hvilken sammenhæng billedet har med persistence og OOA-modellen. Desuden er der en kort beskrivelse af vinduets funktion.