Skip to content

Getting Started

Jump to bottom
Arik Hadas edited this page Jul 29, 2017 · 5 revisions

Getting Started With Awesome

In this guide we explain the basic concepts of how to develop a new aspect mechanism (a weaver for a specific DSAL), and/or a new multi-mechanism (a weaver for several DSALs). After reading this guide you will hopefully get a general understanding of the supplied infrastructure, yet more learning is needed in order to actually develop a fully functioning aspect mechanism. It is assumed that the Awesome platform is already installed as explained in Installation Instructions.

An aspect mechanism is the back-end of your DSAL that handles the weaving process. A full implementation of a new DSAL consists of:

  • Front-end - a component responsible for analyzing the DSAL source code and producing corresponding artifacts that are passed to the back-end.
  • Back-end - an aspect mechanism. Awesome facilitates the back-end implementation (either for a single DSAL or for multiple ones). To implement the front-end, you may utilize existing tools such as Xtext.

Outline

Developing a New Aspect Mechanism

An aspect mechanism is developed within an Aspect Mechanism project. Hence the first step is to create such a project using a wizard:

Next, we fill-in the name of the DSAL to which the aspect mechanism is developed. We develop a DSAL for input validation hence we call it Validate:

Hitting 'Finish' and a new aspect mechanism project is created in the workspace:

The weaving process of the mechanism is encapsulated in the aspect ValidateMechanism.aj. The Awesome platform, which manages the overall weaving process, is provided with the different code elements of the application (e.g., a class), one at a time. Given such a class, Awesome retrieves all its join point shadows and consults each mechanism in its turn for possible advice weaving. For this process to work, each mechanism should implement within the mechanism's aspect the match and order methods:

@Override
public List<IEffect> match(BcelShadow shadow) {
    // TODO Auto-generated method stub
    return null;
}
@Override
public List<IEffect> order(BcelShadow shadow, List<IEffect> effects) {
    return effects;
}

In addition, if we want our mechanism to have debugging support, two additional methods should be implemented:

@Override
public List<IEffect> getEffects(LazyClassGen aspectClazz) {
    return null;
}
@Override
public boolean handledByMe(LazyClassGen aspectClazz) {
    return false;
}

The implementation of the above-mentioned methods is out of the scope of this guide. These details are provided in another guide - Hello Awesome - where we implement a fully functioning DSAL. Each mechanism has a manifest file describing its key properties. The manifest for our Validate mechanism is validate.manifest (marked in the figure). In future releases of the framework this manifest will play a significant role and will greatly simplify the coding effort required.

To conclude, to develop an aspect mechanism:

  1. An aspect mechanism project should be created using a wizard.
  2. The methods match and order of the mechanism should be implemented.
  3. The methods getEffects and handledByMe should be implemented if debugging support is desired.

Developing a New Multi-Mechanism

To develop a multi-mechanism for a bunch of DSALs, the corresponding individual aspect mechanism projects should be first developed and exist in the Eclipse workspace. For instance, the following workspace is the basis for developing a composite multi-mechanism weaver for AspectJ, COOL, and Validate:

Next, a multi-mechanism project should be created, also using a wizard:

The wizard should be filled-in with the name of the project, and with a list of the composed DSALs:

'Finish', and the following project is created in the workspace:

Note that the project contains three source folders (with the 'awm' prefix). Each folder corresponds to an individual aspect mechanism that is being composed (the folder is copied from the related aspect mechanism project). The folder spec holds the manifest files of the different mechanisms, and also a composition specification file (composition.spec). This file specifies how the aspect interactions between the composed mechanisms should be resolved. Based on that file, AspectJ configuration aspects are generated into the folder config.

Clone this wiki locally