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 (attributes, state variables, instance
  variables, fields, data members), and
• Actions (methods, member functions)
• Objects are independent units
• Conceptual independence
• Physical independence

5
Object-Oriented Analysis (contd)

• Semi-formal specification technique
• Multiplicity of different methods
• Booch
• OMT
• Objectory
• Shlaer-Mellor
• Coad-Yourdon
• All essentially equivalent
• Nowadays, we represent OOA using UML (unified
  modeling language)

6
The Three Steps of OOA

• 1. Use-case modeling (functional modeling)
• Determine how the various results are computed by
  the product (without regard to sequencing)
• Present this information in form of a use-case
  diagram and associated scenarios.
• Largely action oriented

7
The Three Steps of OOA

• 2. Class modeling (object modeling)
• Determine the classes and their attributes
• Then determine interrelationships and
  interactions among the classes.
• Present this information in the form of a diagram
  (similar to entity-relationship diagram). Called
  a class diagram or class model.
• Purely data-oriented

8
The Three Steps of OOA

• 3. Dynamic modeling
• Determine the actions performed by or to each
  class or subclass
• Present the information in the form of a diagram
  similar to a finite state machine. Called a
  state diagram.
• Purely action-oriented
• Iterative process
• In practice steps performed in parallel

9
Elevator Problem OOA

• An elevator is to be installed to control n
  elevators in a building with m floors.
• Problem specify the logic required to move
  elevators between floors according to the
  following constraints
• Each elevator has a set of m buttons, one for
  each floor. These illuminate when pressed and
  cause the elevator to visit the corresponding
  floor. The illumination is canceled when the
  corresponding floor is visited by the elevator.

10
Elevator Problem OOA

• Each floor, except the first floor and the top
  floor, has two buttons, one to request an
  up-elevator and one to request a down-elevator.
  These buttons illuminate when pressed. The
  illumination is canceled when an elevator visits
  the floor and then moves in the desired
  direction.
• When an elevator has no requests, it remains at
  its current floor with its doors closed.

11
Elevator Problem OOA

• 1. Use-Case Modeling
• Use case Generic description of overall
  functionality
• Scenario Instance of a use case (like an object
  is an instance of a class)
• A use-case is concerned with the overall
  interaction between the classes of the software
  product and the users of the product.
• A scenario is one particular set of interactions
  between specific objects and users.
• scenarios are derived from the requirements
  documents
• Get comprehensive insight into behavior of product

12
Elevator Problem OOA

• UML representation
• The only interactions possible between users and
  classes is a user pressing an elevator button to
  summon an elevator
• or a user pressing a floor button to request the
  elevator to stop at a specific floor.

13
Elevator Problem OOA

• Example scenario is on next slide.
• UML provides two types of diagrams for
  representing scenarios
• sequence diagrams
• collaboration diagrams
• will use these for OO design in chapter 13.
• Next slide represents a normal scenario.
• corresponds to the way that we think elevators
  should be used.

14
Elevator Problem OOA

• The numbered events describe the two interactions
  between User A and the buttons of the elevator
  system
• event 1 and 7
• Also describes the actions taken by the
  components of the elevator system
• events 2 through 6
• events 8 through 15
• unnumbered events are comments
• User A does not interact with the components of
  the system.

15
Normal Scenario
16
Elevator Problem OOA

• Next slide represents an exception scenario.
• Depicts what happens when a user presses the Up
  button at floor 3 but actually wants to go down
  to floor 1.

17
Exception Scenario
18
Elevator Problem OOA

• Must develop sufficient scenarios to give the OOA
  team a comprehensive insight into the behavior of
  the system being modeled.
• This information is used in the next phase to
  determine the classes.
• also used in object-oriented design.

19
Class Modeling

• Extract classes and their attributes
• Represent them using an entity-relationship
  diagram
• Only create attributes (member data)
• Methods are assigned in design phase

20
Class Modeling

• Deduce the classes from use cases and their
  scenarios
• study all cases and scenarios and identify the
  components that play a role in the use cases
• In example candidate classes are
• elevator buttons
• floor buttons
• elevators
• doors
• timers

21
Class Modeling

• Often there are many scenarios
• Possible danger too many candidate classes
• it is easier to add a new class than to remove a
  candidate class that should not have been
  included.

22
Two Approaches to Class Modeling

• Noun extraction
• Always works
• CRC classes
• Need to have domain expertise

23
Noun Extraction

• Stage 1. Concise Problem Definition
• Define product in single sentence
• Buttons in elevators and on the floors control
  the motion of n elevators in a building with m
  floors.

24
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.

25
Noun Extraction (contd)

• Stage 3. Formalize the Strategy
• Identify nouns in informal strategy. Use nouns
  as candidate classes
• exclude nouns that lie outside the problem
  boundry
• 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)
• abstract noun identifies ideas or quantities
  that have no physical existence

26
Noun Extraction (contd)

• Candidate classes Elevator and Button
• UML convention boldface class and capitalize
  initial letter.
• Subclasses Elevator Button and Floor Button
• create because problem specifies two types of
  button

27
First Iteration of Class Diagram
28
First Iteration of Class Diagram

• Problem
• Buttons do not communicate directly with
  elevators
• example may have several elevators who decides
  which to dispatch?
• problem did not mention a controller.
• The noun extraction technique only provides a
  starting point.
• We need an additional class Elevator Controller

29
Second Iteration of Class Diagram

• All relationships are now 1-to-n
• Makes design and implementation easier

30
CRC Cards

• class-responsibility-collaboration
• Used since 1989 for OOA
• For each class, fill in card showing
• Name of class
• Functionality (responsibility)
• List of classes it invokes (collaboration)

31
CRC cards

• Has been extended
• A CRC card often explicitly contains the
  attributes and methods of the class
• Instead of using cards, some organizations put
  the names of the classes on Post-it notes on a
  white board.
• move notes as needed
• draw lines between notes to denote collaboration
• Now automated (CASE tool component)
• System Architect can create and update CRC
  cards on the screen.

32
CRC Cards

• Strength
• When acted out by team members, powerful tool for
  highlighting missing or incorrect items
• Weakness
• Domain expertise is needed
• Developers must come up with the classes
  themselves.

33
3. Dynamic Modeling

• Produce UML state diagram
• a description of the target product similar to a
  finite state machine
• this is an informal graphical technique
• Three parts state, event, predicate
• these are distributed over state diagram
• events are outside occurrences
• predicates (or guards) are boolean conditions
  that reflect the current values in the system
• predicates are put into brackets

34
3. Dynamic Modeling

• Example
• Go into Wait State is entered if present state is
  Elevator Event Loop and the predicate elevator
  stopped, no requests pending is true
• When Go into Wait State has been entered, action
  Close elevator doors after timeout is carried out.

35
3. Dynamic Modeling

• State diagrams are constructed from the scenarios
• specific events of the scenario are generalized
• Example consider the first event of the
  scenario seen earlier
• user A presses the Up floor button at floor 3
• generalize this user pushing an arbitrary button

36
3. Dynamic Modeling

• generalize this user pushing an arbitrary button
• two possibilities
• button is already lit (nothing happens)
• button is unlit (action taken to process users
  request)
• To model this draw Elevator Event Loop state
• Case button lit, create the do-nothing loop with
  guard button pushed, button lit (top left hand
  corner)
• Case button unlit, create state Process Request.
  Arrow from Elevator Event Loop to Process Request
  with predicate button pushed, button unlit
• From event 2 of the scenario, clear that action
  Turn on Button is needed in the Process Request
  state
• also pressing a button requests an elevator, so
  action Update requests must also be carried out.

37
3. Dynamic Modeling

• Event 3 An elevator arrives at floor 3.
• generalize to an arbitrary elevator moving
  between floors
• motion of elevator modeled by the guard elevator
  moving in direction d, floor f is next
• and state Determine if Stop Requested
• two possibilities
• there exists a request to stop at floor f, guard
  user has requested stop at floor f
• go to state Stop at Floor
• action Stop Elevator (from event 3)
• action Open doors and start timer (from events
  5 and 6)
• action Update Requests
• if the button for this floor is lit (ie,
  predicate elevator button lit )
• state Elevator Button Off
• action turn off elevator button (from event 4)

38
3. Dynamic Modeling

• Event 9 Elevator doors close after a timeout.
• generalize to state Close Elevator Doors
• Event 10 The elevator travels to floor 7.
• generalize to state Process Next Request
• Use a different scenario where user exits from
  elevator and no buttons remain lit
• get state Go into Wait State
• with guard no requests pending, doors closed
• Other states similar

39
Testing during the OOA Phase

• CRC cards are an excellent testing technique
• Create CRC cards from class diagram and state
  diagram.
• Fill in a CRC card for each class on class
  diagram
• The RESPONSIBILITY of the class is obtained by
  listing all the actions in the state diagram for
  that class.
• The COLLABORATION of the class is obtained by
  seeing what classes call/are called by this class
  on the class diagram

40
Testing during the OOA Phase

• CRC card for class Elevator Controller

responsibilities are all of the actions from the
state diagram for the Elevator Controller class
Collaborators taken from the class diagram
41
CRC Cards

• There are 2 major problems with the first
  iteration of the OOA.
• Consider responsibility
• 1. Turn on elevator button
• Totally unacceptable for object-oriented paradigm
• Responsibility-driven design ignored
• Objects of class Elevator Button should turn
  themselves off
• Information hiding ignored
• Elevator Controller should not have the knowledge
  of the internals of Elevator Button needed to be
  able to turn on a button

42
CRC Cards

• Responsibility
• 1. Turn on elevator button
• should be
• 1. Send message to Elevator Button to turn
  itself on
• Similar changes needed for responsibilities 2
  through 6 of CRC card.

43
Second Iteration of CRC Card
44
CRC Cards (contd)

• Problem 2 A class has been overlooked
• Consider responsibility 7 Open elevator doors
  and start timer
• concept of a state the values of all variables
  of an object.
• If a component in question possesses a state that
  state changes, component should be modeled as a
  class.
• Elevator doors have a state that changes during
  execution (class characteristic)
• Add class Elevator Doors
• Safety considerations objects encapsulate state
  and prevent unauthorized changes to variables

45
CRC Cards (contd)

• Reconsider class model
• now CRC card responsibilities 7 and 8 must be
  changed to messages
• problem start timer.
• Timer is part of the Elevator Controller itself
• So do not need to send message just handle
  action itself

46
Third Iteration of Class Diagram
47
CRC Cards (contd)

• Then reconsider dynamic model, use-case model
• user-case diagram still ok
• actions in the state diagram must be modified to
  reflect the responsibilities of the second
  iteration of the CRC card.
• state diagrams must be extended to include the
  additional class.
• then scenarios must b e updated to reflect these
  changes.

48
Second Iteration of Normal Scenario
49
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

50
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, and
• 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

51
Finishing the specifications

• The specifications are a contract
• diagrams are not adequate for a contract
• Thus must change the diagrams into formal
  specifications.

52
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
• Rose

53
Air Gourmet Case Study OOA

• Use-case model for making a reservation

54
Making a Reservation Extended Scenario
55
Air Gourmet Case Study OOA

• Use-case for returning and scanning a postcard

56
Postcards Extended Scenario
57
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.

58
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.

59
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

60
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

61
Second Iteration of Class Diagram (contd)

• Cause of our problems
• Flight should have been a candidate class
• BUT, we all have 2020 hindsight

62
Air Gourmet Case Study Dynamic Model

• State diagram

63
Challenges of the OOOA Phase

• Do not cross the boundary into object-oriented
  design
• The modules of the OO design phase are
  extracted during the OO analysis phase.
• ready for refinement in the OOD phase
• Do not allocate methods to classes yet
• too much iteration must be done in the
  specification phase
• do not need to know the methods in this phase
• assigning methods only complicates the refinement
  process