Object oriented analysis and design
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:
- Video collection - a lot of videos - see below for PDFs: Cave Game - Sprint 1
- Cave - Sprint 1 - Analyzing the old specification I (sid 1-7 i pdf)
- Cave - Sprint 1 - Analyzing the old specification II (sid 7-13 i pdf)
- Cave - Sprint 1 - Analyzing the old specification III (sid 13-24 i pdf)
- Cave - Sprint 1 - Analyzing the old specification IV (sid 24-30 i pdf)
- Cave - Sprint 1 - Analyzing the old specification V (sid 31-41 i pdf)
- Java Cave Game - Sprint 1 - Designing 1
- Java Cave Game - Sprint 1 - Designing 2
- Java Cave Game - Sprint 1 - Designing 3
- Java Cave Game - Sprint 1 - Designing 4
- Java Cave Game - Sprint 1 - Designing 5
- Java Cave Game - Sprint 1 - UML 1
- Java Cave Game - Sprint 1 - UML 2
- Lecture: Analysing the old specification (PDF)
- Lecture: Re-interpretation of the old specification and Javadoc for the new classes
- Hand-out - Sprint 1 - Specification - limited features of the game
- Lecture: Designing the Sprint 1 version and UML (PDF)
- Lecture: Sprint 1 UML - Walk-through - a tiny introduction to UML(TM)
- Students implement the UML classes (with help of the Javadoc)
- Resource: javadoc and UML for Sprint 1.
- Resource: - PNG with the UML: UML for Sprint 1 classes
- Resource: - Some classes we have written for you: (CaveInitializer and Things) and some GUI code (MainGui, MainFrame etc)
- Download from https://github.com/progund/cave-sprint-1
- You need to write the classes (by looking at the UML and Javadoc): Player and Room (Thing is given to you)
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:
- Java Cave Game - Sprint 2 - Player movements 1
- Java Cave Game - Sprint 2 - Player movements 2
- Cave Game - Sprint 2 - Determining responsibilities 1
- Cave Game - Sprint 2 - Determining responsibilities 2
- Java Cave Game - Sprint 2 - Implementing Rules 1 (pdf pages: 1-8)
- Java Cave Game - Sprint 2 - Implementing Rules 2 (pdf pages: 9-15)
- Java Cave Game - Sprint 2 - Implementing Rules 3 (pdf pages: 15-17)
- Java Cave Game - Sprint 2 - Implementing Rules 4 (pdf pages: 18-22)
- Java Cave Game - Sprint 2 - Implementing Rules 5 (pdf pages: 23-26)
- Java Cave Game - Sprint 2 - Implementing Rules 6 (pdf pages: 27-30)
- Java Cave Game - Sprint 2 - Implementing Rules 7 (pdf pages: 31-35)
All videos in one channel:
- Java - Cave Game Sprint 2 (Vimeo channel, English)
- Lecture: Analysing Sprint 1 (we'll talk about your solution and a proposed solution)
- Proposed solution to Sprint one - starting point for Sprint 2 - if you didn't make it in time: github (includes working implementations of Room/Player/Thing etc)
- Lecture: How to move on with Sprint 2
- Lecture: Should the Player be allowed to move in a direction where there is no Room? About the Player movements
- Up until now, we've settled with throwing a RuntimeException when this happens (IllegalArgumentException)
- What if the GUI teams ignores this (catch and forget)?
- How can we force the GUI team to care about this case?
- Lecture: Rules for picking things up Implementing Rules for Thing:s
- What is a Rule for a Thing, really?
- Where do we store the Rules?
- How are rules usually stored in a board game (and in real life)?
- Lecture: Who should have the responsibility for what behavior(methods)? Determining responsibilities
- Should the GUI know about the Room class?
- Also: OO-principle - Law of Demeter
- Lecture: We have arrived in a Specification for Sprint 2 Sprint 2 Specification
- UML for
- Illegal movements https://github.com/progund/cave-sprint-2/blob/master/uml/Player_and_Exception_example.png
- New responsibilities - New methods in Player - We'll have to change the GUI too, since Player has been changed
- Implement the Sprint 2 design according to the specification and UML
In this sprint, we'll add rules for special rooms.
See the following video lectures:
- Java Cave Game - Sprint 3 - RoomRule 1
- Java Cave Game - Sprint 3 - RoomRule 2
- Java Cave Game - Sprint 3 - RoomRule 3
- Java Cave Game - Sprint 3 - RoomRule 4
- Java Cave Game - Sprint 3 - RoomRule 5
- Java Cave Game - Sprint 3 - Design RoomRule 1
- Java Cave Game - Sprint 3 - Design RoomRule 2
- Java Cave Game - Sprint 3 - Design RoomRule 3
- Java Cave Game - Sprint 3 - Design RoomRule 4
- Read on Oracle - Abstract classes - Tutorial at Oracle - Abstract classes
- 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
- Hand-out: Sprint 3 Specification
- Föreläsning: Snakes and Dragons - Room rules
- Föreläsning: Designing the RoomRule class
- Hand-out: UML for Sprint 3
- Hand-out: Skeleton code för RoomRule and RuleBook (för dem som inte vill skriva helt själva)
- Hand-out: A working version for Sprint 2
- Hand-out: CaveInitializer for Sprint 3 - adds RoomRule:s to the RuleBook, so the RuleBook have better be modified ;-)
- Hand-out: A working GUI (för dem som inte vill skriva själva)
- 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
- 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?