tn 10 Class to Class Join Point - modelint/shlaer-mellor-metamodel GitHub Wiki

mint.sm-meta.system.tn.10 / Leon Starr / Version 0.2.0 / 22-7-10

Concept

Our focus here is on the Class to Class implicit bridge. One or more classes in a client domain are mapped to a single class in a service domain. We would like to know the minimum information supplied by the modeler as well as the responsibilities imposed on the MX (model execution) domain.

Example 1: Animation case study

This case study is described in tn1, but here's an excerpt showing two classes from the Scene domain (client) that map to one class in the Animation (service) domain:

images/bridge-subsystem/tn-10-10.png

The modeler specifies a join point that maps the classes.

An empty correspondence table or set of tables must be generated by the MX domain where correlated instance identifier values will be entered. All the information necessary to generate this table is available from the join point. The type and number of identifier attributes for each class varies, so multiple tables are necessary if there are multiple counterpart classes in the client domain all mapping to the same class in the service domain.

The animation example class-class correspondence is populated dynamically. Here is an example population at some point during runtime.

images/bridge-subsystem/tn-10-20.png

If a system is initialized with a static population, that table is filled in during system initialization. Afterward, the population never changes. This means that we can safely assume that any instance lookup will yield a valid instance reference.

If instances of the mapped classes are created and deleted during runtime, the instance correspondence table is typically empty initially.

One domain will initiate creation and usually deletion as well. The other domain must supply an EE operation to be invoked whenever a creation or deletion action (regardless of context) is initiated in the other domain. The MX domain is responsible for ensuring that an initiated create or delete triggers the associated EE operation.

From the Animation example consider the creation of a Light instance in the Scene Application client domain and its corresponding Actor in the Animation service domain.

An EE named LIGHT is defined as a proxy for the Light class with the following ingress operation (via the user interface domain) defined:

Create( Housing: Housing ID, Source: Source ID, Intensity: Intensity Level, Color: Color Temp )
    *Light( in.Intensity, in.Color ) &R1 Housing( ID:in.Housing ) &R2 Source( ID:in.Source ) // Create with supplied values

In fact, whether or not an EE is defined or not does not matter. But when the create action, *Light... is performed, the resulting Light instance reference is made available to a linked EE ingress operation in the Animation service domain.

No explicit invocations of the service create EE ingress operations are necessary. These operations will be implicitly invoked whenever as a consequence of the create action in the client domain. But the modeler must also specify a proxy EE for the Actor class, most likely named ACTOR. On this EE there must also be a Create operation and, ideally only one. Most importantly, this EE operation must be designated as the implicitly invoked create operation associated with the class-class mapping.

When the designated EE operation is invoked, the MX maintained instance to instance correspondence table is updated.

Actions and Join Points

We note that a class BE has two bridgeable actions associated with it, create and delete. As a Join Point, a decision must be made for each of these actions as to whether it is mapped implicitly or explicitly.

In our example, both create and delete actions are each mapped implicitly on the client side. This means that we don't need to invoke an EE operation in our action language on the client side for these two actions when they are applied to the Join Point BE. But we do need to register each action as being implicitly mapped. An action that is implicitly mapped is used in any Activity of its Domain as normal without any special adornment.

If an action is explicitly mapped, it is replaced with an EE operation. Rather than call the action directly, an EE operation is invoked which is itself mapped.