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
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.
|
Term
|
Description
|
|
server ID
|
Identification of the server, including information
identifying the implementation provider.
|
|
|
|
|
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.
|
Figure 4‑1:
Use Case Diagram of the three systems
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.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.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.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.
|
|
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
|
|
|
|
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.
|
|
|
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.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.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.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.
No comments:
Post a Comment