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.
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:
- ændre abonnement, dvs. antal bestilt,til,fra
- fjerne enkelt nummer fra serie og crossover
- 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.
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.
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.