vides a predicate that defines the subset of the state space in which the event is accepted, in this case, in states {1,1} and {2,3}. This subset can be given a single name (here st), or it could be fragmented into several named subsets, which can be referred to in the evaluated part. 3. The third heading provides an identifier name for the activity (here aTR) to be performed (only for modifier operations). If different activities are performed in different transitions, a list of activity names are given. The name of an activity must end in TR (for "transaction") to distinguish activities from operations. The reason is that an activity is normally performed over a number of activity objects, or by a number of operations on a single activity object, see Fig. 7.57. The activity aTR is a function that when executed, returns the value true if it succeeds, otherwise false. The evaluated part consists of rules. It is evaluated in the order in which the headings stand. If a rule is found valid, the evaluation stops. 1. First the state is checked. If the actual state is not within st, the rule is valid. The general event stateErrorReportConfirm is then initiated, and the machine stops. Note that stateErrorReportConfirm substitutes a normal response (Confirm or Refuse) in all cases when the service object refuses to execute an activity because the event is detected in an erroneous state. 2. The next rule is evaluated only if the actual state is within st. If the activity failed, the rule is valid. The machine will then initiate a chSeizeRefuse event and stop. 3. If the evaluation passes to this rule, it means that the actual state is within st and that the activity has succeeded. The machine will make the postcondition (given by the predicate (x=2 and y=2)) true, initiate a chSeizeConfirm event and then stop. Each object in the substructure has a special role in handling events. A port object stores operation specifications. The role of the object is to relieve the event object from those functions that can be handled in 