| Metaclass | Description |
| source.metatype | The target element must match the exact stereotype defined at the source. |
| source.metatype.general | The target element may match the exact stereotype used at the source and any concrete (isAbstract=false) generalized stereotypes. |
| source.metatype.specific | The target element may match the exact stereotype used at the source and any concrete (isAbstract=false) specialized stereotypes. |
| source.metatype.both | The target element may match the exact stereotype used at the source and any concrete (isAbstract=false) generalized or specialized stereotypes. |
The good news that the deficiency is in the help, not the tool.That IS good news! :)
The help should have something like this.
Special Metaclasses
You can specify the source of a connector to be a superclass of all specialized forms, and the target to a special metaclass that specifies a relationship to the actual metaclass when it's used.
[SNIP]
so where do you specify the target "value"?The name of the target metaclass.
To follow your archiMate example:Haven't had a chance to try this out yet, stillat home. But a quick question, why does Element extend Concept. In our model, it specializes. (Trying to understand how this all works)
Define Abstract Stereotype 'Element' (may extend Concept if you're following their metamodel)
[SNIP]Good question, Gunga Din. That's one reason I was using the term metatype. Even Standards writers can be sloppy at times. Regardless of what ArchiMate says, we want (in our methodology/technology) to implement "every element in the language can have composition, aggregation, and specialization relationships with elements of
Which one is your interpretation of "every element in the language can have composition, aggregation, and specialization relationships with elements of
the same type"?
But a quick question, why does Element extend Concept. In our model, it specializes.Yes, I should have said specializes.
Good question, Gunga Din. That's one reason I was using the term metatype. Even Standards writers can be sloppy at times. Regardless of what ArchiMate says, we want (in our methodology/technology) to implement "every element in the language can have composition, aggregation, and specialization relationships with elements of
the same metatype". So I guess, we'll be using source.metatype.
[8] Any classifier that specializes a Block shall also have the Block stereotype or one of its specializations applied.
[2] Any classifier that specializes a ConstraintBlock shall also have the ConstraintBlock stereotype applied.Taken literally this would only allow specializations of itself and not potential specializations that may be defined later.
[SNIP]Ah yes, my bad. Having re-read the definiioons, I'd agree. I'm hoping to have a go shortly and will use source.metatype.specific.
My interpretation would call for source.metatype.specific, and I'm not sure I would read it any different with the word metatype.
[SNIP]
Do you mean the Target.Role Name? Nothing seems to pop out on MDG when I do (unlike, say , _MeaningForwards)so where do you specify the target "value"?The name of the target metaclass.
No. A class element, with the stereotype «metaclass» and the name "source.metatype".Sorry, Eve,
Ie. You specify it exactly the same as saying you can only specialize a "UseCase", "Class" or any UML metaclass. It differs from your stereotypes because it is «metaclass» instead of «stereotype».
<?xml version="1.0" encoding="windows-1252"?>
<xmi:XMI xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001" xmlns:umldi="http://www.omg.org/spec/UML/20131001/UMLDI" xmlns:dc="http://www.omg.org/spec/UML/20131001/UMLDC" xmlns:thecustomprofile="http://www.sparxsystems.com/profiles/thecustomprofile/1.0" xmlns:EAUML="http://www.sparxsystems.com/profiles/EAUML/1.0" xmlns:Profile_Constraints="http://www.sparxsystems.com/profiles/Profile_Constraints/1.0">
<xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
<uml:Model xmi:type="uml:Model" name="EA_Model">
<packagedElement xmi:type="uml:Profile" xmi:id="EAPK_E48A9BBC_5DB2_4d63_96A2_FFE843F40EEF" name="MyArchiMate">
<packagedElement xmi:type="uml:Stereotype" xmi:id="EAID_311CC9E2_E488_4e56_9F5E_3BA42DA14153" name="Element" isAbstract="true"/>
<packagedElement xmi:type="uml:Dependency" xmi:id="EAID_45B06FE1_D511_4242_82AE_D5B6DEC97761" supplier="EAID_E74B6DDB_F70D_40d8_9032_C5667C6E1F64" client="EAID_311CC9E2_E488_4e56_9F5E_3BA42DA14153"/>
<packagedElement xmi:type="uml:Dependency" xmi:id="EAID_4BC5A764_60C8_444e_88D7_DEB9396168C3" supplier="EAID_E74B6DDB_F70D_40d8_9032_C5667C6E1F64" client="EAID_311CC9E2_E488_4e56_9F5E_3BA42DA14153"/>
<packagedElement xmi:type="uml:Dependency" xmi:id="EAID_64E0282A_347F_42ed_B590_44B1A9CEC0F6" supplier="EAID_E74B6DDB_F70D_40d8_9032_C5667C6E1F64" client="EAID_311CC9E2_E488_4e56_9F5E_3BA42DA14153"/>
<packagedElement xmi:type="uml:Class" xmi:id="EAID_E74B6DDB_F70D_40d8_9032_C5667C6E1F64" name="source.metatype.specific"/>
</packagedElement>
<profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_thecustomprofile">
<appliedProfile xmi:type="uml:Profile" href="http://www.sparxsystems.com/profiles/thecustomprofile/1.0#thecustomprofile"/>
</profileApplication>
<profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_9752B6B7-0">
<appliedProfile xmi:type="uml:Profile" href="http://www.sparxsystems.com/profiles/Profile_Constraints/1.0#9752B6B7-0"/>
</profileApplication>
</uml:Model>
<Profile_Constraints:stereotyped_relationship base_Dependency="EAID_45B06FE1_D511_4242_82AE_D5B6DEC97761" __EAStereoName="stereotyped relationship" stereotype="Aggregation"/>
<Profile_Constraints:stereotyped_relationship base_Dependency="EAID_4BC5A764_60C8_444e_88D7_DEB9396168C3" __EAStereoName="stereotyped relationship" stereotype="Composition"/>
<Profile_Constraints:stereotyped_relationship base_Dependency="EAID_64E0282A_347F_42ed_B590_44B1A9CEC0F6" __EAStereoName="stereotyped relationship" stereotype="Specialization"/>
<thecustomprofile:metaclass base_Class="EAID_E74B6DDB_F70D_40d8_9032_C5667C6E1F64"/>
</xmi:XMI>
<?xml version="1.0" encoding="windows-1252"?>
<UMLProfile profiletype="uml2">
<Documentation id="E48A9BBC-5" name="MyArchiMate" version="1.0" notes="MyArchiMate"/>
<Content>
<Stereotypes>
<Stereotype name="Element" notes="" isAbstract="true">
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyArchiMate::Composition" constraint="source.metatype.specific"/>
<stereotypedrelationship stereotype="MyArchiMate::Specialization" constraint="source.metatype.specific"/>
<stereotypedrelationship stereotype="MyArchiMate::Aggregation" constraint="source.metatype.specific"/>
</stereotypedrelationships>
</Stereotype>
</Stereotypes>
<TaggedValueTypes/>
<ViewDefinitions/>
<Metamodel/>
</Content>
</UMLProfile>| Metaclass | Description |
| source.metatype | The target element must match the exact stereotype defined at the source. |
| source.metatype.general | The target element may match the exact stereotype used at the source and any concrete (isAbstract=false) generalized stereotypes. |
| source.metatype.specific | The target element may match the exact stereotype used at the source and any concrete (isAbstract=false) specialized stereotypes. |
| source.metatype.both | The target element may match the exact stereotype used at the source and any concrete (isAbstract=false) generalized or specialized stereotypes. |
I haven't had the time to test it to my satisfaction, but it's not working like I would have expected. I'll try to comment further when I get a chance.Thanks, Eve,
[BUMP]I haven't had the time to test it to my satisfaction, but it's not working like I would have expected. I'll try to comment further when I get a chance.Thanks, Eve,
I've put it aside until you give further guidance.
Paolo
I still haven't had time to investigate to my satisfaction.Thanks, Eve,
I'm afraid that some of the described functionality is currently only in a development version.
From what I can see, source.metatype and source.metatype.specific have checks in quicklinker generation. However, because the stereotype check later includes specialized stereotypes they act the same except when dragging to empty space.
Those two plus source.metatype.general have validation code, but given you seem to be able to create the relationships it doesn't appear to be correct.
Hi Eve,[BUMP]
Any "movement at the station" in the intervening week?
At a minimum, we'd like to know what the eventual functionality will be so we can plan our MDG relationship structure.
Paolo
I'm expecting all four self.metatype variants to work in 15.1.Thanks, are you able to specify them analogously to that I published on Aug 20, 2019? If they now work that way then a statement to that effect would be useful.
[BUMP]I'm expecting all four self.metatype variants to work in 15.1.Thanks, are you able to specify them analogously to that I published on Aug 20, 2019? If they now work that way then a statement to that effect would be useful.
Paolo
<?xml version="1.0" encoding="windows-1252"?>
<UMLProfile profiletype="uml2">
<Documentation id="65DAE813-A" name="metatypetest" version="1.0" notes="metatypetest"/>
<Content>
<Stereotypes>
<Stereotype name="A" notes="">
<stereotypedrelationships>
<stereotypedrelationship stereotype="metatypetest::W" constraint="source.metatype"/>
<stereotypedrelationship stereotype="metatypetest::X" constraint="source.metatype.general"/>
<stereotypedrelationship stereotype="metatypetest::Y" constraint="source.metatype.specific"/>
<stereotypedrelationship stereotype="metatypetest::Z" constraint="source.metatype.both"/>
</stereotypedrelationships>
<AppliesTo>
<Apply type="Class">
<Property name="isActive" value=""/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="B" notes="" generalizes="A" baseStereotypes="A"/>
<Stereotype name="C" notes="" generalizes="B" baseStereotypes="B"/>
<Stereotype name="W" notes="">
<AppliesTo>
<Apply type="Dependency">
<Property name="_MeaningBackwards" value="RW"/>
<Property name="_MeaningForwards" value="FW"/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="X" notes="">
<AppliesTo>
<Apply type="Dependency">
<Property name="_MeaningBackwards" value="RX"/>
<Property name="_MeaningForwards" value="FX"/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="Y" notes="">
<AppliesTo>
<Apply type="Dependency">
<Property name="_MeaningBackwards" value="RY"/>
<Property name="_MeaningForwards" value="FY"/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="Z" notes="">
<AppliesTo>
<Apply type="Dependency">
<Property name="_MeaningBackwards" value="RZ"/>
<Property name="_MeaningForwards" value="FZ"/>
</Apply>
</AppliesTo>
</Stereotype>
</Stereotypes>
<TaggedValueTypes/>
<ViewDefinitions/>
<Metamodel/>
</Content>
</UMLProfile>
My sample profile behaves as I would expect.Indeed it does! Having now played with it, I realise that I have made a fundamental misunderstanding of the functionality provided. Now that I understand, I see that it is, indeed, providing the specified functionality for:
[SNIP]
<Stereotype name="D" notes="" generalizes="A" baseStereotypes="A"/>
<Stereotype name="E" notes="" generalizes="D" baseStereotypes="D"/>
I'd like to be able to define the ability to specify relationships between "Ds" and "Bs", "Ds" and "Cs", "Bs" and "Es" and ""Cs" and "Es". Since they all descend from "A",I may be misunderstanding what you're after.To paraphrase Professor Higgins (My Fair Lady). "By George, he's got it!"
If you want to B and C to be able to link to D and E, just target A itself with the stereotyped relationship. There's no need for a special target because it's consistent across all specialisations.
To paraphrase Professor Higgins (My Fair Lady). "By George, he's got it!"I'd prefer the original.