Home › Topics › Essence › Structural

Structural Essence: Options for Handling Unidirectional Associations

This is a page of the online appendix of our paper on Structural Essence.

Unidirectional Associations

There are four possible kinds of unidirectional associations, and we have thought of 5 different options for transforming them into the distilled model.

Option
Case Association 1 2 3 (chosen) 4 5
1 A 1->1 B A->B
(essence=0)
2 A 1->* B A->*->B
(essence=1)
3 A *->1 B A->B
(essence=0)		 A->B
B->*->A
(essence=2)		 A->B
*->A
(essence=1)		 A->*->B
(essence=1)		 A->B
.->A
(essence=0.5)
4 A *->* B A->*->B
(essence=1)		 A->*->B
B->*->A
(essence=3)		 A->*->B
*->A
(essence=2)		 A->*->B
(essence=1)		 A->*->B
.->A
(essence=1.5)

Options

  1. We treat a * at the tail end of a uni-directional association as a 1. Thus, we transform A *->1 B to A 1->1 B, and we transform A *->1* B to A 1->* B. The advantage is that we can do more or less what we have done before, and we can ignore this aspect that can be modeled in UML but cannot be explicitly expressed in common programming languages. The disadvantage is that this * does not increase the essence.
  2. We treat a uni-directional association with a *at its tail end as a bi-directional association. Thus, we transform A *->1 B to A *<->* B, and we transform A *->* B to A *<->* B. This has the advantage that a * always increases the essence, even if that * is at the tail end of an arrow. However, it increases the essence twice, once for the "*", and once for the (artificially) introduced cycle.
  3. We introduce a new kind of node in our distilled model. A *->1 B would be transformed into a node "A", a node "B", an edge from "A" to "B", plus a node "*" and an edge from "*" to "A". This latter node and edge show that there are multiple "A"s that can somehow be found, but it does not introduce a cycle (and thus not increase the essence twice). The disadvantage is that it becomes unclear that the meaning was that FOR A GIVEN B, there are multiple As (the distilled model now just says "there are multiple As").
  4. Treat cases 3 and 4 like case 2 (if there is any star, treat it as a 1:N relationship). This would make A *->1 B look the same as A 1->* B (and even as A *->* B). Those two associations mean very different things, and having them represented the same way (A->*->B) in the distilled model seems strange.
  5. I'd like to see a different in essence between case 1 and case 3 (and between case 2 and case 4) -- and option 3 would not give that (essence would be 1). Option 5 would be a variation of option 3, but with a different weight (say 0.5) for the strange "*" node (let's show that by using a "." instead of a "*"). This is because the "." node represents a multiplicity that is not going to be navigated with code. It's there (there indeed can be multiple A objects for a given B object), but it doesn't matter much in terms of program behavior or heap structure. So, acknowledging it (by creating a special "." node) but giving it a small weight might be a way to go.