Naming and documenting derived relationships?

[Alberto]

Does anyone have best practices for naming/documenting derived relationships?

I usually just name the relationships "Derived" but I'm finding that as models grow, knowing exactly the source, path, and rule used for the derivation is lost if I don't add it to the documentation, but even that is something I haven't quite nailed in a satisfactory way.

I wonder what everyone is using for capturing this information? The notation used in the Archimate documentation (e.g. DR2: p(a,b):S and q(b,c):T then r(a,c):U) seems like a good start and something I can add to scripts, but can get ugly fast.  Would using properties be better?

[Jean-Baptiste Sarrodie]

Hi,

Well, derived relationships are just "relationships", so I see no need to name or tag them in a specific way.

For example, I often have multiple Flows that go from some application functions to some other application components/functions/services (in detailed views), and some derived one that only go from application component to another application component (in overviews). In such cases, I simply name them according to the single data conveyed (in detailed view) or the dataset (in overviews). But the order in which I create them can vary because for a new application I might start from the overview, while when documenting an already existing application I might start from the detailed one. So it is hard to says which one is derived based on the other (and I don't see a need for that).

During some "philosophical" discussions with some peers, we acknowledged that in some (IMHO rare) cases, it might be handy to keep track of the fact that a relationship has been derived from other ones, so that when deleting one of the latter, we could get warned that the derived relationship might no more make sense. But this is really a tool thing and should not be managed by hand (too error prone). I think the only way to do it is to keep track of the ids of underlying relationships inside some properties or metadata, and then add a check rule into the Validator.

I'm working on a "derivation engine" written using jArchi, this might be something to add on top of it at some point.

Regards,

JB

[Alberto]

derived relationships are just "relationships"

agreed, don't think of derivations as second class, just find that in the context of a stablished model (one where the elements/relationships have been already pre-defined), sometimes I need to create a different view where elements are either omitted or encapsulated (e.g. sub-process A,B,C contained within process X).

https://imgur.com/a/XK3LMQw

we acknowledged that in some (IMHO rare) cases, it might be handy to keep track of the fact that a relationship has been derived from other ones, so that when deleting one of the latter, we could get warned that the derived relationship might no more make sense

I hadn't thought of this use case, but I do see this is a natural next step to where I was going with keeping track of the original path.