OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-uc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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:

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]