The document details the analysis workflow within object-oriented development, emphasizing the importance of the elaboration phase and the iterative nature of development processes, which include requirements, analysis, design, implementation, and testing. It outlines the goals of analysis modeling, which focuses on capturing the business requirements and producing analysis models that are independent of technology, and the relationship between use cases and analysis and design workflows. Key methodologies for identifying analysis classes and the creation of interaction diagrams are also discussed as part of the modeling process.

1. 5 ANALYSIS
Examining the analysis workflow

2. 1 INTRODUCTION
2 METHODOLOGIES
3 MODELS AND UML
4 OBJECT CONCEPTS
5 ANALYSIS
2
6 SOFTWARE DESIGN

3. Our Process
3
 Reminder of object-oriented development process we are following in this
course is that there are four phases:
 Inception
 Elaboration
 Construction
 Transition
 Each phase consists of one or more iterations of the following workflows:
 Requirements
 Analysis
 Design
 Implementation
 Test
 In this section, we are going to examine the analysis workflow principally
in the context of the Elaboration phase.

4. 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 message2()
Requirements Model Analysis Model

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

6. Analysis Model
6
 The aim of the analysis workflow is to produce an
analysis model.
 This is a logical model that is technology-
independent (i.e., unconcerned with how it is to be
implemented).
 Itallows 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.

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

8. 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 «realize»
how classes PlaceOrder PlaceOrder
collaborate to realize
system functionality
Source: Object-Oriented Analysis with UML (Rational Software Corporation, 2001), p. 3-18.

9. Use Case Realizations
9
 Use case realizations consists of the following elements:
 Analysis class diagrams
 Show the analysis classes that interact to realize the use case
 Interaction diagrams
 Show collaborations and interactions between objects that
realize the use case.
 Use Case refinement
 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.

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

11. Analysis Class
11
 Analysis classes are classes that:
 Representa 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.

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

13. Discovering Domain Classes
13
 The best source for discovering these basic classes is
a high-level (100-300 words) problem statement or
system definition.
 Ifyou 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.

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

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

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

17. Step 2. Noun Phrase
17
Consolidation
 After identifying nouns and noun phrases,
 make plural terms singular
 eliminate duplicate terms
 consolidate synonyms into single term
 place list in alphabetic order

18. Noun Phrase Consolidation
18
actual cashflow order sell order
Assistant Trader pairoff method system
entry portfolio trade
forecasted cashflow Portfolio Manager trade data
General Ledger posting trade lot
level results Trader
After the consolidating noun phrases

19. 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 order sell order
Assistant Trader pairoff method system
entry portfolio trade
forecasted cashflow Portfolio Manager trade data
General Ledger posting trade lot
level results Trader
Analyze the list

20. Noun Phrase Analysis
20
actual cashflow order sell order
Assistant Trader pairoff method system
entry portfolio trade
forecasted cashflow Portfolio Manager trade data
General Ledger posting trade lot
level results Trader
actors
actions
out of the scope of the project
too vague

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

22. 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 Collaborations with other
are listed in this section. classes are listed here,
together with a brief
description of the purpose of
the collaboration.

23. CRC Cards
Class Name Client
23 Responsibilities Collaborations
Provide client
information.
Provide list of Campaign provides
campaigns. campaign details.
Class Name Campaign
Responsibilities Collaborations
Provide campaign
information.
Provide list of adverts. Advert provides advert details.
Add a new advert. Advert constructs new object.
Class Name Advert
Responsibilities Collaborations
Provide advert details.
Construct adverts.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 193.

24. Digression on UML Class & Object Notation
24
Customer
Customer Customer Name compartment
m_name
m_name
m_address
m_phone
m_address Attribute compartment
m_phone
getName()
getPhone() Operation compartment
«entity» stereotype
Customer
fred:Customer
fred:Customer
m_name=Randy
m_address=123 Any Ave Objects
m_phone=123-4567

25. UML Attribute Compartment
25
visibility name multiplicity: type=initialValue
optional mandatory optional
Customer
-m_name
-m_address
-m_phone: String
-m_age:int=0
+Children[]
#salary
+numCustomers static attribute
+ public visibility
- private visibility
# protected visibility

26. UML Operation Compartment
26
visibility name ( parameterName: parameterType, ...): returnType
optional mandatory optional optional
Customer
m_name
m_address
m_phone
numCustomers
getName() Customer
getPhone(): String
setName(name: String)
setPhone(phone: String): void Customer()
getNumCustomers(): int 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.

27. 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 0..*
-parent 1
Directory
-m_parent[1] : Directory
-m_subfolders[0..*] : Directory
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 152.

28. 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 object does not
1 * contain an Order link,
Order Product but an Order object
does contain a
collection of Product
navigable links.
1 * If no arrows, then
Order Product the relationship is
bidirectional.
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 154-5.

29. 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 B
+someMethod(in value : B)
+otherMethod() : B
+doSomething() 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.

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

31. Scenarios
31
 Ways of describing (not realizing) scenarios:
 using textual descriptions
 using activity diagrams

32. 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).

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

34. action join
state Check Schedule
Select Course
Check Pre- guard
requisites expression
initial
state
fork
[checks completed] [checks failed]
Assign to Resolve
Course Conflicts
[student added to the course]
Update Schedule
34

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

36. Exercise
36
[pending]
Enter Order
[aborted]
[approved]
Authorize Purchase Allocate Order Items Ship Order
[declined]
«trace»
This activity diagram is a
Place Order
refinement of the use case
[pending]
Enter Order
[aborted]
[approved]
Authorize Purchase Allocate Order Items Ship Order
[declined]

37. 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).

38. Exercise
38
Cancel Order
Item
[not pending]
Update Order Item Credit Account
[pending]
Release Inventory

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

40. Interaction Diagrams
40
 Two types
 Collaboration diagrams
 Emphasize structural relationships between objects.
 Sequence 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).
 Thusa collaboration diagram can be converted to a
sequence diagram, and vice-versa.

41. Interaction Diagrams
41
 In these diagrams, focus is on communication
between objects, not classes.
Student fred fred : Student : Student
class objects

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

43. UML Actions: Call and Return
43
Object1 : Customer Object2 : Order
action name()
other action call()
call action notation
Object1 : Customer
action name()
: Customer : Order
Object2 : Order action name() return value
return action notation

44. Call and Return Example
44
: Order : Shipper
calcShippingCost()
lookupCost()
shipping cost
: Order : Shipper
calcShippingCost("BC", 30)
lookupZone("BC")
return(15.50)

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

46. Sequence Diagram Example
46
:Home Page :Login Page :UserAccount
: Customer
clickLogin()
lifeline
displayLogin()
enterUserID()
validateLogin()
login okay
Focus of
control
displayLoginOkay()

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

48. Collaboration Diagram Example
48
1: clickLogin()
:Home Page
: Customer
3: enterUserID()
2: displayLogin()
5: displayLoginOk()
:UserAccount :Login Page
4: validateLogin()

49. Collaboration vs Sequence
49
Diagrams
 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
 Explicitlyshows time ordering of messages
 Better for visualizing overall flow in real-time systems
and complex scenarios.

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

51. Analysis in Context
51
message()
«
»
«
»
realized by message2()
«
»
«
»
Analysis Model
refined by
implemented by
message()
message2()
Design Model Implementation Model

52. 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
El aborati on
3 4
Construction
5 6 7
Transiti on
8
Requirem ents
Anal y s is
Des i gn
Implement ation
T es t

53. 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
 Additionaluse case realizations for any newly
discovered use cases.