Asynchronous creation

Creating an instance asynchronously (with an event)

With this approach, a creation signal is sent and, upon dispatch, the model execution domain creates the new instance and places it in an initial state as designated on the target class’s state model. Any parameter values supplied with the creation event are made available to the new instance’s creation activity.

If the new instance’s class holds any references, a target instance reference must be supplied with each along with the corresponding association names.

This style of creation is called asynchronous since the sending instance can continue about its business, advancing through states, etc. without necessarily waiting on any feedback regarding the creation status.

To perform asynchronous creation, send a signal to a class name (not an instance set variable). For clarity, a special creation signal symbol is used.

New folder( notify user: true ) *> Folder( Color: .red ) &R1 parent folder

The event target is a class name which establishes that this is a creation rather than a normal instance directed event.

The signal may carry parameters that can be acted upon by the newly created instance. In this example, 'notify user' is not an attribute of Folder, but simply a value passed to the newly created instance. In this example the supplied event value may trigger some action after the instance is created. Contrast the event parameter with the initial value supplied for the Folder.Color attribute. The second pair of parenthesis encloses an attribute initialization clause whereas the first is a set of event parameters.

All data necessary to create a complete instance of Folder must be available to the creation state. Though, not all data need be specified as parameters on the creation event if that data is available elsewhere, such as in attribute initialization values specified on the class model.

The Create folder event will be defined as a creation event on the Folder state model. But the * is helpful to clarify to the model reviewer that a new instance is created. It also encourages the model developer to be explicit about their intention. Consider a non-creation event sent to all instances of Folder:

Close -> Folder

In the above example a Close event will be sent to each instance of Folder. The fact that all instances are selected, you could have done this instead with the same result:

Close -> Folder(*)

Now let’s say that we want to asynchronously create an instance of a class that holds more than one reference.

The syntax is similar to that for synchronous creation. You must specify a comma separated list of association name, instance reference pairs.

Recasting the Shaft example as asynchronous creation, it could look like this:

Create -> *Shaft() &R4 *Cabin(), &R6 mybank

Creating multiple instances

To create multiple instances, use square brackets after the signal name and signature. A positive integer greater than zero indicates the number of signals to generate and, hence, instances to create:

New folder( notify user: true )[initial qty] *> Folder( Color: .red ) &R1 parent folder

Assuming the value of initial qty is, let's say 100, then 100 instances of Folder (all red) will be created underneath the same parent.