Rob Kremer

Practical Software Engineering

• OOA/OOD
• OOD vs. Structured design
• Relationships among objects
• Early Phases
• Later Stages
• CRC Cards
• Improving your skills
• Example Problem
• References

OOA/OOD

Not much

• Don't worry about reuse of existing classes/objects (in class libraries etc.).
• Get at the objects that exist in the problem domain.
  
• Domain objects may be
  • tangible, eg: inventory-shelf (physical object)
  • abstract, eg: inventory-transaction (event)

• Reconfigure the OOA model for:
  • implementability
  • reuse of existing components
• Optimize the model for:
  • maximize/simplify inheritance
  • performance

OOD vs. Structured design

• OO strives for a networks of objects
  • Society of cooperating objects
• contrast with structured design which is hierarchies of procedures
• Large systems in both paradigms should be layered
  • Layering can be "objectized" via the facade pattern (or nested classes, but this isn't as flexible)

Relationships among objects

• subtype/supertype
  • true subtype
  • delegation
  • inclusion
• containment
  • single
  • multiple
    • fixed/non-fixed cardinality
    • ordered/unordered
    • indexing
• reference
  • single
  • multiple
    • fixed/non-fixed cardinality
    • ordered/unordered
    • indexing
• message

Early Phases

• Just worry about interfaces (public methods), not method implementation
  • Interfaces describe the type of the class, not the implementation
  • Can use interfaces create common type between to implementation-disimilar classes (eg: two lists may need different implementations due to efficiency considerations)
  • Interfaces are explicit in Java, Objective-C; use public/private inhertance in C++
• Control Strategies
  • Control is simple in Structured Design, but one has to consider the thread of control in a network of cooperating objects
  • Examples:
    • MVC (Model/View/Controller) and variants (windows interfaces)
    • Event generation object (simulation)
    • External events (real-time data acquisition)
    • Simple linear (batch)
• Consider infrastructure functions
  • These are often available through class libraries
  • Experienced programmers usually carry these with them in their "bag of tricks"
  • Examples:
    • Error handling: "universal" function (standard interface, platform-dependent implementation); exceptions with specific message protocols...
    • Memory management: garbage collecting; container-based cleanup; individual objects responsible...
    • Storage: global/local persistence; ad-hoc translators; binary/ascii; file- or stream- based...
• Consider humans and other real-world actors as part of the system
• Develop scenarios

Later Stages

• plan for incremental development and release
  • Top down: the sooner a working prototype is available, the sooner testing can begin
  • Bottom up: modules can be tested in "test harnesses"
  • Top down is usually cheaper because test harnesses can be costly to construct
  • But top down is no always feasible (how about "middle-out"?)
  • User testing can even begin very early with good top-down incremental release
• Many trade-offs:
  • efficiency/simplicity
  • efficiency/generality
  • efficiency/reusability
  • ...
• Layer the structure where appropriate
  • Layering can be "objectized" via the facade pattern (or nested classes, but this isn't as flexible)
• Look for method commonality
  • Several methods often perform similar sub-functions
  • Common sub-functions should be abstracted into private methods that each public method can call
• Break down large method bodies into components in a manner similar to structured design (see point above)
• Look for components that can be put into a reuse library (possibly by generalizing slightly)
• Use scenarios to test design

CRC Cards

• Class Responsibiltiy Cards
• Used to identify classes and their interfaces
• Recipe Cards divided into 3 sections:

  class_name

  type attribute ...

  [type] method_name [(parameters...)] ...

• Cards are filled out, and posted on cork board or metal whiteboard
• Use wool (for cork board) or pens (for whiteboard) to draw relationships
• The idea is that cards are easy to create, throw away, modify, and rearrange:
  • Therefore, designers are encouraged to try various ideas
  • Contrast: pen-and-paper can be difficult to change, causing the first design to be accepted
• Example:

  consList<T>

  T* data; consList* next;

  consList(T* d, consList<T>* c) data(d), next(c) {} T&* car() {return data;} consList<T>&* cdr() {return next;} listLength(); ...

• Lots of variations exist, eg:

  class name:
  class type: (eg: device, property, role, event, ...)
  class characteristics: (eg: tangible, atomic, concurrent, ...)
  responsbilities: ...	collaborators: ...

Improving your skills

• Read
• Practice!

Example Problem

(Done in class)

Interactive concept map consisting of labeled nodes and arcs that can be attached to nodes. Requirements:

• Nodes have various characteristics such as shape (ellipse, rectangle, rounded rectangle, diamond...), fill color, border color, text color, ...
• Nodes are labeled with text that wraps to conform to shape
• Nodes can be dragged by the mouse
• Arcs have various characteristics such as line color, line style, arrow head type, ...
• Arcs may have labels with all the attributes of nodes
• Arcs terminals may be dragged and dropped over nodes, after which they are attached to that node and move to always terminate on the node's edge
• All visual attributes of nodes and arcs may "changed on the fly" without affecting their connectivity, etc.
• All visual objects have popup menus that allow the user to choose all object-specific commands (move, change attributes, delete...)
• Require flexibility, since extensions will be requested later (non-mouse-sensitive objects, "annotation" objects with less functionality, etc.)

Design the class hierarchy.

Remember, there are a lot of implicit requirements that aren't stated.

References

Pressman, R. S. (1997). Software Engineering: A Practitioner's Approach (4th edition). New York, McGraw-Hill. (Chapter 21)
Heavily influenced by structured design

Coad, P., North, D. & Mayfield, M. (1995). Object Models: Strategies, Patterns, and Applications, Yourdon Press.
A collection of examples

Booch, G. (1994). Object Oriented Design With Applications, Benjamin/Cummings.

Cox, B. J. (1991). Object-Oriented Programming: An Evolutionary Approach. Reading, Mass, Addison -Wesely.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. & Lorensen, W. (1991). Object-Oriented Modeling and Design. Englewood Cliffs, N.J., Prentice-Hall.

---

Practical Software Engineering, Department of Computer Science

Rob Kremer