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 takennumber of sticks leftwhether 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 componentssupport maintainabilityefficiency

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

Pile Player

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