Fyra i rad Javaprojekt inom TDDC32

Transkript

1 Fyra i rad Javaprojekt inom TDDC32 Analys och design-dokument Version 2.0 Datum Dokumentnummer

2 Sammanfattning Detta är analys och design-dokumentet för programmet Fyra i rad. Fyra i rad är ett spel skapat i Java och utgör ett projektmoment i kursen Design och implentering av programmodul i Java som ges vid Linköpings universitet. Detta dokument beskriver programmets uppbyggnad och funktion. Dokumentet beskriver spelets olika klasser och relationen mellan dem. Vidare innehåller det även use case- aktivitets- och tillståndsdiagram för att tydligöra hur spelet kommer att framskrida. Dessutom presenteras det grafiska gränssnittet med bild och kort beskrivning. 2

3 Innehållsförteckning Sammanfattning... 2 Innehållsförteckning... 3 Dokumentkonventioner... 4 Klassdiagram... 5 Klassbeskrivning... 6 Use case-diagram... 6 Interaktionsdiagram... 7 Aktivitetsdiagram... 7 Tillståndsdiagram... 8 Brädet... 8 Spelare... 9 Grafiskt gränssnitt... 9 Slutgiltigt resultat jämfört med den ursprungliga kravspecifikationen Test Avrundning

4 Dokumentkonventioner Dokumenthanteringen i projektet kommer att skötas på följande sätt: Varje textdokument i projektet ges ett namn och ett dokumentnummer som är datumet för den dag dokumentet först skapas (ÅÅÅÅMMDD) samt ett versionsnummer som ursprungligen är 0.0 och sedan ökar på höger sida om punkten med ett steg i taget enligt 0.1, , 0.12 etc. Varje gång ett dokument skickas in till ledningen för kursen TDDC32 nollställs höger sida om punkten och den vänstra sidan ökar med ett t.ex. 1.0, 2.0 etc. Efter granskning kommer dokumentnumret sedan fortsätta att öka på höger sida enligt tidigare. Detta görs direkt när filen öppnas för att på så sätt behålla gamla versioner av dokumenten vid eventuella filproblem. När arbetet med textdokumentet är klart kommer det att laddas upp på gruppens grupportal på för att komma hela gruppen till del. De diagram som presenteras nedan följer UML-standarden. Detta följer de första intentionerna som vi presenterade i kravspecifikationen. All kommunikation i projektet kommer att vara på svenska. Ytterligare dokumentkonventioner kommer att tilläggas till detta dokument om och när behov uppstår. 4

5 Klassdiagram Nedan följer ett klassdiagram över de klasser som ingår i programmet. Figur 1. Klassdiagram 5

6 Klassbeskrivning Game (main): Denna klass innehåller main-metoden. Här skapas en instans av klassen MenuGui och sedan körs metoden play() för denna instans. MenuGui: Skapar ett fönster, att rita upp grafiken i, samt en meny. Ärver från JFrame som redan finns i javax.swing. Implementera även gränssnittet ActionListener för att kunna svara på input från de olika menyalternativen. Denna metod innehåller även själva spelförfarandet, som finns I metoden play(). Denna klass är således den centrala klassen i programmet. BoardGui: Används för att rita upp själva brädet Board-klassen. Ärver från JPanel som finns i javax.swing. Markerar även vinst genom att byta ut de fyra marker, som innebär vinst, mot fyra stjärnor. Board: Brädet utgörs av en matris (6 x 7) innehållandes marker. Brädet används för att hålla reda på vilken spelares marker som ligger var. Brädet håller även redan på om någon spelare vinner eller om det blir oavgjort. Marker: En marker har en färg (gul eller röd) beroende på vilken spelare den tillhör samt en variabel som visar om marken är lagd eller ej. Player: Är huvudklassen för samtliga spelarklasser. Denna klass har fyra underklasser som presenteras nedan. HumanPlayer: Klassen som tar hand om den mänskliga spelaren och svara på i vilken kolumn spelaren väljer att placera sin marker. AiEasy: Enklaste Datormotståndare. Placerar markerna helt slumpmässigt. AiMedium: Medelsvåra datormotståndaren. Finns det möjlighet att vinna hittar den denna möjlighet och placerar marken där. I nästa steg söker den efter hot där motståndaren har möjlighet att vinna och försöker blockera dessa. Finns varken hot eller möjligheter placeras markerna ut slumpmässigt. AiHard: Den svåraste datormotståndaren. I första steg letar den efter direkta möjligheter och hot precis som AiMedium. Därefter söker den efter indirekta hot och möjligheter. Skapar även en array över dåliga positioner som bör undvikas. Lyckas den inte finna något lämpligt drag efter dessa kriterier sker en slumpmässig placering. Use case-diagram Nedan följer ett use case -diagram. Det är endast aktören Mänsklig spelare som kan välja speltyp och starta spel eftersom vi väljer att definiera Mänsklig spelare som den som sätter igång spelet. Val av speltyp inkluderar val av motståndare Dator eller Människa och svårighetsgrad enkel, medel eller svår om Dator väljs som motståndare. Det är således alltid endast två aktörer som agerar i systemet. Som förvalt alternativ är spelare 1 (gult) Mänsklig spelare och spelare 2 (rött) lätt datormotståndare. Starta nytt spel kan ske när som helst och innebär att eventuellt pågående spel avbryts och ett nytt startas. Marker kan placeras ut av samtliga aktörer då de står på tur. Om Mänsklig spelare väljer att två datormotståndare skall spela mot varandra så kan denne inte 6

7 placera marker under denna spelomgång. Alternativet hjälp och alternativet om kan när som helst användas av aktörerna Mänsklig spelare och Mänsklig motståndare dock kan det aldrig användas av aktören Datormotståndare. Figur 2. Use case-diagram Interaktionsdiagram Vi anser att det inte är befogat med något interaktionsdiagram då användargränssnittet är så pass enkelt att det inte finns några komplicerade fall. Aktivitetsdiagram Nedan visas ett aktivitetsdiagram över själva spelgången sett utifrån spelare ett. Spelare ett börjar alltid oavsett om den utgörs av en människa eller av programmet. Mänsklig spelare 1 är i detta fall användaren. Spelare refererar till objektet som denne styr. Motspelare är det objekt som motspelaren styr. Kan vara både människa eller dator. I detta aktivitetsdiagram avslutas spelet efter en omgång men i programmet kan man även starta om efter ett spel utan att avsluta programmet. 7

8 Stjärnor Figur 3. Aktivitetsdiagram Tillståndsdiagram Brädet Nedan följer ett tillståndsdiagram för brädet. Brädet kan ha tre grundtillstånd: tomt, delvis fullt eller helt fullt med marker. Dessutom kan det indikera vinst genom att de marker som skapar den vinnande raden byts ut mot stjärnor. Själva den grafiska presentationen av detta sker dock inte i klassen Board utan i klassen BoardGui, det är dock klassen Board som avgör vilka marker som utgör den vinnande raden. 8

9 Figur 4. Brädets tillståndsdiagram Spelare Nedan följer ett tillståndsdiagram för en spelare. Spelaren kan befinna sig i två lägen: dels kan det vara spelarens tur att lägga en marker eller så inväntar spelaren sin tur. När spelet väl är slut kan spelare inta tre olika tillstånd: vinnare, förlorare eller oavgjort. Figur 5. Spelares tillståndsdiagram Grafiskt gränssnitt Nedan presenteras en bild över det grafiska gränssnittet. I menyn finns två huvudalternativ: Spel och Hjälp. Under Spel kan man välja spelartyp för spelare 1 (gul) respektive spelare 2 (röd). Det händer dock inte något med dessa val förrän man väljer Starta nytt spel. Då startas ett nytt spel utifrån vad som är markerat för Spelare 1 och Spelare 2. Alternativet Avsluta stänger ner hela spelet. Under Hjälp finns två alternativ: Regler som kort talar om vad spelet går ut på samt Om som talar om vilka som skapat spelet. Själva spelbrädet är uppbyggt av olika gif-bilder; en för tom plats, en för plats med gul marker i samt en för plats med röd marker i. Genom att klicka med musen någonstans på brädet så känner programmet av koordinaterna för musklicket och kan på så sätt räkna ut vilken kolumn som markern skall läggas i. Ovanför spelbrädet finns en rad med ytterligare gif-bilder. Dessa kan antigen vara genomskinliga, innehålla en gul marker eller en röd marker. Markern följer 9

10 muspekarens läge i sidled beroende på vilken kolumn muspekaren för tillfället står över. Markerns färg avgör av vems tur det är. Figur 6. Det slutgiltiga grafiska gränssnittet Slutgiltigt resultat jämfört med den ursprungliga kravspecifikationen Kravspecifikationens systembeskrivning har följts. Vi har skapat ett program som spelar fyra-i-rad med ett bräde på 6 rader och 7 kolumner. I kravspecifikationen delade vi upp programmet i 3 delar som vi skulle programmera var för sig. Vi har i stort sett hållit oss till de tre delarna. AI blev ganska snart utökad till att även innehålla den mänskliga spelare då det visade sig vara praktiskt. Dessutom blev vi tvungna att integrera Regelverket och GUI mer än vad vi räknat med från början. När det gäller funktionalitet så skiljer sig det färdiga programmet gentemot kravspecifikationen på några punkter. Det finns inte med någon funktion för att ångra ett steg. Vi bedömde att de skulle bli för lätt att spela med en sådan funktion. Dessutom diskuterades en del animeringar i kravspecifikationen som aldrig har realiserats på grund av tidsbrist. En sak som vi inte tog upp i kravspecifikationen men som finns i det slutgiltiga programmet är att man kan välja att låta två datorspelare spela mot varandra. 10

11 Test Se separat testprotokoll. Avrundning Sammanfattningsvis kan vi konstatera att vi följt den satta kravspecifikationen, dock med några små undantag. Däremot har själva programmeringsarbetet skiljt sig en del från det planerade utförandet. Klassdiagrammet skiljer sig en del från det som presenterades i version 1.0 av designdokumentet. Användargränssnittet har dock inte ändrats nämnvärt. Arbetsgången har alltså följt planeringen till stora delar. 11