1. Design Constraints By: Tuan Ha Cohort: MCIS 21 Class: MISS 470

2. The Second-System Effect Self Discipline The architect’s first work is spare and clean  Cautious  Grand ideas set aside

3. The Second-System is dangerous 3 rd systems and later versions generally confirm each other 2 nd system tends to be over-designed Grand ideas are attempted ie: IBM 709 architecture was a second system of 704. only half features were regularly used

4. How the programmer avoids the 2 nd System Effect Be aware of the hazards Avoid functional ornamentation Make sure functions are purposeful Assign each little function a value - capability x is not worth more than m bytes and n microseconds

5. How the project manager avoids the 2 nd System Effect Senior Programmer with not less than 2 systems under his belt Ask the right questions during development

6. Chapter 13 The Whole and the Parts  Designing the bugs out  Component Debugging  System Debugging

7. Designing the bugs out Bug proof the definition  Conceptual integrity Easy to use Easier to build Less subject to bugs  Careful function definition, careful specification, and avoiding frills of function all reduce the number of system bugs found

8. Designing the bugs out (cont) Testing the specification  Spec must be handed to an outside testing group Top-down design  Niklaus Wirth (1971)  Sketch out rough task definition and rough solution method that achieves principal result  Examine definition more closely How does the result differ from what is wanted?

9. Designing the bugs out (cont) Top-down design (cont)  Take large steps of solution and breakdown  Each refinement in definition of task becomes a refinement in the algorithm for the solution  Modules become identifiable Modules can become separated and developed independently  High-level notation is encouraged Exposes concepts

10. Designing the bugs out (cont) Top-down design avoids bugs  Clarity of structure identifies requirements and functions of modules easier  Partition and independence of modules avoids system bugs  Suppression of detail makes flaws more apparent  Design can be tested at each refinement step so that testing can start earlier with proper focus

11. Designing the bugs out (cont) Structured programming  Use control structures consisting only of DO WHILE Loops IF… THEN Conditions GO TO branches produces errors  Think about control structures as control structures of a system, not as individual branch statements

12. Designing the bugs out (cont) Component Debugging  On-machine debugging Early machines had painfully slow I/O Design of this debugging method took half as long as writing the actual program  Memory dumps High-speed printers made it possible to dump memory at the end of a failed program Still required desk time to debug but minimized computer time use

13. Designing the bugs out (cont) Component Debugging  Snapshots As memory grew exponentially, techniques for selective dumping, selective tracing, an inserting snapshots into memory without having to reassemble or recompile  Interactive debugging Time shared debugging One computer with multiple programs that could be tested from terminals. Machines kept busy

14. Designing the bugs out (cont) System Debugging  Begin only after pieces seem to work  Sooner put together, sooner system bugs emerge

15. Designing the bugs out (cont) System Debugging  Build programs and data for tests only Dummy components  faked data Miniature file  Issues with formats for tape and disk files  few records but all pointers and descriptions Auxiliary programs  test data generator, analysis printouts, cross-reference table analyzers

16. Designing the bugs out (cont) System Debugging  Control Changes One person in charge  Of component changes and version substitution Controlled copies  Latest version locked up for component testing  Test copy with latest fixes being installed  Play pen copy for individuals to develop their own components with

17. Designing the bugs out (cont) System Debugging  Add one component at a time Have thorough test cases  Test partial systems after each new piece added Old test cases must be rerun to test for system regression

18. Designing the bugs out (cont) Quantize updates  Changes need to be quantized Component builders will have hot new versions Replacing an existing component will require testing Is it too disruptive?