CSC 395 – Software Engineering Lecture 2: Programming As Art & Intro to Software Engineering.
CSC 395 – Software Engineering Lecture 11: Object-Oriented Goals –or– Who Moved My #$&@!...
-
Upload
dorthy-maxwell -
Category
Documents
-
view
222 -
download
6
Transcript of CSC 395 – Software Engineering Lecture 11: Object-Oriented Goals –or– Who Moved My #$&@!...
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