Difference between Quicklinkers and Stereotyped/Meta Constraints

[Jayson]

Hey all

I am trying to understand the difference between the traditional quicklinkers and stereotypesd/meta constraints.

Are they functionally the same (i.e. just two methods to achieve the same thing)?
It seems to me that the quicklinkers seem to have more options built into them, but it could be that I am missing something with the constraints.

Cheers

Jays :-)

[Geert Bellekens]

The meta constraints serve actually two purposes

- They define the allowed relations between stereotype (strict connector syntax
- They define the quicklinker entries.

The good thing is that both quiklinker and valid relations are now using the same source.
And of course you are no longer required to work with the dreadful quicklink csv.

Geert

[Jayson]

Hey Geert

Thanks for that.
Looking at the Quicklinker format, it has the ability to filter to diagram.
Is there an equivalent in the constraints? I can't seem to find any.

Cheers :-)

[KP]

Hey Geert

Thanks for that.
Looking at the Quicklinker format, it has the ability to filter to diagram.
Is there an equivalent in the constraints? I can't seem to find any.

Cheers :-)

The quicklinker has a Filter to Toolbox option, set to true by default. The toolbox shown depends on the diagram type.

[Jayson]

Hey KP

My mistake for not making my question clearer.
I was asking if Stereotyped/Meta Constraints have an equivalent functionality.

Cheers

Jays :-)

[Eve]

What KP was saying is that it's automatic when using metaconstraints.

The quicklinker only populates relationships and new elements that appear in the current toolbox. That means your toolbox definition (or view specification) is equivalent to the diagram filter in the old table.

Every diagram type you (or someone else using your profile) define automatically gets a restricted view of the quicklinks matching the toolbox for that diagram.

You lose the ability to express it with excruciating detail, in return for not having to.

[Modesto Vega]

Having read through this post, the way forward is to use meta-constraints instead of the old Quicklinker. However, there is something I am unclear about.

If I want to develop an MDG where I extend the out-of-the-box relationships,

1) Can I use the umlRole tag to refer to the extended relationships?
2) If so, what syntax do I use? [Profile Name]::[Relationship Name]?

I am likely to have a further question but let's start here.

[Eve]

1) Can I use the umlRole tag to refer to the extended relationships?

No. If you have the umlRole property you've used a metaconstraint connector. The umlRole can only have the values specified in https://sparxsystems.com/enterprise_architect_user_guide/15.2/modeling/metaconstraint.html

2) If so, what syntax do I use? [Profile Name]::[Relationship Name]?

Simplest approach is to create a stereotyped relationship and specify your relationship in the stereotype field. You can specify [Profile Name]::[Relationship Name] here to describe a relationship from another profile.

[Modesto Vega]

2) If so, what syntax do I use? [Profile Name]::[Relationship Name]?

Simplest approach is to create a stereotyped relationship and specify your relationship in the stereotype field.

This is exactly what we are doing. However, how do we get the stereotype relationships to show in the Quicklinker?

The nearest example in https://sparxsystems.com/enterprise_architect_user_guide/15.2/modeling/metaconstraint.html to what we are doing is "realizingConnector/ realizingActivityEdge/ realizingMessage" but there is a lot of missing detail that needs to be guessed.
1) How do we get the "OperationalExchange (which extends a UML InformationFlow metaclass)" to appear in the Quicklinker associated with the OperationalPerformer stereotype without using the Quicklinker CSV?
2) What does the OperationalConnector extend, the Realization? Is the meta constraint "telling it" to extend the Realization?
3) What does the OperationalPerformer extend? This is missing from the example.
4) How do we specify that the OperationalExchange  stereotyped relationship applies to the OperationalPerformer? I thought we could use meta constraints for this but it is clear from Eve's response that this is not the case.

[snip]
The meta constraints serve actually two purposes

- They define the allowed relations between stereotype (strict connector syntax
- They define the quicklinker entries.

My understanding from the quote above is that the dreaded Quicklinker CSV can be avoided by using meta constraints. What have I missed?

Nowhere in the documentation I can find a detail description of how to get stereotyped relationships 1) used between "stereotyped" elements and 2) appearing in the Quciklinker without using the CSV file. Yet discussions in the forum seem to suggest it is possible. Perhaps I missed something.

[Eve]

create a stereotyped relationship and specify your relationship in the stereotype field.

This is exactly what we are doing. However, how do we get the stereotype relationships to show in the Quicklinker?

Are you? You appear to be looking for anything except doing that.

Possible mistakes... 1. Entering the wrong value into the stereotype field. 2. Creating the stereotyped relationship between the wrong stereotypes. 3. Not having the stereotype in the toolbox. 4. Not exporting your profile or importing the technology.

The nearest example in https://sparxsystems.com/enterprise_architect_user_guide/15.2/modeling/metaconstraint.html to what we are doing is "realizingConnector/ realizingActivityEdge/ realizingMessage" but there is a lot of missing detail that needs to be guessed.
1) How do we get the "OperationalExchange (which extends a UML InformationFlow metaclass)" to appear in the Quicklinker associated with the OperationalPerformer stereotype without using the Quicklinker CSV?
2) What does the OperationalConnector extend, the Realization? Is the meta constraint "telling it" to extend the Realization?
3) What does the OperationalPerformer extend? This is missing from the example.
4) How do we specify that the OperationalExchange  stereotyped relationship applies to the OperationalPerformer? I thought we could use meta constraints for this but it is clear from Eve's response that this is not the case.

This constraint type only apply if you have a stereotyped information flow that you want to restrict the relationships that can realize the flow. You still need to create both relationships before you can realize a flow though, so it will not help your current problem even if you do have a stereotyped information flow.

The extensions for OperationalConnector and OperationalExchange are not relevant to the example. At a guess, OperationalConnector would be extending Connector (the instance type for an Association) and OperationalPerformer would be extending Object.

My understanding from the quote above is that the dreaded Quicklinker CSV can be avoided by using meta constraints. What have I missed?

Nowhere in the documentation I can find a detail description of how to get stereotyped relationships 1) used between "stereotyped" elements and 2) appearing in the Quciklinker without using the CSV file. Yet discussions in the forum seem to suggest it is possible. Perhaps I missed something.

https://sparxsystems.com/enterprise_architect_user_guide/15.2/modeling/metamodelconstraints.html
You have the two stereotypes from your profile that you want to link between, create a stereotyped relationship connector between them and set the name of the stereotyped connector in the stereotype field (Not setting the stereotype). If one of the ends is from another profile, use an abstract stereotype with the name <Profile>::<Stereotype>. If the relationship is from another profile you can just type in <Profile>::<Stereotype>.

[Modesto Vega]

[SNIP]

create a stereotyped relationship and specify your relationship in the stereotype field.

This is exactly what we are doing. However, how do we get the stereotype relationships to show in the Quicklinker?

Are you? You appear to be looking for anything except doing that.

The beginning of your reply is rather unhelpful, you are assuming your customers are doing something wrong. But I have come to expect this type of reply from time to time.

Certainly the last example in the page does not result on the relationship appearing in the Quicklinker. But we will double check the possible mistakes, starting with guessing the syntax for whatever needs to go in the stereotype field.

[Eve]

you are assuming your customers are doing something wrong

It works for many users and it works for built-in profiles. Even if you've found a bug, it will be possible to make it work. Yes, I'm assuming that you're doing something wrong and I'm assuming that I can help you find out what that is. Here's a hint. The closest to a stereotyped relationship is a stereotyped relationship. It's not any kind of metaconstraint.

Certainly the last example in the page does not result on the relationship appearing in the Quicklinker. But we will double check the possible mistakes, starting with guessing the syntax for whatever needs to go in the stereotype field.

There's no need to guess any syntax. If the stereotype is in the same profile you just need the name. If it's in a different profile (even within the same technology) it also needs the profile name.

How about you share the structure of your profile? Are the two elements you want to connect and the relationship type in the same profile? If not, which ones are in a different profile?

[Modesto Vega]

[SNIP]
The closest to a stereotyped relationship is a stereotyped relationship. It's not any kind of metaconstraint.

Stereotyped relationships are unlikely to be the issue.

[SNIP]
There's no need to guess any syntax. If the stereotype is in the same profile you just need the name. If it's in a different profile (even within the same technology) it also needs the profile name.

How about you share the structure of your profile? Are the two elements you want to connect and the relationship type in the same profile? If not, which ones are in a different profile?

I suspect the issue is here. The profile is too big to be shared but the general idea is a follows:

• We have a profile called "AF"
• The profile extends a Class to create an element called "Business Information"
• The profile extends 2 Components to create 2 elements we called "Information System Service" and "Application" (each of them has different properties)
• The profile extends an Association to create a relationship we call "Conveys" (this relationship can be bi-directional)

In addition, we want to be able to specify that the "Conveys" relationship applies between an "Information System Service" or an "Application" and "Business Information" element or vice-versa, and, of course, make it appear in the Quicklinker. To try to achieve this, we have drawn a stereotyped relationship between "Information System Service" and "Business Information", and between "Application" and "Business Information". If the above is supposed to work, the issue we may have is how do we refer to "Conveys" relationship in the stereotype tag of the stereotyped relationship, we see 3 options:

• Conveys
• AF::Conveys
• AF_Conveys

From memory, we are using the 2nd option but reading through the documentation I suspect we should be using the last option. Unless I missed something this is not very clear in the documentation.

[Geert Bellekens]

You need to use only the name of your stereotype Conveys since it's in the same profile (option 1)

An alternative for the stereotyped relationship is to create metaconstraints from your "Conveys" stereotype to your "Business Information" stereotype with umlrole "supplier"
and create two metaconstraints from "Conveys" to "Information System Service" and "Application" with umlrole "client"

This is a bit more crude as it won't allow you to indicate the exact allowed combinations, but in this case it should work just fine.

Make sure you have all your stereotypes on the toolbox when you try the quicklinker.

Geert

PS. Your stereotypes might collide with other existing stereotypes, making things harder than they have to be sometimes. I made it a habit to prefix all of my stereotypes with the name of the profile. So if I were you I would choose "AF_Application" as stereotype and not simply "Application"

[Eve]

we see 3 options:

• Conveys
• AF::Conveys
• AF_Conveys

From memory, we are using the 2nd option but reading through the documentation I suspect we should be using the last option. Unless I missed something this is not very clear in the documentation.

Both 1 and 2 will work. 1 is easier, but the export adds the namespace of the current profile if none is found anyway. 3 is completely unrelated to the name of the stereotype and will not work.

If you are using 2, make sure that AF is your profile name. Not the profile alias or the technology name/alias which will all be displayed in various places if they exist.