CSC 395 –
Software Engineering
Lecture 11:
Object-Oriented Goals –or–
Who Moved My #$&@! Cheese?
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
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
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?
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?
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
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
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
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
Strength or Cohesion

Measure of interaction within a module




Cohesion discussed using 7 possible levels




Ideally each module should do single thing
Ideal modules are simple & easy to debug
Few people actually think this way, though
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
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?
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?
Best of Breed Approaches

Communicational Cohesion: “Spork module”



Functional Cohesion: “one-time pad module”



Combines temporal & procedural cohesion
Reuse of this code is iffy
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
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
Binding or Coupling

Measure of interaction between modules




Coupling has 5 possible levels




Ideally modules independent of each other
Ideal world would involve 1 HUGE module
Examines how to get modules to play nicely
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
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
Good, Better, & Best

Control Coupling: “Wingman Linking”



Stamp Coupling: Too-Much-Information Linking




Modules actions dictated by & relied upon others
Modules rely on detailed working of each other
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
Coupling Review

Measure of interaction between modules



Good OO keeps coupling at highest levels



Are module relationships between equals who
have their own lives?
Suggests when counseling (e.g., reprogramming)
is needed
Proper documentation also important
Even more important for multi-threaded programs
Consider the coupling between objects of
similar types also
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
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
UML Class Diagrams

Show relationships between objects



Generalization uses open triangle
Aggregation/Composition uses diamonds
Also list multiplicity when that is appropriate
UML Class Diagram

Can also establish other relationships


Include interface definitions
Show calls between classes
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