Should I use a UML trace or realization

Question

I have a logical data model and multiple physical data models for different systems, all documented in UML. I want to show how the data in the physical models trace back to the logical model so that when changes are made to the logical model we can readily determine all of the physical models that are impacted.

Are these relationships best represented as a trace or a realization? I suspect the answer is "trace", but wanted to see what others thought prior to investing too much time in this and being wrong. Does a trace or realization relationship offer extra semantics over the other that would be useful in this context?

Answer 1

My interpretation so far (intentionally quoted): "I usually make them <<trace>> dependencies. A Realization is between an interface or an abstract class and a 'regular' class. The physical model is derived from the logical model, not 1:1 realized. In most cases you make modifications on a physical level which are not foreseen in a logical model (de-normalization and all sorts of optimization you need on a DB level). Somehow this is sort of a realization."

However, and this is the pure truth, this is what the UML spec says on p. 54:

7.8.14 Realization [Class]

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.

So you can actually use a realization here. The <<trace>> is more informal, but not necessarily wrong.

Answer 2

These relationships are best represented as a trace, i.e. a dependency relationship with stereotype <<trace>>. The trace is meant to relate elements in different models, which is exactly your situation.

The UML 2.5.1 specification defines the trace stereotype as part of the 'standard profile' (section 22.3), as follows:

Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.

Although the UML specification defines the realization relationship broadly enough to fit your purpose as well, the examples in the UML specification (e.g. figure 7.21) and the way I have seen this relationship been used in real world projects lead me to the conclusion that this type of relationship is primarily intended to be used to relate elements within the same model, in particular interface elements with classes that implement these interfaces.