Skip to main content

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

That would be nice, but that still would imply transferring data from one java type instance to another since the model is generated java code ?

Though this could be made automatic using EMF reflection...

Regards,
Marc


Christian Saad a écrit :
Hi,

In order to show concrete elements in a more abstract view, the elements
could be set to be visible in the abstract view but replacing their figure
and caption with the figure/caption of the abstract type. Maybe we could
also add an option to hide certain elements in the palette, so that the fake
abstractcontrolnode (really forknode) doesn't show up in the palette.

And for replacing abstract concepts with concrete ones, I think that this
could become quite tedious for the user if the control really has to be
removed and a new one should be added since connections and already set
attributes must be restored (if this is the way it is done until now?). I'm
thinking that we could provide a way to do this automatically, e.g. by
offering an option in the context menu that shows all concrete subtypes and
automatically changes the type of the EMF model element internally to the
concrete type while keeping all existing preferences.

Regards,
Chris

FL:

Concerning the abstract activity node: the metamodel already includes
some
abstract nodes such as ExecutableNode or ControlNode that might be
used for
that purpose. For the moment they are themself abstract classes and
not
shown in the palette or elsewhere, but it might be possible to add
those in
one view and remove the concrete subclasses from this (business) view
and to
refine these abstract classes in a more technical view afterwards!?


Yes, it's what we did. By choosing elements to be displayed into the
created view-file (Business/Technical) it becomes possible  to decide
elements  that are present  into the palette of the  two views within
the editor.
For instance ControlNode can be displayed in the palette of both views
(we simply added ControlNodeFigure ...) since fork/join node is only
displayed in the palette of the Technical design.
But the following use case cannot be realized:
- create controlNode in Business view
- switch to Technical view and "replace" controleNode by forkNode
- switch again to Business view :   the forkNode is no more visible in
this view. We would want to keep this type of element visible (even the
palette of business view does not contain this element).
In other word after refinement of the abstract class in a more
technical
view switching back to the less technical view does not prevent to
display the refined element.
May be this possibility already exists ?

Concerning "activity, gateways, events, connections and artifacts.
Should
all of them extend ActivityNode":
No, definitely not. A connection can't be an ActivityNode of course.
As
already mentioned the ExecutableNode might be the activity, the
ControlNode
the Gateway. Events are already included in the metamodel but without
any
concrete subclasses, those will be needed in the future anyway, as
soon as
we decided what kind of events we want to model (hopefully not the
whole set
of BPMN which makes it quite confusing). For artifacts we currently
distinguish between Role, Application and Data, which can be refined
via
aspects and those artifacts are connected with a specific edge to the
Action/ExecutableNode.






	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 ?

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

FL:

Hmm, another thought would be to define the maximum number of
incoming and
outgoing edges for each element by the view-file? So, a business
manager
would be allowed to ignore such things as control nodes and simply
used
nodes and edges (as he would love to do), but in the technical view
could
then be changed and more semantics via different control nodes added.
Probably this needs also a validation mechanism when switching from
one view
to another. What do you think?





	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.

FL:

Yes, I think that would be the way you were asking for. In additional
plugins you can say that an already existing figure shall be replaced
by a
new figure and this new figure can be constructed however you'd like
it. So,
if you do not only want to have the name of the action in it, but
also some
properties, be it. If you'd prefer to show a monkey instead of
anything, so
just design one ;-)






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.

FL:

I fully agree. Best regards,

Florian

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev



_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev


_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev



Back to the top