Chapter 9 Putting together a complete system

This chapter discusses n Designing a complete system. n Overview of the design and implementation process. n Example of a simple game called “nim.”

Steps in system development n problem analysis: a thorough examination of the problem to be solved. n functional specifications: a precise description of what the system is intended to do. u A contract between the user and the developer.

Steps in system development (cont.) n design phase: defining a collection of classes and their interactions to satisfy the specifications. n implementation: constructing the software modules that make up the system. n testing: ensuring that the modules conform to the specifications.

The system development process is n Iterative and incremental u Inadequacies often are found. u Testing uncovers design and implementation flaws. u Test plans must be updated continually as the process proceeds. n Compositional u The system is composed of simpler pieces (objects, algorithms). n Evolving u The problem a system is designed to solve inevitably changes over time, requiring system maintenance.

Fundamental subsystems n A typical system consists of three fundamental subsystems: u Interface u Model u Data management

External Interface n A system must communicate with the external world. n It is generally desirable to isolate these functions into a collection of objects called the external interface or user interface. u It obtains and verifies input. u It formats and presents output.

User interface:

Data management n Many systems must manage some external data. n Example: a bank must keep customer account and transaction records even when the bank is closed. n persistent data: data maintained externally and independently of what the system is doing, and which continues to exists. n The part of the system responsible for storing and retrieving persistent data is the data management subsystem.

Model n The components that actually solve particular problems.

Subsystems n Student registration example

The “nim” system n Two players and a pile of sticks. n Each player in turn removes 1, 2, or 3 sticks from the pile. n The player who removes the last stick loses.

System functionality n Play a number of games of “simple nim,” reporting the results to the user. u Allow the user to specify the number of sticks the pile contains at the start of the game. u For each player in turn, determine the number of sticks to remove and make the play. u Display the state of the game after each play. u Allow the user to determine whether another game is to be played.

Preliminary design n There are many possible approaches and rarely one “best” solution for any non-trivial problem. n The task of the designer is to explore the “solution space” for the problem, and evaluate alternatives. n With our implementation, we will aim for simplicity.

Basic subsystems n User interface - how the user interacts with the system. n Model to play the game. n No data management is required.

Identifying objects n Design involves defining a collection of objects and their interactions to satisfy the specifications. n Specify classes u some derived from the external system. u “architectural” classes that form the underlying structure of the solution. u “implementation” classes to support the algorithmic implementation of the system.

Identifying objects (cont.) n An initial collection of potential problem- modeling classes can be developed by carefully examining the required system functionality. n Other potential classes, architectural classes, and organizational approaches will suggest themselves as responsibilities are allocated to these classes and relationships between them are identified.

Identifying objects (cont.) n In the “nim” example, we will use a Player class (2 player objects), and a PileOfSticks class. The sticks individually don’t have much meaning. n We will also include a GameManager class that will keep track of things such as whose turn it is.

Determining responsibilities n Pile: u Know how many sticks remain u Remove sticks. n Player: u Know its name. u Remove a certain number of sticks. u Know how many sticks it took on its last turn.

Determining responsibilities (cont.) n GameManager: u Know Players and Pile. u Know whose turn it is. u Know when the game is over. u Know who the winner is. u Know how many stick can be taken per turn.

Collaborators n The Pile is a complete server-- it requires no other objects to satisfy its responsibilities. n The Player needs the Pile in order to move.

Relations between objects

Relations between objects (cont.)

The user interface n The user interface is a mechanism for viewing and controlling the solution process. n It generally is preferable for the model to be as independent of the user interface as possible. n The interface is usually one of the least stable parts of the system, and often among the last to be finalized in system design. n We will design our user interface as a client of the model. The user interface queries the model for information and commands as directed by the user.

Event-driven system n The system responds to “events” that occur external to the system; in our case they will be user actions.

Observer n The user interface must know when the model changes states. u The observer tells the target, “I need to know when you change state.” u Whenever the target changes state, it informs the observer “I’ve changed state.” u The observer then queries the target for any detailed information it needs.

Observer (cont.) To implement the relation, the target provides a method ( register ) for the observer to use to identify itself to the target, and the observer has a method ( update ) that the target calls to inform the observer of a state change.

Client invokes Target. change ; Target invokes Observer. update ; Observer. update ; Target. queryState completes and returns control to Observer; Observer. update completes and returns control to Target; Target. change completes and returns control to Client.

Pile specifications public Pile (int number) Create a Pile with the specified number of sticks. require: number >=0 ensure:this. size() == number public Pile () Create an empty Pile. ensure:this. size() == 0 public int size () Number of sticks in this Pile ensure:this. size() >= 0

Pile specifications (cont.) public void setSize (int number) Set the number of sticks in this Pile require: number >= 0 ensure:this. size() == number public void remove (int number) Remove the specified number of sticks from this Pile. If the specified number is more than the Pile size, remove all the sticks. require: number >=0 ensure: this. size() == max (0, old. size() - number )

Player Specifications public Player (String name) Create a new Player with the specified name. require: name != null ensure:this. name() == name public String name () This Player’s name.

Player Specifications (cont.) public void setName (String name) Change this Player’s name. require: name != null ensure:this. name() == name public int numberTaken () Number of sticks taken on this Player’s most recent turn. ensure:4 > this.numberTaken() >= 0 if Player has not yet had a turn, this. numberTaken == 0

Player Specifications (cont.) public void makeMove (Pile pile, int maximum) Make a move: remove up to specified maximum number of sticks from the specified Pile. require: pile != null 4 > maximum > 0

GameManager specifications public GameManager (Player player1, Player player2) Create a nim GameManager, with the specified players; by default, the first Player specified plays first in the first game. require: player1 != null player2 != null public int sticksLeft () The number of sticks in the Pile. ensure:this. sticksLeft() >= 0

GameManager specifications (cont.) public int sticksTaken () The number of sticks taken on the last play. ensure:this. sticksTaken() >= 0 public Player nextPlayer () The Player whose turn is next. public Player previousPlayer () The Player who last played; returns null if no play has been made yet.

GameManager specifications (cont.) public boolean gameOver() The game is over. public Player winner () The winning Player; returns null if the game is not over. ensure:if this.gameOver() this. winner() != this. previousPlayer()

GameManager specifications (cont.) public void setPileSize (int number) Set the number of sticks in the pile. require: number >= 0 ensure:this. sticksLeft() == number public void setNextPlayer (Player player) Set which Player takes the next turn. require: player == one of the Players provided as constructor arguments. ensure:this. nextPlayer() == player

GameManager specifications (cont.) public void register (NimUI observer) Register a user interface; user interface will be notified of GameManager state changes. require: observer != null public void play () Play a game of simple nim.

UserInterface specifications public NimUI (GameManager theGame) Create a new user interface for the specified GameManager. require: theGame != null public void update (GameManager target) Notify this user interface of a state change in the specified GameManager. require: target != null public void start () Start the interface.

Top level public class NimGame { public static void main (String[] args) { GameManager theGame = new GameManager (new Player(“Player 1”), new Player(“Player 2”)); NimUI theInterface = new NimUI (theGame); theInterface.start(); }

We’ve covered n How to put together a complete, simple system. u problem analysis u specification u design u implementation u testing u maintenance n Three basic subsystems : u interface u model u data management

We’ve covered (cont.) n Designing and implementing a simple “nim” game. u Identifying classes u assigning responsibilities u determining fundamental relationships u writing detailed specifications u integration of the user interface with the model n The observes relation.

Glossary

Glossary (cont.)