Guidance Example
Home Business Change Analysis & Design Agile Testing Templates About us

Problem Statement
Introduction
What they are
Granularity
Coupling
Flow Proliferation
Description
Dos and Don'ts
Example

Example "good" use case

The following example highlights a typical component level use case

Component Use Case ABC Accept Trade Transaction

Description

The goal of this use case is to receive a message and initiate validation. The systems responsibility is therefore to ensure that the message is in a correct format to allow this validation to occur. [1]

Actors

bullet

BPL: Business Presentation Layer (Primary)

bullet

RM: Risk Management

Assumptions

Trade Management component will perform this use case.

Pre-conditions

The received message:

bullet

is syntactically valid having been processed by the Business Presentation Layer.

bullet

has performed and passed sanity checks on the individual fields within the message. [2]

Post-conditions

bullet

System logs how far it got and returns an exception status code related to the outcome to the invoking use case.

bullet

A generic structure representing the message is stored.

Trigger

Actor (BPL) sends a request to the system to accept a automatic message from a trade source.

bullet

(Component Use Case100 Receive New Trade Message)

Actor (BPL) sends a request to the system to accept a manually entered message.

bullet

(Component Use Case101 Create Trade)

Actor (BPL) sends a request to the system to accept messages within a contingency file.

bullet

(Component Use Case1164 Load Contingency File) [3]

Flow of events

Main Flow

  1. Actor (BP) sends a syntactically correct message for the system to accept.[4]

  2. System identifies source of message and requests a basic audit entry to be stored.

bullet

Rule. Identify source of message

bullet

Rule. Audit Entry creation for received messages rule [5]

  1. System determines a storage and validation strategy.

bullet

Rule. Identify storage structure and validation strategy

  1. System converts the message into a generic structure for storage.

  2. System generates the appropriate internal reference numbers for the message.

bullet

Rule. Generate Internal References for message rule

bullet

Rule. Internal reference format

  1. System requests the message to be stored.[6]

bullet

Rule. Storage Rules

  1. Actor (RM) stores the message.

bullet

Component Use Case: Store Order [7]

  1. System establishes that the message was successfully stored.

bullet

Alternative: Message was not stored

  1. System requests the message to be validated.

  2. Actor (PM) validates the message [8]

bullet

Use Case: Validate Order

Alternative Flows[9]

Exception: Message was not stored.

  1. System does not store the message because it was a duplicate from a contingency file.

  2. System requests an audit entry is stored, for a duplicate trade transaction from a contingency file has been received and will be ignored.

  3. System stores the audit entry.

  4. Exit use case.

Exceptions:

Etc...

Action definitions [10]

Rule: Identify source of message

bullet

automatically received messages have a  type “ABC123”

bullet

manually entered messages have a  type “ABC124”

bullet

contingency file messages are  indicated using an identifier.

See Model: TradeMessage.getMessageSource()[11]

Rule: Audit Entry creation for received Messages Rule

bullet

Create a basic audit only for manually entered messages with type “ABC125”

bullet

contingency file messages, indicated using an identifier.

bullet

Not required for automatically received messages with type “ABC127

See Model: Audit.setMessageAudit()

Rule: Identify storage structure and validation strategy

bullet

The storage structure and validation strategy are determined using:

bullet

Product

bullet

Transaction              

bullet

Trade Source  

bullet

Message Type

See Model: Trade.getValidationStrategy()

Rule: Generate Internal References for message rule

bullet

For messages where the trade source is not a migrated trade the system generates an internal reference for the whole trade and one for each participant.

bullet

Where trade source is ‘migrated trade’ the system only assigns an internal reference for the message (participant reference already available on the message).

See Model: Trade.setInsternalReference()

Rule: Storage Rules

bullet

Message is converted into an appropriate format. The system sends the message information in a XYZ format, also indicating the trigger was from a contingency file, as duplicates from a contingency must not be stored.

See Model: Trade.doStorageConversion()

Back

  1. This section summarised the use case objectives

  2. This section made clear that the above two actions are not this components responsibility

  3. This section made clear that it is invoked by the BPL component in a number of ways

  4. We have explicitly identified BPL as the initiator of the flow. Although this can be inferred by the trigger, describing this here makes the flow "complete"

  5. Expressing business rules in this way makes the flow simpler. The rules can be described elsewhere

  6. Note the dialogue nature of these pair of steps. We want to emphasise this dynamic interaction between system and actor, and not leave it implicit

  7. Actor and its responsibility shown explicitly

  8. Even in this rather "technical" use case we have only 10 steps - the ideal number to have in the flow of events to prevent overspecification!

  9. Although I prefer not to distinguish an alternative flow to an exception one (it is a pointless internal analysis debate), exception can be treated as something which does not rejoin the main flow (as is here), wheres an alternative is something that does.

  10. Business rules can be described in text form here to avoid complication of the narrative within the flow.

  11. Alternatively these can be described in a class model using Codel Services' Business Rules Methodology

© 2002-2005 Codel Services Ltd

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com