12–1
CHAPTER 12
OBJECT-ORIENTED ANALYSIS
The exercises in this chapter give students their first practical exposure to the object-oriented
paradigm. It is important to stress that repeated iteration is an intrinsic quality of this paradigm,
and of object-oriented analysis (OOA) in particular. For example, problems 12.2 and 12.4 seem
extremely straightforward. However, the students will have to iterate a number of times between
use-case modeling, class modeling, and dynamic modeling before they arrive at an acceptable
solution. (In general, there may be more than one acceptable solution to a given problem.)
PROBLEM SOLUTIONS
12.1: The state diagrams for classes Button, Elevator, and Elevator Doors are shown in Figures
12.1, 12.2, 12.3, and 12.4, respectively.
Figure 12.1. Statechart for class Button.
Turn button off
no command pending
elevator controller sends
turn button on message
elevator controller sends
turn button off message
Button Event Loop
Turning Button On
Turning Button Off
Turn button on
12–2
Figure 12.2. Statechart for class Elevator.
Figure 12.3. Statechart for class Elevator Doors.
12.2: As explained in Section 11.6 of Object-Oriented and Classical Software Engineering,
Seventh Edition, an FSM is a quintuple. In nonmathematical terms, an FSM consists of
states and the inputs that result in a transition from state to state. For object-oriented
modeling, however, we also want to incorporate the action that is to be taken on entering
a state.
Furthermore, this should appear as part of the statechart. This simplifies later develop-
ment, particularly during the object-oriented design phase. However, the resulting for-
malism will not be formal, a price we are willing to pay because OOA as a whole is a
semiformal technique.
12.3: Entity-class extraction consists of three steps: functional modeling, entity-class modeling,
and dynamic modeling. It is possible, in theory, to do the dynamic modeling step before
the entity-class modeling step. However, this is not advisable, because when the entity
classes are eventually extracted, major changes in the statechart are almost certain to be
required. The reason is that the statechart (essentially a finite state machine) cannot
represent or identify inheritance. Thus, the latest point at which classes can be introduced
is the start of the entity-class modeling
Move 1 floor in direction d
Elevator Event Loop
no command issued
Moving
elevator controller
sends move command
elevator controller sends
close doors message
no command issued
Elevator Door Event Loop
Close Doors
Open Doors
Open elevator doors
Close elevator doors
elevator controller sends
open doors message
12–3
12.4: It is possible (though not advisable) to use the rapid prototype as a way of determining
what the classes should be. Thus, classes would be introduced early in the requirements
workflow.
Alternatively, class modeling could precede use-case modeling during the object-oriented
analysis phase, and classes would then be introduced at the very beginning of the object-
oriented analysis phase. However, this approach would preclude experienced developers
from extracting the classes from the scenarios or using CRC cards.
12.5: A wide variety of formalisms could be used, both graphical and textual. All that is re-
quired is that the formalism should reflect the various states, transitions, and actions that
are involved.
However, such formalisms are less convenient to use. For example, the mathematical
formalism of Section 11.6 of Object-Oriented and Classical Software Engineering,
Seventh Edition is less suitable than the one used here. Textual formalisms are equally
unsuitable.
12.6: The principle of stepwise refinement requires as many decisions as possible to be post-
poned. All the operations that have to be included in the product (“methods”) must
eventually appear in the state diagram. However, assigning the methods to specific
classes can wait until the design phase. On the other hand, modeling becomes extremely
complex unless the attributes are assigned to their specific classes.
In fact, there is another good reason to wait until the design phase before allocating meth-
ods to classes, namely that the choice of architecture (for example, client-server) will
affect where the classes are physically located, and hence may affect how the operations
are organized into methods, and which methods should be allocated to which classes.
12.7: The purpose of noun extraction is to find the classes. The other parts of speech are irrele-
vant for that purpose.
An MSG Foundation staff member wants to update the expected annual return on an investment.
1. The staff member enters the new value of the expected annual return on the investment.
2. The information system changes the date on which the expected annual return was updated to that
day’s date.
Possible alternatives:
A. The staff member enters the investment number incorrectly.
B. The staff member enters a negative number for the new value of the expected annual return on the
investment.
Figure 12.4. An extended scenario of the use case Manage an Investment.
12–4
An MSG Foundation staff member wants to update the estimated annual operating expenses.
1. The staff member enters the new value of the estimated annual operating expenses.
2. The information system changes the date on which the estimated annual operating expenses
were updated to that day’s date.
Possible alternative:
A. The staff member enters zero or a negative number for the new value of the estimated annual
operating expenses.
Figure 12.5. An extended scenario of the use case Update Estimated Annual Operating
Expenses.
An MSG staff member inputs the new annual property tax for a mortgage (1, 2). The information system
updates the mortgage record (3), and informs the staff member that this has been done (4–6).
Figure 12.6. The flow of events of the interaction diagrams for updating the annual property tax (Figures
12.40 and 12.41 of Object-Oriented and Classical Software Engineering, Seventh Edition).
12.8: See Figure 12.4.
12.9: See Figure 12.5.
12.10: See Figure 12.6.
An MSG staff member inputs the new weekly income of the couple (1, 2). The information system
updates the mortgage record (3), and informs the MSG staff member that this has been done (4–6).
Figure 12.7. The flow of events of the interaction diagrams for updating weekly income (Figures 12.43
and 12.44 of Object-Oriented and Classical Software Engineering, Seventh Edition).
An MSG staff member inputs the new annual operating expenses (1). The information system updates
the record (2), and informs the MSG staff member that this has been done (3, 4).
Figure 12.8. The flow of events of the interaction diagrams for updating annual operating expenses
(Figures 12.48 and 12.49 of Object-Oriented and Classical Software Engineering, Seventh Edition).
An MSG staff member requests that the list of mortgages be printed (1, 2). The information system does
so (3), and informs the staff member that this has been done (3, 4).
Figure 12.9. The flow of events of the interaction diagrams for printing the list of mortgages (Figures
12.54 and 12.55 of Object-Oriented and Classical Software Engineering, Seventh Edition).
12.11: See Figure 12.7.
12.13: See Figure 12.8.
12–5
12.14: See Figure 12.9.
