COMP2110 Software Design in 2005 Design lecture 6 lecture 1 of 6 on Design

1
COMP2110 Software Design in 2005 Design
lecture 6 - lecture 1 of 6 on Design

• Software Surgery the video
• What is software design?
• Introduction to doing design by an example
  Tetris

2
Comp2110 course components

• core content
• methods for designing software for a given
  purpose
• technical "design ideas" to use
• at high level
• at detailed level
• specifications of requirements for software
• supporting concepts
• notational methods for describing software design
• notations for specification of requirements
• software lifecycle framework
• "quality" what makes it a good design (or not)

3
The Waterfall Software Process Analysis phase
time
4
The Waterfall Software Process Design phase
time
5
Specification and design in software

• The difference between specification and design
  for software is not clearly marked because we use
  some of the same descriptive tools for
  both,especially in object-oriented analysis and
  design.

6
Software Design is? (1) product

• A software design document describesa program's
  structure and componentsin enough detailso that
  a program coder can easily create a program from
  the design document
• modular structure of the software system
• a high level architecture, and groups of classes,
  packages, libraries
• module relationships inheritance and uses
• using class diagrams, sequence diagrams
• module interfaces
• methods, features, attributes, pre- and
  post-condition contracts
• module internals
• algorithms and data structures

7
Software design is? (2) processes

• "Design" resists automated support.It is a
  human-focussed, creative activity.
• Design as a topic is an onion it is
• experiential (you have to do it)
• mathematical
• cognitive
• social
• Robert L. Glass, On Design, IEEE Software,
  March/April 1999, pp 104-103

8
WARNING!

• what follows is not an example of the design
  process
• it is a very fast overview of some of the parts
  of a simplified design document
• the Tetris design document in the notes is also
  only a partial exmple

9
Tetris the game (1)
shot 1
10
Tetris the game (2)
11
analysis and design for Tetris

• a starting point
• try following a generic model of simple games
• playing pieces
• playing board
• rules/games control

12
Example Tetris game - specification(1)

• The purpose of the Tetris software system is to
  allow a user to play games of Tetris.
• A. Tiled Display Board
• 1. The game is played on a board which is a
  rectangle of square cells.
• 2. A cell may be empty (shown as black) or
  occupied by a tile (shown as a colour).
• 3. Only one tile can occupy a cell at a time.
• 4. Each cell is initially empty.
• B. Game Control and Scoring
• 5. The player shall select the size of the
  playing board at the start of a game as a number
  of rows, and number of columns.
• 6. The player shall be able to select a relative
  speed setting at the start of each game fast,
  medium, or slow.
• 7. The game shall start with a new active brick
  (with random shape, entering the playing board at
  the top row see specs 19 and 23)
• 8. The active brick will move downwards ("fall")
  until it lands.
• ..... total of 26 requirements statements...

13
The Design Process

• the key insight
• bricks change
• There is only one active (moving) brick at any
  one time, and once a brick has landed it never
  moves again. While a brick is moving it retains
  all of its constituent tiles, but once it has
  landed, the coloured squares its tiles then
  occupy may disappear in rows - not in whole
  bricks.
• This point of view gives us three rather than two
  domain classes, as well as the game control
• bricks (playing pieces), playing board, display
  board, game controller

14
Parts of an Object-Oriented Design Document

• high level design, or architecture - a
  decomposition into modules packages and classes
• detailed design
• classes and their relationships
• interfaces of classes and methods
• internal description of each class and method

15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
Design 2.2. Interfaces

• the interfaces are best described relatively
  formally (e.g. programming language-like)
• all visible (exported) features or methods
  names, parameters, signatures,possibly pre- and
  post-conditions
• must include a black-box description of the
  module - what the module does - not how.
• just enough information to use the module in the
  program and nothing more(this is also a property
  of Design by Contract)

19
Design 2.2. Interfaces part class Brick

• / Make a Tetris brick of specified shape that
  shape's colourplaced at column Xpos on the
  nominated playing field /
• void createBrick(playingBoard field, int Xpos,
  char shape)
• / Rotate brick left (counter clockwise) /
• void rotateLeft() / similarly rotateRight /
• / Move the brick one column to the left /
• void moveLeft() / similarly moveRight /

20
Design 2.3. Module internals

• explains the intent/requirement of the module/
  feature/method to the programmer (implementer)
• describes algorithms and data structures
• states effect of each function on data structures
  
• states any side effects as well as pre- and
  post-conditions of the contract, invariants
• states any exceptions raised or handled
• has a "verification" argument that the module's
  properties are sufficient to satisfy the
  specification
• typically uses pseudocode for anything more than
  simple operations

21
Internals pseudocode for gameControl

• while not field.isFull() do
• brick.createBrick (field, randomPosition(),
  randomShape())
• while not brick.hasLanded() do
• delayAndHandleInputs(responseDelay)
• if not brick.hasLanded() then
  brick.moveDown()
• end
• end
• / the brick has landed /
• increment runningScore report runningScore
• field.removeFilledRows()
• end
• / game has finished /
• finalReport runningScore waitForResponse
• exit.

22
The Design Document wrong and right

• What can go wrong
• document is badly organized avoid stream of
  consciousness, stream of execution
• wrong notation/technology is used (use tables,
  diagrams, figures, formulae, code))
• design is inconsistent, imprecise, incomplete...
• How to do it properly
• design the form of the documents! (and
  redesign...)
• allocate sections of document one-to-one to
  aspects of the design
• rewrite, inspect, review two or more times