Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Merging Models Together
In addition to successive transformation of complete models, models need to be woven together with other models to produce a system, as mentioned above. In an elevator system, the elevator model could be expressed as an executable model, but it would not solve the building's problem until it was connected to another complete model of the Transport subject matter. When linked together, and translated into code, the executable models become systems.
To effect this combination, we can define a mapping function. (This mapping is generally a merge, rather than a refinement that transforms a model from one form to another.) Specifically, we need to establish that one kind of thing in one model "corresponds" to another kind of thing in another model. An example is that the class Teller and the class Customer in the Bank model each correspond to an instance of a Role in the Security model. Another example is that each Account instance in the Bank corresponds to an instance of ProtectedResource in Security. Similarly, a subset of Train instances in a control application corresponds to instances of Icon in a User Interface domain. (These last two are called "counterparts" or "counterpart instances.")
These mappings can be between any two kinds of identifiable entity in an executable UML model. For example, the state Stopped in the Train Control domain corresponds to the enumerated value Red of the attribute Icon.color. This extends to dynamics. A signal in one domain, say, Button(3) pushed in the UserInterface, corresponds to a signal in the Train Control domain, TimeToLeaveStation to Train 47. Signals may be mapped to function calls and vice versa, and functions can map to changes in attribute values. Figure 2 provides some examples of such mappings.
)
Figure
2: A sketch of a bridge
Mappings are often directed by marks that correlate elements in source and target models. In Mellor and Balcer [1] and earlier work, these correlations (mapping functions and marks) are called bridges.
Once these mappings are defined, we are ready to combine all the models into a single populated metamodel from which code can be generated. (These steps can take place at once.) The mechanism responsible for compiling is a model compiler, which weaves together the several models according to a single set of architectural rules.