Entity Splitting/Structure Elaboration

This is a modularisation pattern which specialises Phased Construction.

Summary

A transformation contains rules which (i) create instances of two or more target entity types from each instance of a source entity types, and where these instances are not part of a single conceptual unit; or which (ii) maps instances of one source entity type to instances of different alternative target entity types, depending on disjoint conditions.

In either case separate rules should be used to define the creation of the separate/alternative target instances.

Application conditions

If a transformation rule combines the creation of multiple target instances in a single rule, the rule may become excessively complex and difficult to maintain. This problem is an example of tangling of functionality in a single rule, and of lack of cohesion in the rule effect.

Solution

Separate the parts of the rule that create/update separate target instances into separate rules. If one entity type T2 depends on another, T1, then the rule creating T1 should precede the rule creating T2, otherwise they can occur in either order. Identity attributes or traces may be used to relate the different target instances derived from a single source instance. These attributes/traces are also necessary for correct reversal of the transformation.

If the instances created actually form closely bound parts of a single concept (e.g., if classes are mapped to both a table and its primary key, in a UML to relational database mapping), then the rule should not be split. This variation of the pattern could be termed Structure Elaboration. One way of identifying this case is that the rule establishes links of an aggregation association or other mutually mandatory relationship between the respective target elements, such as T1 1..*---1 T2 or T1 1---1 T2 associations.

Benefits

This pattern assists in improving the modularity and cohesion of a specification, separating into distinct rules the construction of distinct target entities. The opportunities for parallel execution of rules are increased.

Disadvantages

The number of rules is increased. The efficiency of the transformation may be decreased, since there are now multiple iterations over the source entity type (e.g., S1), instead of a single iteration.

Applications and examples

The pattern is applicable to the same categories of transformations as Phased Construction, but is particularly relevant for refinement transformations.

An example is given in (Kurtov et al, 2006) of the application of this pattern to the creation of MVC components from source data: source model objects of types such as OpenElement are transformed in a single rule into interconnected model, view and controller objects Open, OpenView, OpenController.

The single rule for OpenElement could be written as:

for e : OpenElement
create t : OpenView; op : Open; oc : OpenController
satisfying t.obsId = e.id and
op.modId = e.id and op.observer = t and oc.view = t

Since the entities Open and OpenController depend on (refer to) OpenView, we can split the rule into three separate rules using the pattern: the first creates OpenView objects, the second creates Open objects and links each of these to the OpenView objects with the same id value, and the third does the same for OpenController.

The motivation for applying the Entity Splitting pattern in this case is to avoid the tangling of several different source-target relationships in a single rule, and instead to separate out these relationships into different rules. It may be necessary to define in the separate target entities some key attribute or stereotype which records the fact of the semantic link between them (i.e., that they represent separate parts of the same source entity). This allows the definition of a reverse relation.

Other examples are refinement or code-generation transformations such as the generation of multiple Java Enterprise Edition elements (database tables, value objects, EJBs) from single UML classes.

Related patterns

The pattern is a special case of Phased Construction. The pattern is also termed local source to global target. The refinement pattern in (Iacob et al, 2008) corresponds to Structure Elaboration.

The Target Model Splitting architectural pattern can be used to store in separate models the instances of separate target entity types T1 and T2 derived from a source entity S1, if there are only implicit links between the two target types, and not explicit object references.

(Iacob et al, 2008) M. E. Iacob, M. W. A. Steen, L. Heerink, Reusable model transformation patterns, Enterprise Distributed Object Computing Conference Workshops, 2008, pp. 1--10, doi:10.1109/EDOCW.2008.51.