RE: [wsbpel-uc] Sally's Action Item

Sally,

 

I also agree that we need to tap multiple
resources for ideas and examples, not just Simpl-eb. That point has been made
and stressed by many people.

 

I also remain puzzled as to why you give a
system analyst definition of “use case”. The nouns and verbs that
comprise “use case” depend on the object you are using. An
excellent example of this is the W3C XQuery Use Cases. They are developing a
language, and they are using it: http://www.w3.org/TR/xquery-use-cases/
this has plenty of snippets of the XQuery language. 

 

In our case the BPEL language describes
intended orchestration of web services, and we can use a similar approach.
Describe our intent (the meta info), then write it in BPEL (using the
language), all of this backed up by sensible business instances, garnered from
respectable sources (UCC, WS-I, etc).

 

++Harvey

 

 

 

 

-----Original Message-----

From: John Evdemon
[mailto:] 

Sent: Tuesday, October 14, 2003
9:04 PM

To: Sally St. Amand;


Subject: RE: [wsbpel-uc] Sally's
Action Item

 

Sally,

 

Thanks for following up
and providing some great references for describing a use case.

 

While the WS-I SCM Use
Cases 1.0 document provides several use cases from a Supply Chain scenario,
none of them are based upon standardized business processes (note the
disclaimer in the document and at http://www.ws-i.org/Documents.aspx#document8).

 

I agree that mapping our
use cases back to one or more issues would be beneficial - this should not
necessarily be the only option for soliciting use cases.  I originally
suggested starting off with Simpl-EB for the following reasons:

 

1)      
Its simple.  J  

a.      
The UCC Simpl-EB
Implementation Guide makes completing this task fairly simple (for lack of a
better word).

2)      
Simpl-EB is based upon
real-world processes and is endorsed by EAN.UCC (a global supply chain/business
process standards organization with over 2 million member companies)

3)      
We can build on it with
additional use cases (once an order process is modeled we should be able to
re-use it if we decide to do so)

 

I agree that Simpl-EB may
not reflect some of the more complex scenarios discussed in the WS-I document
– this doesn’t necessarily mean that we can’t include fault
handlers capable of catching some of the exceptions or conditions documented in
the issues list.  

 

Remember that we are
interested in adopting and modeling multiple use cases – we are not
finishing with Simpl-EB.  I have no problem using WS-I’s supply
chain scenario – I thought it would be better to start off with something
easy and ramp up.  I also think there may be better scenarios available (a
RosettaNet PIP, for example) than the WS-I SC Use Cases.   

 

We should start actively
identifying and submitting additional candidates to the mailing list for future
discussion.  Would you like to add the WS-I SCM Use Cases?

 

Thanks again for
following-up on your action item!

 

John Evdemon

 

 

 

From: Sally St.
Amand [mailto:] 

Sent: Tuesday, October 14, 2003
2:54 PM

To: 

Subject: [wsbpel-uc] Sally's
Action Item

 

Hi All-

My thoughts on the action item, John asked me to take
on in our last con call.

 

A use case is commonly described as: 

A methodology used in system
analysis to identify, clarify, and organize system requirements. The use case
is made up of a set of possible sequences of interactions between systems and
users in a particular environment and related to a particular goal. It consists
of a group of elements (for example, classes and interfaces) that can be used
together in a way that will have an effect larger than the sum of the separate
elements combined. The use case should contain all system activities that have
significance to the users. A use case can be thought of as a collection of
possible scenarios related to a particular goal, indeed, the use case and goal
are sometimes considered to be synonymous. 

A use case (or set of use cases) has
these characteristics: 

·     
Organizes
functional requirements 

·     
Models the goals
of system/actor (user) interactions 

·     
Records paths
(called scenarios) from trigger events to goals 

·     
Describes one
main flow of events (also called a basic course of action), and possibly other
ones, called exceptional flows of events (also called alternate courses of
action) 

·     
Is multi-level,
so that one use case can use the functionality of another on [1]

Ivar Jacobson has a more concise definition. However,
that definition conjures up proprietary issues, which the TC is working hard to
avoid. The important concepts are the same in the various definitions. A use
case provides a description of what is occurring from the user's perspective.
Complex use cases are made up of a series of other use cases. Use cases capture
information about the context, activity and requirements involved in
specification development. 

We need to look at real world situations that require
data to be sequenced, orchestrated and/or choreographed.

The bpel spec ultimately has to demonstrate it will
provide economic value by being a standard that will enable business activity
that is "stateful" (not stateless). Business activity that requires
long series of time, has data dependent interactions, and is not fully predictable;
business activity that requires more than the invocation of a procedure call.

To paraphrase, bpel is data in motion. If the goal of
bpel is to advance web services, this by definition will necessitate using use
cases with complex interactions.

Take another look at the WS-I doc of 4/15/03 in the
use case list repository; the document is SCM Use Cases 1.0. It is, as the doc
states, a series of use cases. Presumably the complex use case would require
the described use cases plus additional ones. A complex use case for the listed
use cases could be something along the lines of (or we can ask the WS-I folks
for the expanded description of the higher-level use case):

Sell electronics to consumers using
a low margin/high volume business model that relies on no customization,
delivery direct from the warehouse, and inventory on hand (in warehouse) equal
to one production run. The amount in the production run varies by product
category.

This is the level we need to get to in order to test
the bpel specification and flesh out any additional requirements.

If we utilize the work of the WS-I (& others) that
has already been done we can build the complex use cases that will be necessary
to test/exercise specific issues/requirements of the specification. That is, if
we cannot obtain a fully developed use case that addresses the specific issue
from the Issues List that is under consideration we can construct a complex use
case using the catalogue we are compiling in the supply chain domain.

When soliciting use cases, we will need to specify
what issue/requirement we are addressing. For example, Issue 5, we will need to
ask for a business perspective example of a suspend/resume that occurs over a
long period of time. The solution is going to be in the design and writing of
the specification. And I suspect there will be multiple times when there will
be several different approaches to that solution. We can't lose sight that the
‘real’ solution is will the spec enable/allow the user to do what
they intended.

[1] Wording from TechTarget.com