Never confuse education with intelligence, you can have a PhD and still be an idiot.
- Richard Feynman -

Object oriented analysis and design

From Juneday education
Jump to: navigation, search

Staus of this page

This page is under construction. We are working on translating a Swedish workshop on designign and re-designing a game with a graphical user interface to English. The workshop is an introduction to object oriented analysis and design with UML and reasoning on what classes/objects should have what responsibilities, different perspectives on these responsibilities etc.

The cave game example

We'll work on an old Java assignment for a "cave game" (a version of the old game Colossal Cave) with a GUI and make a re-design of the assignment. We'll start with analysing the old assignment specification and see what flaws it has, and then we'll move on to a more object oriented design in three "sprints", each one getting us a step closer to a full implementation of the cave game.

The plan for this mini-assignment (or mini course) is:

  • We'll produce the Cave game in three "sprints":
    • Sprint 1 - Limitied "features" - Move around in the Cave, Pick stuff up and Drop things down
    • Sprint 2 - More "features" - Rules for if stuff can be picked up, refactoring of some classes, Exceptions
    • Sprint 3 - Even more "features" - Rules for certain special rooms

Introduction and Sprint 1

In this first sprint, we'll analyse an old specification for writing this game. As it turns out, this specification isn't perfect and we'll discuss what can be done better when writing a specification. We'll end up with a new specification for Sprint 1 with a limited set of features.

After this, we'll also discuss a UML for the classes we'll write during this first sprint.


Read the the old assignment specification

See the following video lectures:



  • Students implement the UML classes (with help of the Javadoc)

Sprint 2

We'll discuss Player movements between rooms, how to decide what class/object has what responsibilities, how to add rules for which things can be picked up etc.


See the following video lectures:

All videos in one channel:



  • Implement the Sprint 2 design according to the specification and UML

Sprint 3

In this sprint, we'll add rules for special rooms.


See the following video lectures:



  • Lecture: Analysis of sprint 2 - What was new, and what did we also have to change in the GUI
  • Lecture: What's next? - The Snake and Dragon rooms have special rules to them
  • Lecture: Producing UML for Sprint 3 - Room Rules
    • RuleBook - changes (storing and fetching also RoomRule:s, default rule for most rooms!)
    • Refactoring of Player and Room? - When to check for RoomRule:s?
    • New version of the Cave Initializer - Adding of RoomRule:s to the RuleBook
  • Sammanfattning vi sammanfattar analys och design från sprint 1-3

Föreläsningar och presentationer under dagen


  • Fix the rule for the Pirate Chest Room (250) so that when you win, it says "You Won!" and all doors close
    • Hint: When have you won? The objective is to be able to pick up the chest (requires all keys), but when have you won?
  • Fix the death rooms (see "analyzing the old specification"):
    • Set the description to "You are dead, game over, man!" and close all doors
  • Challenges:
    • Portals - make a room's exit transport you to the first room
    • Sounds - make the Bird sing - Perhaps louder and louder, the closer you are to it? (how to decide proximity?)
    • Play a triumphant sound when the chest is picked upp and the user wins
    • Play Chopin's death march when the player "dies"
    • Add a menu for saving and loading games - See Serializable - what is the game "state"? What classes/objects must be saved?