stereotypedrelationship on/from metaclass

[qwerty]

The Help says:

You can use a «stereotypedrelationship» connector between two Stereotypes or Metaclasses to specify a valid stereotyped connector between instances of those elements.

So I added one from a metaclass to a stereotype and one self-connector for that metaclass (being ActionPin; I just posted another bug related to that one). But neither is exported in the XML.

Is it just the Help being wrong or is there and work around?

q.

[Eve]

In my test it worked. Not sure what you've done differently. Are you looking in the right place?

Code: [Select]

<?xml  version='1.0' encoding='windows-1252' ?>
<UMLProfile profiletype="uml2">
<Documentation id="F3315FE4-E" name="MetaclassRules" version="1.0" notes="MetaclassRules"/>
<Content>
<Stereotypes/>
<TaggedValueTypes/>
<ViewDefinitions/>
<Metamodel>
<Metaclass name="ActionPin" notes="">
<stereotypedrelationships>
<stereotypedrelationship stereotype="ArchiMate3::ArchiMate_Flow" constraint="ActionPin;ActivityParameter"/>
</stereotypedrelationships>
</Metaclass>
<Metaclass name="ActivityParameter" notes="">
<stereotypedrelationships>
<stereotypedrelationship stereotype="ArchiMate3::ArchiMate_Flow" constraint="ActivityParameter"/>
</stereotypedrelationships>
</Metaclass>
</Metamodel>
</Content>
</UMLProfile>

[Paolo F Cantoni]

A couple of ideas to help debug things, q...


As Eve's solution says, these relationships end up in the <metamodel/> section.


Secondly, you now know how it should work.  I would import Eve's code (with appropriate changes for your specific needs) into your MDG, and confirm that it works.  If not, then there's something else "at play". If so, then just get your model to generate the same thing.  I've found things can get a bit "touchy" with the model-based QL and things stop working for no real apparent reason.


If you run these tests and it doesn't resolve things for you, let us know and I can help with some other ideas.


Paolo

[qwerty]

Well, I can't import the above XML to get me a «profile» model but only a working instance too proof it works. But I'm at the step before that.

I looked again: clearly I do have an ActionPin metaclass with three stereotyped relationships (of my object flow stereotype): One from a sterotyped activity parameter, one towards it and on self-reference for the metaclass. When I export the profile I only see a single occurence of ActionPin in the whole file:

Code: [Select]

<Stereotype name="activity parameter" metatype="Activity parameter" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="1" hideicon="0" generalizes="Noteable" baseStereotypes="Noteable">
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::object flow" constraint="ActionPin;MyProfile::activity parameter"/>
</stereotypedrelationships>
...
So that's only the one from the stereotype towards the metaclass. I don't see the other two.

q.

P.S. Forgot to say that the metamodel section is empty...

[Paolo F Cantoni]

Well, I can't import the above XML to get me a «profile» model but only a working instance to prove it works. But I'm at the step before that.




P.S. Forgot to say that the metamodel section is empty...

Yes, add Eve's code after generation, to check that it works.  Remove all references to the Action Pin relationship (sounds like only one).


Let us know if it works.


Paolo

[qwerty]

I don't doubt it works (though I'll check it). My problem is the step BEFORE that. My profile does not export that structure.

q.

[qwerty]

I added the above to my profile. But these Perspectives drive me crazy. I still have not figured out when they filter what. For the above I need the Archimate stuff. I enabled that in the MDG list but it does not offer anything from Archimate (neither in the drag-to-blank nor for any diagrams to create with). When trying to create an object flow (any) it still croaks it would be invalid.

It feels like crawling from one mud hole to the next.

q.

[Geert Bellekens]

Perspectives work reasonably well, and perspective sets work reasonably well.
The idea is to leave the MDG settings alone (everything enabled) and use the perspective to select the allowed MDG's.

With the perspective sets you can then create a set of (a single in my case) perspectives that is allowed for a group of users.

This helped to greatly reduce the number of diagram types etc.. available for the regular users, while still allowing the full set for power-users and administrators.

Geert

[Geert Bellekens]

Just don't use the "strict" option, because that will mess up everything (such as common relations like trace that are no longer visible)

Geert

[qwerty]

Basically I try to use it as you say. But these filters All, Personal, bla... just confuse me and never seem to do any filtering. It's just "something" that happens or does not happen. I know that I have the tendency to fall into SW traps that lay around nobody else ever fell in. Anyhow, I don't get it. And I've not touched the strict since I did understand the meaning of that less than the rest.

q.

[Geert Bellekens]

I have one Model based set that contains all the MDG's we use.
Then in the group restrictions, I have created a Perspective group that only contains my Perspective set, and I assign that set to the security group(s)

Now the users can only choose between my perspective or All (which is also only my perspective, so it doesn't matter which they choose)

Geert

[qwerty]

Well, I more or less did that too. But eventually I want to see "All" but I never notice any difference between that I my perspective. Just let's pretend it's "just me". There were times when I was excited using EA. Since years it's more and more growing a "uh, EA again?". Sad but true.

q.