Object-Oriented Analysis and Design
Conceptual Model
1. Identify candidate concepts in the domain
- physical or tangible things
- places, organizations
- roles of people
- containers, containees
- transactions (if there is a need to remember)
- transactions line items
- scheduled events
- policies
- noun or noun phrase in description
- long lasting, not "simple"
- represents both state and behavior
2. Add associations between concepts
- a noteworthy bidirectional relationship
- containment relationships
- lasting relationships (marriage - yes, shaking hands - no)
- fleeting relationships (where remembering is significant)
- domain expert insists
- use a verb to "name" each association (Employee "occupies" Office)
- add multiplicity ("at a moment in time, a Patron borrows zero or
more Books", "at a moment in time, a Book is borrowed by zero or one
Patron")
- start with the concept that represents the whole, and introduce
concepts and associations to "satellite" abstractions
- think structural, not behavioral
3. Add attributes (not methods)
System Sequence Diagram
Identify external actors and system events. Every system has at least
a start() system event. Every system event will result in a
Collaboration Diagram.
Collaboration Diagram
A behavioral model - time has meaning. Show the time order of messages
being passed between objects.
Design Class Diagram
A structural model - time has no meaning.
- concepts become classes
- invent new classes to engineer additional abstraction and
flexibility
- add attribute visibility (arrows on the associations)
- add methods
GRASP
General Responsibility Assignment Software Patterns
- Expert
-
"that which knows, does"
"do it myself"
"put services with attributes"
- Creator
-
put the responsibility to create instances of class A in the class
that contains A objects the most, or uses A objects the most
- Controller
-
identify a "controller" for each system event, invent a "facade" to
separate layers
- Coupling
-
minimize coupling between classes
- Cohesion
-
maximize cohesion within a class
- Indirection
-
"all problems in computing science can be solved with one more level
of indirection"
- Don't talk to strangers
-
Law of Demeter
don't ask for a reference to a 3rd-party object from a 2nd-party
object and then couple yourself to the 3rd-party object -
instead, ask the 2nd-party object to do something (and it will
delegate to the 3rd-party object)
- Pure Fabrication
-
invent new classes to engineer additional abstraction and flexibility
- Polymorphism
-
never test the type of an object, and then perform some conditional
logic based on that type
Mapping design artifacts to code
- map Design Class Diagrams to class header files
- map Collaboration Diagrams to class source files
- start with the least connected class (the one that does not
rely on other classes) and work toward the most connected class
- implement and test each class completely before moving on