MDG profile for Activity Diagrams

[vrieg]

Hello all,

I would like to :
1. Provide a toolbox for activity diagram modeling limiting the amount of elements (complexity reduction) to Actions, Activity, Initial/Final Node, and Decision/Merge, Fork/Join,...
2. add a tagged value as an attribute to some of the elements by the use of enumerations.

So which metaclasses should be extended in the MDG profile?
- For Activity/Action corresponding metaclass exists
-For Initial/Final Node I expected a metaclass like a StateNode according to UML Spec. However profile helper and MDG Toolbox dont propose such.
- For Decision/Merge  and Fork/Join Nodes I expected a metaclass like a ControlNode according to UML Spec. However profile helper and MDG Toolbox dont propose such.
I appreciate any feedback ...

In addition to the extension of metaclasses I used a generatlizatio relationship from net created "mystereotype " to the Sysml stereotypes, i.e. SysMLActivity:Decision,  SysMLActivity:Activity,...

Is this technically correct?

Thanks a lot and kind regards

[Geert Bellekens]

No, that doesn't seem correct at all.
You shouldn't use SysML if you are extending UML.

There is an ActivityFinal, ActivityInitial metaclasses.

There are probably also a metaclasses for Decision/Merge, and Fork/Join as well.

You might want to look at the MDG for BPMN as an example as that extends Activity Diagrams as well.

Geert

[wivel]

You might want to look at the MDG for BPMN as an example as that extends Activity Diagrams as well.

Some years back I tried to build an MDG based on BPMN 2.0, with the goal of limiting options. I got stuck prety quickly, since:
1. I couldn't limit the Tagged Value choises
2. For some reason, my MDG couldnt distinguish between Lanes and Pools, even if I used the same metaclasses as in BPMN 2.0

Could just be me not knowing what I was doing, but that wouldn't be the firste time 

On a different note, when you limit choices using an MDG, there is a risk that you will have to revisit it quite often to add make it less and less restricted as the users gets better at using the limited modeling notation. Think you time will be better spend on making a set of modeling guidelines/standards instead.

Henrik

[vrieg]

Hello Geert and Henrik,

thanks for your hints.
Extension of Activity/Actions, Decision/Merge is working as expected now.
For ForkNode, JoinNode, and ActivityFinal, ActivityInitial unfortunately I could not add attritional attributes by an extension. However all elements appear within the toolbox page and can be used as expected within the diagrams. Any further ideas?

[Geert Bellekens]

For ForkNode, JoinNode, and ActivityFinal, ActivityInitial unfortunately I could not add attritional attributes by an extension.

Why not?
What wasn't working?

You can post images of the UML profile diagram, and the relevant part of the generated profile XML for us to verify.

Geert

[Modesto Vega]

ForkNodes and JoinNodes are not "proper" elements. In fact, I am not even sure if they are elements or connectors. They do not appear in the project browser, and are diagram specific/local to diagram.

My guess is that ActivityFinal and ActivityInitial nodes are the same.

[Geert Bellekens]

ForkNodes and JoinNodes are not "proper" elements. In fact, I am not even sure if they are elements or connectors. They do not appear in the project browser, and are diagram specific/local to diagram.

My guess is that ActivityFinal and ActivityInitial nodes are the same.

They might not appear in the project browser, but they are real elements nonetheless.

I did a bit of digging and found that there are metaclasses you can choose for

- Decision -> Decision
- Merge -> MergeNode
- Fork/Join -> Synch(H) or Synch(V) (horizontal or vertical)

I don't see a reason why these should behave different from other metaclasses, but you never know...

Geert

[Modesto Vega]

They might not appear in the project browser, but they are real elements nonetheless.

They are featureless elements, attributes cannot be added to them out-of-the-box. I doubt an MDG can be used to add features - e.g., attributes - to out-of-the-box featureless elements.

Decision, ActivityFinal and ActivityInitial nodes do appear in the project browsers. But this is not the case for fork and join nodes.

[Geert Bellekens]

They might not appear in the project browser, but they are real elements nonetheless.

They are featureless elements, attributes cannot be added to them out-of-the-box. I doubt an MDG can be used to add features - e.g., attributes - to out-of-the-box featureless elements.

Decision, ActivityFinal and ActivityInitial nodes do appear in the project browsers. But this is not the case for fork and join nodes.

I suppose vrieg is trying to add tagged values to these elements (attributes on the stereotype)
That should work (I haven't tried it myself, but I don't see a reason why it shouldn't work)

Geert

[Modesto Vega]

It is possible to add tags to all of them, I have just tried with v15. I agree tags should solve vrieg problem.

[PeteC]

You could consider using a View Specification to limit the items in the toolbox (and that always gives the expert user the option of switching to a fuller set of tools). It's described in https://sparxsystems.com/resources/user-guides/15.2/modeling/mdg-technologies.pdf from page 63 on. That doesn't require you to redefine any diagrams or tools but to work with the tools available from the standard EA toolboxes (if that is appropriate for you - that obviously won't add the tagged values that you are interested in).