The Software Process

1
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
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
• 1. Turn on elevator button
• should be
• 1. Send message to Elevator Button to turn
  itself on

22
CRC Cards (contd)

• A class has been overlooked
• 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