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

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

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

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

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

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