Click here to load reader
Upload
vokiet
View
212
Download
0
Embed Size (px)
Citation preview
02-1© Gunnar Gotshalks
DesignContext and Principles
02-2© Gunnar Gotshalks
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
02-3© Gunnar Gotshalks
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
02-4© Gunnar Gotshalks
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
02-5© Gunnar Gotshalks
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
02-6© Gunnar Gotshalks
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.