Supply Chain
Management

Use Case Model

Document Status: Final Specification

Version: 1.0

Date: December 1, 2003

Editors:

Scott Anderson, Visuale, Inc.

Martin Chapman, Oracle

Marc Goodner, SAP

Paul Mackinaw, Accenture

Rimas Rekasius, IBM

Notice

The material
contained herein is not a license, either expressly or impliedly, to any
intellectual property owned or controlled by any of the authors or developers
of this material or WS-I. The material contained herein is provided on an
"AS IS" basis and to the maximum extent permitted by applicable law,
this material is provided AS IS AND WITH ALL FAULTS, and the authors and
developers of this material and WS-I hereby disclaim all other warranties and
conditions, either express, implied or statutory, including, but not limited
to, any (if any) implied warranties, duties or conditions of merchantability,
of fitness for a particular purpose, of accuracy or completeness of responses,
of results, of workmanlike effort, of lack of viruses, and of lack of
negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT,
QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD
TO THIS MATERIAL.

IN NO EVENT
WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE TO ANY OTHER PARTY
FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF
USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR
SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING
IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL,
WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH
DAMAGES.

Status of this Document

This is a final
specification.  Readers should refer
to the WS-I.org web site for errata and
updates.

Table of Contents

1   Introduction. 4

2   Glossary. 4

3   Actors  4

4   Use
Case Diagram.. 5

5   Overall
Non-functional Requirements and Assumptions. 5

6   UC1:  Purchase Goods. 7

6.1     Definition. 7

6.2     Main
Success Path. 7

6.3     ALT1:
No Such Product 8

6.4     ALT2:
Nothing Available. 9

6.5     Activity
Diagram.. 10

6.6     Non-functional
Requirements and assumptions. 10

6.7     Open
Issues. 11

7   UC2:  Source Goods. 11

7.1     Definition. 11

7.2     Main
Success Path. 11

7.3     ALT
1: Warehouse A can’t fulfill some items. 12

7.4     ALT
2: Warehouse B can’t fulfill some items. 12

7.5     ALT
3: Insufficient quantity in warehouse C. 12

7.6     Activity
Diagram.. 13

7.7     Non-functional
Requirements and Assumptions. 13

7.8     Open
Issues. 13

8   UC3:  Replenish Stock. 14

8.1     Definition. 14

8.2     Main
Success Path. 14

8.3     ALT1:
Malformed Order or No Such Product or Invalid quantity. 15

8.4     Activity
Diagram.. 16

8.5     Non-functional
Requirements and Assumptions. 16

8.6     Open
Issues. 16

9   UC4:  Supply Finished Goods. 17

9.1     Definition. 17

9.2     Main
Success Path. 17

9.3     Activity
Diagram.. 18

9.4     Non-functional
Requirements and Assumptions. 18

9.5     Open
Issues. 18

10 UC5:  Manufacture Finished Goods. 19

10.1   Definition. 19

10.2   Main Success
Path. 19

10.4   Activity Diagram.. 20

10.5   Non-functional
Requirements and Assumptions. 20

10.6   Open Issues. 20

11 UC6:  Configure & Run Demo. 21

11.1   Definition. 21

11.2   Main Success
Path. 22

11.3   Activity Diagram.. 22

11.4   Non-functional
Requirements and Assumptions. 23

11.5   Open Issues. 23

12 UC7: Log
Events. 23

12.1   Definition. 23

12.2   Main Success
Path. 24

12.3   ALT 1: Invalid
Data. 24

12.4   ALT 2:
Repository not available. 24

12.5   Activity Diagram.. 25

12.6   Non-functional
Requirements and Assumptions. 25

12.7   Open Issues. 25

13 UC8:
View Events. 25

13.1   Definition. 25

13.2   Main Success
Path. 26

13.3   ALT 1: Unable to
access the log. 26

13.4   Activity Diagram.. 27

13.5   Non-functional
Requirements and Assumptions. 27

13.6   Open Issues. 27

1
Introduction

This document presents a high
level definition of a Supply Chain Management (SCM) application in the form of
a set of Use Cases.

The application
being modeled is that of a Retailer offering Consumer electronic goods to
Consumers; a typical B2C model. To fulfill orders the Retailer has to manage
stock levels in warehouses. When an item in stock falls below a certain
threshold, the Retailer must restock the item from the relevant
Manufacturer’s inventory (a typical B2B model). In order to fulfill a
Retailer’s request a Manufacturer may have to execute a production run to
build the finished goods. In the real world, a Manufacturer would have to order
the component parts from its suppliers. For simplicity in this application, we
assume this is a manual process which is supported through the use of fax.

Each use case includes a logging call to a monitoring
system in order to monitor the activities of the services from a single
monitoring service.

The primary goal of the application is to demonstrate all
of the scenarios in the WS-I Basic Profile.

2
Glossary

Term

Description

server ID

Identification of the server, including information
identifying the implementation provider.

3
Actors

Actor

Description

Consumer

A party that wishes to shop for electrical goods.

Demo User

A party that is exercising the sample application via the WS-I
web site.

Demo System

The component of the sample application used to set up and run
the demo.

Manufacturing System

A party that manufactures electrical products.

Retailer System

A party that sells electrical products to the general public.

4
Use Case Diagram

Figure 4‑1:
Use Case Diagram of the three systems

5
Overall Non-functional Requirements and
Assumptions

In order to simplify the design, facilitate delivery of a
demonstration application and allow the Working Group to concentrate on Web
services and the implementation of the WS-I Basic Profile, the following
requirements and assumptions have been defined :

1.       A
Retailer will have exactly three warehouses (A, B, and C) that it owns.

2.       There
will be exactly three manufacturers (Brand1, Brand2, and Brand3).

3.       Each
manufacturer supplies exactly three products (TV, DVD, video camera). Hence
there are nine valid products to be offered by a Retailer; Brand1 TV, Brand2
TV, Brand 3TV, Brand1 DVD, etc.

4.       All
three warehouses stock all nine products.

5.       For
demo purposes there will be one invalid product Brand4 TV. The product will be
visible in the Retailer’s catalog but is not stocked (or recognized) by
any warehouse.

6.       An
order may contain multiple line items, where each line item relates to a
specific product and quantity required. A product shall not appear more than
once in an order.

7.       There
are no minimum order quantities, and quantities express units of one (true for
both Consumer to Retailer and Retailer to manufacturer).

8.       Partial
shipments of a single product are not supported; either the required quantity
of a product in a line item can be fulfilled in full or none are.

9.       The
requested quantity of a product must be shipped by a single warehouse, or none
are shipped i.e. it is not possible to split the shipment of a product across
warehouses.

10.   Back
orders are not supported; either the required quantity of product can be
fulfilled in full by a single warehouse (points 7 and 8) or that line item is
rejected.

11.   The
Consumer’s information (payment details, address, etc.) are known to the
Retailer system via an implicit logon when the demo starts.

12.   Payment
is not demonstrated, it is assumed that a Consumer has pre-registered credit
card details and billing happens out of band.

13.   The
start of each purchase use case assumes state is set back to predefined values
i.e. predefined stock levels, min/max levels, etc.

14.   It
is assumed that all implementers will implement all use cases in the Retailer
and Manufacturing Systems i.e. 1 Retailer with three warehouses (A, B, and C),
and three Manufacturers (Brand1, Brand2, and Brand3.)

15.   Only
implementation team sanctioned implementations can be configured in this demo
i.e. these use cases and demo system do not provide a means for third parties
to plug in their implementations.

16.   A
manufacturer will always ship the requested number of a product to a warehouse
i.e. we assume it can always manufacture the required amount.

17.   To
maximize interoperability testing, a non-Roman character set should be used in
an appropriate place. The suggestion is for the description of at least one
product to be in a non-Roman text.

18.   When
a purchase request brings a warehouse quantity to below a certain level, the
warehouse makes a request of the appropriate manufacturer for more goods.

6
UC1:
Purchase
Goods

6.1
Definition

Goal of Use
Case:

A Consumer goes
to the Retailer website with the intent of purchasing Consumer electronic
products.

Preconditions:

1.
Product Catalog Exists

2.
All state (warehouse levels etc) set back to
predefined values

3.
Payment and address details for Consumer are
known

Success Post
Conditions:

1.
At least one product is shipped

2.
The Consumer is returned a Confirmation page
outlining which products will be shipped

3.
The Retailer has requested the warehouses to
ship the available goods.

4.
Payment from the Consumer’s credit card
is triggered.

Failed Post
Conditions:

The Consumer is
returned an error stating that none of the items in the order can be
fulfilled.

Actors:

Retailer System, Demo System, Consumer

Triggers:

This process is
started by the Consumer (human interaction)

6.2
Main Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Consumer

The Consumer
navigates to a shopping page.

2.

Demo System

The Demo System
presents a shopping page, including a catalog of products.

3.

Consumer

The Consumer
enters the number of each product required (i.e. changes the number from zero
to a required amount).

4.

Consumer

Once happy with
the quantities, the Consumer submits the order to the Retailer System via the
demo system.

5.

Retailer System

Validate order.
An order is rejected completely if it contains a product that does not exist.

No Such Product

ALT1

6.

Retailer System

The
Retailer’s system determines which warehouse can supply each line item
and asks the warehouse to ship them.

UC2

7.

Retailer System

The Retailer
System returns the order back to the Consumer indicating which line items
have been shipped and which line items could not be shipped.

Nothing
Available

ALT2

8.

Trigger payment
from the Consumer’s pre-registered card (this is a manual process in
this system)

9.

The use case
ends

6.3
ALT1: No Such Product

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System

The Retailer
System returns an error to the Consumer, informing them that they have
selected a product that does not exist. The name/brand of the product is
reported to them. All items in the order are rejected.

2.

The use case
ends in failure

6.4
ALT2: Nothing Available

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System

The Retailer
System informs the Consumer that none of the items in the order can be
shipped as no warehouse has the required quantity.

2.

The use case
ends in failure

6.5
Activity Diagram

6.6
Non-functional Requirements and assumptions

At least one
invalid product should be in the catalog displayed to the Consumer.

6.7
Open Issues

None.

7
UC2:
Source Goods

7.1
Definition

Goal of Use
Case:

To locate
ordered goods in a warehouse and request shipment

Preconditions:

none

Success Post
Conditions:

1.
For each line item in the order, a warehouse
is selected that has the available quantity and that warehouse ships the
goods.

2.
For line items that are accepted, the
inventory levels in the shipping warehouse for that product are decreased by
the quantity in the line item.

Failed Post
Conditions:

There is no
stock availability in any Warehouse for all of the line items in the order.

Actors:

Retailer System

Triggers:

Receipt of order
from Consumer.

7.2
Main
Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System

Present the list
of line items to warehouse A and request A to ship those items it has
available.

ALT 1

2.

Retailer System

Record the line
items that warehouse A is shipping and decrement A’s stock levels for
the items it will ship.

Warehouse A
can’t fulfill some items

ALT 1

3.

Retailer System

The
use case ends

7.3
ALT 1: Warehouse A can’t fulfill some
items

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System

For the items
that warehouse A could not ship, request warehouse B to ship those items it
has available.

2.

Retailer System

Record the line
items that warehouse B is shipping, and decrement B’s stock levels for
the items it will ship.

Warehouse B
can’t fulfill some items

ALT 2

3.

Retailer System

The use case
ends

7.4
ALT 2: Warehouse B can’t fulfill some
items

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System

For the items
that warehouse B could not ship, request warehouse C to ship those items it
has available.

2.

Retailer System

Record the line
items that warehouse C is shipping, and decrement C’s stock levels for
the items it will ship.

Warehouse C
can’t fulfill some items

ALT 3

3.

Retailer System

The use case
ends

7.5
ALT 3: Insufficient quantity in warehouse C

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System

For the items
that are left, record that no warehouse can ship those items

2.

Retailer System

The use case
ends.

7.6
Activity Diagram

7.7
Non-functional Requirements and Assumptions

None.

7.8
Open Issues

None.

8
UC3:  Replenish Stock

8.1
Definition

Goal of Use Case:

The Retailer System orders goods from a manufacturer to
replenish stock for a particular product in a particular warehouse.

Preconditions:

The inventory level of a product in a particular
warehouse has fallen below its minimum level

Success Post Conditions:

The inventory level of the product in a particular
warehouse is at the maximum level.

Failed Post Conditions:

The inventory level of the product in a particular
warehouse is not updated and remains under stocked.

Actors:

Retailer System, Manufacturing System

Triggers:

Triggered internally in the Retailer System for each
warehouse that detects the pre-condition.

8.2
Main
Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System

The Retailer System constructs a purchase order for the
product with the necessary quantity to bring the product up to its maximum
level for that warehouse.

2.

Retailer System

Place Order.
The Retailer system submits the purchase order to the relevant
Manufacturing System (Brand1, Brand2 or Brand3) as dictated by the product.

3.

Manufacturing System

Validate Order

Malformed order or invalid product or invalid quantity

ALT 1

4.

Manufacturing System

Send an acknowledgement back to the Retailer System

5.

Manufacturing System

The Manufacturing System constructs a shipment of the
requested quantity of product.

unconditional

UC4

6.

Manufacturing System

The Manufacturing System ships the goods and sends  shipping notice to the warehouse. The
shipping notice is the business level reply to the purchase order.

7.

Retailer System

When the Retailer System receives the shipping notice,
an acknowledgement is sent back to the Manufacturing System.

8.

Retailer System

Upon receipt of the shipment, the warehouse updates its
product inventory level based on receipt of the shipped order.

8.3
ALT1: Malformed Order or No Such Product or Invalid
quantity

Step

Actor

Description

Branches

Condition
Location

1.

Manufacturing System

The Manufacturing System rejects the order either due to
a malformed order, a request for a product that doesn’t exist, or a
request for an invalid quantity (such as zero or more than the max level for that
product).  A reply, containing an
application error message/code, is sent back to the Retailer System.

2.

The use case ends in failure

8.4
Activity Diagram

8.5
Non-functional Requirements and Assumptions

None.

8.6
Open Issues

None.

9
UC4:
Supply Finished Goods

9.1
Definition

Goal of Use Case:

A manufacturer processes a purchase order from a
warehouse.

Preconditions:

Min < Manufacturer’s Finished Goods Inventory
Level < Max

Success Post Conditions:

The purchase order is fulfilled and finished goods are
shipped to Retailer’s warehouse.

Failed Post Conditions:

The purchase order is not fulfilled.

Actors:

Manufacturing System, Retailer System

Triggers:

Receipt of a purchase order.

9.2
Main
Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Manufacturing System

Check Inventory.
For each item in the purchase order, the manufacturer checks its
finished goods level to determine if it can fulfill the order.

Insufficient goods

UC5

2.

Manufacturing System

Ship Order.
The manufacturer ships all the finished goods to the retailer’s
warehouse and sends the warehouse a shipping notification. A single shipping
notice is sent even if the purchase order contained multiple items.

3.

Manufacturing System

Update Inventory.
The manufacturer updates its finished goods inventory level based on
the quantity being shipped in step 3.
If the minimum finished goods threshold is exceeded, manufacture more,
which is defined by UC5.

Minimum threshold exceeded

UC5

9.3
Activity
Diagram

9.4
Non-functional Requirements and Assumptions

No multi-line orders are accepted i.e. an order relates to a
single product (finished good).

9.5
Open Issues

None.

10
UC5:
Manufacture Finished Goods

10.1
Definition

Goal of Use Case:

The goal of this use case is to initiate a production
run for the purposes of replenishing the stock levels of a specified product.

Preconditions:

Stock
levels for the manufactured product are not sufficient to meet a purchase
request or stock levels have fallen below the minimum level for the product.

The
necessary parts and their quantities for a production run are available.

Success Post Conditions:

The stock level for the manufactured product will be at the
maximum level.Part stock levels will have diminished, unless one or more parts were
ordered as a result of the run, in which case the levels of the ordered parts
will be at the maximum level.

Failed Post Conditions:

Stock levels will be left unchanged.

Actors:

Manufacturing System

Triggers:

Manufacturer is requested to supply finished goods

10.2    Main
Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Manufacturing System

Determine part list and quantities required to
manufacture product. Quantity to manufacture = order quantity – current
inventory level + max inventory level

1.

Manufacturing System

For each part, check stock level is greater than (unit quantity
required multiplied by production run quantity).

Insufficient stock

UC6

2.

Manufacturing System

Start production run.

3.

Manufacturing System

Wait for production run to finish.

4.

Manufacturing System

Stack finished goods in (manufacturer’s)
warehouse.

2.

Manufacturing System

Deduct parts from stock.

3.

Manufacturing System

Update product stock levels.

10.3ALT
1: Invalid Request

Step

Actor

Description

Branches

Condition
Location

1.

Manufacturing
System

Prepare and send
response to initiator of request, indicating request is invalid.

2.

Manufacturing
System

Terminate
process.

10.4    Activity
Diagram

10.5    Non-functional
Requirements and Assumptions

1.       A
pre-defined unit production time exists for each product.

2.       Each
production run takes exactly the calculated time to complete.

3.       There
is an unlimited manufacturing capability, meaning that any requested quantity
can be manufactured.

10.6
Open Issues

None.

11       UC6:
Configure & Run Demo

11.1
Definition

Goal of Use Case:

Allow the person operating the demo (a.k.a. demo user)
to select from among a list of different, equivalent web service
implementations.

Preconditions:

There is more than one implementation of each web
service to choose from.

Each web service that is offered has been approved by
WS-I’s Sample Applications Working Group.

Success Post Conditions:

A configuration is selected and the demo is started.

Failed Post Conditions:

1. Incorrect or incomplete configuration selected

2. Endpoints not available

Actors:

Demo User, Demo System

Triggers:

Demo User navigates to the WS-I demo web page.

11.2
Main Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Demo System

Present Choices.
The system presents the demo user with a number of configuration
options.  It is assumed that the
system will not present any invalid options, and that all combinations of
options are valid.

2.

Demo User

Select Options.
All options will have randomly generated default selections.  The demo user selects implementations
of individual web services.  Each
web service in the demo will be implemented by one or more vendors.

3.

Demo System

Generate ID.
The Demo system generates a unique ID which is used to retrieve the
log entries for different (concurrent) demo users.

4.

Demo User

Start Demo.
The demo user records the generated ID and acknowledges receipt of the
ID to the system.  This
acknowledgement causes the system to start the demo, branching to UC1.

Demo user receives ID.

UC1

11.3
Activity Diagram

11.4
Non-functional Requirements and Assumptions

Use UDDI to discover the web service implementations to be
presented to the Demo User (step 1, main success scenario).

11.5
Open Issues

None.

12
UC7: Log Events

12.1
Definition

Goal of Use Case:

The goal of this use case is to log events relating to
the execution of other use cases for the purpose of enabling a Demo User to
view these events.  In this way
the Demo User will be able to see which web services have been consumed by a
given operation and the outcomes of those web services.

The events should be able to be viewed at any time.  This may mean that for asynchronous
operations one or more web services may still be executing.

Preconditions:

none

Success Post Conditions:

Event is logged to the repository.

Failed Post Conditions:

1.
An entry will be added to the log, which will
include an error code and description outlining the cause of the failure. Or

2.
Repository is not available

Actors:

Any web service system as Initiator, Demo System.

Triggers:

Initiation, termination or any significant point in the
execution of one of the core use cases.

12.2
Main Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Retailer System or Manufacturing System

Sends a request to the Demo System to log events.

2.

Demo System

Receives request to log events.

3.

Demo System

Validate request.

Invalid request

ALT 1

4.

Demo System

Logs events, including user ID, initiating server ID,
responding service ID, unique demo ID, use case ID, date/time of operation and
other transaction details.
Transaction details can be passed as a long string.

Repository not available

ALT 2

12.3
ALT 1: Invalid Data

Step

Actor

Description

Branches

Condition
Location

1.

Demo System

Log reason for failure (e.g. XML fragment does not
conform to schema)

Repository not available

ALT 2

2.

Terminate process.

12.4
ALT 2: Repository not available

Step

Actor

Description

Branches

Condition
Location

1.

Terminate process.

12.5
Activity Diagram

12.6
Non-functional Requirements and Assumptions

Call to log statistics will use the Document Style One-way
Message Scenario.

12.7
Open Issues

None.

13
UC8: View Events

13.1
Definition

Goal of Use Case:

The goal of this use case is to allow the Demo User to
view the log of events that occurred as a result of running the demo.

Preconditions:

Events related to the demo user are clearly marked in
the log.

Success Post Conditions:

Events are displayed

Failed Post Conditions:

Events cannot be located

Actors:

Demo User, Demo System

Triggers:

Demo User navigates to an appropriate place in the user
interface.

13.2
Main Success Path

Step

Actor

Description

Branches

Condition
Location

1.

Demo User

The Demo User requests the display of events related to
a demo.

2.

Demo System

Extracts from the log all the entries related to the
latest demo run by the Demo User.

Unable to access the log

ALT 1

3.

Demo System

The Demo System returns to the Demo User a list of the
relevant events for them to view.

13.3
ALT 1: Unable to access the log

Step

Actor

Description

Branches

Condition
Location

1.

Demo System

Report back to the Demo User that the events cannot be
displayed.

2.

The use case ends unsuccessfully

13.4
Activity Diagram

13.5
Non-functional Requirements and Assumptions

None.

13.6
Open Issues

None.