1. OBJECT-ORIENTED ANALYSIS PHASE
CHAPTER 12
OBJECT-ORIENTED ANALYSIS PHASE

2. Overview Object-oriented analysis Use-case modeling Class modeling
Dynamic modeling
Testing during the object-oriented analysis phase
CASE tools for the object-oriented analysis phase
Air Gourmet case study: Object-oriented analysis
Challenges of the object-oriented analysis phase

3. Object-Oriented Analysis Phase
Object-oriented paradigm
Reaction to perceived shortcomings in structured paradigm
Problem of larger products
Data and action treated as equal partners

4. Object-Oriented Paradigm
Object consists of
Data
Actions
Objects are independent units
Conceptual independence
Physical independence

5. Object-Oriented Analysis (OOA)
Semi-formal specification technique
Many methods exist
Booch
OMT
Objectory
Shlaer-Mellor
Coad-Yourdon
All essentially equivalent
Most of OOA is done these days using UML (Unified Modeling Language)
Just In Case You Wanted to Know on pg. 367

6. The Three Steps of OOA 1. Use-case modeling
Determine how the various results are computed by the product (without regard to sequencing)
Also referred to as functional modeling
Generate use-case diagram and associated scenarios
action oriented
2. Class modeling (“object modeling”)
Determine the classes and their attributes
Determine the interrelationships and interactions among the classes
Generate class diagram - similar to ER diagram
data oriented
3. Dynamic modeling
Determine the actions performed by or to each class or subclass
Generate state diagram
action-oriented
Iterative process

7. Elevator Problem: OOA 1. Use-Case Modeling
Use case: Generic description of overall functionality
Scenario: Instance of a use case

8. Normal Scenario

9. Exception Scenario

10. More on Scenarios
Sufficient scenarios should be generated to give the OOA team a comprehensive insight in the behavior of the system to be modeled
Scenarios are used in the class modeling step to determine the classes (objects)
Scenarios are also used in the OO design

11. 2. Class Modeling Extract classes and their attributes
Represent them using an entity-relationship diagram (ERD)
Deduce the classes from use cases and their scenarios
Only the attributes of a class are determined (the methods are determined in the OO design)
Often there are many scenarios
Possible danger: too many candidate classes

12. Two Approaches to Class Modeling
Noun Extraction
Three-stage process to extract candidate classes
Always works
CRC cards
Class-responsibility-collaboration (CRD) cards
Need to have domain expertise

13. Stage 1. Concise Problem Definition
Noun Extraction
Stage 1. Concise Problem Definition
Define the product as briefly and concisely as possible, preferably in a single sentence
Elevator problem example
Buttons in elevators and on the floors control the motion of n elevators in a building with m floors.

14. Noun Extraction (contd)
Stage 2. Informal Strategy
Incorporate constraints, express result in a single paragraph
Buttons in elevators and on the floors control movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

15. Noun Extraction (contd)
Stage 3. Formalize the Strategy
Identify nouns in informal strategy (excluding those that lie outside of the problem boundary). Use nouns as candidate classes
Nouns
button, elevator, floor, movement, building, illumination, illumination, door
floor, building, door are outside problem boundary — exclude
movement, illumination, illumination are abstract nouns — exclude (may become attributes)
Candidate classes: Elevator and Button
Subclasses: Elevator Button and Floor Button

16. First Iteration of Class Diagram
Problem
Buttons do not communicate directly with elevators
We need an additional class: Elevator Controller

17. Second Iteration of Class Diagram
All relationships are now 1-to-many
Makes design and implementation easier

18. CRC Cards Used since 1989 for OOA For each class, fill in card showing
Name of Class
Functionality (Responsibility)
List of classes it invokes (Collaboration)
Now automated (CASE tool component)
Strength
When acted out by team members, powerful tool for highlighting missing or incorrect items
Weakness
Domain expertise is needed

19. 3. Dynamic Modeling Produce UML state diagram
State, event, predicate distributed over state diagram
UML “guards” are in brackets

20. Testing during the OOA Phase
CRC cards are an excellent testing technique

21. CRC Cards Consider responsibility
1. Turn on elevator button
Totally unacceptable for object-oriented paradigm
Responsibility-driven design ignored
Information hiding ignored
Responsibility
should be
1. Send message to Elevator Button to turn itself on

22. CRC Cards (contd) A class has been overlooked Reconsider class model
Elevator doors have a state that changes during execution (class characteristic)
Add class Elevator Doors
Safety considerations
Reconsider class model
Then reconsider dynamic model, use-case model

23. Second Iteration of CRC Card

24. Third Iteration of Class Diagram

25. Second Iteration of Normal Scenario

26. Elevator Problem: OOA (contd)
All three models are now fine
We should rather say:
All three models are fine for now
We may need to return to the object-oriented analysis phase during the object-oriented design phase

27. Why Is All This Iteration Needed?
Perhaps the method is not yet mature?
Waterfall model (explicit feedback loops)
Rapid prototyping model (aim: to reduce iteration)
Incremental model
Spiral model
Latter two explicitly reflect iterative approach
Iteration is an intrinsic property of all software production
Especially for medium- and large-scale products
Expect iteration in the object-oriented paradigm

28. CASE tools for OOA phase
Diagrams play a major role
Diagrams often change
Need a diagramming tool
Many tools go further
All modern tools support UML
Example
Rational Rose
Smart Draw

29. Air Gourmet Case Study: OOA
Use-case model for making a reservation

30. Making a Reservation: Extended Scenario

31. Air Gourmet Case Study: OOA
Use-case for returning and scanning a postcard

32. Postcards: Extended Scenario

33. Air Gourmet Case Study: Class Modeling
Stage 1. Concise Problem Definition
Define product in single sentence
A computerized system is needed to provide information regarding the efficacy of a special meals program.

34. Air Gourmet Case Study: Noun Extraction (contd)
Stage 2. Informal Strategy
Incorporate constraints, express result in a single paragraph
Reports are to be generated to document the efficacy of the special meals program. The reports concern meals loaded on flights, flights boarded by passengers, names and addresses of passengers, meal quality, and low-sodium meals.

35. Air Gourmet Case Study: Noun Extraction (contd)
Stage 3. Formalize the Strategy
Identify nouns in informal strategy. Use nouns as candidate classes
Nouns
report, efficacy, program, percentage, meal, flight, boarding, passenger, name, address, quality
efficacy, program, percentage, boarding, quality are abstract nouns — exclude (may become attributes)
name, address are attributes of passenger
Question: Should meal and flight be classes?
It is easier to add classes than to remove them
Candidate classes: Report and Passenger

36. First Iteration of Class Diagram
Problems with this class diagram
Data for reports are needed on a per-flight basis
Each report has to access multiple flights
Each flight has multiple passengers
Six reports (not four) are needed

37. Second Iteration of Class Diagram
Cause of our problem
Flight should have been a candidate class

38. Air Gourmet Case Study: Dynamic Model
State diagram

39. Challenges of the OOA Phase
Do not cross the boundary into object-oriented design
Do not allocate methods to classes yet