lecture 8: structured design and object oriented design cse 111 7/12/20151copyright william. e....

Lecture 8: Structured Design and Object Oriented Design

CSE 111

04/19/23 1Copyright William. E. Howden

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

04/19/23 Copyright William. E. Howden 2

Detailed DesignStructured 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


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


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


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


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


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


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


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.


Top-Down Design

• TD is a kind of structured programming strategy– Abstract function/procedure at top level

More detailed functions at next levelMore detailed functions at next level

etc.

– This “refinement process” continues until everything is concrete source code

– At each level only SP constructs are used


Copyright W. Howden 12

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;

}

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– see if record matches daterPrefs and set match


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


Architectural DesignComponents and Relationships

• Component– Separately defined collection of

procedures/methods/functions and/or data definitions

– Varies by programming language– Early programming languages: single procedure


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?


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



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

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



General Levels of Cohesion

• Coincidental• Logical• Temporal• Procedural• Data Flow• Communicational• Functional


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


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.


Temporal Cohesion

• Group things together than can be done at the same time– e.g. • Initialization code component• Termination/clean up component


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


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


Communicational Cohesion

• Group things together than use the same data– E.g. • routines for accessing DB in different ways• methods for the same class


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


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


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


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

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



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

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


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)


lecture 8: structured design and object oriented design cse 111 7/12/20151copyright william. e....

Documents

copyright william

basic constructs

howden slide

howden2 slide

howden7 slide

howden4 slide

howden9 slide

howden6 slide