Use case & use case diagram

Use Cases

Deborah E. Swain, Ph.D.

EXAMPLE

Name:

Provision Service Data on Platform

Owner:

Actor:

Service

Administrator

Assets Impacted:

DataManager, Platform

Type:

Standalone

DB Identifier:

XXX-YY-001

Customer:

All

Scope:

Network

Function:

Configuration

Related Use Cases:

Description:

The DataManager provisions Services. The user will be able to create, update and delete data objects. The data can be provisioned for one or more network elements running onthe Platform.

Frequency:

Used whenever a Service object needs to be created or updated. The frequency of operation is dependent upon the Service’s provisioning requirements and the number of DataManager provisioning users. An example frequency might be 2 transactions per hour per administrator.

Precondition(s):

1. DataManager is running

2. Service to be provisioned is installed.

3. Views for the Service are created.

4. Owners of Service have been defined.

5. Provisioner (administrator) has login and permissions in DataManager to perform provisioning tasks.

Postcondition(s):

Service object data is provisioned on the selected network elements for the Service.

Main Scenario:

1. Provisioner/Service administrator logs into DataManager via graphical interface.

2. Provisioner/Service administrator selects the Service Object option.

3. Provisioner/Service administrator defines the Service Object name to be provisioned.

4. Provisioner/Service administrator then selects the network elements for which the data needs to be provisioned from the list of available network elements for the selected category. Alternatively, the Provisioner/Service administrator can also choose to use the distribution rules to distribute the data.

5. Provisioner/Service administrator then is prompted to select the categories for the feature capability to be provisioned. Provisioner/Service administrator then keys in the data that need to be provisioned. Multiple service object categories and capabilities can be provisioned.

6. Provisioner/Service administrator scan also select if they want to send to only particular network element. (This may be used when the Provisioner/Service administrator knows one of the NE is out of service)

7. On completion of creation of one service object request, the Provisioner/Service administrator will be provided option to:

select particular NE for the provisioning from the NE group (optional)

add more capabilities to the just created service object (optional)

make changes to the data entered for different capabilities (optional)

8. On completion of creating the data to be provisioned, the user will be prompted to provide:

a work order name, or

let DataManager select a work order name

9. The user can also select one of the following types of processing for a work order:

Save it for later provisioning

Submit it for immediate processing

Submit it for later processing

10. A summary of a work order being created is provided.

11. Provisioner/Service administrators are prompted if they wanted to add more service object requests to the work order.

12. When submitted for provisioning, the DataManager performs validation of the data provided in the work order.

13. Upon completion of validation, the DataManager distributes provisioning data to the network elements.

14. Provisioner/Service administrator can use the work order ID to check the status of the work order from the work order summary page.

Extensions:

5a. One of the service data types could be Flexible Service Logic.

12a. Validation error occurs in a work order:

the user may correct the data entered and re-submit the work order

13a. Distribution to the network element fails:

The DataManager marks the status of the work order as failed.

NOTE: Possible types of failures include:

1) Platform-DataManager Link failure,

2) No DataManager communication possible with Platform

3) Invalid login/password between Platform and DataManager

4) Missing target Platform directory,

5) Insufficient disk space on Platform.

The Platform-DataManager corrects the work order and resubmits for provisioning.

*a. User wants to cancel the creation of the service object work order (which can happen at any time during the creation process, i.e., steps 3-8 of the main scenario):

– User chooses cancel operation

– Creation of service object work order is abandoned

Variations:

3a. User can choose to update an existing service object

3b. User can choose to delete an existing service object

Issues/Comments:

1. DataManager can accept work orders containing service objects to be provisioned from an upstream system. DataManager accepts the request through its well defined CORBA API. DataManager applies the validation rules before starting to distribute it to the network elements.

Associated Specification Textual Requirements: ZZZ

Graphical Example of Scope

The figure below provides a visual depiction of an Scope combined with the Actors defined for a particular set of Use Cases. Actors are identified for each set of Use Cases and there is the flexibility to add Actors as the need arises.

UML Use Case Diagram

UML Collaboration Diagram

Process

Define Problem to be solved.
Determine Scope of system (boundaries, domain, customer/business objectives)
Identify Actors (role or roles relative to system, event analysis: when do actor and scope need to interact, any related goals/mission to consider)
“Discover” the Use Cases

Separate Processes (i.e., any mini-scopes)
Form Use Cases (interaction context, scenarios, structure, i.e., any sub-use cases)

Specify Use Case

Define pre- and post- events
Write primary scenario
Determine logic structure (i.e., any extensions or variations)
Write extensions
Write variations

Tips

· Use Action Statement Format

(time factor or sequence -> actor-> action ->constraints)

· Number each action sequentially

· Follow the primary course (separate extensions and variations)

Practical Reference Contacts

Dennis Mancl or Tom Baumgartner, Use Case Primer authors at Lucent Technologies, Inc., ( [email protected] )

Template

Name:

Owner/Author:

Actor(s):

Primary –

Secondary –

Systems Impacted:

Frequency:

Precondition(s):

1. ____________________________

2. ____________________________

3. ____________________________

Postcondition(s):

Main Scenario:

1. ___________________________________________________________________

2. ___________________________________________________________________

3. ___________________________________________________________________

4. ___________________________________________________________________

5. ___________________________________________________________________

6. ___________________________________________________________________

7. ___________________________________________________________________

8. ___________________________________________________________________

9. ___________________________________________________________________

10. ___________________________________________________________________

Extensions:

1. ____________________________

2. ____________________________

3. ____________________________

Variations:

1. ____________________________

2. ____________________________

3. ____________________________

Issues/Comments:

1. ____________________________

2. ____________________________

3. ____________________________

Use Case Template