[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jwt-dev] Bonita Designer use cases and requirements
- From: Pierre Vigneras <pierre.vigneras@xxxxxxxx>
- Date: Tue, 21 Oct 2008 17:49:31 +0200
- Delivered-to: email@example.com
- Organization: Bull
- User-agent: KMail/1.9.9
Dear JWT members,
find here our use cases.
1. At least 2 views should be available : swinlanes/roles view and activity
2. Palette in the business view should have the 5 basic BPMN elements :
activities, gateways, connections, events, artifacts. Once an element has
been specified in the panel, it can thereafter be refined (for example,
making the activity manual or automatic, making the gateway an AND or an XOR,
3. Flexible definitions of gateways
- gateway as separate elements (as in UML-AD)
- task can have multiple incoming and outgoing edges : therefore, conditions
can be specified on those edges directly. In the absence of such conditions,
it is an implicit Split/And. It the case of incoming transitions, it is an
implicit Join XOR.
4. Different views with different palette
5. Viewing activities property should be simple (tooltip, properties in a
separate tab, properties in the activity itself (as in UML class diagram))
Therefore, the following questions arise:
1. what is the status of swimlanes support in JWT? How much remains to be
done approximately (possibly by us)?
2. How can we change the palette (and not extending it)? Especially, we want
to add in the palette abstract element that are not fully specified. Of
course, an analyst doing this will produce an unexecutable process. But it
does not matter at the first place. Usually, analyst design a process (often
on a piece of paper), show it to our N+1 hierarchy, then adapt it again, etc,
until it fullfil some requirements. Afterwards, the process is passed to a
technician than will introduce execution semantic into the process.
Therefore, we want to add in the palette abstract BPMN element (say a
gateway). Sometimes, afterwards, this element will have to become concrete by
being specified (say an AND, wether it is a split or a join depends on its
incoming/outgoing transitions). Those abstract elements are not in the JWT
EMF model (currently). But in the Palette we add EMF elements. Marc suggested
some solutions based on aspects. For example creating an aspect for the
ActivityNode specifying that it is abstract. Still, I am not sure how this
work as we will have to add 5 abstract elements in the palette : activity,
gateways, events, connections and artifacts. Should all of them extend
ActivityNode, can they?
3. We have already talked about the implication of this multiplicity edges on
a given node. As far as I understand, the mode is flexible and does not
constraint this. The graphical layer does constraint action to have only one
incoming and one outgoing transition (as UML-AD specifies). However, if we
provide our own graphical layer (by extension or modification), all the tools
should still continue to work normally if they are based on the model and not
on the graphical layer model. Right?
4. As far as I understand, it should be possible to provide our own palette
with our own view. But what about JWT-WE main palette? Can it be modify (or
at least remove completely)?
5. We would like many different ways to display properties. One of them is
inside the task itself. There is a strict mapping between the palette and the
model. Therefore, how can we modify the way things (and in our case actions)
are rendered just by extension?
We are just starting to get knowledge of EMG/GEF stuff (which is quite huge)!
Some questions may sound very simple! All our excuses for that! ;-)
Bull, Architect of an Open World TM
*BPM Team*, Bull R&D
1, rue de Provence
38130 Echirolles (France)
Direct Line: +33-4-76-29-74-06
*Orchestra*, The BPEL open source project: http://orchestra.ow2.org
*Bonita*, The XPDL open source project: http://bonita.ow2.org