The document discusses the object oriented analysis process and identifying use cases. It describes identifying actors, developing use cases and interaction diagrams to capture system requirements from the user perspective. It provides guidelines for identifying use cases and actors, and developing effective documentation.

1. Unit 3
Object Oriented analysis process
2. Identifying use cases
3. Classification
4. Identifying object
relationships,attributes and
methods

2. Identifying use cases:
Objective
• Use case modeling and analysis
• Identifying actors
• Identifying use cases
• Developing effective documentation

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

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

5. Why analysis is a difficult activity
• Analysis activity involves understanding
– problem
– Associated constraints
– Methods to overcome this constraints
• Iterative process

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

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

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

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

10. yes yes Go to
yes Go to counter and
counter and check out
return the books
Return 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

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

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

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

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

15. • Abstract use case
– No initiating actor
– Used by concrete use cases
• concrete use cases
– Interacts with actors

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

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

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

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

20. Dividing use case into package
• Whole system is divided into many
packages
• Each package encompasses multiple use
cases

21. Developing effective documentation
• Effective document provides
– Reference point
– Form of communication
– Reveals issues and gaps in the analysis and
design

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