Creation and deletion

When creating or deleting instances we need to consider how the action is synchronized and how it impacts the integrity of model relationships.

When creating or deleting instances we need to consider how the action is synchronized and how it impacts the integrity of model relationships.

Synchronization

Creation can be triggered asynchronously by sending a creation event specifying the class of the instance to be created. Asynchronous deletion is achieved by addressing an ordinary event to the instance to be deleted where that event triggers a transition to a deletion state.

Scrall provides syntax both for signaling ordinary events and for sending creation events.

Synchronous creation and deletion are performed remotely by an action in some location other than that of the target instance’s state model.

Scrall provides syntax for both synchronous creation and deletion actions.

Model integrity

The class model specifies various constraints on relationships that must be respected by the state and activity models to ensure model integrity while the models are executing. It is the responsibility of the modeler to ensure that all constraints are respected in the model activities. For example, in a 1:1 association when an instance on one side of the association is deleted, the instance on the opposite side should be likewise deleted or linked to a newly created instance. It is also the modeler’s responsibility to ensure that all attributes have meaningful values at all times. There is no provision for assigning a null (lack of a value) to an attribute.

A referential attribute, in particular, must always hold a legal value. This means that you cannot create an instance with referential attributes if the referenced instance does not yet exist. It also means that you cannot delete an instance currently referenced by one or more referential attributes.

Say, for example, that you have a 1:1 association between classes A and B where A holds a reference to B. You must delete the A instance first and then the B instance immediately after and not in the reverse order. This ensures that you never orphan any referential attributes.