[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-uc] Re: 1st Candidate examples of deliverables
Rand,
We are all still in agreement. Keep in mind the catalog that we all worked on together, and agreed to use, is structured so that:
(a) The ‘objects’ that we anticipate to deliver are organized into types, from high-level business types, down to technical xml object types. We can add better visual separators if that will help keep things clear in the readers’ minds. (b) We can name ‘object types’ whatever we want. I do not have an opinion for the name of any of the ‘object types’. Please propose a set of names! (c) It is organized so that one ‘object’ can reuse other ‘objects’. In fact reuse was one of the primary goals of the current catalog.
The exercise we are doing this week is to create a first set of use case deliverables. I offered that we should try to deliver at least one of each item, and anticipate there will not be uniform emphasis on each of the items 1-7. Indeed there will probably be a good deal of hand-waving on some of them. The point is that we must deliver something, this week, by Friday, in order that we have concrete deliverables to base future discussions on.
Are you volunteering to come up with a draft of deliverables that we need for items #1&2, as well as a naming proposal?
Cheers! ++harvey
-----Original Message-----
Hi Harvey, Hi Sid, et al, Not sure if this is precisely what Sid was after, but I was going to make a similar suggestion. The idea would be to not so much ignore WSDL completely, but rather just decouple items 3-7 from 1-2 fairly explicitly in the organization of our artifacts. This is beneficial as it allows easier re-use of existing non-WSDL-specific requirements use cases, and also lets business analysts who don't know or care about WSDL (or any technology specific mappings) interact with our artifacts without getting pulled into tech-specific issues, etc.
I think that this is a theme that Sally was after earlier as well.
So the idea would be to have the first artifact - have we solidified on what we are calling it? Use Case? Usage Scenario? something else? - focus on just the first two elements that you list below, Harvey. Let me interject at this point that I would propose calling these two elements 'Actors' (was 'Entities') and 'Services' (was 'Actors'). [I'll follow-up separately on this, worth a separate thread, I know there are some concerns about adopting particular vocabs, etc]. So the starting point for any requirements statement is a description of the use expressed in terms of actors consuming/using services.
Then, the additional artifacts (3-7 and maybe more) would be developed and associated with the requirements statement.
HTH, Rand
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]