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

[Harvey Reed <hreed@sonicsoftware.com>]

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:jevdemon@microsoft.com]
Sent: Tuesday, October 14, 2003 9:04 PM
To: Sally St. Amand; wsbpel-uc@lists.oasis-open.org
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:sallystamand@yahoo.com]
Sent: Tuesday, October 14, 2003 2:54 PM
To: wsbpel-uc@lists.oasis-open.org
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