Putting together a complete system Chapter 10

Overview  Design a modest but complete system  A collection of objects work together to solve a problem  Overview over design and implementation process  See how the different steps of this process work  Case study: Simple Nim game  An Example as simple as practicable

Software Life Cycle: Overview  Problem Analysis  System Design  Implementation  Testing  Maintenance

Software Life Cycle: Overview (cont.)  Process is Iterative Incremental Compositional

Software Life Cycle  Problem Analysis  System Specification Document or Functional Specification Document  precisely describes what the system is intended to do (not how)  contract between customer and developer  Description of the product to be delivered  Initial version: incomplete and inconsistent  Requirements are not stable  Hitting a moving target  Several versions needed  Version control

Software Life Cycle (cont.)  System Design Phase  System Design Document  Design a collection of objects (classes) and their interactions  System Implementation Phase  Software Documentation  Constructing the software modules (classes)  Use Programming Languages and other development tools  Actual "Coding" or "Programming"  Test Phase  Test plans & performing the tests

Software Life Cycle (cont.) Features of this process:  Iterative & Incremental  Tests uncover errors which must be corrected  Design changes influence all other documents  Again: Version Control  Compositional  Compose a whole by simpler parts  Apply this cycle to the parts separately  System Maintenance  During the whole lifetime of the system

Fundamental Subsystems  Most Software Systems consist of the following fundamental subsystems: User Interface gets course preferences displays schedules Model represents students, etc. checks prerequisites adds/modifies students, etc. Data Management maintains external data, e.g., transcripts Example: Student Registration System  external interface, user interface  model  data management

Case Study: Simple Nim Game  Two players  Pile of Sticks  In one play a player can  remove one stick OR  remove two sticks OR  remove three sticks  The player who removes the last stick loses.  The user can play several games and choose the number of sticks to start with

Steps of the Design Process of Nim Game Example  System Functionality  Preliminary Design  Basic Subsystems  Identifying Objects  Determining responsibilities  Relations between Objects  Integrating User Interface and Model  Object Specification  Implementation  Top Level  Model  User Interface

Basic Function and System Functionality  Basic Function:  Play a number of games of "Simple Nim", reporting the results to the user.  System Functionality:  Allow the user to specify the number of sticks the pile contains at the start of the game  For each player in turn, determine what play to make (number of sticks to remove) and make the play  Display the state of the game number of sticks taken number of sticks left whether game over, and who wins  Allow the user to choose to play another game

Preliminary Design: Basic Subsystems  Need a user interface  Need a model of the nim game  No need for a data management system (no permanent data to maintain)  In the Basic Functionality description only What not How  e.g., User interface:  Input with keyboard, mouse,...?  How to deal with incorrect input?  How to display results?  Separate user interface allows easy changes without touching the model

Preliminary Design: Identifying Objects  Non-trivial iterative process with many options  Needs experience  What we really do: specify classes (not objects)  Objects are created dynamically after start-up  Different kinds of classes:  some classes are directly derivable from the things we want to model (e.g., student)  architectural classes: define relationships between system components support maintainability efficiency  classes for algorithmic implementation: well-known classes

Preliminary Design for Simple Nim  Initial class collection can be derived from required system functionality  Responsibilities and relationships lead to other classes  Postpone user interface for the moment  Model classes  Player  Pile of sticks  NOT Sticks individually (too simple, but if we had playing cards, we would design a class Card)  Somebody must be responsible to "glue" these elements together: GameManager -- Knows the rules of the game

 GameManager  Manages Pile (aggregate relationship)  Manages Players (component relationship) Relations

 Player  Plays with Pile (client/server relationship) Relations (cont.)

Relations: Model Interactions PilePlayer GameManager Nim Game Model

Model Interaction (cont.) player2:

Integrating User Interface and Model  Principle: The Model should be independent of the User Interface  On the other hand: The User Interface depends on the model  It should be possible to build different UIs while preserving the model  Client/Server pattern:  Server knows little about clients  Client must know about server  Consequence: We choose  the Model as the Server  the User Interface as a Client

Components of the User Interface  The User Interface has two principal components:  Display Data  Input Data  Displaying data consists of providing a View of the Model to the user  Input data consists of providing a means of Control of the Model to the user  In a system with Graphical User Interface (GUI), the control is event-driven  Mouse clicks  Keystrokes  Event driven approach is too difficult for the moment (wait until CSCI 2120)

Dilemma in the UI – Model Interaction  Let us focus on the display function for the moment  The User Interface must display some aspect of the state of the Model  The UI queries the Model as soon as the Model's state changes  Problem: How does the UI know when the model changes??  Periodical queries: not efficient  Model tells UI when it changes: negates independence of Model from UI  Solution: the UI is an Observer of the Model  The Model is the target of this observation

Observer - Target Relations

Observer - Target Interactions

Class Pile: Responsibilities public int size() {…} public void remove( int number ) {…}

Class Pile: Implementation  uses ooj.utilities.Require class to effect validation of preconditions Pile.java

Class Player: Responsibilities public void makeMove( Pile pile ) {…} public String name() {…} public int numberTaken () {…}

Class Player: Implementation  uses ooj.utilities.Require class to effect validation of preconditions Player.java  uses Pile object

Class GameManager: Responsibilities public void play() {…}public Player nextPlayer () {…} public boolean gameOver () {…} public int sticksLeft() {…}

Class GameManager: Implementation  uses ooj.utilities.Require class to effect validation of preconditions GameManager.java  uses Pile and Player objects as servers  collaborates with NimUI object as observer

Class UserInterface: Responsibilities public void update( GameManager target ) {…} public void start() {…} GameManager

Class UserInterface: Implementation  use OOJ.basicIO classes to effect text- based input/output  OOJ.basicIO.BasicFileReader provides methods for input OOJ.basicIO.BasicFileReader  OOJ.basicIO.BasicFileWriter provides methods for output OOJ.basicIO.BasicFileWriter

Class UserInterface: Implementation NimUI.java