关于深度学习:CSC-B07软件设计

6次阅读

共计 9319 个字符,预计需要花费 24 分钟才能阅读完成。

CSC B07 Software Design
Fall 2015 — Assignment 1
Logistics
• Due date: Thursday 22 October 11:59pm
• Group size: Individual
Overview
For Assignment 1, you will implement a set of Java classes according to the UML diagrams provided in
this assignment description. To help make sure you have properly translated the UML diagrams into code,
we have provided a type checker with your starter code; make sure to check your code with it before the
assignment due date.
Learning Goals
By the end of this assignment, you should have:

  1. gained an understanding of how one specifies the design for an object oriented (OO) program using
    basic UML class diagrams,
  2. implemented a given OO design, specified by a UML class diagram, in Java,
  3. become more familiar with Java generics, interfaces, abstract classes, and inheritance,
  4. practised writing high quality Java documentation.
    What to do for this assignment
  5. Your svn repository now contains the starter directories and files for this assinment. Follow the usual
    process to get the starter code from the svn repo.
  6. You should see a directory called a1. It contains a directory A1soln with a subdirectory src, which
    in turn contains the file TypeChecker.java and subdirectories game, sprites, and ui.
  7. Follow the usual process to create a workspace a1 and a Java Project A1soln in Eclipse, so that you
    can see the starter packages and work on them in Eclipse.
  8. Complete the Java program according to the UML diagram in Figures 2 through 4. Commit often!
  9. Run TypeChecker.java. When the type checker reports that
    All type checks passed!
    Note that this does NOT mean your code works perfectly.
    your code has passed the type checker tests. Passing the type checker tests is a necessary but not
    sufficient condition to pass our test suite to check your program correctness (i.e., if you fail the type
    checker tests, you will fail the test suite but passing the type checker does not mean you will pass all
    our tests).
    Figure 1: Example Initial and Intermediate States of the Game
  10. To submit your work, add any newly created Java files and commit all your changes under the existing
    directory A1soln.
    Commit only .java files. Do not commit .class files or the files and directories generated by Eclipse,
    such as bin, doc, .project, etc. Marks will be deducted for submitting these files.
    The Great Vacuum Race
    We are implementing a simple game. The game board is a 2-dimensional grid. Each cell in this grid represents
    either a section of hallway, a piece of wall, or a dumpster. We denote a wall with the symbol X, a hallway
    with a blank space, and dumpster with U. There are two players in this game — two vacuums. We denote
    them with symbols 1 and 2. Some of the cells are dirty: they contain dirt (the symbol .) or dustballs (the
    symbol o). The vacuums’objective is to clean up as many dirty cells as possible. The dirt is stationary,
    but the dustballs move about the grid and each cell that a dustball visits becomes (or stays) dirty when the
    dustball leaves. Figure 1 (left) shows an example initial state of the vacuum game. Notice the two vacuums
    (1 and 2), 16 dirty cells (.), four dustballs (o), and three dumpsters (U).
    In our implementation, vacuum 1 moves left when the user presses the ‘a’ key, moves right on the ‘d’ key,
    moves up on the ‘w’ key and moves down on the ‘s’ key. Similarly, vacuum 2 moves left on the ‘j’ key,
    moves right on the ‘l’ key, moves up on the ‘i’ key and moves down on the ‘k’ key.
    Only one vacuum can move at a time, but they do not need to alternate turns (e.g., vacuum 1 could move
    three times in a row). A vacuum cannot move onto the other vacuum (or a wall, of course), but can move
    onto dirt, a dust ball, a dumpster (or clean hallway, of course). After a vacuum moves, if there are dustballs,
    they move randomly.
    When a vacuum enters a cell, it cleans the cell — i.e., any dirt or dustball is removed; the cell becomes a
    clean hallway — but only if the vacuum is not yet full (see below). Figure 1 (right) shows an example state
    of a vacuum game after vacuums 1 and 2 made some moves. Notice that the dustballs moved (dirtying more
    hallways) and that vacuum 1 cleaned some dirt!
    Each time a vacuum cleans dirt, the vacuum’s score is incremented. In our implementation, dustballs are
    worth more. The score accrued for cleaning dirt or a dustball is defined in the starter code.
    Each vacuum has a capacity. Cleaning up dirt or a dustball adds a constant amount to the fullness of the
    vacuum. When a vacuum becomes full, it cannot clean any more dirt; it can still go to dirty hallways, but
    it has no effect on the dirt that is there. A vacuum that enters a cell with a dumpster is emptied (i.e., its
    fullness becomes a constant that corresponds to“empty vacuum”); thus, if a vacuum is full, in order to
    resume cleaning dirt, it must visit a dumpster. Dumpsters have no limit on their capacity.
    The game ends when all dirt (including dustballs) is gone. The vacuum with the higher score wins, or, if
    the two scores are equal, we declare a tie.
    2
    The Implementation
    We have largely designed The Great Vacuum Race game for you. Your task is to study the UML class
    diagrams provided and to produce a corresponding Java implementation. In addition to what is specified,
    you may add private helper methods (and it is a very good idea to do so!).
    Grid<T> is a (generic!) interface that defines a two dimensional grid of objects of type T. The class
    ArrayGrid<T>, which implements this interface, defines, among others, a toString() method, which needs
    to produce a String representation of the Grid in exactly the same way as specified in Figure 1. The
    class ArrayGrid<T> also defines an equals method, which returns true if and only if the given object is an
    ArrayGrid<T> with the same dimesions and contents as the caller. The UML class diagrams for Grid<T>
    and ArrayGrid<T> are given in Figure 2. This code belongs in package game.
    ArrayGrid<T>
    … private instance(s): your design …
  11. ArrayGrid(numRows: int, numColumns: int)
    VacuumGame
  12. grid: Grid<Sprite>
  13. vacuum1: Vacuum
  14. vacuum2: Vacuum
  15. dirts: List<Dirt>
  16. dumpsters: List<Dumpster>
  17. random: Random
  18. VacuumGame(layoutFilename: String)
  19. getGrid(): Grid<Sprite>
  20. getVacuumOne(): Vacuum
  21. getVacuumTwo(): Vacuum
  22. getNumRows(): int
  23. getNumColumns(): int
  24. getSprite(row: int, col: int): Sprite
  25. move(nextMove: char): boolean
  26. gameOver(): boolean
  27. getWinner(): int
    … private methods — your design …
    Grid<T>
    «interface»
  28. setCell(row: int, column: int, item: T): void
  29. getCell(row: int, column: int): T
  30. getNumRows(): int
  31. getNumColumns(): int
  32. equals(other: Object): boolean
  33. toString(): String
    Figure 2: Grid and VacuumGame (in package game)
    For our vacuum game, you will store and manipulate a Grid of Sprites. Carefully study the UML diagram
    that defines the various Sprites that will go on the grid, and the relationships between them. See Figure 3.
    This code belongs in package sprites. Here are a few things to note about the Sprites:
    • In addition to the Grid keeping track of all its Sprites, each Sprite itself keeps track of where it
    resides.
    • Each Dirt object stores in its value attribute the score accrued for cleaning it.
    • Every Vacuum sits on top of another Sprite, even if it is just a CleanHallway. The Vacuum itself, not
    the Grid, stores what’s under it. No other Sprite can have anything under it. Initially, a Vacuum sits
    on top of a CleanHallway.
    The class VacuumGame is where all the action will happen! Class VacuumGame belongs in package game. It
    keeps track of the Grid of Sprites, the two Vacuum players, and all the Dirts. In addition to getters, this
    class will implement the following methods:
    • The constructor for VacuumGame takes the path to a text file and reads and initializes the Grid from
    it. The starter code has examples that demonstrate the correct content and format for an input file.
    • The method move takes a character. If it is a valid move character, and the move it describes is both
    on the grid and an allowed move (see the description above and the starter code), this method changes
    the position of the corresponding vacuum accordingly. Afterwards, the Dustballs move randomly
    (regardless of whether the vacuum actually ends up moving).
    3
    «abstract»
    Sprite

    symbol: char

    row: int

    column: int

  34. Sprite(symbol: char, row: int, column: int)
  35. getSymbol(): char
  36. getRow(): int
  37. getColumn(): int
  38. toString(): String
    «interface»
    Moveable
  39. moveTo(row: int, column: int): void
    Dirt

    value: int

  40. Dirt(symbol: char, row: int, column: int, value: int)
  41. getValue(): int
    DustBall
  42. DustBall(symbol: char, row: int, column: int, value: int)
    CleanHallway
  43. CleanHallway(symbol char, row: int, column: int)
    Wall
  44. Wall(symbol char, row: int, column: int)
    Dumpster
  45. Dumpster(symbol char, row: int, column: int)
    Vacuum
  46. score: int
  47. capacity: int
  48. fullness: int
  49. under: Sprite
  50. Vacuum(symbol: char, row: int, column: int, capacity: int)
  51. clean(score: int): boolean
  52. empty(): void
  53. getScore(): int
  54. setUnder(under: Sprite): void
  55. getUnder(): Sprite
    Figure 3: The Various Sprites (in package sprites)
    Dustballs can only move onto cells that contain a CleanHallway or Dirt, and when a Dustball moves
    onto a cell, the Dustball is visible instead of whatever was there. If the input does not specify a valid
    move, the method does nothing. A vacuum cannot move to a cell occupied by the other vacuum. When
    a vacuum moves onto a dirty cell, it cleans the dirt (provided there is capacity).
    • The method gameOver() returns true if the game is over and false otherwise.
    • The method getWinner() returns the ID of the winning vacuum (1 or 2), and 0 if there is a tie.
    You will no doubt define several private methods (helper methods) in VacuumGame, in addition to the
    required public methods specified in the UML diagram.
    Finally, the interface Ui defines a user interface for the Vacuum Game. We have provided a very simple Gui
    implementation (see class Gui.java, which uses class GuiListener.java). Your task is to provide a text
    Ui that implements the same interface. The text Ui should read from System.in and print to System.out.
    See Figure 4 for the UML class diagrams. This code belongs in package ui.
    4
    GUIListener
  56. window: Gui
    TextUi
  57. game: VacuumGame
  58. TextUi(game: VacuumGame)
    «interface»
    Ui
  59. launchGame(): void
  60. displayWinner(): void
    Gui
  61. game: VacuumGame
  62. tiles: JLabel[][]
  63. Gui(game: VacuumGame)
  64. getGame(): VacuumGame
  65. updateLabels(): void
    Figure 4: The User Interface (in package ui)
    The Starter Code
    Your repository contains the starter code for this assignment. Make sure to study it carefully before you
    begin coding! Pay careful attention to the class Constants: you should make extensive use of it in your
    implementation.
    Evaluation
    In addition to correctness, your submission will also be marked for style — be sure to run the checkstyle
    Eclipse plug-in often as you develop your solution.
    Checklist
    Have you. . .
    • run the type checker?
    • run the checkstyle plug-in?
    • followed the style guidelines?
    • documented your code well? Generated the HTML documentation to see it in the form that the TAs
    will grade?
    • tested your code on the lab computers?
    • committed all of your files (and no extra files) in the correct directory?
    • used svn list and svn status to verify that your changes were committed?
    5
正文完
 0