I hadn't originally meant to get involved with this, but I may be able to clarify some ideas mentioned in this thread. We use derived relationships a lot in our modelling and have done so for nearly a decade. We've done a lot of thinking about the problem (of derived relationships) and how to model them, and we're quite happy with how this works. BTW: We work in the Enterprise modelling space more than the specific system modelling, so the types of items and relationships are complex.
Firstly, we need to clarify some terminologies. In any model, there is a pile of relationships between items. Some relationships are
canonical (that is, they can't be derived by traversal of other relationships), and if you remove them, the model is not valid any longer, and others can be
derived by traversing two or more other relationships (so they could be removed and if one knows the derivation rule achieve the same outcome).
ArchiMate (for example) has a set of rules for deriving relationships by traversing others.
We distinguish between
Derivation (i.e., by known rules) and
Inference (i.e., arbitrary
guestimation). Thus, a canonical relationship can be
Inferred, but a Derived relationship can't (since the rules are known).
Our MDG will
graphically distinguish between a canonical and derived relationship. It will also
surface that the relationship is inferred. Since there may be more than one route between any two nodes on a network, we also allow the
definition of the traversal route that defines that
specific derived relationship. This is achieved via relationship-to-relationship relationships (try saying that after a few pints
). We don't do this often, but it is very useful when we do.
If the derived relationship is worthy of display, then it is worthy of inclusion in the model
[1]. Remember, you can always suppress the derived relationship on diagrams (and Sparx provides functionality to do this without a lot of effort). However, on an enterprise model, when a new user puts both ends of a derived relationship on a diagram, they get immediate feedback that a known relationship exists between the two, even if they aren't aware of it! We have found this MOST useful.
As I mentioned above, there may be many paths between two arbitrary items on the network, so expecting Sparx to figure that out is both unreasonable and impossible. Whether a (possible) derived relationship between two items is meaningful to the model or not is a modeller-level question, not a tool one.
That being said, it would be good if Sparx allowed ANY relationship type to be marked as derived (not just Associations). In our view, it would also be useful if one could indicate the nature of the derivation. We now use a number:
- Traversal
- Union
- Projection
- Realization
- Specialization
- Generalization
- Restriction
I won't detail the specifics at this time.
Derived relationships are not trivial to use. Over two (but less than three) decades ago, I had the pleasure of escorting Jim Rumbaugh (of "Three Amigos" UML fame) around Sydney for a day - some time before UML was released. I mentioned to him that one of the reasons I
really liked his (original) methodology was that it defined derived relationships! He cautioned me: "Don't say that; we haven't figured out how to make it work!". A few decades on,
we're comfortable that we've figured it out...
HTH,
Paolo
[1]Sparx, themselves, break that rule with Virtual Connector Ends and cause us grief (not themselves, apparently) trying to render them diagrams as we'd wish.
