Starting from an assigner

An assigner state machine is not the lifecycle of a class instance. It is instead associated with a relationship for the purpose of managing competitive associations. So an activity in an assigner state cannot refer to a local instance since the concept has no relevance there. Note that the ME keyword can still be used as the target of a signal in an assigner, but it refers to the state machine instance and not any class instance.

It is convenient, however, to have an implicit origin from which to navigate to class instances.

Single assigner

Consider the association R1 between Customer and Clerk where a single assigner establishes a “Clerk is serving Customer” 0..1:0..1 association. There must be an association class (because of the multiplicity) which we’ll call Service that formalizes R1.

Now we have an assigner state model on R3. There is only one state machine instance for the entire association.

But you can’t do this:

availableClerk .= /R1/Clerk(1, !Serving customer )  // ILLEGAL

This is illegal because no initial point for the navigation has been specified. Instead, you must do something like this:

availableClerk .= Clerk(1, !Serving customer ) // LEGAL

Here there is no relationship navigation at all and we are just selecting an arbitrary instance of Clerk whose Serving customer attribute is false.

This is also okay:

busyClerk .= Clerk(1, Serving customer )
[busyClerk] clerksCustomer .= busyClerk/R1/Customer

If an instance of a Clerk serving a customer is found, that Clerk’s current Customer can be found by traversing R1 from the selected Clerk instance. So you can traverse associations in an assigner state model, but you must explicitly supply some instance reference as the starting point.

Multiple assigner

A single assigner manages competition on an association for all instances on each side of that association. In the Customer-Clerk example, any Customer instance might be associated with any Clerk instance on R1.

A multiple assigner manages competition among a subset of instances on each side of the association. Let’s say that we add a Department class and relate it to both Customers via R2 and Clerks via R3 to reflect the fact that Customers and Clerks are in a particular Department. Now we want a separate assigner state machine instance per Department to manage only those Clerks and Customers in that Department.

So a multiple assigner designates some partitioning class, in this case, Department, and then supplies a separate state machine instance per partitioning class instance. Thus, we can use instances of Department as starting points for relationship navigation. So, you could do this:

availableClerks ..= /R3/Clerk( !Serving customer ) // LEGAL

Navigation implicitly begins from the associated Department instance across R3 to select all of that Department’s Clerks who are not busy.