AW: [jwt-dev] Bonita Designer use cases and requirements

["Christian Saad" <christian.saad@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi Marc and Pierre,

> > 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 ?

Currently the JWT view system supports the replacement of an element's
visual representation and whether it visible in a selected view or not.
However, the view system is revised and a new view editor is currently
developed that will allow to include further details in a view description
so that the names and descriptions of elements can also be altered.
Additionally, it is planned to store view specific information for elements,
so that they can have different positions in different views (which is a
requirement for showing swimlanes).
We already did a student project a while ago that examined the possibility
to add swimlanes to GEF-based editors. The outcome was that this is indeed
possible, however it requires some internal adaptations since GEF does not
by default support swimlanes, meaning a swimlane view cannot be completely
sourced out to a view plugin but requires some modifications to the editor.

> > 	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.

Like Marc said this could possibly be done by using aspects. We're thinking
about linking aspects with views in a way that allows different view options
for dynamic elements, so that the visual representation of element X can be
changed by selecting views e.g. "abstract" or "concrete".

> 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/cust
> omize/package-summary.html
> How GMF integrates it :
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmf/plugins/org.ec
> lipse.gmf.runtime.gef.ui/src/org/eclipse/gmf/runtime/gef/ui/palette/cus
> tomize/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.

Nice research work. It seems that there is much demand for customizing the
elements in the palette. I think that this is at least partly satisfied by
our view concept that allows to rename and hide elements while aspects will
be able to add new elements to the palette.

> > 	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 ?

T shouldn't be a problem. For the time being, I think for the time being we
could also simply read the constraint for the maximum number of
incoming/outgoing edges from plugin.properties where it can be easily
adapted by vendors.

> > 	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 ?

A concrete example would definitly be good in order to get this requirement
right.
Basically, views allow to replace JWT's internal draw2d figures with your
own, so you could implement a new figure that visualizes some of its
element's properties.

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

EMF/GEF is definitely anything but trivial and your questions are very
important for us since we can decide which way the development should take
in order to fulfill business requirements.

Regards,
Christian