[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [jwt-dev] Bonita Designer use cases and requirements
|
Hi all,
> 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".
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!?
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
