5
ANALYSIS
Examining the analysis workflow
1
INTRODUCTION
2 METHODOLOGIES
3 MODELS AND UML
4 OBJECT CONCEPTS
5
ANALYSIS
6 SOFTWARE DESIGN
2
Our Process
3

Reminder of object-oriented development process we are following in this
course is that there are four phases:





Each phase consists of one or more iterations of the following workflows:






Inception
Elaboration
Construction
Transition
Requirements
Analysis
Design
Implementation
Test
In this section, we are going to examine the analysis workflow principally
in the context of the Elaboration phase.
Analysis Workflow
4


In the requirements workflow, use case model and other
artifacts (screen prototypes, glossary, etc) are used to
build an initial model based on the users’ requirements.
In the analysis workflow, the requirements are analyzed
in more detail, so as to begin the description of the
internal structure and behavior of the proposed system.
Use Case Realizations
Use Case Model
message()
Glossary
Prototypes
Requirements Model
message2()
Analysis Model
Analysis versus Design
5


The boundary between analysis and design can be
quite vague; they often overlap.
Rules of thumb for analysis modeling:
Analysis model is always in the language of the business
 Concentrate on capturing the big picture (don’t get bogged
down in details).
 Focus on the problem domain (business requirements), not
the solution domain (detailed design considerations).



e.g., don’t worry about implementation classes such as database
access or user interface classes.
Keep the model simple.
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 101.
Analysis Model
6


The aim of the analysis workflow is to produce an
analysis model.
This is a logical model that is technologyindependent (i.e., unconcerned with how it is to be
implemented).
 It
allows developers to focus on the problems to be
solved.
 Ignoring technology makes it less likely that old ways of
doing things will be carried forward into the design of
the new system.
Analysis is Use Case Driven
7

The use cases defined in the requirements model
are the basis for the entire analysis and design
workflows.
Use Case Realizations
message()
message2()
Use Case Model
Analysis and Design Models
Use Case Realizations
8


Use cases are realized in subsequent analysis and design.
That is, use-case realizations describe how a use-case is
performed ("realized") in terms of interacting objects in the
design model (that is, in terms of how objects collaborate).



Use case realizations tie together the use cases with the classes
and relationships of the domain model.
That is, a use case realization specifies which classes must be built
to implement each use case.
Development of use case realizations is the main goal of
analysis; refining these use case realizations is the main goal
of design. Use Case
realizations show
how classes
collaborate to realize
system functionality
«realize»
PlaceOrder
Source: Object-Oriented Analysis with UML (Rational Software Corporation, 2001), p. 3-18.
PlaceOrder
Use Case Realizations
9

Use case realizations consists of the following elements:

Analysis class diagrams


Interaction diagrams


Show collaborations and interactions between objects that
realize the use case.
Use Case refinement



Show the analysis classes that interact to realize the use case
New info may be discovered that requires the original use case
to be updated.
Activity diagrams may be used to illustrate scenarios in the use
case.
Use case realization is a process of refinement.

Take a use case and then model how the behavior specified
in the use case will be realized by collaborations and
interactions between instances of domain classes you have
identified.
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 200-1.
Analysis Model
10

The two key artifacts are produced in analysis
model:
 Use
case realizations
 These
illustrate how instances of the analysis classes can
interact to realize system behavior specified by a use case.
 Analysis
class diagram
 Integrates
the classes discovered in the use case realizations
into a single diagram that shows methods and attributes
uncovered in the realizations.
Analysis Class
11

Analysis classes are classes that:
 Represent
a clear and concise abstraction in the
problem domain.
 i.e.,
these classes represent the real-world things and
concepts related to the problem the system is being design
to solve.
 Should
map directly onto real-world business concepts.
 Should NOT be concerned with design considerations
such as performance, patterns, best practices, etc.

Also referred to as domain classes.
Finding Classes
12


There is no simple algorithm for finding the right
analysis classes.
Yet, there are techniques which can help you
discover these classes. They are:
 Noun/verb
analysis
 CRC analysis
Source: Meyer, Object Oriented Software Construction (Prentice Hall, 1997), p.
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 134-5.
Discovering Domain Classes
13

The best source for discovering these basic classes is
a high-level (100-300 words) problem statement or
system definition.
 If
you don't have this system definition, then you will
have to write one, in conjunction with the client/users.

You can also use other requirements model artifacts
as sources of information, in particular:
 the
use case model
 the glossary of terms.
Noun/verb analysis
14

You can use the grammatical inspection technique of
circling/highlighting/underling all the noun and
noun phrases (compound nouns or adjective+noun)
in the text.
 This

is sometimes called noun phrase identification.
You will probably find that:
 noun
and noun phrases become classes and attributes
 verbs and verb phrases become methods and relations
 possessive phrases indicate nouns should be attributes
rather than classes.
Step 1. Noun Phrase Identification
15
The Portfolio Manager shall be able to roll up portfolios on several levels.
A Trader shall be able to place orders, on behalf of a portfolio, that generate one or more
trades.
A Portfolio Manager shall be able to select a pairoff method in conjunction with placing a
sell order.
The entry of a trade shall generate forecasted cashflows associated with the given trade
lot.
The system shall match up actual cashflows with forecasted cashflows.
The system shall automatically generate appropriate postings to the General Ledger.
The system shall allow an Assistant Trader to modify trade data and propagate the results
accordingly.
Identify the nouns and noun phrases in this example system definition.
Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18
Noun Phrase Identification
16
The Portfolio Manager shall be able to roll up portfolios on several levels.
A Trader shall be able to place orders, on behalf of a portfolio, that generate one or
more trades.
A Portfolio Manager shall be able to select a pairoff method in conjunction with
placing a sell order.
The entry of a trade shall generate forecasted cashflows associated with the given trade
lot.
The system shall match up actual cashflows with forecasted cashflows.
The system shall automatically generate appropriate postings to the General Ledger.
The system shall allow an Assistant Trader to modify trade data and propagate the
results accordingly.
Identify the nouns and noun phrases in this example system definition.
Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18
Step 2. Noun Phrase
Consolidation
17

After identifying nouns and noun phrases,
 make
plural terms singular
 eliminate duplicate terms
 consolidate synonyms into single term
 place list in alphabetic order
Noun Phrase Consolidation
18
actual cashflow
Assistant Trader
entry
forecasted cashflow
General Ledger
level
order
pairoff method
portfolio
Portfolio Manager
posting
results
After the consolidating noun phrases
sell order
system
trade
trade data
trade lot
Trader
Step 3. Noun Phrase Analysis
19

Now, remove:
references to the system itself or to its context
 nouns which appear out of the scope of the project
 nouns which are too vague
 nouns which represent actions.


Actors might be removed from our list of candidate
classes, and placed instead on the use case diagrams.
actual cashflow
Assistant Trader
entry
forecasted cashflow
General Ledger
level
Analyze the list
order
pairoff method
portfolio
Portfolio Manager
posting
results
sell order
system
trade
trade data
trade lot
Trader
Noun Phrase Analysis
20
actual cashflow
Assistant Trader
entry
forecasted cashflow
General Ledger
level
order
pairoff method
portfolio
Portfolio Manager
posting
results
actors
actions
out of the scope of the project
too vague
sell order
system
trade
trade data
trade lot
Trader
Step 4. Draw Initial Analysis Class
Model
21

If you can, draw an initial analysis class model showing just class
names, generalizations, associations, and aggregation.



At this stage, don't worry especially about multiplicity or composition,
since further analysis is often required to address questions about
multiplicity and composition.
The classes in your analysis class model are sometimes referred to as
entity classes.
Just as noun phrase analysis helped identify candidate classes, verb
phrase analysis can help identify class relationships.


The result can be a table showing each candidate associations with your
candidate classes.
e.g.,
Student enrolls in Course
Professor teaches Course
CRC Cards
22


Another way of discovering your analysis classes is to use CRC (Class
Responsibility Collaboration) cards.
CRC cards are often used within a team to brainstorm the allocation of
responsibilities to domain classes as well as for the discovery of relationship for
domain classes.
Class Name: Class name here
Responsibilities
Collaborations
Responsibilities of a class
are listed in this section.
Collaborations with other
classes are listed here,
together with a brief
description of the purpose of
the collaboration.
CRC Cards
Class Name
23
Client
Responsibilities
Collaborations
Provide client
information.
Provide list of
campaigns.
Class Name
Campaign provides
campaign details.
Campaign
Responsibilities
Collaborations
Provide campaign
information.
Provide list of adverts.
Add a new advert.
Class Name
Advert provides advert details.
Advert constructs new object.
Advert
Responsibilities
Collaborations
Provide advert details.
Construct adverts.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 193.
Digression on UML Class & Object Notation
24
Customer
Customer
m_name
m_address
m_phone
«entity»
Customer
fred:Customer
Name compartment
Customer
m_name
m_address
m_phone
Attribute compartment
getName()
getPhone()
Operation compartment
stereotype
fred:Customer
m_name=Randy
m_address=123 Any Ave
m_phone=123-4567
Objects
UML Attribute Compartment
25
visibility
optional
name
multiplicity: type=initialValue
mandatory
Customer
-m_name
-m_address
-m_phone: String
-m_age:int=0
+Children[]
#salary
+numCustomers
+
#
static attribute
public visibility
private visibility
protected visibility
optional
UML Operation Compartment
26
visibility
optional
name ( parameterName: parameterType, ...): returnType
mandatory
optional
optional
Customer
m_name
m_address
m_phone
numCustomers
getName()
getPhone(): String
setName(name: String)
setPhone(phone: String): void
getNumCustomers(): int
Customer
Customer()
Customer(name: String)
constructors
Note: at the analysis level, you should not be worried about details like constructors,
parameters, data types, etc. These will show up in the design stage.
Reflexive Associations
27

A reflexive association is one in which a class has
an association with itself.
 This
means that a class has links to other objects of the
same class.
-subfolder
0..*
Directory
File
1
-parent
0..*
1
Directory
-m_parent[1] : Directory
-m_subfolders[0..*] : Directory
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 152.
Navigability
28


Navigability refers to ability to traverse from object
of one class to an object of another class.
Means messages can only be sent in the direction of
the arrow.
Thus, a Product
not navigable
Order
1
*
Product
navigable
Order
1
*
Product
object does not
contain an Order link,
but an Order object
does contain a
collection of Product
links.
If no arrows, then
the relationship is
bidirectional.
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 154-5.
Dependency
29



A dependency is a relationship between two elements where a change in
one, affects the other.
Typically used to indicate that one class uses another, but the usage is not
really an association.
Dependencies generated (in class diagrams) by:



An operation of class A needs a parameter of class B
An operation of class A returns a value of class B
An operation of class A uses an object of class B somewhere in its
implementation, but not as an attribute.
A
+someMethod(in value : B)
+otherMethod() : B
+doSomething()
B
void doSomething() {
...
B myB = new B();
// use myB in some way
...
}
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 162-3.
Scenarios
30


The process of realization often begins by looking
at use case scenarios.
A scenario is an instance of a use case.
 It
is one flow through a use case
 It is some combination of basic and alternate flows.
 "this


happened, then this, then this …"
Some people even write scenarios first, then write
the use cases.
Written scenarios can also be a way of
documenting test behaviors for the testing phase.
Scenarios
31

Ways of describing (not realizing) scenarios:
 using
textual descriptions
 using activity diagrams
Activity Diagram
32

Scenarios can be graphically described by using an
activity diagram.
These diagrams are the UML equivalent of a flow chart.
 They visually capture the step-by-step flow of a typical use
case description.
 Are also used in business process modeling



This is a preliminary requirements step in some methodologies. It is
used to help the analysts better understand how a business
operates.
Not as useful for illustrating message communication
between objects (we will use interaction diagrams for that).
Activity Diagrams
33

This diagram shows:
 action
states, which represent the execution of a step
within the flow of a use case.
 Transitions between those action states
 decisions for which guard conditions are defined
 forks, where flow of control is split into two or more
concurrent flows
 joins, where separate flows are joined.
action
state
join
Check Schedule
Select Course
guard
expression
Check Prerequisites
initial
state
fork
[checks completed]
Assign to
Course
[student added to the course]
Update Schedule
34
[checks failed]
Resolve
Conflicts
Exercise
35

Draw the activity diagram for the following use
case scenario:
Use Case: Place Order
Step 1. Enter the order (includes getting info about order
and payment method from customer)
Step 2. Authorize the purchase (requires verification that
the requirement funds can be obtained from customer
using the specified payment method).
Step 3. Allocate the order items from the inventory.
Step 4. Ship the order.
Source: Charles Richter, Designing Flexible Object-Oriented Systems with UML (Macmillan, 1999), p. 27.
Exercise
36
[pending]
Enter Order
[aborted]
[approved]
Authorize Purchase
Allocate Order Items
Ship Order
[declined]
«trace»
Place Order
This activity diagram is a
refinement of the use case
[pending]
Enter Order
[aborted]
[approved]
Authorize Purchase
[declined]
Allocate Order Items
Ship Order
Exercise
37

Draw the activity diagram for the following use
case scenario:
Use Case: Cancel Order Item
Step 1. Update that order item (check to see if the item is
still pending, and if so, change its status to cancelled.
Step 2. Credit the customer's account for that item.
Step 3. Release the inventory request for that item.
Note: Steps two and three can happen in either order (or
concurrently).
Exercise
38
Cancel Order
Item
[not pending]
Update Order Item
Credit Account
[pending]
Release Inventory
Interaction Diagrams
39

Interaction diagrams are a graphical representation of
how objects communicate with one another in a
scenario.
Static diagrams such as the class diagram and the use case
diagram contain no dynamic or temporal information.
 It can be quite difficult proceeding from initial static class
model to designing and implementing behaviors necessary
for an application.



Interaction diagrams help with this task.
Interaction diagrams are a vital part of realizing a use
case (along with the class diagram).

They model the collaborations and interactions between the
objects that realize a use case.
Interaction Diagrams
40

Two types
 Collaboration
 Emphasize
 Sequence
diagrams
structural relationships between objects.
diagrams
 Emphasize
the time-ordered sequence of messages sent
between objects.

Both diagrams are two different representations of
the same thing (i.e., the object interactions).
 Thus
a collaboration diagram can be converted to a
sequence diagram, and vice-versa.
Interaction Diagrams
41

In these diagrams, focus is on communication
between objects, not classes.
Student
class
fred
fred : Student
objects
: Student
Messages
42

How do objects communicate?


By sending messages (i.e., invoking a method).
A message is thus a communication between two
objects (or within one) what results in some activity.

This activity usually involves one or more actions.
Actions are executable statements that change values of the
attributes of an object or return a value.
 Are calls to an object's methods or properties


We will make use of two actions:
Call
 Return

Source: Kendall Scott, UML Explained (Addison-Wesley, 2001), p. 59-62.
UML Actions: Call and Return
43
Object1 : Customer
Object2 : Order
action name()
other action call()
call action notation
Object1 : Customer
action name()
: Customer
Object2 : Order
action name()
: Order
return value
return action notation
Call and Return Example
44
: Order
: Shipper
calcShippingCost()
lookupCost()
shipping cost
: Order
: Shipper
calcShippingCost("BC", 30)
lookupZone("BC")
return(15.50)
Sequence Diagram
45


A sequence diagram focuses on the time ordering
of the messages.
Objects appear along the top margin, with each
object having a lifeline, with an optional flow of
control on the rectangle.
Sequence Diagram Example
46
:Home Page
:Login Page
:UserAccount
: Customer
clickLogin()
lifeline
displayLogin()
enterUserID()
validateLogin()
login okay
displayLoginOkay()
Focus of
control
Collaboration Diagram
47


A collaboration diagram is spatially oriented with
an emphasis on the relationships between objects.
Similar to sequence diagram, except no lifeline and
focus of control.
Collaboration Diagram Example
48
1: clickLogin()
:Home Page
: Customer
3: enterUserID()
2: displayLogin()
5: displayLoginOk()
:UserAccount
:Login Page
4: validateLogin()
Collaboration vs Sequence
Diagrams
49

Collaboration Diagrams
 Shows
relationships and interactions
 Better for visualizing all of the effects on a given object
 Easier to use/draw for brainstorming

Sequence Diagrams
 Explicitly
shows time ordering of messages
 Better for visualizing overall flow in real-time systems
and complex scenarios.
Analysis Class Model
50


This is the final artifact of the analysis.
This is a revised class diagram that includes all the
responsibilities (operations) and attributes for all classes
discovered via the use case realizations.


You interaction diagrams indicate via the messages what
should be the operations and attributes you need to add to
your classes.
Remember that this is an iterative and incremental
process.

The class diagram and the interaction diagrams will be
modified repeatedly and in tandem as you work your work
through the analysis.
Analysis in Context
51
«
»
«
»
message()
realized by
«
»
«
»
message2()
Analysis Model
refined by
implemented by
message()
message2()
Design Model
Implementation Model
Analysis in the big picture
52


Recall that in the Unified Software Development
Process, there are four phases; in each phase there
is a analysis workflow.
What is produced during the analysis workflow
varies from phase to phase.
 Nonetheless,
most of the analysis will occur in the
elaboration phase.
Inception
1
2
Requirements
Analysis
Design
Implementation
Test
Elaboration
3
4
Construction
5
6
7
Transition
8
Analysis in the phases
53

Inception Phase
 CRC
sessions, noun phrase analysis to create domain
model

Elaboration Phase
 Use
case realizations
 Analysis class model

Construction Phase
 Additional
use case realizations for any newly
discovered use cases.