Simulation and own MDG

[Paolo F Cantoni]

Simulation can use the BPMN MDG (in the appropriate EA versions).

As I have mentioned many times, we have created our own MDG to allow us to have finer grained control over elements.

If we wanted to use simulation with our own elements, is it as simple as extending the BPMN elements to our own stereotypes?  If not can it be done at all?

TIA,
Paolo

[Eve]

In theory it should be that simple. In practice I don't know if every single stereotype check in BPMN simulation is done the right way.

It may be safer to apply your stereotype as a secondary stereotype.

[Paolo F Cantoni]

In theory, it should be that simple. In practice, I don't know if every single stereotype check in BPMN simulation is done the right way.

It may be safer to apply your stereotype as a secondary stereotype.

Thanks for that Eve,

I'll have a go.

We've standardised on a single stereotype per element, so secondary stereotypes might be problematic.

From your response, do I take it that if the stereotype check fails I should report a defect?

We haven't got our model based MDG going yet.  Can I do this with the older style MDG file spec?  If so, how do I specify the extension functionality?

Has anybody else attempted this?

[Eve]

I suspected that you would have a single stereotype, although I don't know if that's memory or extrapolation.

I'm curious, how much did EA only displaying one stereotype in the properties influence that decision? EA 15 changes that behavior (although applying the change to connectors etc wasn't quite ready for the current beta)

I'd still suggest using a secondary stereotype if at all possible. It's going to be easier for you to implement, and I suspect significantly less likely to give you issues. While I would encourage bug reports if an extended stereotype doesn't behave like the original, any issues are still going to take time before you end up with a fix.

Extending BPMN stereotypes is possible directly via XML. Follow the instructions in Create Stereotypes Extending non-UML Objects and see what it exports.

[Paolo F Cantoni]

I suspected that you would have a single stereotype, although I don't know if that's memory or extrapolation.

I'm curious, how much did EA only displaying one stereotype in the properties influence that decision? EA 15 changes that behaviour (although applying the change to connectors etc wasn't quite ready for the current beta)

[SNIP]

The decision had nothing to do with EA's rendering.
It was a conceptual decision.  Each item is a specific (and unique) metatype and so requires ONLY one stereotype.  Where we would have used multiple stereotypes in the past we now use tags.  This is further enhanced by v15's display of MDG defined tags as properties.  It's made life MUCH easier in the background having just to check the one stereotype column instead of multiple places and with weird queries.

That having been said, when we get our model-based MDG going, we'll do a lot of specialization via appropriate relationships.  I would think this will further reinforce the single metatype concept.

I'll see if I can get away with NOT having more than one stereotype.

Paolo

[Geert Bellekens]

I agree with you Paolo.
An element should have only one stereotype for both practical as conceptual reasons.

Geert

[qwerty]

I agree with you Paolo.
An element should have only one stereotype for both practical as conceptual reasons.

Geert

For practical reasons multiple stereotypes are just nice. I have defined <<deprecated>> and <<TBD>> stereotypes which also color elements (red and yellow).

q.

[Geert Bellekens]

I agree with you Paolo.
An element should have only one stereotype for both practical as conceptual reasons.

Geert

For practical reasons multiple stereotypes are just nice. I have defined <<deprecated>> and <<TBD>> stereotypes which also color elements (red and yellow).

q.

Aren't those more like statuses?
I use stereotypes only to describe the nature of the object => meta-type.
It feels wrong to use stereotypes for anything else.

But it is true that it sometimes can be an easy workaround. Especially for attributes, as the stereotype is one of the only fields that is shown on a diagram.

Geert

[Eve]

From a UML perspective, stereotypes are a view that is applied on top of an element.

EA extends that a little to define alternate metatypes, but that's not the original intention.

One reason for multiple stereotypes is along the lines of applying multiple orthogonal views to the same set of elements. In order to do that without multiple stereotypes you would need an exponential number of concrete stereotypes.

EA's stereotype handling includes some of the concept of different ways that you may want to use stereotypes.

https://www.sparxsystems.com/enterprise_architect_user_guide/15.0/modeling/restricting_application_of_mul.html
By setting the strictness you can specify that a particular stereotype must be treated as a unique metatype, will be treated as a unique metatype within its own profile/technology or that it can be applied in conjunction with any other stereotype (that doesn't block it the other way around)

[Paolo F Cantoni]

From a UML perspective, stereotypes are a view that is applied on top of an element.

Shouldn't that be "applied to Classifiers"?  Not criticising, just querying (clarifying for my understanding).
Reading the UML 2.5.1 spec, a stereotype could be seen as defining a Property Set to be applied to the Classifier.

EA extends that a little to define alternate metatypes, but that's not the original intention.

One reason for multiple stereotypes is along the lines of applying multiple orthogonal views to the same set of elements. In order to do that without multiple stereotypes, you would need an exponential number of concrete stereotypes.

That sounds suspiciously like multiple-inheritance.  It seems that they (OMG) are advocating to use stereotypes as convenient ways to define standardised property sets (as mentioned above) so that you can mix and match as required.  Is that a reasonable interpretation?

EA's stereotype handling includes some of the concepts of different ways that you may want to use stereotypes.

https://www.sparxsystems.com/enterprise_architect_user_guide/15.0/modeling/restricting_application_of_mul.html
By setting the strictness you can specify that a particular stereotype must be treated as a unique metatype, will be treated as a unique metatype within its own profile/technology or that it can be applied in conjunction with any other stereotype (that doesn't block it the other way around)

So it would seem we can define a "primary stereotype" that defines the explicit metatype (as per mine and Geert's point) and auxiliary stereotypes that define additional properties for the metatype (perhaps common among many metatypes).  Have I understood correctly?

Paolo

[Eve]

I used the word "Element" as a reference to the UML Element type, which is the superclass of everything you see in the UML metamodel. Meaning you can apply a stereotype on top of anything. (The MARTE profile has stereotypes that can be applied to all named elements)

If you have a stereotype extending Classifier, then all classifiers are valid to apply the stereotype to. (The classifier is the metaclass, the instances are any element in your model)

In EA it's more like adding a composite property to the instance that adds properties as defined by the stereotype. (ie. one of the common patterns for avoiding multiple inheritance)

Yes, primary stereotype as a metatype, and auxiliary stereotypes for for additional properties. (I'll call them facets)

And if you want EA to enforce that, set the strictness to profile for all of your metatypes. Then define a second profile in your technology for the facets. EA will then only allow you to define a single metatype, but you can freely apply facets.