Metaconstraints curiosity question

[qwerty]

Now that the <metamodel> tag is populated and EA starts interpreting it, what happens if I have multiple MDGs turned on and they happen to have contradicting settings? E.g. you could have defined constraints for the Package metaclass in more than one profile. I'd guess that just funny (or more correctly frustrating) things might happen. Any idea?

Hmm, while writing this I just think that "constraint" is not the right word being used. It's more the opposite. Each of these constraints does not constrain but free the use of certain connectors. So it makes me wonder why they actually were called that way?

q.

[Eve]

So it makes me wonder why they actually were called that way?

Part of that is easy. We took the names and intention from the UAF profile.

My interpretation of the name metaconstraint is that the set of constraints with the same umlRole from the same element forms the whole constraint. Initially, your stereotyped Property will inherit the UML constraint that the 'type' is a 'Type'. When you add you add a «metaconstraint» { umlRole = type }, that forms a constraint. Subsequent relationships expand that constraint.

Which allows me to answer the first part of your question.

Now that the <metamodel> tag is populated and EA starts interpreting it, what happens if I have multiple MDGs turned on and they happen to have contradicting settings? E.g. you could have defined constraints for the Package metaclass in more than one profile. I'd guess that just funny (or more correctly frustrating) things might happen. Any idea?

The relationship source/target elements in EA are defined using the same system. So, each profile is able to expand the existing constraint. However, you won't necessarily see any extras on all diagram types because the default behavior is to filter the quicklinker to what's available in the toolbox. The result is that the added options in the quicklinker will often be restricted to the diagram types that include the new target elements.

[qwerty]

Thanks for the clarification! I'm not going over to OMG asking for their rationales. I found them reacting on defect reports even slower than Sparx ;-)

Maybe since you were talking about the impossibility of having baby steps with those constraint means that you either have a no-constraint model or one with exact constraints. This again is a bit impractical from a user perspective. The way I'm modeling is to stepwise refine the meta model so you can start somewhere to offer a "meaningful" set of possible connectors rather than the full flagship of possibilities which is really a sort of constraint. Then go over to the next area and repeat the process. Unfortunately that's not the way it works (with EA). I start with the full set and have to tell: cut it down plus add mine. I don't have enough experience yet to get a good idea on how it should be or how to work around things. But definitely I already ran against some boulders which had been not that obvious.

q.