CS320 Lecture: Object-Oriented Analysis 8/2/96
revised 9/3/98
Materials: Transparencies: McGregor/Sykes p. 39
McGregor/Sykes p. 265
Handouts: ATM example problem requirements
ATM example use cases (partial)
ATM example use cases (remainder)
ATM example state diagram and interaction diagram
I. Introduction: The Software Life-Cycle and OO
- ------------- --- -------- ---------- --- --
A. As we noted on the first day, the title of this course is "Object
Oriented Software Development". That is, we want to look at how OO
technology impacts the entire process of software development.
B. As you recall from CS122, software has a life-cycle - i.e. its
development and maintenance involves a number of phases. The following
is the structure of a traditional or "waterfall model" software
life-cycle.
TRANSPARENCY - MCGREGOR/SYKES P. 39
1. The diagram suggests that we have a series of phases that are done
in rigid time sequence - i.e. first the analysis is phase is completed,
then the design phase, then the coding phase ... The completion of
each phase is marked by the formal approval of appropriate documents,
which must occur before the next phase can begin.
2. In reality, as many writers have pointed out, following this model
rigidly doesn't work very well.
a. Discoveries made during later phases may necessitate re-thinking
earlier phases. For example:
i. An ambiguity in the requirements analysis may come to light
during the design phase, when it is discovered that there is no
clear answer as to what is the right way to do something.
ii. Problems encountered during unit or integration testing may be
attributable to errors in the design or even in the requirements.
(The software fulfills the requirements as stated, but obviously
doesn't do what is intended and should have been stated.)
etc.
b. In particular, it is not uncommon to discover that after software
is completely built the user looks at the finished product and says
"but that's not really what I wanted". Users often find it hard to
know precisely what they want, or to communicate what they want to
developers; and developers often find it hard to understand the
user's needs because of lack of familiarity with the problem domain.
c. Of course, the longer the time interval between the place where the
problem arises and the place where it is discovered, the more costly
it is to fix the problem. In fact, whole projects have been
abandoned as a result of serious flaws being discovered so late that
the only way to fix them is to redo a large part of the project.
3. As a result, many software developers have abandoned the traditional
waterfall model in favor of alternate models, which take a more
incremental approach.
a. One approach involves rapid-prototyping. As part of the analysis
phase, the developer builds a "rapid prototype" that has much of
the look and feel of the finished product, but provides only a
subset (or even a simulation) of the functionality. By working
with this, the user can determine whether the developer has
correctly understood his needs before a lot of development effort
has been invested.
b. Another approach involves incremental development. The entire
process is carried out, but only for a minimal subset of the
functionality of the finished product. Then additional functions
are analyzed, designed and added to the project over time until
full functionality is reached.
4. It turns out that OO techniques lend themselves particularly well to
approaches like this. Grady Booch - a leading writer on OO design -
speaks of what he calls "Round-trip gestalt design":
"This style of design emphasizes the incremental and iterative
development of a system through the refinement of different yet
consistent logical and physical views of the system as a whole. We
suggest that round-trip gestalt design is the foundation of the
process of object-oriented design". (p. 188)
C. Regardless of what development model is followed, of course, certain
tasks will need to be done - whether all at once, iteratively, or
incrementally.
1. Analysis. The goal of this task is to UNDERSTAND the problem.
2. Design. The goal of this task is to develop the OVERALL STRUCTURE
of a solution to the problem in terms of individual, buildable
components and their relationships to one another.
3. Implementation. The goal of this task is to actually BUILD the
system as designed.
4. Testing. The goal of this task is to ENSURE that the individual
components and the system as a whole do what they are supposed to do
(which involves identifying their shortcomings and fixing them.)
II. OO Analysis
-- -- --------
A. We have said that the goal of the analysis phase of software development
is UNDERSTANDING of the problem.
1. Obviously, this must take place in the mind of the analyst(s); but it
also must be documented in some form, especially if - as is often the
case - people other than the analyst(s) are involved in later phases
of the project.
2. Typically, this documentation takes the form of one or more MODELS of
the system being analyzed.
a. A model is simply a representation of a system.
b. For complex problems, more than one model is often needed - each
focussing on a different aspect of the system.
Example: Suppose one were building a controller for traffic lights
that are to be activated by sensors embedded in the road.
i. One model needed as part of this analysis would focus on the
relationships between the various objects comprising the system -
e.g. each sensor is embedded in a particular traffic lanes, and
each light controls the flow of traffic in a particular lane.
Further, individual lights are related to one another by
constraints such as one must be red if the other is green, etc.
(This is sometimes called the OBJECT MODEL of the system.)
ii. Another model needed as part of this analysis would focus on the
dynamic behavior of the system - e.g. when a light turns green
it must stay green for a certain period of time, and before it
turns red it must turn amber for a certain period of time.
(This is sometimes called the DYNAMIC MODEL of the system.)
iii. Another model needed as part of this analysis would focus on
control issues - what is the relationship between the state of
the sensors and the sequencing of the lights etc? What
mechanisms are needed to allow manual control of the system
under special circumstances?
(This is sometimes called the FUNCTIONAL MODEL of the system.)
B. Over the years, software engineers have developed a large array of
analysis tools that can be used for modelling a system.
1. Each tool is useful for modelling certain aspects of a system; and
different sets of tools will be appropriate for different problems.
2. Some of these tools are discussed in the software engineering course or
other courses - e.g.
a. Data flow diagrams
b. Finite state automata
c. Entity-relationship diagrams
d. Data dictionaries
3. These tools have typically been developed in the context of the
structured/procedural software development paradigm - but are still
useful when doing OO development.
C. For the rest of this part, we want to focus on analysis techniques
that are particularly relevant to OO development. Such techniques
focus on discovering three things:
1. The objects and classes that are logically a part of the problem
domain, or that need to be a part of a solution to the problem.
2. The relationships that exist between these objects and classes.
3. The way that objects undergo state changes and/or interact with
each other over time.
D. We note, before proceeding, that this kind of analysis can occur at two
levels.
1. DOMAIN ANALYSIS is concerned with modelling the problem's domain,
without regard to the specific problem that is to be solved - i.e.
modelling features of the domain that could be common to many
applications.
2. APPLICATION ANALYSIS is concerned with modelling the requirements of
the specific problem that is to be solved.
3. The reason for analyzing at these two levels is to facilitate
re-use: to the extent that our design is based on a general
understanding of a particular domain, as opposed to the specifics of a
particular application, components of our system are likely to be
re-usable in subsequent applications dealing with the same domain.
Example: in the general domain of traffic lights, a traffic light can
have quite a few different indications:
- the standard round red, amber, and green lights
- but also green arrows pointing left, right, and straight
ahead, plus walk and don't walk lights
Even if our particular application only called for the standard three
round colors, it would be beneficial to allow for these other
possibilities in the components of the system that model traffic lights
to facilitate possible later re-use in another application.
E. If one reads various books on OO analysis, one discovers quite a number
of different models that can be developed as part of analyzing a problem.
For our purposes, though, we will focus on just three such modelling
approaches.
1. Domain object modelling
a. Based on looking at the domain, not just the specific application -
a form of DOMAIN ANALYSIS.
b. Concerned with static relationship of objects and classes that are
naturally part of the domain - a form of OBJECT MODEL.
2. Use case modelling.
a. Based on looking at the requirements for a specific application -
a form of APPLICATION ANALYSIS.
b. Concerned with behavior of the system as it used to do various
things - a form of FUNCTIONAL MODEL.
3. State transition modelling.
a. Also a form of APPLICATION ANALYSIS.
b. Concerned with how an object changes state over time - a form of
DYNAMIC MODEL.
4. Interaction modelling
a. Also a form of APPLICATION ANALYSIS
B. Another aspect of the DYNAMNIC MODEL
F. For most of our examples in the next few lectures, we will use the
continuing example of developing software for an automated teller machine
(ATM). We will assume that the system we are to design has the following
requirements.
DISTRIBUTE/GO OVER ATM REQUIREMENTS HANDOUT
III. Doing OO Analysis
--- ----- -- --------
A. One important step in analyzing a problem is to LIST THE OBJECTS that are
part of the problem's domain. In general, objects may be:
1. Tangible things (people, places, physical entities etc.)
Example: customer, ATM location, ATM machine itself, receipt, log
2. Abstract things (organizations, concepts, roles)
Example: bank, bank branch, bank account, account money is transferred
from and account money is transferred to
3. Events
Example: deposit, withdrawl, transfer
Note: A deposit, withdrawl or transfer is an event that leaves a
permanent record (it is listed on the monthly statement).
4. Interactions
Example: ATM usage session
Note: A complete ATM usage session involves entering a card and PIN,
doing one or more transactions and then ending the session, each
of which involves exchange of information between the customer
and the ATM. The session itself leaves no permanent record over
and above the individual transactions, which is why we classify
it as an "interaction" rather than as an "event".
B. One good place to look for possible objects is to consider the NOUNS
that are used when describing the problem domain and/or the particular
problem that is to be solved.
1. Example - note marked words the following statements that occur in the
problem description for our example ATM machine. (Each noun marked
just once the first time it occurs.)
"A CUSTOMER must be able to make a DEPOSIT to any ACCOUNT linked to
the CARD, consisting of CASH and/or CHECKS in an ENVELOPE ...
The ATM will provide the customer with a printed RECEIPT for each
successful TRANSACTION, showing the DATE, TIME, machine LOCATION,
TYPE of transaction, ACCOUNT NUMBER(S), and AMOUNT."
2. Not every noun will end up being an object though - we need to test
to see if it represents something that has the essential properties
of an object: state, behavior, and identity.
Example: ASK FOR EACH - does it have state, behavior, identity?
Customer Y Y Y
Deposit Y Y Y
Account Y Y Y
Card Y Y Y
Cash Y N ?
Check Y ? Y
Envelope Y ? Y
Receipt Y Y Y
Transaction Y Y Y
Date Y N N
Time Y N N
Location Y N N
Type Y N N
Account Number Y N N
Amount Y N N
In this system, we would not be likely to model items like a date,
time, location, transaction type, account number, or amount as
objects in their own right - rather, we would likely treat them as
attributes of a transaction. (In general, information that can be
adequately represented by a simple atomic value such as as a number or
a string will often end up as an attribute of some object, rather than
as an object in its own right, since such entities seldom have
behaviors or distinct identities.)
Our system does not deal directly with cash and checks, because
verification of the contents of an envelope is done manually - but
even if we did cash would be unlikely to be an object because it
does not have identity (it just ends up as a number on a deposit
slip). Checks are questionable - they do have identity but - at
least in the context of this system - not behavior. The same is
true of Envelope.
3. One should also look for adjectives and verbs that imply nouns that
are not present, and one should likewise think about things that are
not explicitly stated but are implied.
a. Example: suppose that the description had said "able to deposit an
envelope" rather than "make a deposit of an envelope". The whole
process still constitutes an event - a deposit - even though the
word "deposit" is present as a verb, rather than as a noun.
Note, in particular, that verbs that describe an interaction
with the system (e.g. "deposit") often describe an object, even
if no noun is present.
b. Example: suppose that the description had ended with the word
receipt - i.e. it said nothing about the balance of the account.
The existence of an account is still implicit even though the word
does not occur explictly.
C. The approach we have just been discussing is basically a form of domain
analysis. Now we want to look at an approach that keys in on the
specific requirements for a particular application: the USE CASE
approach developed by Ivar Jacobson.
1. The basic idea here is to begin by looking at the system requirements
in order to identify:
a. Actors - people (or sometimes other systems) that must use the
system that is to be built. Note that the same person may need to
be regarded as two or more actors if he relates to the system in
two or more roles.
Actors may further be classified as primary and secondary.
b. Use cases - ways in which the actors use the system
2. Example: ATM
a. Actors:
i. Primary: customer
ii. Secondary: operator
(Note: the same person may be a customer at one time and an
operator at another - but the roles are distinct, so they are
considered two different actors)
b. Use cases:
i. Customer: overall session, depositing money, withdrawing money,
transferring money, balance inquiry
ii. Operator: removing printed log, refilling cash dispenser.
3. For each use case, we now write a description of the sequence of
events that constitute that case, incorporating the user's stated
requirements.
a. Example: ATM session
HANDOUT - JUST FIRST PAGE
b. Note that one of the steps (performs transactions) actually
involves a series of subcases.
Example: ATM cash withdrawl:
ON HANDOUT
c. The above illustrates an important point about use cases: they
typically follow a normal pattern, but have to allow for variations
in individual cases.
i. The customer may enter an incorrect PIN.
ii. The bank may disallow the withdrawl for other reasons (e.g.
insufficient funds).
iii. The customer may cancel the transaction in the early stages
by pushing the "Cancel" button.
etc.
These variations can be accounted for either directly in the use
case (if this happens, then ...) or by creating additional
subcases. (In particular, the case of an improper PIN might well
be implemented as a subcase, since a similar pattern will occur
for all types of transactions.)
NOTE INVALID PIN USE CASE ON HANDOUT
4. Class exercise
a. Develop use cases for other types of transactions (deposit,
transfer of money from one account to another, balance inquiry)
b. HANDOUT remainder of use cases
5. As a final point, we note how use cases can help us identify objects.
a. Note how most of the domain objects we identified previously
showed up in the use case descriptions we discussed. (In fact, a
domain object that doesn't show up in any use cases may end up
being one that we don't actually have to incorporate in our
system.)
b. In addition, we will typically want to associate an object with each
use case that exists while that case is active, and whose internal
state keeps track of information we need as we progress through the
case.
Example: A session object will be active from the time a customer
inserts a card until the customer indicates he/she desires
no further transactions, and will keep track of the
customer's card number and PIN.
Example: A transaction object will be active from the time a
specific transaction is selected until it either completes
or fails, and will keep track of information such as the
specific account(s) being accessed, the amount of money
involved, etc.
D. Often, while we analyze a system, we discover that some objects undergo
defined state transitions over time, which is an important part of the
dynamic behavior of the system.
1. What objects in our ATM example fall into this category? ASK
a. Individual sessions pass through a series of states.
b. Individual transactions also pass through a series of states.
2. We will develop a state transition diagram for a session.
a. Referring to the use case for a session, what distinct states
can we identify?
- Initial start up
- Asking for PIN
- Session aborted (Card not successfully read)
- Asking for transaction choice
- Performing transaction
- Reporting a failed transaction
- Asking if customer wants another transaction
- Session over
b. What events lead us from state to state? (Develop diagram)
Card read PIN Choice
Initial ------------ Asking ------- Asking for ---------- Performing
| succesfully for PIN read trans choice made transaction
| ^ | |
| Card | Yes ----------- | Failed
| read | |Succeeded |
| fails Asking do <----- v
v another? <-------------- Reporting
Aborted | Acknowledged failure
| No
v
Done
HANDOUT STATE DIAGRAM FROM WEB
E. Another thing one often discovers is that objects interact back and
forth with various other objects in a time sequence. This can be
modelled by an interaction diagram.
HANDOUT INTERACTION DIAGRAM
IV. Analysis Examples To Work as a Class
-- -------- -------- -- ---- -- - -----
A. Suppose we were developing a new registration system for the Gordon
College registrar.
1. Domain Analysis
a. What kinds of objects are found in the domain of this system?
ASK
b. What relationships exist between these objects?
ASK
2. Use Case Analysis
a. What actors would use this system? (Note: actor is based on role,
so we can have several kinds of student actors depending on the
reason for the student's interaction with the system.)
ASK
b. What use cases can we identify for these actors?
ASK
c. Develop use case for a student signing up for courses for the
next semester.
B. (From McGregor and Sykes). Consider the development of a program to
play the game of tic-tac-toe.
1. Domain Analysis
a. At first glance, the analysis of this problem appears rather simple.
However, recalling that one of the goals of OO is to facilitate
re-use, we want to do our domain analysis in such a way that as much
as possible of what we develop can be used for other games as well.
i. Can we identify a larger domain of games of which tic-tac-toe is
one instance?
ASK
ii. TRANSPARENCY: McGregor and Sykes p. 265
b. What kinds of objects are found in the domain of strategy board
games?
ASK
c. What relationships exist between these objects?
ASK
2. Use Case Analysis
a. What actors would use this system?
ASK
b. What use cases can we identify for these actors?
ASK
c. Develop use case for a player making a move.
Copyright ©1998 - Russell C. Bjork