1. Cmpe 589
Spring 2006

2. Object Oriented Analysis
Class modeling.
(Build an object model similar to an ER diagram)
Dynamic modeling.
(Build a finite state machine type model)
Functional modeling.
(Similar to data flow diagram)

3. Object Oriented Analysis
Case Study:
Elevator model.
n - elevators.
m - floors in building.
each floor has two buttons (except ground & top).

4. Object Oriented Analysis
Class Modeling
Buttons.
Elevators.
Floor.
Building.
Movement.
Illumination.
Doors.
Requests.

5. Object Oriented Analysis

6. Object Oriented Analysis
Dynamic Modeling:
"Normal" schemas (and 1 or 2 abnormal).
production rules (describe state transitions).

7. Object Oriented Analysis
Functional Modeling:
(Identify source & destination node)

8. Object Oriented Life Cycle Model
Fountain Model:

9. Class Responsibility Collaborator Model (CRC):
Responsibilities:
Distributed system intelligence.
State responsibility in general terms.
Information and related behavior in same class.
Information attributes should be localized.
Share responsibilities among classes when appropriate.
Collaborators build a CRC card
(Build a paper model, see if it works on paper)
On card:
Class name.
Class type.
Class characteristics.
Responsibility/collaborators.
(System is basically acted out)

10. O.O.D. (Booch – Abbot Method):
Define problem.
Develop process narrative for software realization of problem domain.
Formalize strategy.
Identify object & attributes.
Identify operations which can be applied to objects.
Establish interfaces by showing relationships between objects and operations.
Resolve design details to allow implementation.
Recursively apply (2) & (3).
Refine work done during O.O.A..
Represent data structures associated with object attributes.
Represent procedural derail for each operation.

11. O.O.D. (Booch – Abbot Method):
Operator Classifications:
Data manipulator (add, delete, format).
Computation.
Monitors.

12. Basic Notation For O.O.D.:
Class diagram (static).

13. Basic Notation For O.O.D.:
Object diagram (dynamic).
(communication)

14. Basic Notation For O.O.D.:
Object module diagram.

15. Basic Notation For O.O.D.:
Process diagram.

16. Alternative Generic Approach to O.O.D.:Object Oriented Analysis
Identify the data abstraction for each sub-system.
Identify attributes for each data abstraction.
Identify operations for each data abstraction.
Identify communication between objects.
Apply inheritance where appropriate.

17. Object Oriented Program Design:
Undertake object oriented system requirements specification.
Identify object and their services.
Establish interactions between objects (services required & rendered).
Identification of reusable components from previous design.
Implementation of low level objects.
Introduce inheritance relationships (superclass & subclass).
Class combination and generalization.
(prototype revision – change is healthy)

18. Common Design Flaws: (too much junk in the class)
Classes that make direct modifications to other classes.
Classes with too much responsibility.
Classes with no responsibility.
Classes with unused responsibility .
(too much junk in the class)
Misleading names.
Unconnected responsibility.
Inappropriate inheritance.
Repeated functionality.

19. Object Oriented Analysis
Object Oriented Design
Object.
(Class = type vs. Instance = var)
Encapsulation
(Data & methods)
Message passing.
(Method call & return)
Inheritance.
(Polymorphism & reuse)
Dynamic bindings.
(Types & methods)

20. Identify the problem objects
(classes) = nouns (not procedure names)
Example:
External entities (people & devices).
Things in problem domain (reports, displays, signals).
Occurrences or events (completion of some task).
Roles (manager, engineer, sales person).
Organizational units (division, groups, department).
Structures (sensors, vehicles, computers).

21. Object Oriented Analysis
Criteria:
(Object or not)
Does object inf. need to be retained?
Does object have a set of needed services?
(Can change it’s attributes)
Does the object have major attributes?
(Trivial objects should not be built)
Identify common attributes for all object instances.
Identify common operations for all object instances.
(If nothing to share, why make it an object?)
External entities which produce or consume must have defined classes.

22. Object Oriented Analysis
Specifying Attributes:
Similar to building data dictionary.
(define in terms of atomic objects)

23. Object Oriented Analysis
Include anything needed to manipulate data elements
Communication among objects.

24. Object Oriented Analysis
Object Specification:
Object name.
Attribute description:
Attribute name.
Attribute content.
Attribute data type/structure.
External input to object.
External output from object.
Operation description:
Operation name.
Operation interface description.
Operation processing description.
Performance issues.
Restriction and limitations.
Instance connections:
(0:1, 1:1, 0:many, 1:many)
Message connections.

25. Object Oriented Design:
Private data & related operations.
Shared part (interface).
Advantages:
Modularity is inherent
Decomposability (problem -> sub-problem).
Composability (reusability of pieces).
Understandability (with respect to independence).
Continuity (easy to change).
Protection (encapsulation).

26. Object Oriented Design:
Design Principles For Modularity:
Linguistic modular units.
(ADT’s should be supported)
Few interfaces.
Small interfaces (weak coupling).
Explicit interfaces (parameter – not common coupling).
Information hiding.

27. Object Oriented Analysis