Summaries of brainstorm tutorials

lesterk.myweb.port.ac.uk/inse/storms

INSE - Lecture 7

Design

Introduction Strategy Tactics (1) - Reuse

Only 1.4 litres of brain...

Design - meeting the need

This lecture - objectives strategy re-use

Next lecture - modular structure design notations - languages, diagrams, tools verification of design

Antoine de St Expeury

Expeury’s philosophy of design

Good design has been achieved not when there is nothing left to add, but when there is nothing more to take away.

translated by Kit Lester

Objectives of design The specification document is (ideally) a

statement of what the system will achieve, not how it is achieved;

consequently one can seldom code directly from the code; so

design “fills the gap”– key decisions about the principles of “how”;– usually goes through a number of increasingly

detailed stages. ?? The most creative/innovative stage of the

lifecycle ??

The finished design...

… should be correct and complete; understandable (at the “right” level of

detail and no more!); maintainable in itself; actively helpful when maintaining the

code (not just helpful when initially writing the code).

The “obvious” strategy At first, design was “drawing the flow diagram” - there was no discipline on the order of design

decisions, but usually it came out as– design the introductory code, then– design the main code, then– design the concluding code;

that overlooks any decisions about design of data;

detailed decisions were often made early, biasing later large-scale decisions.

[Drawing the flow diagram…]

Low level of flow diagrams In practice, flow diagrams were often too detailed:

– they are at “too low a level” for design;– they “start at the start” – not good when designing

complexity;– they are poor at supporting maintenance, because a

maintained flowchart often becomes a confusing jumble.

So they have fallen into dis-use in the design of large complex systems

But they remain useful for after-the-fact documentation of small pieces of code.

After flow diagrams

SO: Later systems are “higher level” than

flow diagrams; Later systems are also better for

expressing multiple stages of design (whereas flow diagrams usually only express the final stage of design).

Subroutine-driven strategy

The invention of “subroutines” led to a different strategy:

You’d have a library of subroutines; You’d put sequences of subroutine-calls

together to form larger components; You’d put sequences of calls to those

together… … and so on until you had the final program.This is bottom-up design.

Weaknesses of bottom-up

Lashing components together often leads to something not quite what you wanted...

fixing it would require modified components; modifying a component implies changes to sub-

components, sub-sub-components… this discourages you from coding too soon: but the natural way to test is bottom-up...

“Black box” strategy

So in the late ‘60s, people tried the exact opposite to bottom-up:

View the whole spec as a “black box”; Design how it should work in terms of next-

level components: write a spec for each of those components;

Repeat until the components are each simple enough to code directly.

This is top-down design.

Réné Déscartes- top-downmaths andphilosophy in 1635.

Tree-structured designs

With either bottom-up or top-down– you wind up with a tree of components,– the “root” representing the spec of the “main”

program component;– each subordinate representing a sub-component

of a superior component.

But with bottom-up the tree is likely to be “cross-linked”.

Design strategy - conclusionSo top-down tends to lead to not-quite-identical

components (i.e. poor reuse - expensive! & extra maintenance to be done…)

it is hard to test top-down (i.e. hard to test a component before it’s sub-components have been coded & tested);

bottom-up tends to lead to mis-fit with the spec.One solution: top-down near the top of the

pyramid, bottom-up/reuse in the bottom layers.

Design strategy - decide!

The project manager has a decision to make!

Tactics (1)

Reuse of components

Reuse - Introduction In the past – a lot of near-duplication of

designed components of programs therefore a lot of duplication of resulting

code, testing, debugging…– expensive!!– hard to maintain!!

Increasingly: large software producers try to maintain libraries of

– reusable code and– documentation of the detailed designs.

Technical consequences

new designs are worth doing to be more generally applicable (i.e. “generic”) in order to be more reusable in other contexts in the future in the same software & also in future software;

designs need to be better documented; tests need to be more generic as well – but

then only need doing once for many reuses.

Not-so-technical consequences How do we locate an appropriate

component in a big library?

if something was written as part of software for one customer, is it legal (or ethical) to reuse it in software for other customers?

- increasingly, that’s handled bysuitable contract wording

After this lecture review what strategy you actually used

in your past programming efforts – flow-diagram?– bottom-up?– top-down?– some hybrid?– chaos?

could you have reused more?

T J Watson Snr was the founder of IBM