Você está na página 1de 42

Functional View

Use Case (Functional


Model)

The challenge to the analyst is to


identify the real functional
requirements that will satisfy the real
user's real business needs.

The use case approach is an especially


effective technique for deriving
software requirements, analysis
models, and test cases.

Use Case (Functional


Model)

Use cases were introduced as part of


an object-oriented development
methodology by Ivar Jacobson in
Object-Oriented Software Engineering

Each use case describes a scenario in


which a user interacts with the system
being defined to achieve a specific
goal or accomplish a particular task.

Use Case (Functional


Model)

A use case diagram establish the


capability of the system as a whole.

Components of use case diagram:


Actor
Use case
System boundary
Relationship
Specification

ACTOR:
What is an actor?

An actor is some one or something that must


interact with the system under development
UML notation for actor is stickman, shown
below.

Customer

Manager

Cashier

More about an actor:

ACTOR:

It is role a user plays with respect to system.

Actors are not part of the system they represent


anyone or anything that must interact with the
system.

Actors carry out use cases and a single actor may


perform more than one use cases.

Actors are determined by observing the direct


uses of the system,

ACTOR:
Contd

Those are responsible for its use and maintain


as well as other systems that interact with the
developed system.

An actor may
- input information to the system.
- receive information from the system.
- input to and out from the system.

ACTOR:
How do we find the actor?

Ask following questions to find the actors:


Who uses the system?
Who installs the system?
Who Starts up the system?
What other systems use this system?
Who gets the information from the
system?
Who provides information to the system?

Actor is always external to the system. They


are never part of the system to be developed.

ACTOR:
4-Categories of an actor:

Principle : Who uses the main system functions.


Secondary
: Who takes care of administration &
maintenance.
External h/w : The h/w devices which are part of
application
domain and must be used.
Other system: The other system with which the system
must
interact.

USE CASE:

What is USE case?


A use case is a pattern of behavior, the
system exhibits
Each use case is a sequence of related
transactions performed by an actor and
the system in dialogue.
USE CASE is dialogue between an actor
and the system.
Withdrawal of cash
Examples:
Open new account
from ATM

USE CASE:
More about USE CASE:

They model a dialog between actor and system.


A use case typically represents a major piece
of functionality that is complete from
beginning to end.
Most of the use cases are generated in initial
phase, but you find some more as you proceed.
A use case may be small or large. It captures a
broad view of a primary functionality of the
system in a manner that can be easily grasped
by non technical user.

USE CASE:
Contd

A use case must deliver something of value to an


actor.
The use cases may be decomposed into other use
cases.
Use cases also present a good vehicle for project
planning.

USE CASE:
How do we find the use cases?

What functions will the actor want from the


system?

Does the system store information? What actors


will create, read, update. Or delete that
information?

Does the system need to notify an actor about


changes in its internal state?

SYSTEM BOUNDARY:
What is System Boundary?

It is shown as a rectangle.
It helps to identify what is external verses
internal, and what the responsibilities of the
system are.
The external environment is represented only by
actors.

A Use case diagram of the


business
Place Order
Cancel Order

Catalog
Custom
er

Cancel Order
Item

Return Order
Item
Catalog Order System

RELATIONSHIP:
What is Relationship?

Relationship between use case and actor.


Communicates
Relationship between two use cases
Extends
Uses (include)
Generalize
Notation used to show the relationships:

<<

>>

RELATIONSHIP:
<<uses>> or <<include>>:

A uses relation from use case A to


use case B indicates that the an
instance of the use case A will also
include the behavior as specified by
B

RELATIONSHIP:

<<extends>>:
An extends relationship from use
case A to use case B indicates that
an instance of use case B may
include the behavior specified by A

<<Uses>> Relationship

Cancel Order

<<uses>>

Cancel Order
Item

<<extends>>
Relationship

Add
Customer

<<extends>>

Place Order

Uses V/s Extends

A uses B means that A always


invokes B.

B extends A means
that A sometimes
<<uses>>
A B
invokes
B

<<extends>>

<<generalize>>
ralationship

The third form of relationship among use


cases,
ageneralization/specializationrelationship
exists.
A given use case may have common
behaviors, requirements, constraints, and
assumptions with a more general use case.
In this case, describe them once, and deal
with it in the same way, describing any
differences in the specialized cases.

Notation is

User

Customer

Administrator

Specification

Generic format for documenting the use case:

- Pre condition:

Use case :
Actors
:
Purpose :
Overview :
Post condition:

If any
Name of the case.
List of actors(external agents), indicating who
initiates the use case.
Intention of the use case.
Description.
If any

Typical Course of Events:


ACTOR ACTION
: Numbered actions of the actor.
SYSTEM RESPONSE : Numbered description of system responses.

24

USE CASE documentation example:


The following use case describes the process of
opening a new account in the bank.
Use case
:Open new account
Actors
:Customer, Cashier, Manager
Purpose
:Like to have new saving account.
Description :A customer arrives in the bank to open the new
account. Customer requests for the new account
form, fill the same and submits, along with the
minimal deposit. At the end of complete successful
process customer receives the passbook.

25

Activity Diagram

Use case diagram defines the actors, use


cases and relationship between them but it
contain no information about the dynamics of
these function:

Suppose one use case uses several use cases. You


do not see in what order those are used.
Suppose one use case extends another. You do not
see under what conditions the extension occurs

Activity diagram provides solution for these


deficiencies.

Activity Diagram

Shows control/data flows from one


activity to another
Emphasizes the flow of control
among objects
Purpose
Model business workflows, flow control
within a system, and operations
Captures dynamic behavior (activityoriented)

Notations
Notation
Activity Name

Meaning
Activity
Work Flow /
Transition
Start
Stop
Condition
Fork
Join

Activity Diagrams

An Activity diagram shows the workflow of


activities
An Activity is modeled as Capsule with the
activity name enclosed.
Transition
X

Activity Y follows Activity


X

Conditional Activities
(Branching)

[ i==0
]

[ i !=0

Nested Activities
X

[ i==0
]

Y1

[ i !=0

[ i>0 ]

Y2

Repeated Activities

For each widget


produced by x

Activity X is followed by multiple


Activity Ys

Parallel Activity
Y1
X

Z
Y2

Y2

Y2

Y2

[Y1 and either Y2


or Y3]

Synchronization
bars

Event

In activity diagram communication


between object is model as Event.
Notation for event is
Event Name

Event Sent

Event
Name
Event Received

Activities in Placing
Order
1. Entering the order, which involves taking

information about the order and the payment


method from customer

2. Authorizing the purchase, which requires


verification of funds

3. Allocating the order items from inventory


4. Shipping the order

Activity diagram for


Placing Order

Enter Order
[denie
d]

[abort
ed]

[committe
d]

Ship Order

[approve
Authorize Funds d]

Allocate
Inventory

<<trace>> & <<refine>>


Relationship

<<trace>>:- Indicates a design


refinement.

<<refine>>:-indicates any other


kind of refinement

Refined Activity diagram for Placing


Order
Place Order
<<trace>>

Enter Order

[committe
d]

Ship Order

[denie
[approved
Authorize
Funds
d]
]
[aborte
d]

Allocate
Inventory

Refined Activity diagram for Placing


Order with Events
Place Order
<<trace>>

Enter Order

[committ
ed]

Ship Order

[denie
[approve
Authorize Funds
d]
d]
Allocate
Inventory

[abort
ed]

<<trace>>
Request
Item

:Product
Warehou
se

Item
Available

*
For each order item

Update Order
Item

Activity diagram for Cancel Order


Item
Cancel Order
Item
<<trace>>
Check Order
Status

[not pending]

Credit
Account

Release
Inventory

Activity diagram with


Swimlanes

You can extend the activity diagram


to show exactly who carries out what
activity, by dividing it into
Swimlanes
Region 1

Region 2

Region 3

Region 4

Activity diagram with


Swimlanes
Place Order
<<trace>>
Order Entry

Finance

Enter Order

Inventory
Management

[committe
d]

[denie
[approved
Authorize Funds]
d]
[aborte
d]

Shipping

Allocate
Inventory

Ship Order

Você também pode gostar