Download
1 / 26
260 likes | 359 Views
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
E N D
Summaries of brainstorm tutorials lesterk.myweb.port.ac.uk/inse/storms
INSE - Lecture 7Design Introduction Strategy Tactics (1) - Reuse
Design - meeting the need This lecture - • objectives • strategy • re-use Next lecture - • modular structure • design notations - languages, diagrams, tools • verification of design
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.
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.
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... Weaknesses of 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.
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”. Tree-structured designs
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.
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 • reusablecode 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 by suitable 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?
