Reference management for simple associations
Since xUML is based on relational theory there are no object oriented programming style links. Instead, one instance may refer to another by storing the values of one of the referenced instance’s identifiers.
When referring toward a one, unconditional direction, a reference may be placed in the referring class. Otherwise, an association class may be used to refer to both sides of the association.
The proper use of referential attributes and identifiers is explained in the book Executable UML: A Foundation for Model Driven Architecture, Mellor-Balcer, Addison-Wesley. They will also be explained elsewhere on this website eventually. Here, though, we’ll assume that you know the rules.
Links vs. references
The following model snippet is from an animation application. A setting programs a control value at one point in time on a timeline.
A Setting cannot exist by itself, so when we create one we must place it on a Timeline.
Unlike conventional UML there is no notion of an invisible link connecting instances of Event to instances of Timeline. But there is a very visible attribute in the Event class named Timeline that holds the value of the ID of some existing Timeline. For this reason the Setting.Timeline attribute is called a referential attribute.
Forgetting references for the moment, when we create an instance of any class we must provide a legitimate value for each of its attributes. There are no special null or not-applicable values in xUML. So when we create an instance of Setting we must supply a value for its Timeline attribute which effectively forces us to associate it with its Timeline instance.
Fortunately, the MX domain knows how to manage referential attributes with respect to relationships so that they are set correctly. Consequently, the modeler never directly writes the values of a referential attribute. This helps ensure the integrity of relationships so that you don’t accidentally set the value of a referential attribute to a value for a non existent target instance.
Setting a reference
In the following Scrall example we introduce the
& reference operator. It creates a reference from some referring instance to a target (referred to) instance. Assume we have a domain operation that creates and associates an instance of Setting to a Timeline.
Let’s say that a creation event is processed by the MX domain to create a new instance of Setting. There must be a creation action in the initial state like this:
The creation event supplies needed initialization values. The ID value is not supplied and no default initial value is shown on the class diagram. Consequently, the Nominal type initialization operation will supply the needed value. For the Nominal data type, an unused and unique number for the local class is selected from the set of positive integers. (In the illustration we preface that number with the initial of the class, S8, for example.
The reference to the required Timeline instance is performed by the
& action which requires a source instance, a relationship name and a target instance set. When, the source instance is omitted, as it is in this case, the local instance is assumed. The
in.Timeline value is used to select an instance of Timeline as the target of the reference. To complete the initialization a signal is sent to the local instance and, on dispatch, it moves on to the next state.
Deleting a reference
To delete a reference, simply delete the class holding the relevant referential attributes. When referring in a to-one direction, as in this example, just delete the referring instance. For all other multiplicities (to-0..1, to-1..*, etc), the referential attributes will be in some association class, so delete the relevant association class instance.
In our example, we don’t need to use any special action to delete a reference to Timeline. Let’s say that we delete setting S8 from our example. When S8 enters its deletion state it will be removed along with its Setting.Timeline referential attribute. No “unlink” action is required.
Swapping a reference
Especially with unconditional (non-zero) association multiplicities, you need to replace one reference with another rather than temporarily have a non-reference that would break the model consistency. In this case you can use the
& operator to swap out the old reference and set a new one.
In the following example it is necessary for an instance of Control Zone to replace its current air traffic On Duty Controller with someone else. In this model it is illegal for a Control Zone instance to be left on its own, undirected.
&R2 On Duty Controller( ID: in.new controller )
The above action in some state activity of Control Zone will replace the currently referenced On Duty Controller with one found from the supplied ID value in
in.new controller. The MX domain will simply replace the value of the local instance’s Control Zone.Controller attribute with the ID value of the new air traffic controller.
Fully qualified reference
References are not always managed in the scope of a local instance. Sometimes a remote instance will perform a synchronous action that changes a reference through creation, swapping or deletion.
In the following example an instance of Aircraft is associated with an instance of Runway assigned for take-off by an instance of Landing Clearance. So, in some activity of the Landing Clearance state model we might see this:
aircraft to land = Aircraft(ID: in.land this one next) land runway = find available runway() if (land runway) land this one next &R24 land runway
In the last line above, the source instance is associated with the target instance. The MX domain will set the value(s) of the referential attribute(s) of the Aircraft class to refer to the assigned Runway instance.