| The following comments refer to the "Rules about Signals" enumerated in the box on page 190. Specification, not implementation. The primary point to grasp is that these rules are designed to describe required synchronization between objects. This means that when we say that "signals are never lost," we mean that the sender requires the receiver to execute after the signal is sent, and that this is the required order. It is the job of the model compiler to ensure this is so by whatever mechanism it deems appropriate. No priorities. Similarly, there is no notion of signal priority in these rules, and a modeler cannot arbitrarily accelerate one signal ahead of another. To do so would be equivalent to "going backwards in time." Sender receiver instance pair sequencing. We know from Rule 6 that two signals sent from one object to another are received in the order generated. But what happens if signals are outstanding from different senders? Rules about Signals Signals are never lost: Every signal will be delivered to the object or external entity to which it is directed. A signal is "used up" when it is accepted by an object: The signal then vanishes as a signal and cannot be reused. At some time after a signal is generated, it is made available to the destination object or external entity. When an object completes a procedure, it is now in the new state. Only after completion of the procedure can the object accept a new available signal if any such exist. This is called run-to-completion. Multiple signals can be outstanding for a given object, because several objects can be generating signals to a particular receiver during the time the receiver was busy executing a procedure. If a single object generates multiple signals to a receiving instance, the signals will be received in the order generated. If there are signals outstanding for a particular object that were generated by different senders, it is indeterminate which signal will be accepted first. Signals sent to self are always accepted before other signals to that instance. |
The rule is that there is no rule. This is analogous to a set of computers sending messages directly one to another. The receiver can distinguish, with certainty, the sending order of messages from the same sender, but the receiver cannot determine the exact ordering of the sending of messages from two different computers. Even time stamping doesn't help because of the problem of synchronizing clocks. This is precisely the situation described above with the three signals. If the behavior of the recipient is different depending on whether Y arrives at B before Z, and such indeterminacy is undesirable, then the model must be changed to synchronize the signals correctly.  A model compiler may, and probably will, employ mechanisms to resend signals, and it could use priorities on signals. The model compiler is required only to preserve the synchronization built into your executable models. |
Rules about Procedures Only one state procedure of a given object can be in execution at any time because an object can be in one state at a time. Multiple accessors of an object may execute concurrently, with respect to each other and to state procedures. Procedures in different objects can be executing simultaneously. A procedure takes time, possibly none, to execute. Once initiated, a procedure of an object must complete before another signal can be accepted by the same object. It is the modeler's responsibility to ensure that the procedure will complete. A procedure must leave data describing its own instance consistently. If a procedure updates an attribute of its own instance, it must update all attributes that are derived from the first attribute. If a procedure creates or deletes instances of its own class, it must ensure that any links involving those instances are made consistent with the rules stated on the class diagram (by action or by signal). When a procedure completes, it must leave the system consistent, either by writing data (described in the three rules above) or by generating signals to cause other objects to come into conformance with the data changes made by the sender of the signal. |
|
