Putting together a complete system Chapter 10. Overview Design a modest but complete system A...
-
Upload
alan-bennett -
Category
Documents
-
view
214 -
download
0
Transcript of Putting together a complete system Chapter 10. Overview Design a modest but complete system A...
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