v15 - How to show self-metatype relationships in metamodel?

[Paolo F Cantoni]

IIRC the Archimate specification says (something along the lines of):
"Any metatype vertex can have an aggregation relationship to another vertex of the same metatype."

In the new model-based QuickLinker mechanism, I can create a generic abstract metatype (Element) and I can define a self-referencing «stereotypedrelationship» which does, indeed, allow me to link any element to any other element with the aggregation relationship.

But how do I restrict the destination metatype to be the same metatype as the origin?

TIA,
Paolo

[philchudley]

Hi Paolo

My first instinct would be try using metaconstraints specifying valid source and target

I know this works with defined stereotypes, it's worth a try between the metaclass which the stereotype extends?

All the best

Phil

[Paolo F Cantoni]

Thanks, Phil, 

but in our previous mode - where we generated the QuickLinker from a database,  we had tens of thousands of relationships between specific metatypes.  I agree that it ought to be a meta-constraint to handle this, but I can't see one.  Moving it up from the specific metatype vertex to its immediate parent abstract stereotype doesn't give us much simplification.

I suspect an extension of umlRole subtypes is what's needed.  (Or I may have misinterpreted what the existing values can do - still a neophyte here)

Paolo

[Geert Bellekens]

I don't think this is one you can generalize (at least not with the current toolset)
If you define in on the top level that would allow any type to be connected to any other type, so you'll have no choice but to define the relation on each of the (concrete) stereotypes.

Geert

[Eve]

The good news that the deficiency is in the help, not the tool.

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 to the actual metaclass when it's used.

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.

[Paolo F Cantoni]

The good news that the deficiency is in the help, not the tool.

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]

That IS good news!

Since I'm so new to this do I just add the meta-constraint to the arc?
Is this a umlRole meta-constraint or some other?  Can you provide a worked example for "the source metatype and the target metatype must be the same"?

TIA,
Paolo

[Eve]

To follow your archiMate example:

Define Abstract Stereotype 'Element' (may extend Concept if you're following their metamodel)
Abstract Stereotype 'Motivation Element' specializes Element (possibly indirectly)
Concrete Stereotypes 'Value', 'Meaning', 'Driver', 'Assesment', 'Goal', 'Outcome', 'Principle', and 'Requirement' all specialize 'Motivation Element'
Concrete Stereotype 'Constraint' specializes requirement.

I'm not describing the extension connectors.

Create a stereotype «stereotyped relationship» {stereotype=Composition} to a «metaclass» with one of the names in my previous post. In all cases each of the stereotypes will be allowed to have a composition to other elements with the same stereotype. How they differ is in the behavior of Requirement and Constraint.

If the target is 'source.metatype' Neither Requirement or Constraint will be able to have a composition relationship to the other.

If the target is 'source.metatype.general', Constraint can have a composition to Requirement.

If the target is 'source.metatype.specific', Requirement can have a composition to Constraint.

If the target is 'source.metatype.both', both can have a composition to the other. (Which happens to match the relationship table in the ArchiMate specification)

Which one is your interpretation of "every element in the language can have composition, aggregation, and specialization relationships with elements of
the same type"?

[philchudley]

Interesting and thanks

I am a little confused over the target "value" source.metatype etc  How this is specified, since a stereotype relationship has a tagged value for the stereotype, so where do you specify the target "value"?

Thanks
Phil

[Eve]

so where do you specify the target "value"?

The name of the target metaclass.

[Paolo F Cantoni]

To follow your archiMate example:

Define Abstract Stereotype 'Element' (may extend Concept if you're following their metamodel)

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)

[SNIP]

Which one is your interpretation of "every element in the language can have composition, aggregation, and specialization relationships with elements of
the same type"?

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.

Paolo

[Eve]

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.

I've read a lot of specifications. In my opinion the writers of the ArchiMate specification are guilty of sloppiness more than most specification writers. I guess that's part of why they added the relationship tables to the spec.

My interpretation would call for source.metatype.specific, and I'm not sure I would read it any different with the word metatype.

Interestingly, SysML is a mixed bag.

8.3.2.4 Block Constraints

[8] Any classifier that specializes a Block shall also have the Block stereotype or one of its specializations applied.

9.3.2.9 InterfaceBlock doesn't list a restriction in its constraints, so it should inherit the above constraint. Because of this it would seem block should directly reference itself rather than using source.metatype.specific.

10.3.2.1 ConstraintBlock Constraints

[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.

[Paolo F Cantoni]

[SNIP]

My interpretation would call for source.metatype.specific, and I'm not sure I would read it any different with the word metatype.

[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.

One thing I've noted that NONE of the standards has is the ability to exclude.  We use the multiplicity zero for exclusion.  So for example, we might make a relationship relate to a higher-order metatype, but have an additional semantically identical relationship to a lower order metatype but with a multiplicity of zero.  we render that multiplicity as a red cross via shapescripts which identifies that there may be no such relationship between these two metatypes.  Perhaps you might think about including the concept of exclusion to handle special cases.

Paolo

[Eve]

How about I say that you should link to a metaclass called 'unmatched.metatype'?

[Paolo F Cantoni]

so where do you specify the target "value"?

The name of the target metaclass.

Do you mean the Target.Role Name?  Nothing seems to pop out on MDG when I do (unlike, say , _MeaningForwards)

Paolo

[Eve]

No. A class element, with the stereotype «metaclass» and the name "source.metatype".

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».