Stereotype Relationship vs. Metaconstraint with source/target

metaconstraints are a powerful tool to define user specific constraints. For example, if you want to define that a certain relationship with a stereotype should be used between two model elements (with or without stereotype), there are several possibilities.

Two different approaches lead to the same goal:

  • Stereotyped Relationships: This restriction can be created between two stereotypes or metaclass model elements. In a TaggedValue an existing stereotype of a relationship can be entered.
  • Meta-Constraint: This constraint can be configured differently. With the TaggedValue umlRole=source | target a constraint can be created between model element(s) and relation. See example below. In the EA help we also find terms like client | supplier; informationSource | informationTarget; All these configurations lead to the same result, but use the corresponding terms from the UML meta model.

The following example shows how to define stereotyped lifelines (MyLifeline and YourLifeline) in a sequence diagram and how to use a message with stereotype MySequence and YourSequence. I.e. this restriction adds a rule that these relationships may be used and also appear in the Quicklinker.

But if you want to classify the Lifelines, you have to change the profile.

For this example we adapt the stereotypes a bit. Say we want to create the stereotype <<MyA>> and <<<MyB>>.

In a sequence diagram we want to use Lifelines of type <<MyA>> or <<<MyB>> to connect them to the message with stereotype <<<MyASequence>> and <<<MyBSequence>>. The profile for this looks like this:

To give the Lifeline its own stereotype, the stereotype <<MyAInstance>> and <<<MyBInstance>> was created. Further constraints can now be defined on these stereotypes. For example, the message with the stereotype <<MyBSequence>> can only be created between <<<MyBInstances>>. 

With <<MyAInstance>> the same happens, but with a different constraint technique, the Stereotype Relationship constraint instead of the metaconstraint with source/target.

Furthermore, a classifier constraint is introduced which states that a <<MyAInstance>> or <<<MyBInstance>> may have the type <<<MyA>> or <<<MyB>>. This also means that the EA offers an additional “Drop as:” option for drag & drop of <<MyA>> or <<<MyB>>:

The dropped element will be a model element of type Lifeline with stereotype <<MyAInstance>> from the profile SupportCase. 

If a Lifeline with the stereotype <<MyAInstance>> is created, the Classifier Constraint results in the fact that only model elements of the type Component with the stereotype <<<MyA>> can be selected. Of course, the same is true for <<MyB>>.

If the stereotype of the Component (<<MyA>>) and the Lifeline (<<MyAInstance>>) is identical, this does not lead to the desired result! Since the stereotype can be applied to Component and Lifeline, you have to choose what you want to create, which is not so critical, but since the stereotype <<<MyASequence>>/<<MyBSequence>> extends the Message and this is constrained to <<<MyA>>/<<MyB>>, this leads to the fact that <<<MyASequence>>/<<<MyBSequence>> can also be used between Components with stereotype <<<MyA>>/<<MyB>>!

The following profile defines the same stereotype for Component and Lifeline. but leads to the mentioned constraint application for Component and Lifeline model-elements.

It is not recommended to duplicate the stereotype (<<MyA>>/<<MyB>>) model element, because they are unique in the profile and may only be defined once!



Posted in Best Practices, News