Strict connectors and Metaconstraints

[qwerty]

Turned out (or looks like) defining a single metaconstraint will cook up everything. While without it's possible to create stereotyped ControlFlows between two elements as long as there is no metaconstraint, EA croaks about invalid connectors once I defined a single metaconstraint. Which basically means that I have to define EVERYTHING in order to make use of those constraints. Else you have turn off the whole mechanism COMPLETELY with the Start/Preferences/Connectors/Strict setting. It's probably a Sparxian approach but renders the whole thing to be very delicate Chinoise. I can't slightly introduce it, so to offer certain connectors the new way. It's all or nothing. Happy to learn something different but that made the fun turn into immediate pain again (already used to that so no pity).

q.

[Eve]

I accept that it's a bit of a balancing act. Strict connector checks have only one option, in comparison as soon as you have defined any constraints for a connector type it will obey that set of rules. I can't see any alternative to that second part though, if you're going to enforce the constraints they have to be enforced as soon as they are defined.

To be fair, it's not a system designed for baby steps. It's designed to help you define a full language.

Here's a starting point for your stereotyped ControlFlow. Drop ActivityNode from the abstract page of the metaclass dialog. Create two metaconstraints from your stereotype to it, one source the other target. Alternatively you could even do that with a single stereotyped relationship connector. For that much work your relationship is restricted to any elements that normally appear on Activity diagrams and offers quicklinks for all of them.

Edit: I wasn't going to mention it, but since it's been mentioned in other threads already... _HideUmlLinks on the source element's stereotype will stop the rule above from working because you've defined it to apply to the base UML type. In which case I hope that the elements you want to use have a common supertype.

[Paolo F Cantoni]

I accept that it's a bit of a balancing act. Strict connector checks have only one option, in comparison as soon as you have defined any constraints for a connector type it will obey that set of rules. I can't see any alternative to that second part though, if you're going to enforce the constraints they have to be enforced as soon as they are defined.

To be fair, it's not a system designed for baby steps. It's designed to help you define a full language.

Here's a starting point for your stereotyped ControlFlow. Drop ActivityNode from the abstract page of the metaclass dialog. Create two metaconstraints from your stereotype to it, one source the other target. Alternatively, you could even do that with a single stereotyped relationship connector. For that much work your relationship is restricted to any elements that normally appear on Activity diagrams and offers Quicklinks for all of them.

Edit: I wasn't going to mention it, but since it's been mentioned in other threads already... _HideUmlLinks on the source element's stereotype will stop the rule above from working because you've defined it to apply to the base UML type. In which case I hope that the elements you want to use have a common supertype.

(my emphasis)
The stereotyped relationship is the approach we've taken.  Are you inferring that the stereotypes relationship also functions as a form of metaconstraint?  We run without [  ] Strict Connector Syntax since, prima facie, we don't want to constrain the modeller.  However, we'd be interested in using the model validation process to find anomalies and investigate them.  Are we able to use these stereotyped relationships in the model validation process?

TIA,
Paolo

[Eve]

Are you inferring that the stereotypes relationship also functions as a form of metaconstraint?

Yes, they are functionally almost identical. With stereotyped relationship you are defining for each source here is the set of valid targets. It's more flexible, but the number of required links grows exponentially with the number of types you want to link. Although that can be mitigated by using abstract stereotypes as the source and targets as I believe you are doing.

In contrast, adding metaconstraints for the connector grows linearly with the number of source and targets. It does so at the expense of allowing control over which source elements link to which target elements. You can however use a mix of both. Stereotyped relationships from a source will override metaconstraints that include that type.

We run without [  ] Strict Connector Syntax since, prima facie, we don't want to constrain the modeller.  However, we'd be interested in using the model validation process to find anomalies and investigate them.  Are we able to use these stereotyped relationships in the model validation process?

Ah, but what is the value of the end model if the modeller doesn't model correctly? Strict Connector Syntax just gives the modeller instant feedback that what they are doing isn't supported by the metamodel. In turn that may allow you to find errors in the metamodel sooner. (Which is why I encourage everyone here who will listen to use strict connector syntax)

But yes, metaconstraints and stereotyped relationships are checked in Model Validation.

[Jayson]

I'm going to throw in a minor segue here as this topic is (kinda) related to something that is currently "doing my head in".

My understanding with Abstract Metatypes was that you can define stereotypes with abstract metatypes BUT that you CANNOT instantiate those abstract metatypes. Instead, you create a ToolboxItem that creates one of the CONCRETE sub-classes of that Abstract Metatype.

HOWEVER, what about UCInclude & UCExtend?
BOTH are abstract and yet you see them implemented as ToolboxItems that CAN be created between two Use Cases in the UML Use Case diagram.

Obviously my understanding of the Sparxian World is not correct, so what is the correct world view?

Jays :-)

[Paolo F Cantoni]

Not using [  ] Strict Connector Syntax is a legacy issue.  This will possibly change when we get the MDG fully converted to the new mechanisms.

"Professional Modellers" don't need it, and newbie modellers find it intimidating (and it greatly increases the friction they perceive).  Our current view is that it is more important to get them to enter their understanding of the model (with as little friction as possible) and help them refine it to be more correct as we detect errors - hence my question about validation.

The use of a sophisticated and valid QuickLinker is designed to make it much easier to create valid models (for everyone).  And yes, even with abstract stereotypes, the number of stereotyped relationships can be quite daunting for the modelling architect to manage.  I haven't had time to explore the metaconstraint mechanism, but I suspect that for our type of modelling it will be almost as complex (since if we can abstract, we do).  I might let qwerty be "point man " on this and see if we can piggyback on his experience.

Paolo

[Eve]

HOWEVER, what about UCInclude & UCExtend?
BOTH are abstract and yet you see them implemented as ToolboxItems that CAN be created between two Use Cases in the UML Use Case diagram.

The main issue I see is that they are not actually abstract, despite their appearance in the Abstract Metatypes page. You're getting a little into oddities the come about from Enterprise Architect being active now for 20 odd years and when writing profiles some of the available types you end up facing some places where the types available in EA don't align perfectly with the current standard.

Not using [  ] Strict Connector Syntax is a legacy issue.  This will possibly change when we get the MDG fully converted to the new mechanisms.

Just stirring the pot a little. 

[Paolo F Cantoni]

HOWEVER, what about UCInclude & UCExtend?
BOTH are abstract and yet you see them implemented as ToolboxItems that CAN be created between two Use Cases in the UML Use Case diagram.

The main issue I see is that they are not actually abstract, despite their appearance in the Abstract Metatypes page. You're getting a little into oddities the come about from Enterprise Architect being active now for 20 odd years and when writing profiles some of the available types you end up facing some places where the types available in EA don't align perfectly with the current standard.

Not using [  ] Strict Connector Syntax is a legacy issue.  This will possibly change when we get the MDG fully converted to the new mechanisms.

Just stirring the pot a little. 

Is there a list of the available types which DO fit the current standard?  I've fallen foul of a couple of these oddities in the past.
What I'd like is a list that is, "if you use these types (as far as we can see), you should be covered".  Anything else is "caveat emptor".

As to stirring the pot, I didn't take it personally... 

Paolo

[Jayson]

You mean something like documentation?
That's crazy talk. I'll report you to the mods if you keep that up!
But yeah, totally agree.

[qwerty]

I accept..

Thanks for the feedback. Good to have some confirmation. I already stumbled in the direction you pointed out (I'm quite a bit away from freely walking). So I have to get my head around that all. The all or nothing choice does not make it easy. So there should be configurability in the area of the model checks (I know it won't come and I'll see how to arrange myself with the given possibilities).

q.