Inferred relations

[Paolo F Cantoni]

If A is related to B which is related to C which is related to D, then transitively A is related to D (and so on).

I often want to show only A and D on a diagram.  The others are not useful on that diagram.

If I want to show the relationship between A and D, I create the relationship and give it the stereotype «inferred» - meaning it is transitively derived from other, relations.

I think (and have used it for over 10 years) this is a useful concept.  I think it would be good if EA provided more formal support for this; perhaps like the way we denote an element as "Abstract" we could denote it "Inferred".

Thoughts anyone?

I'll deal with the detailed semantics of inference if requested.

BTW «inferred» relations are not normally instantiated, but they could be on a case by case basis.

Paolo

[sargasso]

This is typically what I use dependencies for.

bruce

[Paolo F Cantoni]

This is typically what I use dependencies for.

Bruce

But if the relations are associations then A is associated to D, not dependent.  (As per your posts passim)

I won't go any deeper at this point.

Paolo

PS: If you ask me nicely, I'll put "bruce" and "sargasso" in my spell checker...

[sargasso]

But if the relations are associations then A is associated to D,...

No, I disagree.  Back to the assoc/depends argument.  To me , the association A-B is a discrete instance of the UML association element.  The existence of other, albeit equally valid associations between B and [some other element] do not confer any semantics between A and [some other element].  In your example, there is a (or some) semantic relationship between them, but to me it is not an association.

Concrete example, if I can think of one while the cleaner is vacuuming around me....

[Plant]-----[Fruit]
    |
    |*
[Fertilizer]

In the above case, unless there is a specific semantic in this implementation  there is no implied or inferred relationship, association or otherwise between Fertilizer and Fruit.

If there is some relationship, whether it be structural or otherwise, I can highlight it visually as a dependency and thus gain audience attention to the fact that its not just an association.

So we might add a dependency between Fruit and Fertilizer, further adorned with constraints or whatever to  include some information.  For example, a constraint indicating to the coders that they need to consider the legality of the particular fertilizer being added to :Plant iff
:Fruit is for human consumption.


bruce

[Paolo F Cantoni]

No, I disagree.  Back to the assoc/depends argument.  To me , the association A-B is a discrete instance of the UML association element.  The existence of other, albeit equally valid associations between B and [some other element] do not confer any semantics between A and [some other element].  In your example, there is a (or some) semantic relationship between them, but to me it is not an association.

Concrete example, if I can think of one while the cleaner is vacuuming around me....

[Plant]-----[Fruit]
     |
     |*
[Fertilizer]

In the above case, unless there is a specific semantic in this implementation  there is no implied or inferred relationship, association or otherwise between Fertilizer and Fruit.

If there is some relationship, whether it be structural or otherwise, I can highlight it visually as a dependency and thus gain audience attention to the fact that its not just an association.

So we might add a dependency between Fruit and Fertilizer, further adorned with constraints or whatever to  include some information.  For example, a constraint indicating to the coders that they need to consider the legality of the particular fertilizer being added to :Plant iff
:Fruit is for human consumption.


bruce

Sorry, Bruce...  So long as the multiplicity of any association is NOT 0..0, there IS a transitive association.  In your example it is the fertilizer used to fertilise the plant the fruit came from.  The semantics spring from the mathematical transitivity, not t'other way round...

Since they are binary relationships, we can always convert an association to its equivalent "functional notation"  engine_number(engine_in(car_with(number_plate))).

From this comes the notion of functional identity of inferred associations versus canonical ones.  A technique that can be used to validate models very effectively...

Paolo

[Eve]

I'm not going to get into the discussion of what is what, but you may be interested in the Heirachy window.

It shows relationships between elements to the level specified in the options (Tools | Options | General)

For example, if I set up the original example of this thread with associations between the classes.  If I click on A I get (in a tree form) A links to B links to C links to D.

It's not visible unless you click on a class involved, but I thought that you may find it interesting.

Simon

[Paolo F Cantoni]

I'm not going to get into the discussion of what is what, but you may be interested in the Hierarchy window.

It shows relationships between elements to the level specified in the options (Tools | Options | General)

Thanks Simon, I do find it very interesting!  I've observed some anomalies and I have some suggestions which I'll document in formal support email.

One suggestion which I will air here is:

At present, the hierarchy window (which may be misnamed as there are associations there as well) shows the "decomposition" from the source node only.  With (hopefully) only slight changes, If I select more than one classifier, the window could show ONLY those relations that connect the select classifiers!
As a conceptual and logical modeller, this would be very USEFUL!

Paolo