Download pdf - Waterfall Model – Software Life Cycle fileWaterfall Model – Software Life Cycle Apply recursively at all levels – from system level to subprogram. » At all stages the artifacts

02-1© Gunnar Gotshalks

DesignContext and Principles


Waterfall Model – Software Life Cycle

» At all stages the artifacts produced are documents> They may be formal – use mathematics and programming

languages

> They may be informal – use natural language

» At all times strive for correctness and precision

Needs analysis – requirements

Architectural design – framework

Detailed design – data, algorithms

Specification – input/output

Implementation – program text

Maintenance – corrections, evolution

Apply recursively at all levels – from system level to subprogram.Spiral model and evolutionary development are variations


What is Programming?

¥ Specifying what to to do and when to do it

¥ The what consists of the following

» At the assembler level the hardwired instructions> add, load, store, move, etc.

» At the Eiffel, C, Java level> assignment, arithmetic, read/write

> Subprogram library, API (Application Program Interface)

¥ The when consists of specifying in what order to do the "what" operations

» Control structures – these are the only ones> sequence > choice > loop

¥ What and when are intertwined – changing one often requires changes the other


What is Design?

¥ Design is the creation of a plan.

» Consider design as imposing constraints on the "when" and "what" of programming.

» From this perspective, the entire life cycle is comprised of design at various levels .

> Design bridges the span from requirements to implementation

¥ Design comes from the root to designate, to name

» In design one names objects and their relationships

» The difficult part is finding the "right" objects and the "right" relationships

» There must be a correspondence between specification and implementation.

> The objects and relationships in the specification must correspond to the objects and relationships in the implementation


Design within the Lifecycle

¥ Consider the constraints imposed in the software lifecycle

» Putting together a requirements document constrains what can be done from all possible programs to the set of programs corresponding to the requirements

» The specification formalizes the requirements and in the process adds more constraints.

» Architectural design adds constraints, and so on.

» Even implementation (programming) adds constraints by specifying in detail every when and what and so is a part of the design process.

¥ At each stage, there are fewer choices for what and when.

¥ At each stage the choices must be made within the constraints imposed by the earlier choices – or else backtracking to earlier stages is required


Seamlessness

Since design pervades the entire software lifecycle it is important that supporting methods should apply to the entire lifecycle, in a way that minimizes the gaps between successive activities

Corollary: Should be easy to move information among different notations formal – program text and mathematics <––> informal – documentation text <––> informal – diagrams

02-7©

Gunnar G

otshalks

Design for S

oftware Q

uality

¥W

orks»

Com

plete – Correct – U

sable

»E

fficient as it needs to be>

Speed up w

here necessary after instrumentation

¥R

eadable and understandable»

All D

esign artifacts – program text included – are prim

arily to be read and used by people.

»E

xecution is incidental

¥M

odifiable»

All program

s evolve over time

»M

ake plausible modifications easy

¥O

n Tim

e and on Budget

»T

ime is m

oney – pay back on investment

»Im

bedded systems – program

s are only a part of the system

02-8©

Gunnar G

otshalks

Principles of P

ublic Design

¥P

rinciple of Use

»P

rograms w

ill be used by people

¥P

rinciple of Misuse

»P

rograms w

ill be misused by people

¥P

rinciple of evolution

»P

rograms w

ill be changed by people

¥P

rinciple of migration

»P

rograms w

ill be moved to new

environments by people

Prim

ary purpose of design is to comm

unicatew

ith other people – even you are somebody

else in the future, so you must com

municate

with yourself

02-9©

Gunnar G

otshalks

¥C

orrectness

»W

orks correctly for all possible inputs that one might

encounter within a dom

ain of interest

»F

irst write correct program

s, then worry about efficiency!!!

>A

fast program that is w

rong is worse than useless

¥E

fficiency

»U

se an appropriate amount of resources for the task

>S

pace for storing data and temporary results

>E

xecution time

>S

pace – time tradeoff

>C

omm

unications bandwidth

¥E

ase of use – including installation

High Level D

esign Goals

02-10©

Gunnar G

otshalks

Implem

entation Goals

¥R

obustness

»W

orks correctly for defined inputs

»R

ecover gracefully from unexpected inputs

»R

ecover gracefully from hardw

are and algorithm errors

¥A

daptability

»M

odifiable

»U

se in unexpected ways

¥R

eusability

»U

se variations in different software products

>sam

e as ... except ...

»N

OT

just using>

A kettle is not reused w

hen boiling water. It is m

eant to boil water

on many different occasions

>R

euse -- kettle is used to bail a boat, m

aybe by bending it to fit the shape of the hull

02-11©

Gunnar G

otshalks

Structural D

esign Aspects

¥T

okenization»

What kinds of sym

bols are in the input and output

¥D

ata structures»

How

and what data structures should be selected

¥P

rogram structures

»H

ow should a program

be structured

¥P

rocedure partitioning»

How

should one decide when a set of operations be m

ade into a procedure

¥M

odule partitioning»

How

to decide what goes into a m

odule

¥C

orrespondence»

When do structures correspond

»W

hen to use comm

unicating sequential processes

02-12©

Gunnar G

otshalks

OO

Design P

rinciples

¥A

bstraction

»E

xtract fundamental parts

>D

escribe what is w

anted

»Ignore the inessential

>D

o not describe how to do it

¥E

ncapsulation – Information H

iding

»E

xpose only what the user needs to know

>T

he interface

»H

ide implem

entation details

¥M

odularity

»H

andle complexity using

divide and conquer

»M

inimize interaction betw

een parts

02-13©

Gunnar G

otshalks

OO

Design T

echniques – 1

¥C

lasses and Objects

»C

lasses define abstract data types

»O

bjects are instances

of those types

¥Interfaces and S

trong Typing

»Interface

gives the user what they need to know

to use objects from

a given class>

AP

I – Application

Program

Interface

»S

trong typing com

piler enforces objects are used correctly by type>

Do not take square root of a colour

¥Inheritance and P

olymorphism

»Inheritance

– single and

multiple

– provides for reuse

»P

olymorphism

invoke the proper method for an object

depending upon its type

02-14©

Gunnar G

otshalks

OO

Design T

echniques – 2

¥A

ssertions

»E

quip a class and its features with pre and post conditions,

and invariants

»U

se tools to produce documentation out of these assertions

»O

ptionally monitor them

at run time

¥Inform

ation hiding

»S

pecify what features are available to all clients, no clients or

specified clients

¥E

xception handling

»S

upport robustness with a m

echanism too recover from

unexpected abnorm

al situations

02-15©

Gunnar G

otshalks

OO

Design T

echniques – 3

¥G

enericity

»W

rite classes with form

al generic parameters representing

arbitrary types

¥C

onstrained genericity

»C

ombination arising from

genericity and inheritance to constrain form

al generic parameters to a specific type

¥redefinition of and deferred features

»R

euse requires the ability to modify an object for a new

environm

ent so features can be redefined

»S

ome design decisions m

ust be deferred so provide a means

to specify the interface of a feature without defining how

it does it.