Ad/2010-08-01 Concrete Syntax for a uml action Language for Foundational uml (Alf) Second Revised Submission
Download 1.74 Mb.
|
- Navigate this page:
- ANNEXES
- State Machines
19.16Reception Definitions
Subclause 6.1 describes the normative requirements for integrating the use of Alf text into the context of a larger UML model. In all such cases, the execution semantics of Alf are defined by the mapping of Alf to fUML. However, the UML models in which Alf may be used will likely often include constructs that are outside the fUML subset, with execution semantics as given in the UML Superstructure standard, but not covered by the fUML Specification. Some care must therefore be taken in understanding the semantic integration of Alf-specified behaviors with the constructs in which those behaviors are embedded. This annex suggests how such an integration can be understood for the important cases of state machines (see UML Superstructure, Clause 15) and composite structure (see UML Superstructure, Clause 9). However, the approaches suggested here are not normative, both because the issues of this integration go beyond the basic requirements for the standard UML action language and because the UML Superstructure specification allows some variation in how this integration may be done. It is expected that normative semantic integration of state machines and composite structure with Alf (and fUML) will be addressed as a part of future standards that further formalize the execution semantics of those constructs.
State machines are a commonly used mechanism for modeling state-dependent behavior in UML. Clause 15 of the UML Superstructure defines execution semantics for state machines. However, to be fully executable, it is necessary to also provide executable specifications for transition guard expressions and effect behaviors and state entry, exit and do-activity behaviors. One of the principal uses for UML action languages has been to specify such behaviors. In this regard, it is to be expected that a common use of Alf will be to write the executable specifications of behaviors owned by state machines. Therefore, even though state machines are not themselves part of the fUML subset, it is important to understand how the formal execution semantics of Alf can be integrated with the semantics of state machines as given in Clause 15 of the UML Superstructure. An approach to such integration is described below for behaviors attached to state machine transitions and states. Annex B.2 provides an example of the use of Alf within a state machine model.
Subclause 15.3.14 of the UML Superstucture defines the default notation for labeling a transition in a state machine. In the EBNF format used for Alf (see Table 6 -1 in Subclause 6.3 below), this notation is: Transition =
Subclause 13.3 of the UML Superstructure defines the textual notation for triggers of the various kinds of events. For the purposes of integration with Alf, guard constraints and behavior expressions may be defined as follows: GuardConstraint = Expression BehaviorExpression = Name | StatementSequence with Expression as given in Subclause 8.1, Name as given in Subclause 7.5 and StatementSequence as given in Subclause 9.1. The guard constraint and behavior expression in a transition are semantically mapped to fUML as follows, with the given constraints.
Consistent with UML Superstructure, Subclause 15.3.14, the execution of a transition proceeds as follows:
States A state may optionally have an entry behavior, an exit behavior and/or a do-activity behavior. If a state has one or more of these behaviors, then this is notated in the internal activities compartment of the graphical symbol for the state as follows (see UML Superstructure, Subclause 15.3.11). InternalActivity = ActivityLabel "/" BehaviorExpression ActivityLabel = "entry" | "exit" | "do" where BehaviorExpression is as given above. The behavior expression in an internal activity specification is semantically mapped to fUML as follows, with the given constraints.
Consistent with UML Superstructure, Subclause 15.3.11, the execution of the internal activities of a state proceeds as follows.
Current Event Data An event occurence that is dispatched for processing is known as the current event (see UML Specification, Subclause 13.3.31). If this is a signal or call event, then there may be data associated with the event occurrence: signal attribute values for a signal event or operation input parameter values for a call event. It is often necessary that transition and state behaviors to access such current event data for the event occurences that trigger them. There is currently no universally accepted, standard approach in UML for accessing current event data. This means that usually some tool-specific convention is adopted. One popular approach is to make some sort of “current event variable” available within action language text, through which the current event data can be accessed. This works particularly well for signal events, for which such a variable can hold the signal instance for the current event. It is less well suited for call events, for which there is no specific single value associated with the call, and some convention is required for individually accessing operation parameters. Unfortunately, there is no direct support in the UML action metamodel (let alone the fUML subset) for referring to any sort of current event variable. One related alternative approach is to provide access to current event data through calls to library functions, which can be invoked using normal call behavior actions. However, since such library functions cannot depend on specific signals and operations, the data they return had to be untyped, requiring the caller to do careful type testing and casting on the returned data. Now, the UML Superstructure specification does actually include a textual notation for specifying the names to be associated with signal or call events (see the Notation sections of Subclauses 13.3.6, 13.3.25 and 15.3.14). This notation is known as an assignment specification: CallEvent = Name [ "(" AssignmentSpecification ")" ] SignalEvent = Name [ "(" AssignmentSpecification ")" ] AssignmentSpecification = AttrSpec [ "," AttrSpec ] AttrSpec = Name [ ":" TypeName ] An assignment specification may be included (but is not required) for a call event for an operation with parameters (other than a return parameter) or a signal event for a signal with attributes. The stated semantics of an assignment specification require that the given names be names of attributes of the context classifier for the state machine owning the transition and that the corresponding current event data are assigned to attributes so named. However, the abstract syntax for events does not provide any way to capture such assignment specifications. Since UML semantics is formally defined on the abstract syntax, not any particular concrete syntax, there is no clear way to formalize the semantics given for the assignment specification notation. One possible alternative is to use the assignment specification notation, but to treat the notation as specifying parameters with the given names on the effect behavior for the transition. Then, when that behavior is invoked, the current event data can be assigned to the behavior input parameters. For call events, the behavior would have parameters corresponding to both the input and output parameters of the called operation, with output parameters assigned after the behavior completes execution. For this alternative, the effect behaviors on transitions would have to meet the following contraints.
The assignment specification notation could then be used to show the names (and optionally the types) of the parameters of the effect behavior of a transition (other than the return parameter for a call event). The advantage of this approach for Alf semantic integration is that, if an effect behavior with parameters as given above is specified using Alf, then the named parameters can be accessed as usual as local names within the Alf text (see Subclauses 8.3.3 and 8.8), and a return value (as appropriate for a call event) can be given using a return statement (see Subclause 9.14). A disadvantage is that these parameters are only available in the single effect behavior corresponding to the call event or signal event trigger. Input parameter values could be explicitly copied to context classifier attributes in order to make them to be available to, e.g., behaviors on downstream segments of a compound transition or on entry or exit behaviors. And there would be no easy way at all to give values for output or return parameters outside of the original effect behavior.
|