Unit 3

Object Oriented analysis process

1. Identifying use cases
2. Classification
3. Identifying object
relationships,attributes and
methods
 Identifying use cases:
Objective
• Use case modeling and analysis
• Identifying actors
• Identifying use cases
• Developing effective documentation
 Identifying use cases
• Introduction
• Objective of analysis
– To capture complete, unambiguous , consistent
picture of requirements of system
– Separating system’s behavior from behavior
implementation
• What the system must do to satisfy users requirement and
needs
• Won't specify how to do it
• Requires to view the system from users perspective
 Cont.. Of introduction
• Transformation 1
– users need to problem statement and
requirement
• Tools to extract information about a
system
– examination of existing system documentation
– Interviews
– Questionnaire
– observation
 Why analysis is a difficult activity
• Analysis activity involves understanding
– problem
– Associated constraints
– Methods to overcome this constraints
• Iterative process
 Cont..
• Sources that makes analysis difficult
– Fuzzy descriptions
• Bcs of interpretation problem
– Incomplete requirements
• Due to users forgetting to identify them, High cost,
politics
– Unnecessary features
 Business object analysis:
understanding the business layer
• Process of
– understanding sys requirement
• Developing use case
– Discussing uses and objectives with users
– Understanding expected inputs, desired response
• Prototype
– Helps to understand how the system ’ll be used
– Establishing goals
• Outcome of this process
– Identifying classes
– Relationship
 Use case driven object oriented
analysis: the unified approach
Identify
Develop Develop classes , Refine
actors usecase & interaction relationships, &
activity diagram attributes, iterate
diagram methods
Build
prototype
 Business process modelling
• Not necessary for all project
• When required business process and
requirements can be modelled to any level
of detail
• Activity diagram support this modelling
• disadv
– Time consuming process
• Adv
– familiarity
 yes yes Go to
yes Go to counter
counter and check
and return out the
Return books
books
book?
yes
yes
Interlibrary
loan
borrow
no
book?
no
Search for
book

yes Do
Do search
research
on topics
no

yes Read news

Read news paper and
paper?
no magazine

Acivty diagram –library system

 Use case model
• Senarios for understanding the system
• Interaction bw user and system
• Captures users goal and systems responsibility
• Used to discover classes and relationship
• Developed by talking to users
• Use case model
– Provides external view of the system
• Object model (UML class diagram)
– Provides internal view
 Use cases and microscope
• A use case is a sequence of transaction in a
system whose task is to yield results of
measurable value to an individual actor of the
system
• Actor
– Role played by the user with respect to the system
– Single actor may perform many use cases
– Can be external system
– Can be one get value from the system, or just
participate in the use case
 Borrow books uses

Check library card

extends
uses
Get an
interlibrary loan
uses

Return books
member Circulation clerk

Do research

Read books and news paper

Purchase supplies
supplier
 Uses and extends association
• Uses
– common sub flows are extracted and
separate use case is created
– Relationship bw usecase and extracted one is
called uses relationships
• Extends
– Used when use case is similar to other, but do
bit more or more speciliazed
• Abstract use case
– No initiating actor
– Used by concrete use cases
• concrete use cases
– Interacts with actors
 Identifying actors
• Actor
– Role played by the user
• Actors found thru answers of following question
– Who is using the system
– Who is affected by the system
– Which group needs help from the system
– Who affects the system, which user groups are needed by the
system to perform it functions
– Which external h/w or other systems use the system to perform
tasks
– What prob does this application solve and for whom
– How do users use the system(ie use case), and what they are
doing with the system
• Accounts need not be human. It is an external system
 Identifying actor (cont..)
• Two-three rule
– Used to identify the actors
– Start with naming at least 2 or 3 , people who
could serve as the actor in the system.other
actor can be identified in the subsequent
iteration
 Guideline for finding use cases
• For each actor, find the tasks and function that
the actor should be able to perform or that the
system needs the actor to perform (use case)
• Name the use cases
• Describe the use cases briefly by applying terms
with which the user is familiar (to make less
ambiguous)
• Each use case has only one main actor
– Isolate users from actor
– Isolate actors from other actors(separate
responsibilities)
– Isolate use cases that have different initiating actors
How detailed must a use case be? When to
stop decomposing it and when to continue
• Develop system use case diag
• Draw package
– to represent business domains of the system . for
each package create child use case diagram
• Prepare at lest one senario for each use case
– Each scenario shows different sequence of
interaction , with all decisions definite
• When the lowest use case level is arrived, which
can’t be broken further, sequence and
collaboration diagram is drawn
Dividing use case into package
• Whole system is divided into many
packages
• Each package encompasses multiple use
cases
Developing effective documentation
• Effective document provides
– Reference point
– Form of communication
– Reveals issues and gaps in the analysis and
design
Guidelines for developing effective
document
• Common cover
– Identify document
– Current version
– Individuals responsible for doc
• 80-20 rule
– 80% of work can be done with the 20% of doc.
– 20% -easily accessible, 80%-only who needs can
access
• Familiar vocabulary
• Make the doc as short as possible
• Organize the document