Presentation is loading. Please wait.

Presentation is loading. Please wait.

Summaries of brainstorm tutorials

Similar presentations

Presentation on theme: "Summaries of brainstorm tutorials"— Presentation transcript:

1 Summaries of brainstorm tutorials

2 INSE - Lecture 7 Design  Introduction  Strategy  Tactics (1) - Reuse

3 Only 1.4 litres of brain...

4 Design - meeting the need This lecture -  objectives  strategy  re-use Next lecture -  modular structure  design notations - languages, diagrams, tools  verification of design

5 Antoine de St Expeury

6 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

7 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 ??

8 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).

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

10 [Drawing the flow diagram … ]

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

12 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).

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

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

15 “ 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.

16 R é n é D é scartes - top-down maths and philosophy in 1635.

17 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 ”.

18 Design strategy - conclusion So  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.

19 Design strategy - decide! u The project manager has a decision to make!

20 Tactics (1)  Reuse of components

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

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

23 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 by suitable contract wording

24 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?


26 T J Watson Snr was the founder of IBM

Download ppt "Summaries of brainstorm tutorials"

Similar presentations

Ads by Google