[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jwt-dev] Bonita Designer use cases and requirements
|
Hi Pierre
You've presented your requirements in a very clear manner.
Pierre Vigneras a écrit :
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)?
Chris, Florian ?
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?
This use case of "abstract elements" makes plentiful sense.
My suggestion is to use in each case the model element that best
represents its possible concrete element and decorate it with a specific
aspect that makes it abstract, and tells everybody (the view etc.) not
to look into it but that only its transitions etc. are meaningful.
I agree the Palette still has to be made more flexible. I've not yet
looked in depth at it, so here are my first thoughts :
GEF has actually a "Customize Palette" dialog and feature :
http://dev.eclipse.org/mhonarc/lists/gmf-dev/msg01087.html
however there's not much doc about it :
http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/org.eclipse.gef.doc.isv/guide/guide.html
The point would be to concretize the PaletteCustomizer class, which
gives access to the Palette model, and whose save() method is still
abstract.
Here is its javadoc :
http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/org.eclipse.gef.doc.isv/reference/api/org/eclipse/gef/ui/palette/customize/package-summary.html
How GMF integrates it :
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmf/plugins/org.eclipse.gmf.runtime.gef.ui/src/org/eclipse/gmf/runtime/gef/ui/palette/customize/PaletteCustomizerEx.java?root=Modeling_Project&view=co
A meaningful thread about its technical details :
http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg09099.html
I've also stumbled lately across a similar need in the BPMN ed mailing
list, with an XML-based solution that might be interesting to provide a
proof of concept :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=215815
(btw it shows how Intalio extends the BPMN editor to fit more specific
needs)
On my own side, I'd like to be able to configure the Palette to display
creatable model elements, but creatable elements that will be created
with a given set of aspects (like an AbstractAspect) as well.
The PaletteCustomizer.save() could be done to an XML file, or the merged
view / aspect - profile conf file (which in my mind would be the right
place), or even a custom aspect put on the JWT model.
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?
Yes, they "should" ;) The only way to be sure is
* 1. to test them, since they have only been tested on workflow
models that have been created with a constrained WE till now
* to have validation rules that validation engines can enforce.
That's why I was talking about moving such constraints to a validation
engine (ex. EMF's), and then why not allow vendors to customize the set
of validation rules for their own use (profile). However, if it has to
be done in October I'd simply make the existing edge constraint
"disablable" using an extension point. Chris, what do you think ?
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)?
See above about Palette.
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?
Properties are already displayed in the PropertyView. There you can
create a custom editor for a given property (extension point by
Mickaël), or a whole new tab (by Chris), see wiki. You can make them
also appear in the Outline by changing the ModelContentOutlinePage's
content and label provider.
Or do you mean, display properties within the diagram, like above the
task icon ?
Maybe the UML View sample plugin (see bugzilla) is interesting... Chris,
any idea ?
And could your describe concrete examples of such different ways ?
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! ;-)
Well, I'm not sure there is any simple one ;)
Anyway, we'll try to make it easy to get in. And no need to learn
everything, there are other people with other knowledge !
Regards,
Marc
Best regards.
