3/15/2013

Object-Oriented Analysis Process

OOA Process
The OOA phase of the unified approach uses actors and use cases to describe the system from the users perspective. Consists of the following steps:
Identifying the actors Identifying the use cases Develop the use case diagram Prepare the use case documentation Prepare activity diagram Prepare interaction diagram Prepare state transition diagram

3/15/2013

Models and Diagrams

Use Case Diagram

shows a set of external Actors and their Use Cases connected with communication associations The communication associations between the Actors and their Use Cases define the boundary between the system and its external environment.

3/15/2013

Use Case Diagram Components: The System

A boundary separates what is outside the system from what is inside the system defines what must be designed and what must be accommodated in the design.

Use Case Diagram Components: The Actors

Represent the entities that interact with the system. Typically represents a role that a user can play. Actors can represents entities other than user roles.
Eg. External systems and hardware devices.

External to the system. Actors may have a generalization relationship.

6

3/15/2013

Run Applications

Install Applications

A User can Run Applications. A Super User can Install Applications and Run Applications, since a Super User is a specialization of User.

User

Super User

Use Case Diagram Components: The Use Cases

A behavior, or related and coherent set of behaviors, triggered by events sent to the system by a user, by another system or by a hardware device. A specific instance of executing a Use Case is called a scenario.

A scenario represents a specific execution path through the Use Case.

Each Use Case represents a typical interaction between a user and the system. A Use Case captures functions that are visible to the user. Each Use Case documents a complete behavior, including possible alternatives, errors, and exceptions.

3/15/2013

Use Case Diagram Components: Communication Associations

connects an Actor with a Use Case with which the Actor interacts. denotes an interface between a Use Case and an Actor.

Use Case Diagram

Select Catalog Actor1

<extends>

Place Order
<include> <include> Arrange Payment

Order Product

Actor2

Actor3

10

3/15/2013

Use Case Diagram Components: Relationships among use cases

UML supports 2 types of relationships among use cases:

<<includes>> <<extends>>

11

Use Case Diagram Components: <<includes>> relationship

Analogous to whole-part relationship between objects. One use case (the whole) may require several subordinate processing actions or steps (the parts).

12

3/15/2013

Use Case Diagram Components: <<includes>> relationship

Arrange Payment

includes

Bank
Buy Product includes includes

Customer
Browse Catalog

Order Product

Manager

13

Use Case Diagram Components: <<extends>> relationship

This relationship is used to model optional parts of a Use Case, to model complex alternative paths that seldom occur, or to model separate sub-paths that are executed only in selected situations. E.g:
Describe what happens if an actor provides a wrong filename to access a given file
14

3/15/2013

Use Case Diagram Components: <<extends>> relationship

Take in payment

extends

Verify Cheque

Cashier

extends Verify Credit Cards

extends Insufficient Balance

15

Showing Non-Functional Requirement Using UML notes

3/15/2013

ViaNet Bank ATM Case Study

The bank client must be able to deposit an amount to and withdraw an amount from his or her accounts using the touch screen at the ViaNet bank ATM kiosk. Each transaction must be recorded, and the client must be able to review all transactions performed against a given account. Recorded transactions must include the date, time, transactions type, amount and account balance after the transaction. A ViaNet bank client can have 2 types of accounts: a current account and savings account. One PIN code allows access to all accounts held by a bank client. For a deposit transaction, the client has a choice of using his account number or PIN code as an input. Neither a current nor a saving account can have a negative balance.

17

Strategies for developing use case model

1. Finding Actors:
Who will use the main functionality of the system? Who will require support from the system to accomplish their daily work? Who will need to maintain, administer, and operate the system? What hardware devices does the system handle? With what other systems must the system interact?
18

3/15/2013

Strategies for developing use case model

2. Finding Use Cases through Actors
What are the main tasks of each Actor? Will the Actor have to access or update any system information? Should the Actor be notified about abnormal events? What input and output does the system need? What are the major flaws or problems with the current system? What external events must the system handle?
19

The Use Case Diagram

20

10