YCP Logo Assignment 5: Design

Due: Wednesday, March 16th by 11:59 PM

This is a team assignment


In this assignment you will refine the analysis model you created in Assignment 4 so that it is detailed enough to begin implementing the system. The resulting model is the design model.

You have three overall tasks.

Task 1 - Refine and validate the model

Starting with your analysis model, add method parameters and return types to each method in the model. Also add fields where doing so would help clarify how a class is implemented.

Your goal is to make the design model detailed enough that you can sketch detailed pseudo-code showing how a particular use case is carried out by the classes/objects in your model.

For example, here is a use case for a TicTacToe game (this is the same example which appeared in Assignment 2):

Player takes a turn

Actor: a human player

0. Precondition: it is the player's turn

1. The player chooses a location on the board in which to place a piece

1.1 If the location is already occupied by a piece, display error message and go back to step 1

2. System checks to see if the player has won the game, or if a draw has resulted

2.1 If a player has won, indicate which player

2.2 If a draw has occurred, inform players

Here is an analysis model for the TicTacToe game:


The analysis model is fairly detailed, and has assigned a number of methods to specific classes, but we have not specified parameters and return types for any methods.

Here is an elaborated version of the model that is closer to a design model:


Note that we have introduced a new class, Location, to represent a location on the board where a player can place a piece. This was necessary to flesh out the takeTurn method (in Player and subclasses) and the placePiece method (in Board).

We can use this updated model to sketch pseudo-code for our use case:

Player player = ...whichever Player is taking a turn...
Piece piece = ...whichever Piece is being played on this turn...

Board board = ...the Board...

boolean placed = false;
while ( !placed ) {
        Location loc = player.takeTurn(piece);

        // the placePiece() method will return false
        // if the Player chooses an invalid Location
        placed = board.placePiece(loc);

if ( board.isGameDone() ) {
        if ( board.isGameDraw() ) {
                ...inform user of draw...
        } else {
                ...current Player is the winner...

Even though the final implementation may implement this same logic in a different way, we have established that the classes and methods in the design model are capable of supporting the behavior described in the use case, which increases our confidence that we have a workable design.

Task 2 - Apply Design Principles

Your second task is to think about whether or not your design conforms to the design principles we have discussed in class. The design principles you should consider are:

The Open/Closed Principle (OCP)

The Liskov Substitution Principle (LSP)

The Single Responsibility Principle (SRP)

In the TicTacToe design above, we could argue that the design of the Player class supports the OCP in the sense that we should be able to add new kinds of Players (e.g., NetworkPlayer) without modifying clients of the Player class. However, we will probably need a PlayerFactory class to shield those clients of Player from knowledge of the various concrete Player subclasses.

Task 3 - User Interface

Your third task is to incorporate support for a user interface into your design model, assuming that the system you are designing has a user interface.

User interfaces, especially graphical user interfaces (GUIs) are an interesting challenge to design and implement. As we discuss OO Design we will discuss design patterns, such as Model-View-Controller (MVC) and Observer, which are useful for building GUIs. For now, you should consider the following two issues:

You will need a class to represent the "main window" of the GUI. You may need classes to represent other windows (or window regions.)

GUIs are event-driven, meaning that each user input even (clicking a button, choosing a menu item, etc.) are dispatched to event-handler methods. For this reason, GUI applications work by

waiting for an event to happen

when an event does happen, in the event handler method, updating the model objects to reflect the event

refreshing the views of the changed objects (how the information in the model objects is displayed)

For this assignment, I am not expecting a "perfect" design for your user interface. However, I do expect you to give it some significant thought, and to try to find a way to handle the event-driven nature of GUI applications.

Deliverables, Submitting

The deliverable is a zip file containing the following files:

  1. An Violet UML class diagram file (.class.violet) with your design model.
  2. A text document with the most important use case for your system, and detailed pseudo-code illustrating how your design model supports the behavior seen in the use case.
  3. A text document explaining your model. This text should discuss the following issues:
    • How the analysis model changed; did you introduce any new classes or methods? If so, why?
    • Does your design follow the three design principles (OCP, LSP, and SRP)? Cite specific classes and methods in your design as evidence.
    • How does your design support a user interface? If you are going to support a GUI, what happens when user input events arrive? Where in the model are your event handler methods?

Text documents must be in PDF format.

You can create a zip file using Windows by creating a folder, putting some files inside the folder, right-clicking on the folder, and choosing Send to->Compressed Folder.

Upload the zip file to the Marmoset server as assign5:


Only one team member needs to upload the zip file.