 | Level: Intermediate Jim Conallen (jconallen@us.ibm.com), Senior Software Engineer, IBM
Eoin Lane (eoinlane@us.ibm.com), Senior Solution Engineer, IBM
27 Jun 2006 Modeling with aspects takes a model-driven development (MDD) approach to simplify development with aspects. This approach to modeling with aspects involves annotating UML model elements with aspect keywords to address cross-cutting concerns at design time. Aspect code specific to the target environment is generated during the UML to target transformation. In subsequent articles, the reader will be introduced to the Aspects for MDD framework, which provides an implementation of this style of software development for AspectJ and Java development teams using IBM® Rational® Software Architect (hereafter, Software Architect). This framework will allow the reader to easily package their own AspectJ-based mechanisms for a variety of cross-cutting concerns that can be introduced into an application during design modeling. Introduction
Aspects technology is a very important addition to object-orientated programming for addressing cross-cutting concerns without breaking object encapsulation. Tools support for applying aspects is beginning to grow -- with notable examples including the AspectJ Development Tools (AJDT) Eclipse project, which provides tools support for AspectJ -- as the importance of the aspect contribution is better understood. However, developers are still required to learn a new syntax and style of programming in order to be able to take advantage of this new technology.
Modeling with Aspects takes a model-driven development (MDD) approach to solving this problem. A modeler/developer can apply aspects to a UML model (typically a class diagram) and have the corresponding AspectJ generated during a UML to Java™ transformation. The modeler/developer need not know anything about aspect technology, and only has to specify which aspects to apply to the model.
Model Driven Development
UML has given architects and developers a way of visually understanding object-orientated systems and their interactions. Modeling tools such as IBM® Rational Rose® and Software Architect provide rich environments in which the models can be architected.
MDD, in a nutshell, is the development of software through the use of abstract models. Models of the application and system are created at different levels of abstraction and, through automation or manual effort, are used to drive the evolution of the models at lower levels of abstraction (Figure 1). Models in this method of software development are considered first-class artifacts of the development process. They are every bit as much the focus of software development activities as is the source code.
Figure 1. Typical models in an application development project
The models provide a mechanism with which to focus on the concerns of specific parts of the application, independent of the others. A data model, for instance, is mostly concerned with the persistence of data (object state) and its structure. It is not concerned with the dynamic behavior of the user interface, or even of business logic behavior. Each type of model in the development process is selected to match up to a particular role and set of activities, so that all the work done in the activities are narrowly focused on the domain of the task. This not only allows development team members to become specialists, but also defines a natural way to divide up the artifacts and activities of the development process.
As an example, a reservation use case for a business application could provide a textual description (human readable) of the use case. This description can be validated by the non-technical domain experts in the organization. The analysts would begin the process of describing the system with objects that exhibit the desired behavior of the application. These are documented in the model with sequence diagrams and class diagrams, which would include the specification of a reservation entity and a controller class (for entity management). The design models driven by the analysis models would realize the entities with various EJB interfaces and implementation classes and associated deployment descriptors, and any other concrete artifacts necessary to implement the design.
At the design model level of abstraction, the difference in level of abstraction from the source code is small enough that off-the-shelf code generators (transformations) can transform the models into source code and configuration files, as shown in Figure 2. In some instances, even the behavior (method bodies) can be generated (when a specific design pattern has been applied).
Figure 2. Transforming model to code
Aspects
A cross-cutting concern is a problem or issue that is shared or exhibited across layers and subsystems. Examples of common concerns include:
- Logging
- Security
- Persistence
- Caching
- Error handling
- Consistency checking
Traditional approaches to addressing cross-cutting concerns involve the use of intrusive APIs or frameworks, introduced through the IDE and other types of automation in the development process. This may lead to hard-to-maintain code, and turn the developer's focus away from the core business functionality of the object and to the integration of these concerns.
Aspects provide a non-invasive solution to address cross-cutting concerns. Aspects introduce concern-specific behavior into the system after the objects have developed. Their functionality is weaved into the runtime code after the objects have been compiled. This leaves the object's business code untouched by the concern code.
Aspect functionality can be weaved around an object's behavior in many ways. For example, Figure 3 shows a UML activity of some object's method. The object's code and behavior are focused on the business functionality that it delivers, not on any cross-cutting concerns. These concerns are implemented in another object, or more specifically in an aspect that is weaved into the main flow of control.
Figure 3. The control flow of a typical object's method
An aspect's functionality can be inserted into the overall flow before the object's method is called (Figure 4), or after the method (Figure 5). An aspect can also be placed around an object's method, where the aspect can optionally decide to bypass or invoke the target method (Figure 6).
Figure 4. Aspect behavior invoked before a method
Figure 5. Aspect behavior invoked after a method
Figure 6. Aspect behavior around a method
Aspect technology can be a very effective way to introduce architectural mechanisms without touching the business logic code in the IDE. An aspect can be targeted to apply to a specific package, class, or method. Using aspects in an application requires two things:
- The development of the aspect itself
- The definition
of the pointcuts, the places, or conditions where the aspect code is invoked
The development of the aspect functionality is best left to the experts, the architects and technical leads of a project. These developers have experience with -- and skills in -- aspect technology. This still leaves the task of connecting up the aspects to specific points in the application. This task is best done by the rest of the code developers. The challenge here is that this requires some knowledge of aspect technology and AspectJ syntax. It is this part of the usage of aspects in MDD projects that this asset addresses.
The Aspects for MDD framework makes it easy for architects to package aspect-based architectural mechanisms, so that the general developer -- one with little or no aspect skills -- can apply and use aspects in the design and development of an application.
Aspect- and Model-Driven Development
MDD is a methodology for developing software, while Aspects are a technology for delivering functionality to a software application. The two are complimentary; however, until recently they were not often thought of together. The Aspects for MDD framework brings these two together to solve the one problem of how to make it easy for large development teams to leverage the architectural advantages of Aspect technology in an MDD process. The main pain point addressed is that developers who wanted to use aspects in their part of the application needed to know how to write aspect code just to marry up possibly pre-developed aspects with the parts of the system that they were working on.
An architect modeling an implementation of a system in UML will typically model at both an analysis and a design level. At the design level, the architect can be explicit about the coding artifacts that she wants to create. The design level is also typically where the architect will address cross-cutting concerns as a means of addressing non-functional requirements.
However, in order to document the use of cross-cutting concerns in the object model, an architect will often need to create verbose documentation detailing the architectural consideration that she wants addressed. These architectural considerations will then need to be realized by the developer, either using aspect technology -- provided they are sufficiently skilled in this technology -- or more likely using a more conventional method like the invasive API and frameworks already mentioned.
Combining aspects and MDD solves both of these problems. This article suggests a mechanism by which aspects can be introduced into a development effort -- using a standard document modeling notation -- without requiring any significant knowledge of either how they where created or their underlining technology.
The key point is that the developer (ignorant of aspect technology details) can now tag and mark certain model elements
to be associated with a pre-developed aspect. When these model elements are realized (or transformed into code), any necessary
aspect glue code is automatically created to connect up to the predefined aspect. Figure 7 shows the annotation process of a couple of operations in a class. This class is an implementation of an operation, and only the concrete operation can be made aspect-aware. In this example the getCatalog() operation model element is annotated with the <<Log>> stereotype, while the getCatalogs() operation model element is annotated with the <<Cache>> stereotype.
Figure 7. Annotation of a model with aspect keywords
Figure 8. Generating AspectJ Code
The basic process involves an architect or aspect development specialist creating aspect-based code, which is expected to be introduced at various points throughout the application. For example, the architect could create a reusable in-memory cache, to be used in the application when performance needs dictate the need for something like a simple cache. Before any serious design takes place, there is little indication of where such a mechanism would be needed. However,based on past experiences, it might be clear that at some point it will be needed.
The architect can develop such a mechanism based on aspect technology, and with the Aspects for MDD framework package it
could be put up as a reusable asset. These aspects are nearly complete, but one or more definitions in them (pointcuts that define
the elements in the target application to which they apply) are made abstract. This is important because -- before the target application is even created -- these aspect-based architectural mechanisms can be created and tested, waiting only for the final pointcut definitions that make the aspect concrete in the context of the target application. That pointcut definition will only be known after the application starts getting defined.
These abstract aspects are packaged in such a way that they can be installed into developer's workstations. There they can be applied to specific, discrete points in the developing application. The developer, who can be largely ignorant of aspect technology, applies this aspect by selecting model elements (packages, classes, or operations) and marking them with the installed aspect's UML stereotype. During subsequent code generation transformations, the pre-developed aspects -- or rather the libraries that contain them -- are brought into the project, and small concrete extensions of the abstract aspects are generated and weaved into the target application.
The main benefits of this approach are that aspects -- implementing any number of architectural mechanisms, and addressing
various concerns in a target application -- can be developed prior to the beginning of any specific application effort. They can be developed and placed in an asset repository, and downloaded and used as necessary in future projects. The other main benefit is that non-aspect savvy developers can leverage these aspects, with proper guidance, in the course of their normal MDD process. No extra skills -- apart from understanding the goal and use of any particular aspect -- are required.
What has been accomplished
This article introduces the Aspects for MDD framework for Software Architect. It is a simple framework for packaging and deploying AspectJ-based architectural mechanisms and code. This framework can be applied to applications being developed with Software Architect, without requiring any significant aspect skills on the part of the development team applying the aspects in a real project. It enables aspect-based mechanisms to be developed and placed in an asset repository, and selectively installed and applied to specific parts of evolving applications. It enables architects and aspect specialists to share their skills with large development teams, allowing the development team to remain focused on designing and implementing the business and domain functionality of the application.
Resources Learn
- Learn more about the OMG standard for Reusable Asset Specification, version 2.2 by reading the specification.
- Visit the developerWorks SOA and Web services zone to expand your skills.
- Visit IBM's Pattern Solutions and find out what IBM is doing around patterns and reusable assets.
- Stay current with developerWorks technical events and Webcasts.
- IBM Rational Software Architect product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational Software Architect.
- Read the developerWorks article, Develop aspect-oriented Java applications with Eclipse and AJDT, which introduces the AspectJ environment.
- Read the developerWorks tutorial, Developing and deploying Aspects in a Model-Driven Development environment: Part 1: How to package an Aspect for MDD, which discusses the details involved in creating an AspectJ-based library.
- Read the developerWorks tutorial, Developing and deploying Aspects in a Model-Driven Development environment: Part 2: How to package and customize an Aspect for MDD, which describes in detail how an existing AspectJ library can be packaged, deployed, and used in Rational Software Architect.
Get products and technologies
- Download the Aspects for MDD plug-in for Rational Software Architect. The plug-in is available from the RAS repository, under the "design_aspects" category. You can access the RAS repository directly from the Rational Software Architect tool. For more information about how to do this, visit the Pattern Solutions page, and view the text under the "Installing RAS asset" section.
- IBM Alphawork provides a reference implementation of the RAS called Reusable Asset Specification Repository for Workgroups, this reference implementation is available for download directly from alphaWorks.
- Download a free trial version of Rational Software Architect V6.0.
- Build your next development project with IBM trial software, available for download directly from developerWorks.
Discuss
About the authors | 
| | Jim Conallen is a software engineer in IBM Software Group's Rational Model-Driven Development Strategy team, where he is actively involved in applying the Object Management Group's (OMG) Model-Driven Architecture (MDA) initiative to IBM's Rational model tooling. Jim is a frequent conference speaker and article writer. His areas of expertise include Web application development, where he developed the Web Application Extension for UML (WAE), an extension to the UML that lets developers model web-centric architectures with UML at appropriate levels of abstraction and detail. This work served as the basis for IBM Rational Rose and IBM Rational XDE Web Modeling functionality. |
| | | Dr. Eoin Lane, Senior Solution Engineer, is the lead for harvesting and developing of application pattern from key IBM SOA engagements and driving those patterns through IBM pattern governance process to accelerate adoption. Eoin also specializes in Model Driven Development (MDD), asset based development and Reusable Asset Specification (RAS) to facilitate SOA development. |
Rate this page
| |
