Signal Action Tech Note - modelint/shlaer-mellor-metamodel GitHub Wiki
mint.sm-meta.action.tn.7 / Leon Starr / Version 1.0.0 / 22-2-10
A signal can be generated inside an Activity in one of three forms based on destination (or lack thereof):
A Signal can:
- Be addressed to a specific Instance and trigger an Event in its Lifecycle State Machine.
- Be addressed to an Association and trigger an Event on its Assigner State Machine.
- Be designated as a creation signal in which case it is used to create some Instance asynchronously.
- Be addressed to an External Entity
Each of these three kinds of Signal may be delivered immediately, at some designated time, or after a designated delay.
Each generated Signal has an associated Signal Specification providing a signature requiring a set of Signal Parameters. Each Signal Parameter is typed as some Scalar, Instance Reference, Table, or Tuple.
Technically speaking, the original Shlaer-Mellor documents don't specify any limitations on the type of data that might be associated with an event parameter. Here we are a bit more explicit. Shlaer-Mellor was, however, built on a relational foundation and all types mentioned here are consistent with relational theory [RTCP] [TTM].
Let's now take a look at data flow diagram representations of all three kinds of Signals along with some signature and delivery time variations.
Signal Instance Set Action
Here we take an example from the Elevator Case Study where an instance of Transfer sends a signal to its destination floor (Accessible Shaft Level):
Notice that the signal action can operate on an instance reference set which means that zero, one or many instances, of the same class, may be supplied as destinations. Shlaer-Mellor Executable UML does not provide any facility for broadcasting the same signal to multiple instances and we are NOT introducing such a facility here.
If multiple instances are supplied to a signal action, a separate signal is delivered to each instance lifecycle state machine. We are simply applying the single signal delivery operation for each destination.
Note that the term 'destination floor' used in the elevator application example is a coincidence. We're referring to its sense in the primitive action depiction on the left.
If the destination flow is empty, zero signals are sent.
The corresponding Scrall could be:
Serviced stop -> my destination floor
Feel free to express the primitive in your favorite action language. I'm just using Scrall syntax here as an example expression of the metamodel content.
Signaling with parameters
If the Event Specification associated with a Signal requires any Event Parameters, a value must be supplied for each.
Here we have revised our primitive action to accept parameter value input. A tuple is supplied with a column for each required parameter and a set of values corresponding to each column.
The corresponding Scrall would be:
Dest change request( new dest: destination aslev.floor ) -> xfer
In the statement above, the floor 3 value is obtained as the value of the floor attribute of the destination aslev single instance flow and xfer is the target instance of Transfer.
A parameter value need not be limited to a scalar value. It can, in fact, be any type: scalar, table, tuple or instance reference set.
Our example usage is found in the 'Search for alternate destination' state of the R53 assigner state machine. Here the Dest change request signal is sent to the active instance of Transfer lifecycle state machine. A single parameter 'new dest' is required and supplied with a scalar value representing a floor number.
Generating a delayed signal
Now we further revise our primitive action that generates a delayed signal. The only difference data-wise is that the action requires a duration value to specify the delay.
In the example usage we send three Off signals, one to each supplied instance of the Heater class. Since the associated Event Specification does not have any Event Parameters in its signature, we don't supply any parameter values. We mark that particular flow (as well as our delay flow) in our primitive action as optional by changing the flow color. A delay value of 23.1 sec is supplied and all three signals will be delivered after that duration has elapsed.
For the Scrall we could have:
Off -> overworked heaters @ shutoff delay
In the text above, the Off signal is sent to instances in the multiple instance flow named overworked heaters with the value 23.1 sec stored in the shutoff delay scalar variable typed as a Duration.
Generating a signal at a specific time
We also have a primitive variation that will deliver a signal at a specified time. So we change the name of the Scalar Flow to When and assume it is typed as either Duration or Time (or some Type inherited from either of these).
The Scrall here is:
On -> ac @ cooling time
Here we have the On event sent to a single instance reference named ac (instance reference set variable) with cooling time being a scalar variable typed as Time. Scrall knows that this is a specified time rather than a delay by examining the type. (If the type is not Time or inherited from Time, it is taken as a duration, for example).
Signal Assigner Action
An assigner is associated with a relationship as either a single or multiple assigner. A single assigner defines only one state machine on a relationship while a multiple assigner defines multiple state machines partitioned by some instance reachable from that relationship.
(Other than the optional when and signal parameter inputs, we are now dealing with a different signal destination with differing input requirements so we define a distinct Signal Assigner action.
In the Elevator Case Study example below, an instance of Accessible Shaft Level in the Requesting service state sends a signal to the R53 multiple assigner partitioning the set of assignable instances by its Shaft.
The Scrall in the Requesting service state reads:
Service requested -> R53( /R3/R28/Shaft )
So we have the event name directed at the assigner's relationship. Since it is a multiple assigner, we supply in parenthesis the partitioning instance, found by traversing R3 and R28 to obtain the Shaft instance.
Signal Creation Action
To create a new instance via a creation signal, we need the name of the new instance's Class, a value for each attribute of that Class, the name of the signal and any Event Parameter values to be received by the newly created instance.
We do not send the initialization values as Event Parameters since the creation action will initialize all attribute values before the instance is able to do anything with incoming parameter values. Relationally speaking, there is no such thing as a partially created instance. An instance is manifested as a tuple (table row) and every tuple must have a value specified for each column at all times.
Below we have borrowed an excerpt from tn5, Instance Creation with the synchronous creation action replaced by an asynchronous creation signal action:
The Scrall could be:
Change lane( turn signal: dir ) -> *Single Lane Change( Target lane open: false, Max time exceeded: false ) &R7 mlc
On the left side we see the Change lane signal sent along with a dir scalar variable supplying the turn signal event parameter value. Nothing here to indicate we have a creation signal.
On the right side of the arrow symbol, however, we note the * creation symbol associated with the Single Lane Change class. Two initial non-referential attribute values are provided, both as false values.
To obtain the initial referential attribute values, we supply a reference across R7 to an instance of Multi Lane Change in the mlc instance reference variable.
Signal EE Action
One way to trigger activity outside of our Domain is to send a signal to an External Entity. All we need is the name of an External Entity defined within our Domain.
We'll take a simple example from our Elevator Case Study. Here an instance of Door wants to open so it sends an Open Signal to the SIO (signal io) External Entity as shown:
The Scrall appears as shown:
Open door( Shaft ) -> SIO
The longhand version of the above statement is:
Open door( shaft: Shaft ) -> SIO
The Scrall syntax has the first term as the name of the parameter followed by the supplied value. We are simply referencing the Cabin's Shaft attribute value hinted at by the initial capital letter. Scrall supports shorthand to avoid name doubling. If the case insensitive parameter and value names match, you need only write the name of the value. That's why the shorthand version omits the parameter name.