[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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@ 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 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]