Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] Bonita Designer use cases and requirements

Dear JWT members,

find here our use cases.

1. At least 2 views should be available : swinlanes/roles view and activity 
view

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, 
etc.).

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! ;-)

Best regards.
	
-- 
Pierre Vignéras
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


Back to the top