anu comp2110 software designlec 06: design part 1 1/26 comp2110 software design in 2004 design...

ANU COMP2110 Software Design lec 06: Design part 1 1/26

COMP2110 Software Design in 2004 Design

lecture 6 - lecture 1 of 6 on Design

1. What is software design?2. Introduction to doing design by example:

Tetris


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)


Implementation

The Waterfall Software Process – Analysis phase

time

RequirementsAnalysis

Design

Phases (activities)Testing

Maintenance

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Processes-gathering requirements-verifying requirements

Product a SRS document describing information models

Software

Requirements

Specification

Retirement


The Waterfall Software Process – Design phase

time

RequirementsAnalysis

Design

Phases (activities)Testing

Maintenance

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

ProductSDD describing modules, classes, interfaces, algorithms, data structures:as text and diagrams

SoftwareDesignDocument

Retirement

Processes - decide high-level architecture

- do detailed design

- reviews

Implementation


Example: The dog house 1. requirements1 keep the dog alive in freezing Canberra winter or

dry and cool in Brisbane

2 provide satisfactory (to owner) level of dog happiness

3 anchor the dog to the home base -to provide security and visitor announcement services

4 have good enough appearance to satisfy owner’s family, and increase or maintain house property value

5 be easy for the owner to keep clean, remove fleas etc

6 be “right size” for the number and size of dogs

7 be maintainable: materials should need attention no more than once in 3 years in the intended location

8 be at least 900mm long, 500mm wide, 600mm high at the door and no lower internally


The dog house: design (1)The kennel shall be

● built from wood planks 1 cm thick and 5mm craftwood [requirement 1 and 7]

● have two rectangular side walls, floor, pitched roof, solid back wall, arch-opening front wall [req 1 and 4]

side 1

side 2

floorfront

backscale 1:10

craftwood

plank wood


The dog house: design (2)The front: - cut-out for dog entry and exit (size: X wide x Y1 cm

high, max width to height Y2 cm)

The roof:attached to front back, sides by

clips, so it is removable foreasy cleaning

solid 5mm craftwood in two pieces,overlapped at top – see detail fig 3.

Attachments and fastenings: - blah blah blah...


Specification vs Design in Software

– conceptual, abstract

– applicable to several designs

– less formal– less expensive to do– outlines the design

– few layers– relatively unconstrained

– concrete, an implementation blueprint

– specific to a particular implementation

– more formal– ~5 times as expensive– manifests the design in

detail– many layers– constrained by analysis

and target

Analysis Design


Software Design is: (1)

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


Software design is? (2)

● "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]


Example Tetris game - specification(1)

The purpose of the software system is to allow a user to play games of Tetris.

1. The game is played on a board. The board is a rectangle of square cells. A cell may be empty (shown as black) or occupied by a tile (shown as a colour). Only one tile can occupy a cell at a time: tiles cannot overlap, nor cover each other. Each cell is initially empty

2. 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.

3. At all times during the game exactly one brick will be active.4. At the start of the game and when the active brick has come to a

stop, the next active brick is a shape chosen at random.5. The shape of a brick is one of the five standard Tetris brick

shapes [ Square, ell ('L'), tee ('T'), ess ('S') Zed ('Z') etc. etc.


Tetris – the game (1)

shot 1


Tetris – the game (2)


Design (1) Module structure

One way to describe the program's module structure is called a "module guide"

● defines the name for each module andthe design responsibility for a moduleby stating thedesign decisions/ areas of design responsibility that will be found within it(not the functional responsibility)


Design (1) – module structure (2)

The module guide describes a decomposition of the solution

● decompose the solution into modules,each module may consist of submodules

● the document should reflect a tree structure,dividing the system into a small number of modulesand treating each module in the same wayuntil all modules are "quite small"

Note:– we also call this the system architecture or high-level design

There are other ways to choose and describe the architecture


Design (1) Module structure/architecture

Describing the architecture:● The system is event driven in a computational loop that generates and drives a series of falling bricks in soft real time,using interrupt events to process user command keystrokes.

The system includes a reusable generic playing field for games with coloured tiles.

The system design requires a generic GUI library.


Tetris module guide


Tetris module guide

Each modules is described in the guide:

abstract module Field

* hides the representation of the field of tiles; * specifies the representation of an empty tile; * provides algorithms to determine whether a field is filled to the top by Tetris rules, and to delete any fully-occupied rows; * provides facilities to change the colour of individual tiles, to report on the colour of any tile, to delete any filled rows * consists of modules PlayingField and TetrisField.


Design 2. Module relationships

● the relationships include– inheritance– use (aggregation, association – and navigation)– data flows between modules– control sequences between modules


Module relationships

uses relationships... between modules ...between classes


Class relationships – control sequence


Design 3. Interfaces

● the module interfaces must be relatively formal (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)


Class relationships and interfaces


Design 3. Interfaces – class Brick

/** Make a Tetris brick of specified shape & that shape's colourplaced at column Xpos on the nominated playing field */

createBrick(PlayingField field, int Xpos, int shape)

/** Rotate brick left (counter clockwise) */ void rotateLeft() /* similarly rotateRight */

/** Move the brick one column to the left */ void moveLeft() /* similarly moveRight */


Design 4. Module internals● explains the intent/requirement of the module/

feature/method to the programmer (implementer)● describes algorithm 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– 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


Internals – pseudocode main loop Tetrisrun:while not field.isFull() do brick.createBrick (randomPosition(), randomShape()); while not brick.hasLanded() do delayAndHandleInputs(DELAY); if not brick.hasLanded() then brick.moveDown(); end; end; /* the brick has landed */ field.removeFilledRows(); runningScore += 1;end; /* game has finished */report runningScore;exit.


The Design Document – right and wrongWhat 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))

– inconsistent, imprecise, incomplete...

How to do it properly– design the documents! (and redesign...)– allocate sections of doc. to aspects of the design one

to one– rewrite, review twice or more

anu comp2110 software designlec 06: design part 1 1/26 comp2110 software design in 2004 design...

Documents