Labb2

  • Inlämningsdatum Inget inlämningsdatum
  • Poäng 0
  • Lämnar in en filuppladdning
  • Filtyper java

Laboration 2

Mål

  • Att förstå hur man med hjälp av interface kan specificera gränssnittet (beroendet) mellan två programdelar och hålla det litet.
  • Att förstå mönstret Model-View-Control och att tillämpa mönstret i en uppgift med Model för sig och View+Control tillsammans i en klass.
  • Att kunna hantera många knappar med lyssnare på ett smidigt sätt samt att bygga upp ett litet grafiskt gränssnitt.
  • Att programmera logiken i ett enkelt spel på ett snyggt och tydligt sätt.
  • Att förstå begreppet Mock object och göra ett sådant.

Uppgifter

Model

 Interfacet nedan har metoder som används för att spela ett enkelt spel på en nxn-spelplan.  I labben ska minst ett av spelen Femtonspelet och TicTacToe (3x3-luffarschack med två faser https://www.youtube.com/watch?v=IDchqc56aQY Links to an external site. ) implementeras enligt interfacet. 

public interface Boardgame {
   public boolean move(int i, int j); //ger true om draget gick bra, annars false 
   public String getStatus(int i, int j); // returnera innehåll på ruta (i,j)     
   public String getMessage(); // returnera OK (eller liknande) eller felmeddelande avseende senaste drag
}

Varje drag i spelet utförs genom att man väljer en ruta genom att välja koordinaterna (indexen) i och j. Metoden move(i,j) anropas och draget utförs.  Spelets ställning uppdateras då inuti klassen och kan avläsas position för position genom metoden getStatus(i,j).  Anrop av getMessage() ger ett aktuellt meddelande som säger om draget gick bra eller ej. Vid felaktigt drag ska hjäpsam information ges.

Spelklassen ska vara helt fri från grafik och utgör modelldelen i Model-ViewControl. Spelklassen kan användas tillsammans med en textbaserad ViewControl-del eller en grafisk.

Spelmodellens uppgift är att tillhandahålla metoder som behövs för att man ska kunna spela spelet. Spelet spelas genom många anrop av metoderna.

I grunduppgiften ska ett av spelen Femtonspelet och TicTacToe implementeras. De detaljerade anvisningar för modellen som följer under Uppgift 1  avser Femtonspelet.
 
TicTacToe ska implementeras med en utplaceringsfas och en "flyttfas". Spelet ska alltså inte ta slut när 3 + 3 pjäser är utplacerade utan fortsätta genom att en användare i taget flyttar en pjäs. Vi kräver dock inte att ni detekterar vinst för någon spelare.
I TicTacToe så måste modellen hålla reda på vems tur det är och meddela detta genom getMessage(). Vartannat lyckat drag tolkas som spelare1 och vartannat är spelare2.

 

Uppgift 1 – Implementera ett Femtonspel

Läs åtminstone t.o.m. uppgift 2 noga (testen av modellen) innan ni börjar!

Känner du inte till Femtonspelet? Läs då på wikipedia: http://sv.wikipedia.org/wiki/Femtonspel Links to an external site..

Skriv en klass 

// OBS! Det behövs inga import-satser i FifteenModel.
// FifteenModel innehåller ingen grafik !!!

class FifteenModel implements Boardgame {
  // Implementera Boardgame-metoderna
  // Deklarera variabler och övriga metoder som ni
  // tycker behövs för ett femtonspel
}
Låt Boardgame-metoderna vara public. Variabler och övriga metoder kan gärna vara private. Exempel på variabler som kan behövas är 
  private String currentMessage = "No message yet";
  private String[][] board = new String[4][4];   // spelplanen
  private int iemp, jemp;                        // index till den tomma rutan
Spelaren väljer en ruta som ligger intill den tomma. Då flyttas den valda rutan till den tomma platsen.
  • När Femtonspelet startar ska sifforna vara i slumpmässiga positioner.
    Kan ordnas genom att man placerar ut dem i ordning och sen gör slumpmässiga anrop av move(i,j). 
    Om man slumpar placeringen direkt finns risk att spelet inte går att lösa.
  • Det krävs inte att meddelande om att spelet är löst ges.
Kom ihåg: Inga knappar, färger, fönster eller annan grafik i modellklassen.
Studera testprogrammet och körningen av det noga!

 

Uppgift 2 – Testa FifteenModel

Provkör ert spel med följande testprogram som inte ska ändras alls. Testprogrammet finns också att hämta här:Text15.java. 
import java.util.*;
class Text15 {
    public static void main(String[] u) {
        Scanner scan = new Scanner(System.in);
        Boardgame thegame = new FifteenModel();                 // Model object is created
        System.out.println("\nWelcome to fifteen puzzle\n");
        while (true) {
            // Print the current board
            for (int i=0; i<4; i++) {
                for (int j=0; j<4; j++)
                    System.out.print("  " + thegame.getStatus(i,j)); // getStatus
                System.out.println();
            }
            System.out.println();
            System.out.print("Your move: ");
            int i = scan.nextInt();  // get an int number from terminal window
            int j = scan.nextInt();
            thegame.move(i,j);	                             // move
            System.out.println(thegame.getMessage());	     // getMessage
        }
    }
}
Studera testprogrammet noga och titta särskilt på att kommunikationen med modellklassen sker endast genom metoderna i interfacet. Modellen skapas på den första kommenterade raden. Gränssnittets metoder anropas för att visa spelets ställning, att utföra drag och att se på aktuellt meddelande. I Text15 visas också hur man i Java får inmatning från ett terminalfönster med hjälpklassen Scanner. Klicka här för att få se en körning av Test15: Text15-demo. Utskriften här är prydlig tack vare att getStatus() alltid returnerar två tecken, dvs tom ruta returneras som två blanktecken "   ", ensiffrigt tal som t.ex. "  7" och tvåsiffrigt utan extra blanka.

Det är rätt jobbigt att spela Femtonspelet i ett terminalfönster. Det blir mycket trevligare i den grafiska varianten.

 

Uppgift 3 – View-Control

Skriv en grafisk klass som visar och spelar ett nxn-"rutspel" av typen Boardgame. n ska vara parameter när objekt av klassen skapas. Klassen ska ha nxn knappar som representerar rutorna. Ett meddelandefält ska också finnas där resultatet av anrop av getMessage() visas. Spelet spelas enligt interfacet Boardgame, endast metoderna i Boardgame får användas i kommunikationen mellan ViewControl och Boardgame. När spelet startas (ett objekt av ViewControl skapas) ska starttillståndet visas direkt genom att det läses av från  Boardgame.

Själva spelet går till så att användaren klickar på en ruta och i och j avläses. Därefter anropas metoderna i modellen: Först move(i,j) och sedan getMessage() och sen eventuellt getStatus(i,j) för uppdatering av alla knapparna. Vi uppdaterar alltså alla knappar även om bara två  stycken har ändrats. Lite slösaktigt men enkelt.   ViewControl får inte innehålla något som är specifikt för Femtonspelet.  Här är ett förslag på start av ViewControl

// lämpliga import-satser här
class ViewControl extends JFrame implements ActionListener {

    private Boardgame game;
    private int size;
    private Square[][] board;        // Square är subklass till JButton
    private JTextField mess = new JTextField();  // JLabel funkar också

    ViewControl (Boardgame gm, int n){  // OK med fler parametrar om ni vill!
         ...
    }

 Tips

  • En subklass till JButton som lagrar indexen i och  j rekommenderas.
  • Testa klassen innan den är helt klar genom att låta knapptryckningarna skriva ut texter av typen 

       "Tryck på knapp 3 1"    i terminalfönstret. 

    Man kan vänta med att införa Boardgame tills den testen är klar, eller så sätter man Boardgame-objektet till null till att börja med.

  • Låt alla rutor i spelet ha samma färg eller välj två färger och gör det schackrutigt. Texten på rutorna ska förstås kunna varieras.
  • Uppdatera ALLA rutor (knappar) i det grafiska gränssnittet efter varje lyckat drag (trots att bara två har ändrats).

 

Uppgift 4 – Sätt ihop

Sätt ihop en FifteenModel och en View-Control till ett spelbart spel.

 

Uppgift 5 – Ett Mock Object för ytterligare ett spel

Implementera Boardgame för ytterligare ett spel men utan spelets funktionalitet, som ett Mock Object. Ingen logik alls behövs och metoderna kan göra nästan ingenting. De kan returnera samma svar hela tiden, bara svaren är av rätt typ. Spelet ska ha en annan storlek än det spel ni redan gjort. Sätt ihop med ViewControl!

 

Att redovisa för grunduppgift

  1. En spelmodellsklass för Femtonspelet som kommunicerar enligt gränssnittet Boardgame. Ingen grafik får finnas i den klassen.
  2. Test av modellen för Femtonspelet genom att köra programmet Text15 ovan.
  3. En generell ViewControl-klass med en rutindelad kvadratisk (nxn) spelplan som spelar ett spel enligt interfacet Boardgame. n är parameter när spelplanen skapas.
  4. Ett program som sätter ihop Model enligt 1 och ViewControl till ett spelbart grafiskt spel. När spelet startar ska det finnas text på alla rutor utom den tomma. Man ska inte behöva trycka på någon knapp för att få se startbilden.
  5. En mini-implementation i form av ett "Mock Object" av en annan spelmodell än den ni valt i 1 och en demo med ViewControl av detta spel.
  6. UML-klassdiagram för allt. Tag med de publika metoderna för varje klass men inga variabler. Metodernas parametrar behöver inte vara med. Eventuella klasser som enbart innehåller en main-metod behöver inte heller vara med i diagrammet. Superklasser till biblioteksklasser ska inte tas med i UML-diagrammet. Gäller t.ex. superklasser till JFrame och JButton.

 

Extrauppgift för högre betyg

Här finns två alternativ, välj ETT av dem:

Alternativ 1

Välj ett annat rutspel än det i grunduppgiften, dvs välj i första hand TicTacToe om ni har gjort Femtonspelet i grunduppgiften och tvärtom. Det är tillåtet att välja andra spel här, men de flesta är svårare att implementera och det behövs inte här. Svårare spel  kan sparas till projektuppgiften. Implementera det nya spelets  spelmodell som ett fullständigt Boardgame och gör ett spelbart spel med hjälp av ViewControl-klassen. Textbaserad test rekommenderas men behöver inte redovisas. Det är alltid en bra teknik att testa programdelar var för sig innan de sätts ihop.

Samma ViewControl som i grunduppgiften används alltså även till detta spel.

TicTacToe ska implementeras med en utplaceringsfas och en "flyttfas". Spelet ska inte ta slut när 3 + 3 pjäser är utplacerade utan fortsätta genom att en användare i taget flyttar en pjäs. Ni behöver inte detektera att någon vunnit.

 

Alternativ 2

En nackdel med implementationen i grunduppgiften är att man uppdaterar alla rutor i ViewControl trots att man vet att endast två rutor ändras i varje drag. Åtgärda denna brist genom att ändra lite i gränssnittet Boardgame samt i implementationen av FifteenModel och användningen i ViewControl.  Med det nya upplägget ska endast ändrade rutor uppdateras i ViewControl.

Vi rekommenderar att Boardgame utökas med en enda metod.

Lösningar där Boardgame fortfarande har tre metoder eller har fem metoder kan godkännas. 

Krav

  • Ändringen ska vara generell, alltså inte anpassad till de spel som implementeras i labben. Ändring av godtyckligt antal rutor ska hanteras, även om det bara är två rutor som ändras vid korrekt drag i just Femtonspelet.
  • När ett ViewControl-objekt skapas ska startställningen (från modellen) visas direkt. Detta måste fungera även med det nya gränssnittet.

 

0