Spelprogram. Objektorienterade applikationer Laboration 2

Transkript

1 1 (5) Spelprogram Objektorienterade applikationer Laboration 2 Syfte Projektet syftar till att belysa och ge träning i Programutveckling i grupp. Objektorienterad modellering med UML. Användning av ett modelleringsverktyg. Dokumentation och presentation av programutvecklingsarbete. Programmering i Java. Mål Produktmål En program med grafiskt användargränssnitt. En skriftlig rapport som beskriver en objektorienterad design av programmet. Processmål Varje deltagare skall efter genomfört projekt ha förvärvat erfarenheter av ett objektorienterat arbetssätt vid programutvecklingsarbete. ökat sin förmåga att konstruktivt bidra till uppfyllelse av produktmål. ökat sin samarbetsförmåga. utvidgat sin förmåga att använda utvecklingsverktyg för modellering och kodutveckling. Projektgruppen Arbetet genomförs i grupper om 6-7 personer och pågår under v Samtliga gruppmedlemmar måste bidra substantiellt till projektet. Överenskommelser om arbetsmöten och åtaganden skall hållas och mötestider passas. Gruppen ansvarar själv för sin tidsplanering. Eftersom projekttiden är kort är det viktigt att arbetet kommer igång direkt. Får gruppen samarbetssvårigheter skall detta meddelas till kursledaren så att problemen kan lösas snabbt. De handledda 4-timmarspassen kommer inte att räcka. Kursen går på halvfart vilket innebär en arbetsinsats om ca 20 timmar per vecka. Gruppen bör ha minst ett långt gemensamt arbetspass utöver det schemalagda per vecka. Tillkommer individuella insatser. Bokning av ev. grupprum för dessa extra möten administreras av gruppen. Utvecklingsmiljö För modellering med UML används t.ex. modelleringsverktyget Poseidon eller UMLet, och för kodutveckling eclipse. BlueJ kan upplevas som alltför begränsat för lite större program. En tidsbegränsad demoversion av Poseidon kan laddas ner från UMLet finns på

2 2 (5) Litteratur Barnes & Kölling: Kap. 1-14, Skansholm Java direkt, Java API, mtrl om eclipse. Gruppen inhämtar själv relevant information efter behov. Redovisning Projektets resultat redovisas i v. 10 genom: En skriftlig dokumentation, som skall innehålla: Användarmanual: En beskrivning på användarnivå av programmets utmärkande egenskaper och dess handhavande. En analysmodell bestående av användningsfallsdiagram med beskrivning i ord av användningsfallen, samt klassdiagram och sekvensdiagram. Dokumentationen av modellen skall göras med ett modelleringsverktyg, t.ex. Poseidon. Övergripande designbeskrivning. Dokumenterad, testad och fungerande programkod. Muntlig redovisning. I redovisningen ingår att agera både i rollen som presentatör, och som opponent. Varje grupp skall provköra program, samt studera dokumentation som utarbetats av en annan grupp, samt förbereda frågor och kritik av arbetet inför den andra gruppens presentation. OH-bilder för presentationen. Använd gärna PowerPoint eller motsvarande verktyg. Demonstration av programmet. Mer preciserade krav på dokumentation, presentation, programkod etc. ges senare på kursens webbplats. Arbetsprocess Programmet bör utvecklas inkrementellt (stegvis) och iterativt. Bestäm milstolpar (inkrement) för projektet. (Se kravspec. betr. miniminivå som skall hinnas med.) Skriv en planeringsrapport på ca en A4-sida omfattande milstolpar och tidplan. Iterera faserna: Modellering i UML, detaljdesign (utformning av klasser, metoder, parametrar,...), implementering, samt testning för varje inkrement. Enhetstesta nya komponenter noga var för sig, innan de integrationstestas med resten av programmet. Tillämpa refaktorering vid behov - strukturera om innan ny funktionalitet införs. Modellering i UML a) Beskriv användningsfallen för hantering av de aktuella funktionerna (rita användningsfallsdiagram för att sammanfatta användningsfallen överskådligt). b) Idéstorm: Leta efter objekt (substantiv i problembeskrivningen är en bra början). Ingen kritik i detta steg, alla tänkbara objekt skall fram i ljuset! c) Är vissa objekt onödiga? Sovra! d) Klassificera objekten (inför klasser). Motivera klassernas ansvar i systemet. Vilken information håller de reda på? Sträva efter klasser med hög kohesion! (använd gärna CRCkort!) Se även punkt g. e) Sök efter objekt- och klassrelationer ( känner till, har, använder, arv ). Bör vissa relationer vara enkelriktade? Försök uppnå en låg grad av koppling mellan klasserna! (rita klassdiagram)

3 3 (5) f) Undersök hur objekten kan samarbeta för att implementera användningsfallen. Inför nödvändiga metoder i objekten. (rita sekvensdiagram). g) Hur ser objektens tillstånd ut? Inför instansvariabler i klasserna. h) Handexekvera modellen med papper och penna. Kommer det att fungera?

4 4 (5) Kravspecifikation Projektgruppen har ganska fria händer att utveckla spelprogrammet efter egna idéer. Nedan följer minimikrav samt förslag på tänkbara utvecklingsmöjligheter. Programmet kan vara en vidareutveckling av spelet zuul som beskrivs i BK kap Som startpunkt finns projektet zuul-for-images som är föreberett för att kunna visa bilder på de olika rummen som besöks i spelet i ett mycket enkelt GUI. Programmet behöver dock struktureras bättre (refaktoreras) innan det byggs ut. Ickefunktionella krav 1. Programmet skall ha ett grafiskt användargränssnitt (GUI) med lämpliga grafiska komponenter så att det blir användarvänligt. 2. Rum skall presenteras med bild och textbeskrivning. 3. En spelarklass införs så att en spelare representeras av ett eget objekt. 4. Kommandon kan ges med textinmatning, men hellre med interaktion med grafiska komponenter som knappar, dialoger, pop-up-fönster, etc.. Kommandona bör i båda fallen internt struktureras som en klasshierarki i enlighet med övn Se även avsnitt Programmet skall designas efter goda objektorienterade principer. Aspekter som kohesion, koppling och ansvarsdriven design skall beaktas. Kvalitet prioriteras framför kvantitet. 6. Observer-mönstret skall tillämpas på lämpligt sätt. Se exempel från förel. om MVCmodellen. Se även avsnitt i BK. 7. Programmet skall kunna köras självständigt (utanför BlueJ eller eclipse). 8. Vad handlar spelet om? Skriv ett manus. Beskriv spelscenarion i form av användningsfall. Hur ser scenen ut? En skum källare, ett stort sjukhus, Chalmers Johanneberg, Ö. Nordstan,...? Vad skall poängsättas? Vad innebär det att vinna? Funktionella krav Kraven under denna rubrik anger en ungefärlig miniminivå som bör designas och implementeras. Spelaren skall kunna fråga var han/hon befinner sig med ett look-kommando, samt kunna backa tillbaka till tidigare besökta rum (kommandot back). (Se övn och ) Rum kan innehålla flera föremål, t.ex. mat, kärl, nycklar. Föremål har egenskaper: vikt, näringsvärde etc. Vissa kan tas upp och bäras vidare av en spelare, andra inte. Somliga kan bara finnas i vissa typer av rum. Kommandon: take, drop, eat,... Spelaren bör informeras om vilka föremål som finns i rummet och vilka som bärs av spelaren, t.ex. med grafiska symboler i GUI:t. Spelare kan bara bära ett begränsat antal föremål upp till en viss maxvikt. Flera spelare skall kunna registrera sig men bara en spelar åt gången. Resultatet av en spelomgång skall kunna sparas i fil. Inför High-score-beräkning. Inför menyer för filhantering, avslutande, hjälp, m.m.. Osorterade idéer Några ej bindande förslag. Föreslå gärna egna - dokumentera dem, formulera krav. Väggarna i ett rum kan presenteras med olika bilder. Spelaren kan vända sig åt olika håll. Rum kan ha lås som kräver nyckel för att öppnas. En spelares energinivå kan bero på hur mycket hon äter och vilken mat hon lyckas hitta. Varje förflyttning sänker energinivån.

5 5 (5) En spelares förmåga att bära föremål beror på spelarens energinivå. En spelares hälsa kan variera. Blir den för dålig dör spelaren. Olika sjukdomar kan drabba spelaren. Medicinburkar kan finnas i vissa rum. Varje sjukdom kräver rätt medicin. Sjukdom påverkar energinivån. Skaffa fler bilder. Tag ev. egna. Inför tidmätning. Spelarens energinivå sjunker med tiden. Hinner man inte fram i tid åker man ur spelet. Koppla poängberäkningen till tidsåtgången. Karaktärer är autonoma figurer som rör sig i rummen på egen hand. Troll, lektorer, studenter, djur, robotar, dvärgar. En karaktär kan tilltalas och ge mer eller mindre upplysande svar. Karaktärer presenteras med bild. Du möter en dvärg. Om du ger dvärgen mat talar den om för dig var du kan hitta en nyckel. Om du hittar nyckeln kan du öppna en dörr för att komma ut och få poäng. Om dvärgen fick ont i magen av maten halveras dina poäng. Eller: Du möter en lektor. Om du ger lektorn din inlämningsuppgift, och den blir godkänd, talar hon om för dig var du kan hitta ett lösenord. Om du hittar lösenordet kan du själv mata in valfritt betyg i ladok och få poäng. Om lektorn underkänner uppgiften halveras dina tidigare poäng. Transporteringsrum. Alla som går in förflyttas automatiskt till ett slumpmässigt rum. Ljudeffekter (använd hörlurar, tack!). Avancerat Se upp! Här kan det lätt bära iväg och svälla över alla gränser. Ge er bara på detta om tiden räcker till. Om utbyggnad av nedanstående slag blir aktuell är det viktigt att den designas väl och att den blir färdig. Central high-score-server med nätverkskommunikation. Kräver trådar och kommunikation (socketar). Flera spelare kan spela samtidigt via olika GUI-klienter. Intressanta saker kan hända om flera möts i samma rum? Kräver trådar och kommunikation (socketar). Dynamisk laddning av spelkaraktärer kan ske under run-time. Kräver dynamisk klassladdning. Spelscenariot (rumsbeskrivningar etc.) kan lagras i en extern fil. Programmet kan då köra olika scenarion. Lycka till!