Ad/2010-08-01 Concrete Syntax for a uml action Language for Foundational uml (Alf) Second Revised Submission
Download 1.74 Mb.
|
Composite StructureClause 9 of the UML Superstructure defines the ability for modeling the composite structure of certain kinds of classifiers. This capability is widely used for modeling the hierarchical structure of large systems and systems of systems. It is also provides the basis for the structuring and encapsulation mechanisms commonly used with components (see UML Superstructure, Clause 8). While neither composite structure nor components are part of the fUML subset, it is to be expected that, in larger models, executable behaviors will often be nested in some way within a component or other structured classifier. Fortunately, with certain restrictions, a composite structure model can be understood as an instruction for constructing a specific set of run-time objects connected by links, which may then be interpreted according to fUML semantics. This integration is described below. Annex B.3 provides an example of the use of Alf to specify executable behavior within the context of a composite structure model.
A part of a structured classifier is simply a property that is an owned attribute of that classifier with composite aggregation. When an instance of a structured classifier is created, instances are created to fill the parts of the classifier, consistent with the multiplicity of those parts. Such instantiation may be specified using an instance model or through an explicit constructor operation. (See UML Superstructure, Subclause 9.3.13.) The parts of a structured classifier may also act as the end points for connectors. A connector is a “specification of a link that enables communication between two or more instances” (UML Superstructure, Subclause 9.3.6). When an instance of a structured classifier is created, links are created between instances of parts of the classifier corresponding to any connectors between the parts, consistent with the multiplicity of the connector ends and of the parts (see UML Superstructure, Subclause 9.3.13). A connector may optionally be typed by an association, in which case the links it specifies are instances of that association. According to UML Superstructure, Subclause 9.3.6, if the type of a connector that is omitted, the type is inferred based on the elements at the ends of the connector. The links specified by the connector are then instances of this inferred association, which does not actually appear in the model. However, fUML semantics for links require that every link have an explicit association as its type unless it has been destroyed (see fUML Specification, Subclause 8.3.2.2.11). Therefore, for the purposes of integration with fUML execution, connectors must always have a modeled association as an explicit type. Further, as required in the fUML subset, every such association must own all its association ends.
With the above restriction, once an instance of a structured classifier is constructed, its composite structure at run-time is simply the set of instances assigned to its parts, possibly interconnected by links of explicitly defined associations. While the fUML semantics do not provide a formal definition of how the construction of such an instance happens relative to the composite structure of its classifier, the resulting run-time structure is fully within the subset covered by fUML semantics. Therefore, Alf may be use to specify behavior related to the structured classifier based solely on modeling capabilities within the fUML subset, such as classes, attributes and associations. For example, if a class C has a part a whose type is class A and a part b whose type is class B, with a connector between then whose type is association R, then the methods of operations of C can access parts a and b as a regular attributes of C. Further, behavior associated with class A can navigate as usual across association R in order to access the opposite instance of class B. And, for any instance that fills the part C::a, the opposite end of R is guaranteed by the semantics of composite structures and connectors to the instance that fills C::b—even though this is not formalized in fUML semantics, presumably this will be the semantics provided by any execution tool that supports UML composite structure.
A port represents an interaction point between an encapsulated classifier and its environment (see UML Superstructure, Subclause 9.3.11). The allowed interactions are specified using interfaces—provided interfaces specify requests the environment can make on instances of the classifier, while required interfaces specify request that instances of the classifier can make on the environment. Ports are connectable elements. A connector that connects compatible ports on two internal parts of a structured classifier is known as an assembly connector. A connector that connects a port on a classifier to a compatible port on an internal part of that classifer is known as a delegation connector. (See UML Superstructure, Subclause 8.3.3, for the definition of assembly versus delegation connectors. Note that the connector kind is a derived attribute, based on the usage of the connector, not a flag that has to be set by the modeler.) In addition, a delegation connector may be used to connect a port on a classifier directly to an internal part of that classifier. Requests to the provided interfaces of the port are then delegated directly to the internal part. Further, the internal part may send requests out through the required interfaces of the port. Integration with fUML execution may be achieved by using fUML-subset capabilities to specify the behavior of an internal part connected to a port by a delegation connector. For the purposes of this integration, the part must realize all of the provided interfaces of the port, which must only have features that conform to the fUML subset. This allows requests received on the port to be delegated as normal invocations on the behavior of the internal part. If a port does not have any required interfaces, then the delegation connector for it does not need to be explicitly typed by an association, since internal parts then have no need to send requests through the connector. However, if the port has one or more required interfaces, then the delegation connector must be explicitly typed by an association, where the type of the association end corresponding to the connector end connected to the port is a class that realizes all the required interfaces of the port. This allows requests sent out through the port to be modeled in the behavior of the internal part as normal invocations across the association. NOTE. The specific requirements above should be considered to supercede the informally specified constraints in UML Superstrucure, Subclause 9.3.6, on the compatibility of connectable elements at the ends of a connector with each other and with the types of the ends of the association typing the connector. Interfaces and interface realization are not actually part of the fUML subset. However, a class that realizes an interface must itself own features that are compatible with all the features specified as part of the interface. Therefore, once the constraints of the interface realization are enforced, the realizing class implements within itself the features required by the interface and the interface realization relationship can then be ignored for the purposes of execution. At run-time, an instance filling the internal part will be connected by a link (that is an instance of the association typing the delegation connector) to an instance of a class that realizes the required interfaces of the ports. The internal part instance may make calls on the opposite object over the link, and vice versa, per regular fUML semantics. Note that what instance is actually provided on the opposite end of a delegation link is execution tool specific—for example, it may be the ultimate end object or it may be an intermediate proxy object—but it must always have a type that realizes all the required interfaces of the delegated port. For example, suppose a class has a port with a provided interface P that has an operation x and a required interface R that has an operation y and that this port is connected to an internal part whose type is class A. Then class A must realize interface P and have an operation that conforms to P::x. Further, the behavior of class A may navigate across the association typing the delegation connector in order to call the operation R::y.
|