Relationship directionality and verbs

[Modesto Vega]

The following thread l, https://sparxsystems.com/forums/smf/index.php/topic,48487.0.html, has triggered the following though process, which is not new.

Let’s assume that I want to verbalise connectors, for example:

A ———>B, where the connector is a dependency
A ———|>B, where the connector is a realisation
A———-<>B, where the connector is a composition

If I want to represent them as sentences in a document as follows:
A depends on B or A flows to B
A is realised by B or B realises A
B consists of A or A is part of B

What elements should I put as the source and destination of each relationship?

How does the choice of modelling language affect the choice of source and destination elements? For this 2nd question, please think about ArchiMate’s flow relationship: if A flows to B, I would put A as my source and B as my destination, but if I were to draw this as UML dependency, I would say that B depends on A and will have the directionality reversed.

I am sure I have posted about this before but I want to understand in more detail how Sparx EA transition from base UML to ArchiMate or other modelling languages.

[Paolo F Cantoni]

The following thread l, https://sparxsystems.com/forums/smf/index.php/topic,48487.0.html, has triggered the following though process, which is not new.

Let’s assume that I want to verbalise connectors, for example:

A ———>B, where the connector is a dependency
A ———|>B, where the connector is a realisation
A———-<>B, where the connector is a composition

If I want to represent them as sentences in a document as follows:
A depends on B or A flows to B
A is realised by B or B realises A
B consists of A or A is part of B

What elements should I put as the source and destination of each relationship?

How does the choice of modelling language affect the choice of source and destination elements? For this 2nd question, please think about ArchiMate’s flow relationship: if A flows to B, I would put A as my source and B as my destination, but if I were to draw this as UML dependency, I would say that B depends on A and will have the directionality reversed.

I am sure I have posted about this before but I want to understand in more detail how Sparx EA transition from base UML to ArchiMate or other modelling languages.

Hi Modesto,
 As it happens, I’ve been thinking about directionality and relationship naming quite intensively over the last couple of weeks.  My concerns aren’t quite the same as yours, but this discussion may be useful.  In particular, we use our own modelling technology, that tries to incorporate all the major languages.
A little bit of scope/context to apply to my remarks.  I’m currently exploring how to take visual modelling models and use them as part of knowledge Graphs.  This means that the semantics of the model needs to be very clear.  As I’ve said many times if we look at a visual model relationship (normally a binary relationship or arc) on the screen or a piece of paper, we can’t tell which end was the origin and which was the destination.  However, as you note, knowing this is vital for understanding the correct semantics – especially by machines!
Accordingly, we have adopted the convention that where the rendering of the arc has a defined destination shape (such as the realization arrowhead) then that end will be the destination and the other end the origin.  Where the destination isn’t clearly defined with a unique shape (such as with Associations – especially when using “crow’s feet” notation), then an indicator of the destination is provided (via the shapescript).  Thus, both the machine and the viewer can see which end is which.
Further, having consistently defined the direction, we can then assert that for such structural relationships, the origin is the client and the destination is the supplier.
In attempting to incorporate all the major visual modelling languages, we noted (in a sense as you have), discrepancies between the semantics and directionality of the arcs.  The major discrepancy is between the UML Generalization and ArchiMate Specialization.  Our analysis suggests that UML got it the wrong way around!  Indeed, ArchiMate corrected this with the Specialization relationship!
What do we mean by “got it the wrong way around” and what does it imply for your question?
If as we decided, the client is the origin and the destination is the supplier, then the named semantics should flow from the client to the supplier.  For example, if we have a dependency relationship the named semantics have to be read: origin depends on destination (or client depends on supplier).  Any other interpretation is inconsistent!  This mechanism is true for all the other UML relationships except for Generalization.
9.9.7.1 Generalization [Class]
Description
A Generalization is a taxonomic relationship between a more general Classifier and a more specific Classifier. Each instance of the specific Classifier is also an instance of the general Classifier. The specific Classifier inherits the features of the more general Classifier. A Generalization is owned by the specific Classifier
From this, we can determine that the origin is the specific and the destination (with the arrowhead) is the general.  It makes no sense to say: “the specific generalizes the general”.
Compare this with the ArchiMate definition:
5.4.1 Specialization Relationship The specialization relationship represents that an element is a particular kind of another element. The specialization relationship has been inspired by the generalization relationship in UML class diagrams but is applicable to specialize a wider range of concepts. A specialization relationship is always allowed between two instances of the same element type.
See how they use the “magic” word inspired?  They are indicating that UML is not the same as ArchiMate.
From the ArchiMate definition, we can infer that the origin (client) is specific and the destination (supplier) is the general – just like in UML!  But see the difference in semantics: “the specific specializes the general”.
As an aside, immediately under this section, ArchiMate says:
Alternatively, a specialization relationship can be expressed by nesting the specialized element inside the generic element.
This puts paid to Sparxian Eve’s assertion that visual embedding always implies containment!

OK, so assuming you agree with the above, I would assert that the semantics you imply to the Realization relationship you provided an example of above, is similarly the wrong way around…
The UML standard says:
7.8.14.1 Realization [Class]
Description
Realization is a specialized Abstraction relationship between two sets of model Elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.
It seems pretty clear from the foregoing discussion that the origin (client) is the instance and the destination (supplier – with the arrowhead) is the specification.  Consequently, the semantics are: “instance realizes specification”!  This is borne out by the example in the standard but is the opposite of yours!

Unfortunately, I would contend that you have also got the Composition relationship semantics the wrong way around.  From my reading of the UML specification (and unfortunately the definition of “Composition” isn’t in one place but spread around - particularly sections 9.5.3 and 11.2.3), the composition glyph needs to appear at the destination (supplier – the composition) and the origin (client) is the component.  Thus, the semantics will read: “component composes into composition” (alternatively, “component is part of composition”).  I believe this is the opposite of your example.
Now to your “Flow Example”.  As you suggest, in common parlance one would assert that the flow is from the origin to the destination (and thus the flow arrowhead would be placed at the destination end).  However, from what I’ve previously said, this would mean the origin is the client and the destination is the supplier.  This would seem at odds with how one would normally understand such a narrative.  This is resolved by observing that Flow is NOT a structural relationship and thus we can say that the origin is the supplier and the destination is the client in this case.
You are correct in asserting that the directionality of the dependency is the inverse of the flow.  This is common in many situations – indeed, ArchiMate addressed this when they replaced the uses relationship with the serves relationship.  We had to reverse all our uses in our repository when we converted!

Does this help clarify things?

Paolo



By the way, if figuring out the naming of binary relationships “does your head in”, wait till you need to handle N-Ary relationships!

[Geert Bellekens]

In UML there is no source/target or client/supplier for associations. (A composition is nothing more than a (binary) association with aggregationkind "composite" at one of the ends)

There is simply a relationship, and two (or more) ends.

The fact that we still need to use source/target is purely a technical contraint from Sparx and shouldn't have a meaning.

Geert

[Paolo F Cantoni]

In UML there is no source/target or client/supplier for associations. (A composition is nothing more than a (binary) association with aggregationkind "composite" at one of the ends)

There is simply a relationship and two (or more) ends.

The fact that we still need to use source/target is purely a technical constraint from Sparx and shouldn't have a meaning.

Geert

Hi Geert,
This is indeed true, but it REALLY helps if you have a consistent mechanism to provide consistent semantics.  This is particularly true of Associative relationships.
Without this consistency, it gets very hard to semantically validate a model.

Paolo

[Elpis]

From this, we can determine that the origin is the specific and the destination (with the arrowhead) is the general.  It makes no sense to say: “the specific generalizes the general”.

But you can say "the specific _is generalized by_ the general". :-)

[Paolo F Cantoni]

From this, we can determine that the origin is the specific and the destination (with the arrowhead) is the general.  It makes no sense to say: “the specific generalizes the general”.

But you can say "the specific _is generalized by_ the general". :-)

Yes Elpis,  you can...
Every binary relationship has two semantic directions.  The forward and the inverse.  Indeed, EA handles this in the MDG via the MeaningForwards and Meaning Backwards properties of the metaclass.   If the forward direction is named generalizes then is generalised by is the inverse name.  Alternatively, if the forward direction is named is generalised by then generalizes is the inverse (or backward).
I can't say why Modesto posed the original question, but my interpretation is that he was having difficulty coming up with a consistent mechanism to name the meaning of the relationships in the generated narrative.
I would contend that if you want to use the second form (and I have in some/many past cases) then you need to do that consistently (as with the first form).  Modesto's examples are therefore self-inconsistent in both forms!
Nowadays, we tend to use the active form.  But either is fine, so long as one is consistent.  As user Uffe says:
Concistency, konsistency, consistensy! ^TM_{Uffe - after Paolo}

Providing that consistency allows the QuickLinker to work correctly!

Paolo

PS: I didn't notice this before, but Dependency and Flow are not inverses of each other as Modesto suggests.  They are two interrelated relationships that happen to have inverse directionalities.

PPS: @Modesto - this isn't a "Modesto bashing" episode, but your OP was the catalyst for the analysis.

[Modesto Vega]

It has been a long week and this is a big subject.

I am not sure what examples were inconsistent or self-inconsistent.

But to provide some context, I am exploring how Sparx EA implements relationships in 4 UML, ArchiMate, XML, and data models. This exploration is taking place as I am considering switching a UML based custom MDG to an ArchiMate based MDG with some additions to handle things ArchiMate cannot do - e.g., anything that involves the use of data attributes. The main reason for doing this is that ArchiMate does many of the things we want to add to the custom MDG and it is easier to do it with a selection of out-of-the-box Sparx EA ArchiMate functionality than writing our own UML based MDG. As part of this process I reviewed section 5.6 of the ArchiMate specification, https://pubs.opengroup.org/architecture/archimate3-doc/ch-Relationships-and-Relationship-Connectors.html#sec-Summary-of-Relationships, which indicates that relationships in ArchiMate are directional.

I am making a number of assumptions:
1. Sparx EA has an under the hood a meta model which is not full UML but something very similar the root of UML, see section 7.2 Root of the UML 2.5.1 specification.
2. Sparx Systems has implemented, under the hood, an MDG of sorts to support full UML modelling.
3. This UML MDG of sorts introduces directionality, irrespective of whether UML is directional or not, this includes the meaning forwards and backwards of connector properties Paolo referred to.
4. This UML MDG of sorts is the foundation for any other native MDG - i.e., Sparx EA translates everything to UML, for example it translates ArchiMate to MDG. This is a critical point.

In short, Sparx EA uses a very layered approach to supporting any modelling languages other than UMl.

Now, lets look at some examples.

In UML

Start	End	Connector	Meaning forwards/backwards
A	B	Dependency	A depends on B/B is dependent on A
A B C	D	Realization	A, B & C realize D/D is realised by A, B & D
A B C	D	Composition	A, B & C are composed into D/D is composed of A, B & D
A B	C	Generalisation/Specialisation	A & B specialised C/C is specialised by A & B
A B C D	F	Association	A, B, C & D are associated to F/F is associated to A, B, C & D

Hopefully none of of that is too controversial.

Now ArchiMate does not have the concept of a Dependency, instead it has 4 dependency relationships: serving, access, influence & association, all of which are implemented in Sparx EA as dependencies - i.e., using a UML dependency as the underlying type - and they are all directional -e.g A access B/B is accessed by A, A is the source and B the target. The facts that an ArchiMate association is a dependency presents a challenge, perhaps not unsurmountable, but not having the concept of a dependency is a more complicate challenge to address, as we will have to translate all dependencies to one of those types if we chose to switch the MDG to ArchiMate.

The dynamic relationships and flow, in particular, are more interesting. Flow is also implemented with a UML dependency as the underlying type. But it is what I called in my original post a reversed dependency - e.g., if A flows into B, in ArchiMate I put A as the start and B as the target, the meaning forward is B depends on A - so far no problem with this.

What it is becoming clear as I write this, is that switching the MDG from UML to ArchiMate is likely to require a new MDG not just an iteration of the current MDG as I had hoped.


 

[Paolo F Cantoni]

Hi Modesto,
your assertion that ArchiMate says that Association is a Dependency and thus would be challenging intrigued me.  I'd never thought that.  So I went and checked! You're correct that it appears in section 5.2 Dependency Relationships.  But I don't think they explicitly say it's a dependency.  I read that they put it there because they had nowhere else to put it and didn't want to have a section containing just one relationship.

Association as Dependency makes no sense!  Indeed, Association is different from the other relationships because it is explicitly bi-directional and without the explicit semantic naming of the two directions would read "A is associated with B and B is associated with A".  This is unlike any other relationships we discussed.  Your last example above confirms this.

In our modelling environment which encompasses both UML and ArchMate, we have left Associations as Associations.

HTH,
Paolo

[Eve]

From this, we can determine that the origin is the specific and the destination (with the arrowhead) is the general.  It makes no sense to say: “the specific generalizes the general”.
Compare this with the ArchiMate definition:
5.4.1 Specialization Relationship The specialization relationship represents that an element is a particular kind of another element. The specialization relationship has been inspired by the generalization relationship in UML class diagrams but is applicable to specialize a wider range of concepts. A specialization relationship is always allowed between two instances of the same element type.
See how they use the “magic” word inspired?  They are indicating that UML is not the same as ArchiMate.
From the ArchiMate definition, we can infer that the origin (client) is specific and the destination (supplier) is the

I'm sure you'll be thrilled to learn that SysML2¹ has Specialization, although in general you'll use its specializations: Subclassification to relate Classifiers, Subsetting and Redefinition to relate Features, and FeatureTyping to relate a Feature to a Classifier.

As an aside, immediately under this section, ArchiMate says:
Alternatively, a specialization relationship can be expressed by nesting the specialized element inside the generic element.
This puts paid to Sparxian Eve’s assertion that visual embedding always implies containment!

Or it would, if I had said that.

My comments were on a thread that noted that ArchiMate relationships are hidden when the elements are visually embedded, but most UML connectors aren't. That behavior is because we explicitly implemented the ArchiMate rules for when visual embedding can imply a given relationship. UML on the other hand does not explicitly specify similar rules, so Sparx Systems implemented our own rules for when the intention is clear without showing the connector. Those rules, which predate ArchiMate, do correspond to containment. I will say those rules do allow for a minimum loss of information by suppressing the connector, and every additional possible relationship that behaves like that will make the intention less clear. That does not mean I'm saying that there are no other interpretations, especially not in other languages.

In UML there is no source/target or client/supplier for associations. (A composition is nothing more than a (binary) association with aggregationkind "composite" at one of the ends)
...

This is indeed true, but it REALLY helps if you have a consistent mechanism to provide consistent semantics.  This is particularly true of Associative relationships.
Without this consistency, it gets very hard to semantically validate a model.

Again, it sounds like SysML2¹  will be something that you'll like. Associations do have source and target, and FeatureMembership which is the equivalent of aggregation/composition is always from owningType to ownedFeature.

Association as Dependency makes no sense!  Indeed, Association is different from the other relationships because it is explicitly bi-directional and without the explicit semantic naming of the two directions would read "A is associated with B and B is associated with A".  This is unlike any other relationships we discussed.  Your last example above confirms this.

In our modelling environment which encompasses both UML and ArchMate, we have left Associations as Associations.

An ArchiMate Association has shares nothing but the name in common with a UML Association.

An association relationship represents an unspecified relationship, or one that is not represented by another ArchiMate relationship.

That sounds very similar to how I often see a UML Dependency used and the summary text for UML Dependency.

A Dependency signifies a supplier/client relationship between model elements where the modification of a supplier may impact the client model elements.

¹ Technically all this is actually from KerML, which has been developed as part of SysML2 and forms the basis of SysML2.

[Modesto Vega]

As an aside, immediately under this section, ArchiMate says:
Alternatively, a specialization relationship can be expressed by nesting the specialized element inside the generic element.
This puts paid to Sparxian Eve’s assertion that visual embedding always implies containment!

Or it would, if I had said that.

My comments were on a thread that noted that ArchiMate relationships are hidden when the elements are visually embedded, but most UML connectors aren't. That behavior is because we explicitly implemented the ArchiMate rules for when visual embedding can imply a given relationship. UML on the other hand does not explicitly specify similar rules, so Sparx Systems implemented our own rules for when the intention is clear without showing the connector. Those rules, which predate ArchiMate, do correspond to containment. I will say those rules do allow for a minimum loss of information by suppressing the connector, and every additional possible relationship that behaves like that will make the intention less clear. That does not mean I'm saying that there are no other interpretations, especially not in other languages.

I never thought Eve said that containment = embedding.

Going back to the original question and before dwelling deeper into the subject.

Composition in ArchiMate is defined as  "[It] represents that an element consists of one or more other concepts"; if the verbalisation is based ← composed of/→ composed in.

How do we verbalise  Car ♦---- Wheel, Car is composed of Wheel or Wheel is composed of Car?

[Paolo F Cantoni]

As an aside, immediately under this section, ArchiMate says:
Alternatively, a specialization relationship can be expressed by nesting the specialized element inside the generic element.
This puts paid to Sparxian Eve’s assertion that visual embedding always implies containment!

Or it would, if I had said that.

My comments were on a thread that noted that ArchiMate relationships are hidden when the elements are visually embedded, but most UML connectors aren't. That behavior is because we explicitly implemented the ArchiMate rules for when visual embedding can imply a given relationship. UML on the other hand does not explicitly specify similar rules, so Sparx Systems implemented our own rules for when the intention is clear without showing the connector. Those rules, which predate ArchiMate, do correspond to containment. I will say those rules do allow for a minimum loss of information by suppressing the connector, and every additional possible relationship that behaves like that will make the intention less clear. That does not mean I'm saying that there are no other interpretations, especially not in other languages.

I never thought Eve said that containment = embedding.

Going back to the original question and before dwelling deeper into the subject.

Composition in ArchiMate is defined as  "[It] represents that an element consists of one or more other concepts"; if the verbalisation is based ← composed of/→ composed in.

How do we verbalise  Car ♦---- Wheel, Car is composed of Wheel or Wheel is composed of Car?

Hi Modesto, we use:
Wheel composes into Car.  Car is composed of Wheel. However, I don't like the second.  One could use Car includes Wheel (removing the implication that a car consists ONLY of wheels).


HTH,
Paolo

[PDC]

we use:
Wheel composes into Car.  Car is composed of Wheel. However, I don't like the second.  One could use Car includes Wheel (removing the implication that a car consists ONLY of wheels).

Interesting. I don't think there is anything in the SysML spec to suggest that a Composition Relationship is restrictive to *only* those Elements that partake in that Relationship. I don't think the English language implies that either. If anything , 'composes into' sounds very clunky to me (doesn't really make sense in English). But I'd probably never read it that way round - the Relationship is directed, with a source and target, so I would *always* read it as "A Car is Composed of Wheels (as well as potentially other things too that are not described by this Relationship".

[Paolo F Cantoni]

we use:
Wheel composes into Car.  Car is composed of Wheel. However, I don't like the second.  One could use Car includes Wheel (removing the implication that a car consists ONLY of wheels).

Interesting. I don't think there is anything in the SysML spec to suggest that a Composition Relationship is restrictive to *only* those Elements that partake in that Relationship. I don't think the English language implies that either. If anything, 'composes into' sounds very clunky to me (it doesn't really make sense in English). But I'd probably never read it that way around - the Relationship is directed, with a source and target, so I would *always* read it as "A Car is Composed of Wheels (as well as potentially other things too that are not described by this Relationship".

It's not a SysML thing, I think it was related to UML in the past.  Also, when EA (and UML) had Composition Relationships (UML 1.x) as distinct from Associations (rather than as today, an Association with the ends marked with the appropriate holonymy marker), you could have EA draw them in weird ways - adding to the potential confusion.

Back to the issue of the implication that a car only consists of wheels, I acknowledge that I spoke somewhat incorrectly.  Why have I italicised somewhat?  The original UML point was that just as it was a consequence of the Composition relationship that when the holonym was destroyed, any currently attached meronyms would also be destroyed, it follows that when ALL the meronyms of a holonym are destroyed, the holonym is, ipso facto, destroyed (the essential difference between an aggregation and a composition).  The problem is that there may be more than one composition relationships that make up the holonym.  I should have been clearer.

In SysML, (I don't use it yet), is the source (origin) the meronym (part)  or is it the holonym (whole)?  In our modelling, the meronym is always the origin and the holonym the destination. The semantics we use require that the naming be origin to destination.  So while I agree that composes into is a bit clunky - it is consistent with the requirements we have.

Paolo

[PDC]

It's not a SysML thing, I think it was related to UML in the past.  Also, when EA (and UML) had Composition Relationships (UML 1.x) as distinct from Associations (rather than as today, an Association with the ends marked with the appropriate holonymy marker), you could have EA draw them in weird ways - adding to the potential confusion.

Ah ok, I don't really have the history on EA (only used v9, 15 and 16) so I haven't experienced it from all angles. Thanks for the background!

Back to the issue of the implication that a car only consists of wheels, I acknowledge that I spoke somewhat incorrectly.  Why have I italicised somewhat?  The original UML point was that just as it was a consequence of the Composition relationship that when the holonym was destroyed, any currently attached meronyms would also be destroyed, it follows that when ALL the meronyms of a holonym are destroyed, the holonym is, ipso facto, destroyed (the essential difference between an aggregation and a composition).  The problem is that there may be more than one composition relationships that make up the holonym.  I should have been clearer.

No I think you were probably clear enough - again without decdes of experience in UML probably some of this has passed me by; 'every day is a school day'!
I agree with your point about Composition in the context of the wheel/car definition (deleting the car does not delete the wheels, and there will be other things that the car is composed of...).

In SysML, (I don't use it yet), is the source (origin) the meronym (part)  or is it the holonym (whole)?  In our modelling, the meronym is always the origin and the holonym the destination. The semantics we use require that the naming be origin to destination.  So while I agree that composes into is a bit clunky - it is consistent with the requirements we have.

Agreed. I would also say that the Part/meronym is the source/origin and that the whole/holonym is the target (consistent with SysML spec definitions,although I'm struggling to find a specific section reference in there - but it will be the same definition as in UML).

[Paolo F Cantoni]

No, I think you were probably clear enough - again without decades of experience in UML probably some of this has passed me by; 'every day is a school day'!
I agree with your point about Composition in the context of the wheel/car definition (deleting the car does not delete the wheels, and there will be other things that the car is composed of...).

With respect, I believe the composition relationship is not as you describe it.  You may be confusing the classifier with the instance.  You are correct in asserting that destroying (not deleting - more later) the Car classifier doesn't destroy the Wheel classifier.  However, at the instance level, if the wheel is attached to the car, it must be destroyed with the car (think "nuked")!  However, the wheel may be detached from the car (and therefore no longer participates in the composition) then it survives.

This is the essential difference between composite aggregation (aka "Composition") and shared aggregation (aka "Aggregation").  Aggregation is like Team membership, you can destroy the team without destroying the players.  Also, a player can be in more than one team at the same time whereas the wheel can only be on one car at a time.  The other distinguishing mechanism for which type of "holonymy is in play".

HTH,
Paolo