Guidance 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

	BPL: Business Presentation Layer (Primary)
	RM: Risk Management

Assumptions

Trade Management component will perform this use case.

Pre-conditions

The received message:

	is syntactically valid having been processed by the Business Presentation Layer.
	has performed and passed sanity checks on the individual fields within the message. [2]

Post-conditions

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

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.

(Component Use Case100 Receive New Trade Message)

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

(Component Use Case101 Create Trade)

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

(Component Use Case1164 Load Contingency File) [3]

Flow of events

Main Flow

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

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

	Rule. Identify source of message
	Rule. Audit Entry creation for received messages rule [5]

System determines a storage and validation strategy.

Rule. Identify storage structure and validation strategy

System converts the message into a generic structure for storage.
System generates the appropriate internal reference numbers for the message.

	Rule. Generate Internal References for message rule
	Rule. Internal reference format

System requests the message to be stored.[6]

Rule. Storage Rules

Actor (RM) stores the message.

Component Use Case: Store Order [7]

System establishes that the message was successfully stored.

Alternative: Message was not stored

System requests the message to be validated.
Actor (PM) validates the message [8]

Use Case: Validate Order

Alternative Flows[9]

Exception: Message was not stored.

System does not store the message because it was a duplicate from a contingency file.
System requests an audit entry is stored, for a duplicate trade transaction from a contingency file has been received and will be ignored.
System stores the audit entry.
Exit use case.

Exceptions:

Etc...

Action definitions [10]

Rule: Identify source of message

	automatically received messages have a type “ABC123”
	manually entered messages have a type “ABC124”
	contingency file messages are indicated using an identifier.

See Model: TradeMessage.getMessageSource()[11]

Rule: Audit Entry creation for received Messages Rule

	Create a basic audit only for manually entered messages with type “ABC125”
	contingency file messages, indicated using an identifier.
	Not required for automatically received messages with type “ABC127

See Model: Audit.setMessageAudit()

Rule: Identify storage structure and validation strategy

	The storage structure and validation strategy are determined using:
	Product
	Transaction
	Trade Source
	Message Type

See Model: Trade.getValidationStrategy()

Rule: Generate Internal References for message rule

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

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()

This section summarised the use case objectives
This section made clear that the above two actions are not this components responsibility
This section made clear that it is invoked by the BPL component in a number of ways
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"
Expressing business rules in this way makes the flow simpler. The rules can be described elsewhere
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
Actor and its responsibility shown explicitly
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!
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.
Business rules can be described in text form here to avoid complication of the narrative within the flow.
Alternatively these can be described in a class model using Codel Services' Business Rules Methodology

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