The VIDE AO extension provides the functionality to use aspect-oriented concepts at the platform independent model level. The following benefit can be gained by using the aspect-oriented concepts (See D3.2. for detailed motivation):
Realisation of crosscutting concerns in a modular way
Non-invasive adaptation of an existing system
The following sections describe how to create ao-related elements and how to process the aspect composition. The aspects, which contain additional encapsulated behaviour, are intended to be stored in a separate UML model file. Hence, it is not necessary to modify the original application to adapt the behaviour.
First, a standard UML model is created using the eclipse wizard. To store VIDE compliant aspects in this UML model, the AO profile as well as the VIDE profile have to be loaded. If you want to use elements (e.g. types) from the base application, this appropriate resource has also to be loaded into the aspect model (see Figure108). The aspect model has to follow the naming conventions (see D9.2).
Figure 108: Load resources related to the aspect model
The profiles and the imported package have to be applied to all packages, which are intended to store aspects (See Figure 109).
Figure 109: Profile application and package import
After the relevant profiles and packages were imported and applied, an aspect can be created e.g. by using Topcased. An aspect is a regular UML class annotated with an aspect stereotype (see Figure 109) and serves as a container for other relevant aspect-oriented constructs like advice and pointcuts.
Figure 110: Create an aspect
After the container (aspect) was created, the additional behaviour can be modelled within an advice. An advice indicates which behaviour will be executed. The advice-related behaviour is stored in an operation, which is annotated with the stereotype advice. Again, Topcased can be used to model the advice operation within the aspect (see Figure 110).
Figure 111: Create an advice operation
Now the behaviour of the aspect can be specified by using the VIDE textual editor (see Figure112). The textual editor provides a special keyword to invoke the captured joinpoint from within the advice. The so called proceed statement can only be used in an advice, which replaces the behaviour of a joinpoint.
Figure 112: Specify advice behaviour
In the next step we have to specify, when the additional behaviour have to be executed. For this purpose, so called pointcut have to be modelled. There is still no convenient way to specify pointcuts. The standard eclipse tree editor has to be used. The pointcuts are part of the aspect and they are created at the same level like operation, advice, attributes, etc. (See Figure 113) for an example pointcut).
Figure 113: Pointcut modelling
The pointcut defines the point in the execution of the system, where the additional behaviour (advice) should be executed. To complete the aspect model, it is now necessary to connect the pointcut definition with the advice (containing the additional behaviour) and define the way how the advice will be executed at the selected joinpoints (the result of the evaluation of the pointcut definition is a set of joinpoints).
To connect the advice with the pointcut definition, in our approach a construct called binding is used (see Figure 114).
Figure 114: Binding element
After having created the additional behaviour, the pointcut definition and the binding element, the aspect-oriented model can be merged to one composed model. This process is called aspect weaving. The resulting model does not contain any aspect-oriented constructs and can be processed by several backends without support of any kind of aspect orientation.
Figure 115: Run aspect weaving
After the aspect weaving, the composed model is stored in the same folder as the base and aspect model. The result model can now be processed by further component without support of aspect-oriented concepts, like Java generation (see Figure 116).
Figure 116: Run Java code generation from composed model
The following section describes all additional AO-related elements provided by the AO Profile.
Aspect
The stereotype Aspect is applicable to classes and represents an aspect module, which serves as a container for additional aspect-oriented (advices, bindings, pointcuts) and object-oriented (methods, etc.) constructs. The attribute instantiationKind defines the instantiation strategy of the aspect. The two kinds of instantiation singleton (one aspect instance) and instance (one aspect instance per class instance) are supported and covered in the enumeration instantiationKind.
Advice
The stereotype Advice is applicable to operations defined in an aspect module. This stereotype marks an operation as an advice, which contains the advice behaviour. The advice parameters are used to pass context information to the advice. The usage together with the pointcut parameters is explained in the following sections.
Proceed
The stereotype Proceed is applicable to CallOperationActions within an advice. This special action calls the bound joinpoint. Advices, which use the Proceed action, can only be bound using the binding kind “around”. All parameter has to be passed to the Proceed action. Naturally, the target pin of the CallOperationAction must not be set.
Pointcut
The metaclass Pointcut allows modelling pointcuts, which are used to describe a set of joinpoints in the behaviour model. The pointcut does not contain a string representation of this description, but rather uses fine granular instances of pointcut expressions (see PCE) to express the pointcut definition. The resulting set of joinpoints is the union of the results of each contained pointcut expression. Furthermore the pointcut contains a signature, which is used to pass the context information to an advice. The signature of the bound advice has to be equal to the pointcut signature. The parameters, which are associated to the signature, have also to be referenced by the corresponding pointcut expressions (see ContextExposurePCE). This mechanism allows the explicit assignment of context information to the parameters of the poincut.
Binding
The Binding class is used to associate a pointcut with an advice. The bound advice adapts the joinpoints, which are referenced by the connected pointcut. The binding also defines the binding kind (before, after, around), which is defined in the enumeration BindingKind. The advice is not directly associated with the pointcut, because the explicit definition allows to create n:m associations with a separate binding kind for each association.
PCE
PCE is an abstract class, which allows the modelling of pointcut expressions. Subclasses of the PCE class are used to specify the concrete properties and the kind of joinpoints, which should be captured by the corresponding pointcut.
FeaturePCE
FeaturePCE defines a feature of a class. Operations and class properties are supported. FeaturePCE provides different attributes and associations for specifying detailed properties of the features to be captured (namePattern, visibility, isStatic, declaringType and type). The association type defines the return type if operation is specified. Otherwise the association type defines the type of the specified field.
OperationPCE / PropertyPCE
OperationPCE defines joinpoints, which relate to an operation. To distinguish between the two different joinpoint kinds (call of an operation (CallOperationAction) and the execution of an operation (Operation)) the attribute kind has to be set. Possible values are defined in the enumeration OperationJPKind. In an analogous way, the PropertyPCE defines joinpoints, which corresponds to a property of a class. The values, defined in the enumeration PropertyJPKind can be set to the property kind.
ContextExposurePCE
The ContextExposurePCEs are responsible for selecting joinpoints with the specified context and also for passing the context information to the bound advice. Context information is for instance arguments of an operation call and value, which is set to a property.
For this purpose, the ContextExposurePCEs contains a list of parameters. If the captured context of the current pointcut expression should be passed to the advice, the corresponding instance of the Parameter defined in the pointcut signature has to be referenced by the parameter list of the pointcut expression. The ContextExposurePCEs can also be used to filter the resulting set of joinpoints without passing the context information to the advice. In this case, the parameter referenced by the pointcut expression must not be referenced by the pointcut signature.
ThisPCE
The ThisPCE captures a joinpoint, if the object, where the joinpoint is triggered, is an instance of the type (or subtype of the type) of the first parameter defined in the parameter list.
TargetPCE
The TargetPCE captures a joinpoint, if the target object, on which the joinpoint is triggered, is an instance of the type (or subtype of the type) of the first parameter defined in the parameter list.
ArgsPCE
The ArgsPCE captures a joinpoint, if the arguments (call/execution joinpoints) or the value to be get/set from/to a property match to the parameter list associated by the ArgsPCE.
IntersectionPCE
The IntersectionPCE allows combining pointcut expressions to limit the resulting set of joinpoints.
TypePattern / PackagePattern
Instances of these metaclasses are used to express types and packages. Within the namePattern, wildcards can be used to select related elements. Additionally the TypePattern can be enabled for covering subtypes by setting the property includeSubtypes.