1. Lecture 8: Structured Design and Object Oriented Design CSE 111 7/12/20151Copyright William. E. Howden

2. Structured Design Software engineering for procedural programming – Detailed design Structured Programming Constructing “well structured” programs – structure refers to control-flow as in a flow chart – Architectural Design Components and relationships Components: – (collections of) procedures and methods 7/12/2015Copyright William. E. Howden2

3. Detailed Design Structured Programming Goal: well-structured programs Basic idea – restrict all program structures to those that can be constructed from several basic constructs, plus a well defined rule of composition for building new structures 7/12/2015Copyright William. E. Howden3

4. The Three Basic Structured Programming Constructs Sequencing S1; S2 Alternation if C then S1 else S2 Iteration while C do S1 Variations on the above one-sided alternation, until and for loops, switches 7/12/2015Copyright William. E. Howden4

5. Elements of a Construct Each element Si in the above diagrams is: – another structured programming construct – a procedure/method call – an elementary statement such as an assignment or basic operation such as a string edit Each element Ci is a Boolean expression 7/12/2015Copyright William. E. Howden5

6. Composition: Constructing More Complex Structures by Nesting Start with statement S: e.g. if C1 then T1 else T2 – then nest additional constructs inside S by substituting them in for T1 and T2 – We can do this repeatedly, to get, for example: if C1 then( if C2 then (S1; (S2; S3)) else S4) else (while C3 do (S5; S6)) this has been constructed from one double-nested application of sequencing, 2 nested sequencings, 1 nested alternation and 1 nested iteration 7/12/2015Copyright William. E. Howden6

7. Compound Construct Formatted for Readability if C1 then( if C2 then (S1; (S2; S3)) else S4) else (while C3 do (S5; S6)) if C1 then( if C2 then (S1; S2; S3)) else S4) else (while C3 do (S5; S6)) 7/12/2015Copyright William. E. Howden7

8. Basic “Axioms” of Structured Programming Adequacy: all computations can be programmed using the three basic constructs plus the nesting rule of program composition Well-structured: if this approach to construction is used, then it is not possible to construct “poorly structured” code – poorly structured code? “spaghetti code”, goto’s all over the place 7/12/2015Copyright William. E. Howden8

9. Structured and Go-to-less Programming Modern programming languages, with compound statements that match SP constructs, naturally result in well-structured code Exception: go-to’s, which allow the construction of arbitrary (possibly bad) structures. – Unavoidable use of goto’s may occur in some cases, such as in use of assembly language – But we can still construct well–structured code if we follow the SP guidelines 7/12/2015Copyright William. E. Howden9

10. The Psychology of Structured Programming Even programmers have limited intellectual capabilities What does the mind find easy, when trying to read and comprehend? sequencing, alternation, and iteration control flow stacks for non-linear flow – while trying to read a linear text, we can use a stack to remember where we were when we have to go down a level due to nesting. When finished, pop the mental stack to go back to where we were. 7/12/2015Copyright William. E. Howden10

11. Top-Down Design TD is a kind of structured programming strategy – Abstract function/procedure at top level More detailed functions at next level etc. – This “refinement process” continues until everything is concrete source code – At each level only SP constructs are used 7/12/2015Copyright William. E. Howden11

12. Copyright W. Howden12 DS PseudoCode and Program Refinement 1 Member Data getADate(DaterPreferences daterPrefs) { Record record; Boolean match = false; record = filemanager(“getFirst”); see if record matches daterPrefs and set match while ((record =/ null) and (match == false)) { record = filemanager(“getNext); see if record matches daterPrefs and set match } if (match = = false) return null else return record; }

13. DS PseudoCode and Program Refinement 2 Next level down, refine the following into less abstract prose and actual code, or all actual code – see if record matches daterPrefs and set match 7/12/2015Copyright William. E. Howden13

14. Structured Programming and Object Oriented Design Can be applied to class methods In a procedural program, e.g. in C, procedures may be much larger than the average method, so SP may be more critical 7/12/2015Copyright William. E. Howden14

15. Architectural Design Components and Relationships Component – Separately defined collection of procedures/methods/functions and/or data definitions – Varies by programming language – Early programming languages: single procedure 7/12/2015Copyright William. E. Howden15

16. Component Decomposition Divide the program up into separate pieces Goals – “divide and conquer” – “intellectual manageablity” – facilitate change and reuse What are the characteristics of a good decomposition? 7/12/2015Copyright William. E. Howden16

17. Well-Structured Component Decomposition Cohesion: the artifacts grouped together in a component should have strong intra- relationships and should be together Goal: designs with high cohesion components Coupling: the interaction and inter- relationships between different components should be minimized Goal: designs with low inter-component coupling 7/12/2015Copyright William. E. Howden17

18. Copyright W. Howden18 Extreme Examples of Cohesion and Coupling One component with everything in it – Bad cohesion (probably contains weakly related elements) – Good coupling (all inter-component relationships are weak by default – there are none) Every part of a program in its own component – Good cohesion (all intra-component relationships are strong by default – there are none) – Bad coupling (things that should be together in the same component are separated) Design - balancing the goal of high cohesion against the goal of low coupling

19. Cohesion, Coupling and Procedural Components Cohesion and coupling concepts first developed for procedural programming in languages such as Fortran, PL-1, Algol, C, and Pascal We will introduce them using procedurally oriented concepts, and later specifically consider class oriented concepts 7/12/2015Copyright William. E. Howden19

20. Copyright W. Howden20 General Levels of Cohesion Coincidental Logical Temporal Procedural Data Flow Communicational Functional

21. Copyright W. Howden21 Coincidental Cohesion Accidental decomposition, no functional rationale – e.g. Division of code into modules determined by size consideration Isolation of commonly used but not functionally related pieces of code

22. Copyright W. Howden22 Logical Cohesion Group things together that are the same “kind” of thing – e.g. Module containing all the error handling routines Initialization module that opens files, initializes variables, etc.

23. Copyright W. Howden23 Temporal Cohesion Group things together than can be done at the same time – e.g. Initialization code component Termination/clean up component

24. Copyright W. Howden24 Procedural Cohesion Group things together that will be part of the same computational structure – E.g. the code that will go inside a loop – make it a separate function

25. Copyright W. Howden25 Data Flow Cohesion Group A,B,C together if A prepares data used by B which prepares data used by C – Why is this a stronger form of cohesion? A,B, and C must be part of the same function

26. Copyright W. Howden26 Communicational Cohesion Group things together than use the same data – E.g. routines for accessing DB in different ways methods for the same class

27. Copyright W. Howden27 Functional Cohesion Everything in component works to support a common, well defined function – you know it when you see it – E.g. good component function for computing “goodness” of a match in a complex DS – E.g. bad component calculates day of week given year/month/day computes square roots of integers

28. Copyright W. Howden28 Coupling Measures Kinds of coupling Amount of coupling Can be high due to either kind of coupling and/or amount of coupling High coupling may be justified by high cohesion trade-off

29. Copyright W. Howden29 Kinds of Coupling From high to low coupling – One module directly accesses contents of another e.g. changes data or actual code (possible in assembly or object code programming) – passing different kinds of data in a procedure call pointers control data, such as a “flag” – e.g. if flag then S1 else S2 in called procedure functional computational data

30. Copyright W. Howden30 Amounts of Coupling Scalar versus non-scalar – From high to low Record structures and collections (arrays, vectors) Scalar variables – From high to low Many variables Few variables

31. Cohesion, Coupling and Object Oriented Design Cohesion – We can construct class oriented descriptions of high and low cohesion Coupling – Procedural coupling: when one method calls a method in another class – Class coupling: when one class definition uses another class definition e.g. inheritance, class and local variable type, method parameter definition, method return type 7/12/2015Copyright William. E. Howden31

32. Copyright W. Howden32 Cohesion and Class Design Goal: high cohesion Levels of class cohesion, from low to high – Very low: class responsible for many things in very different functional areas – Low: class responsible for many or complex things in one functional area – Moderate: class has light or moderate responsibilities for a few different areas that are related to class but not each other – High: class has moderate responsibilities in one functional area, cooperates with others to fulfill more complex responsibilities

33. Coupling and Class Design Goal: – low coupling, unless cohesion and design patterns indicate otherwise – design patterns may increase coupling, but improve cohesion e.g. – state pattern creates substate classes that are coupled to the state superclass and superclass is coupled to the main class – tradeoff is better cohesion, ease of alteration 7/12/2015Copyright William. E. Howden33

34. Assignment 7 Write the code for your application When writing the code for the methods, keep to the spirit of structured programming Discuss two examples of non-trivial methods that you used, and how they conform to structured programming (i.e. they could have been designed in a non-structured way also) 7/12/2015Copyright William. E. Howden34