CSC 395 – Software Engineering

1. CSC 395 –Software Engineering Lecture 11: Object-Oriented Goals –or– Who Moved My #$&@! Cheese?

2. Today’s Goal • Discuss object-orientation approach • Goals of OO-based languages • Important features of OO-based software • How OO goals used in software engineering • Begin thinking about next stage of project • You should have complete set of requirements • Time to start moving on to next workflow: analysis

3. Software Engineering CPL • Unstructured Programming • SE Concept: What’s software engineering? • Examples: Early assembly language, BASIC • SE Effects: Eeek! Run for the hills! • Functional Programming • SE Concept: λ-calculus makes generating correctness proofs easy • Examples: Lisp, Scheme, Prolog • SE Effects: Programming becomes as easy and intelligible as λ-calculus

4. Software Engineering CPL • Structured Programming • SE Concept: Break process up into generic actions; hope actions are reusable • Examples: Pascal, C/C++ (non-OO) • SE Effects: Does problem divide into independent actions?

5. Software Engineering CPL • OO Programming • SE Concept: Create independent data classes; assume data types are reused • Examples: Java, C++/C#, Ada • SE Effects: Can data be split into independent reusable actors?

6. Software Engineering CPL • Aspect-Oriented Programming • SE Concept: “Cross-cutting” concerns (e.g., data includes Students, Employees, & Matt G.) are common, but do not fit into normal OO languages • Examples: Aspect-Oriented Java, AspectL • SE Effects: Are programmers really able to keep track of the additional complexity? • AOP still early in its infancy

7. Software Engineers Role • The most likely way for the world to be destroyed… is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein • Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers… -- Jef Raskin • In a few minutes a computer makes a mistake so great that it would have taken many men many months to equal it. -- Unknown • Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. -- Rick Cook

8. To Err is Human; To Really Foul Things up Takes a Computer • After entering maintenance workflow, users call computer programs: • Fragile • Unreliable • Many worse terms that I will not put in slides • (Imagine if they saw the works-in-progress!) • Why is delivery & updating code so hard? • Cohesion & coupling between modules

9. What is a “Module”? • (Supposedly) Independent unit of code • Languages written & organized differently • What a module is also differs between languages • Most languages also have multiple levels at which module can be defined • Examples of potential module definitions: • Java: method, class, or package • C: function or file (*.h) • C++: class or namespace • Assembly: any block of code starting with a label

10. Strengthor Cohesion • Measure of interaction within a module • Ideally each module should do single thing • Ideal modules are simple & easy to debug • Few people actually think this way, though • Cohesion discussed using 7 possible levels • Scale is relative one and changes over time • OO tries keeping cohesion at highest levels • Critically, OO tries making cohesion easy • To be useful, important to understand why levels are good or bad

11. The Bad & the Ugly • Coincidental cohesion: “platypus module” • Module combines completely unrelated ideas • At best, solves current problem; used only once • Logic, proofs, design cannot be used with module • Logical cohesion: “Bassomatic 4000 module” • Does many (logically connected) tasks • One big if/else or switch statement! Hooray! • Don’t we all like reading 1000 line methods? • What happens when the requirements change?

12. Getting There… • Temporal Cohesion: “steamroller module” • Performs long series of time-dependent tasks • Tasks connected only in that they are performed one after another • What happens when the process changes? • Procedural Cohesion: “breadmaker module” • Starting from scratch performs entire operation • Often “optimized” into unintelligible spaghetti code • May be reused, but rarely able to be rewritten • What happens when requirements changes?

13. Best of Breed Approaches • Communicational Cohesion: “Spork module” • Combines temporal & procedural cohesion • Reuse of this code is iffy • Functional Cohesion: “one-time pad module” • Module does one task and does it well • Ideal module in structured programming languages • Informational Cohesion: “String module” • Contains set of related, but independent, operations centered on single datum • Reuse is maximal by ignoring unneeded operations

14. Cohesion Review • Measures of interaction within a module • Describes how easy module is to debug & reuse • Higher the level of cohesion the better • When a module matches multiple levels, assigned to the lowest one • View of cohesion is limited, however • Only considers operation at the unit level • Ignores problems at integration or system level • Pile of Picassos on the floor still looks like trash

15. Binding or Coupling • Measure of interaction between modules • Ideally modules independent of each other • Ideal world would involve 1 HUGE module • Examines how to get modules to play nicely • Coupling has 5 possible levels • Scale is relative though fairly static • OO can restrict attempts at bad coupling levels • Ultimately relies on intelligence of programmers • Unfortunately, coupling rarely stated explicitly • Proper OO methodology make this explicit

16. Use of public & static Fields Considered Harmful • Content Coupling: “Rube Goldberg Linking” • Modules refers to contents inside a module • Both modules are completely intertwined • Changing one module crashes… something • Common Coupling: “Commune Linking” • Modules read & write single global (static) value • Generates many assumptions of values meaning • Provides many opportunities for mischief or worse

17. Good, Better, & Best • Control Coupling: “Wingman Linking” • Modules actions dictated by & relied upon others • Modules rely on detailed working of each other • Stamp Coupling:Too-Much-Information Linking • Module uses only part of the module passed in • Requires more depth when debugging modules • Like common coupling, but w/o statics (& explicit) • Data Coupling:Ideal Linking • Sharing between modules is minimal and overt • Depends on the values only, not the modules

18. Coupling Review • Measure of interaction between modules • Are module relationships between equals who have their own lives? • Suggests when counseling (e.g., reprogramming) is needed • Good OO keeps coupling at highest levels • Proper documentation also important • Even more important for multi-threaded programs • Consider the coupling between objects of similar types also

19. Documenting Relationships • Want to discover problems before implementation • Need approach of documenting class designs • Should highlight relationships between classes • Provide means to examine whether design works • UML Class Diagrams to the rescue • Shows relationships between classes • Includes space for writing down methods and fields

20. UML Class Diagrams • Each class drawn as 3-part box • Class name written in top portion of box • Fields written in middle portion of box • (public) Methods written in bottom portion of box

21. UML Class Diagrams • Show relationships between objects • Generalization uses open triangle • Aggregation/Composition uses diamonds • Also list multiplicity when that is appropriate

22. UML Class Diagram • Can also establish other relationships • Include interface definitions • Show calls between classes

23. For Next Lecture • Why reusability & portability are important • What this has to do with OO goals • How OO can improve reuse & portability • Begin thinking about next stage of project • Must develop analysis & design from your requirements document • These are make-or-break parts of any project