Uppgiften går ut på att skapa en objektorienterad analysmodell för det system ni ämnar konstruera. Gruppen ska förutom själva modellen också dokumentera arbetet bakom denna i en delrapport som ska innehålla en beskrivning, analys och diskussion av er UML-baserade objektorienterade modell. I delrapporten ska ni föra ett väl underbyggt resonemang om viktiga delar i er modell. Strukturen ska följa vetenskapliga normer, d.v.s. när källor används ska detta tydligt markeras och referenser anges.
Delrapporten ska vara en beskrivning av och en argumentation för vald modell, men det är också viktigt att ni försöker förhålla er kritiska till er modell, t.ex. genom att bedöma vilka svagheter ni uppfattar att den uppvisar.
Det är upp till gruppen att bestämma vilka vyer (views) och diagram ni anser lämpliga för att utgöra en fullgod objektorienterad analys. Detta får ni i gruppen resonera er fram till med stöd av kurslitteraturen. Det är viktigt att ni tar uppgiften på allvar, då det är den egna gruppen som ska använda de analysmodellerna för att konstruera och implementera systemet.
Pressman skriver t.ex. om objektorienterad analys i kapitel 20, och vi kommer också att ta upp analysfasen under kursens föreläsningar. Som ytterligare hjälp har ni också bland annat del 2 i Pressman (om projektplanering) och hela del 4 (om den objektorienterade ansatsen) vilket bör sätta in uppgiften i ett Software Engineering-sammanhang. Vid eventuella konflikter mellan Booch et al och Pressman vad gäller objektorienterad modellering görs modelleringen enligt Booch et al. Det kan dock vara nyttigt att notera sådana problem, inte minst för det därefter följande designarbetet.
Vid redovisningsseminariet ska grupperna presentera sin modell av det blivande systemet enligt den notation för UML som läggs fram av Booch et al. Dessutom ska gruppen visa en tidig prototyp av hur ni har tänkt att systemets användargränssnitt (GUI) ska se ut och fungera. Prototypen kan bestå av skisser, gjorda med penna och papper, men också mer high-fidelitylik, t.ex. utformade m.h.a. ett presentationsprogram som exempelvis PowerPoint. Gruppen är helt fri att använda sin fantasi att utforma den på bästa sätt. Prototypen bör dock avspegla gruppens modell över systemet så mycket som möjligt – det ska alltså finnas en klar koppling mellan funktionaliteten som presenteras i er modell och den funktionalitet som presenteras i ert gränssnitt.
Att tänka på:
Underhålls
av: eva@informatik.umu.se
URL: http://www.informatik.umu.se/~eva/metodkonstrukt/redovis.html.html
Senast ändrad: 2000-10-24