Aspect-Oriented Programming (AOP) is an emerging approach to building software application extensions. AOP allows you to modify existing applications without affecting the original application's source code. AOP was primed for Object-Oriented (OO) applications; however, the approach can be used with other application types as well.

The IBM® Rational® Unified Process®, or RUP®, is a widely used software-development process framework and needs little introduction. RUP features an iterative approach to support advanced risk management in the requirements management process based on the use-cases technique.

The IBM Rational Method Composer (RMC) is a new tool designed to build custom delivery processes. Using RMC, organizations can create and manage processes that best fit their business models and principles. RMC also serves as a source of best-practice guidance for RUP and other industry-standard process frameworks, such as the IT Infrastructure Library (ITIL) ¹ , the Project Management Body of Knowledge (PMBOK) ² , and IBM Rational SUMMIT® Ascendant® ³ . Most features of RMC, including the content-authoring environment, are also available in the open source Eclipse Process Framework (EPF) ⁴ .

Reasons for Aspect-Orientation

Here are three key reasons for using the AOA in process engineering:

An AOA addresses the need for a standard method of documenting process extensions. Because most organizations and projects require a custom implementation process, process tailoring is routine. Project team leaders and stakeholders generally have a good working knowledge of classic RUP, but feel less comfortable with custom process extensions and process variants. Such discomfort usually results from colliding methodologies and views, or from poorly documented or redundant artifacts and responsibilities. Although there are many ways of documenting process customizations, none is considered standard, and each organization or implementation must create its own format for describing extensions. If organizations do not properly document and implement the extensions, the extended process becomes difficult to understand and follow. As discussed below, AOA provides a modular way of capturing process extensions.

An AOA helps tools actively assist process customization. A current lack of usage guidance to broadly support new powerful process-authoring tools, such as RMC and EPF, prohibits their wider acceptance. In conjunction with the lack of a standard approach to documenting process customizations ⁵ , this deficiency obstructs project implementation. As discussed below, AOP is a widely understood standard in the development community. AOA implementation by common process engineering tools may bridge the skill and acceptance gap between those who tailor processes and those who enact them.

Principles of the AOA are highly compatible with process-authoring tools. Extensibility mechanisms, such as RMC variability and process contributions examined later in the article, implement some of the same principles that are exploited in AOP. For example, as in AOP, RMC allows you to localize process changes and extensions and apply them without having to change existing delivery processes.

Overview of the AOA

The principles of the AOA are remarkably simple and applicable in a variety of cases. The approach handles the problem of cross-cutting concerns, which is widespread in software programming.

The AOP paradigm

Unlike the AOA, the modular design approach currently widely employed in programming entails breaking down an application into physical parts -- such as components, modules, classes, methods, etc. -- that have minimal functional overlap and encapsulate implementation of the specific concern or a number of concerns. In this regard, a concern can be anything from a narrowly defined business or system problem (e.g.,"withdraw money" or "display user message") to an area of interest or focus (e.g., "security" or "auditing"). Unfortunately, cleanly separating the concern into a module is not always possible, because other concerns tend to cut in. For instance, "withdraw money" is typically intertwined in the program code with "security" and "logging," as shown in Table 1 below:

Table 1: The concern "withdraw money" intertwines in the program code with the separate concerns "security" and "logging" in this example of the modular-design business method.

void moveMoney (Account from, Account to, float amount) {

if  (!getRequestingUser().isAuthorized(OPERATION_WITHDRAW)) {
	throw new SecurityException(MSG_NO_RIGHT_WITHDRAW_MONEY)
}

Transaction trn = database.startTransaction();
try {
	from.withdraw(amount);
	to.deposit(amount);
	trn.commit;

	logger.logOperation(OPERATION_WITHDRAW, from, to, amount);

} catch (DatabaseException e) {
	trn.rollback();
}

The three separate concerns shown -- "withdraw money," "security," and "logging" -- are tangled in this relatively simple method. This lack of separation would be a minor issue if the concerns were not used in other places in the application; however, "security" and "logging" are used in many other business methods, which qualifies them as "cross-cutting concerns" as opposed to simple business logic concerns.

AOP separates the code for concerns into modules called "aspects." The aspect code is also referred to as "advice." The advice executes when a rule, known as a "join point," evaluates to true. Join points are encapsulated in quantifiable expressions (queries) called "pointcuts."

Although this brief summary gives you the basic semantics of AOP, for a thorough understanding I recommend you consult an article or book devoted to the subject. I provide a number of resources in the References section at the end of this article.

Now I will explain the syntax of AOP and discuss how AOP can be applied to the process domain.

AOP syntax

The original and most popular AOP implementation, AspectJ, describes pointcuts using the syntax shown below in Figure 1:

Figure 1: The syntax used by AspectJ to describe pointcuts

Pointcut Designator

In AOP, many event types can trigger execution of an advice. Events, such as methods or constructor calls, classes or object initialization, and exceptions, are all valid AOP triggers. To distinguish between event types, AOP uses Primitive Pointcut Designators (PPDs). In the example above, the "execution" designator activates only join points that are related to run-time execution of the method specified using the "signature."

Signature

A signature declares parameters passed during a method call.

Keyword

A keyword always equates to "pointcut."

Access Specifier

An Access Specifier declares a level of access to a function or method.

A proposed syntax for defining process extensions

The above method for describing pointcuts has proved useful, but at present there is no analogous method for describing process pointcuts. I discuss the reasons for this lack and offer possible resolutions later in the "RMC wish list" section. If you are strictly interested in the pragmatic and practical applications of AOP, you may wish to proceed at this point to the next section. For curious enthusiasts, I'll now provide an overview of a proposed syntax for describing process pointcuts, which may be implemented by process-authoring and enactment tools in the future.

The syntax shown in Table 2 below is not an industry standard, but my own attempt to provide a self-explanatory notation:

"RUP_Element" represents an element of the RUP meta-model, whereas "RUP_element_set" represents an element set. Process-pointcut designators vary from the programming domain. Among other options, pointcut designators may include "initial_step," "initial_task," "initial_iteration," "input_to," "final_step," "final_task," "final_iteration," "output_from," "output_is," "where_used," and "where_declared."

I will clarify the meanings of "RUP_Element," "RUP_Element_set," and "RUP_Element_Mask" later in the article in my discussion of AOA implementation using RMC.

The process-extension definition template

A process-extension definition template offers another way to describe process extensions in AO terms. I will use the template shown below in Table 3 to provide several examples of how to apply AOP concepts to RUP customization:

This template can be used for describing process extensions in real-life process customization and tailoring projects. The template itself is a kind of RUP guidance, and it must be included with the extended process description.

Although you'll see the greatest advantage of using AOA in cases when a change must happen at many points in the process, and therefore must be made to multiple parts of the process description, you should use the process extension template to describe all potential process changes, including those that target a single place in the process description without crosscutting. By following this recommendation, process engineering team members and project teams that use an extended process may benefit from the implied declaration consistency.

After explaining the fundamental AOP concepts below, I will discuss how you can apply them to an RUP customization.

AOP concepts and examples

The following AOP examples use common programming terminology, including "program," "system," and "module." I've put brackets around the proposed concepts such as "process," "activity," and "task" that can be used for extending process methodology as in the RUP.

Cross-cutting concern

A "cross-cutting concern" is an aspect (part) of a program (process) that affects other aspects and cannot be cleanly isolated from the system (process, activity, task). The same is true for inserting a new aspect into the program (process).

Logging is a textbook example of AOP, mainly because it affects a majority of the significant application methods.

AOP example:
Figure 2 below shows a class with multiple methods, of which some need to store details about the user who accessed the method and the money amount that was transferred.

Figure 2: An employer class

RUP example:

An "activity" (formerly workflow detail) that consists of multiple "tasks" (formerly activities), of which some must contribute to a process "deliverable" (a package of work products for delivery to project stakeholders) at the task completion.

Join point

A "join point" is a clearly defined point in a program source code (process description) where the concern crosscuts the program (delivery process) (and where an extension may occur). For an AOP approach to be advantageous, multiple join points for a single concern must exist.

AOP example:
"When a method that affects employer financials is called"

RUP equivalents:
"At the onset of iteration"
"When a task modifies to Iteration Plan artifact"

Pointcut

A "pointcut" is a construct used to programmatically declare and group join points. Pointcuts allow you to unambiguously reference multiple join points in the program code (method content and processes). AOP implementations normally declare join points using template languages.

AOP example:

pointcut employerFinancialUpdates(Employer e, User u): 
	call (public void updateEmployerFinancial* ());
	

The "employerFinancialUpdates" pointcut refers to join points where the method of the name that begins with "updateEmployerFinancial" is called.

RUP Equivalent:

 pointcut RUP_Element.BasicMethodElement.Task_set outputArtifactIsIterationPlan ():
output_is (RUP_Element.BasicMethodElement.WorkProduct.rup_iteration_plan)

This pointcut, called "outputArtifactIsIterationPlan," describes tasks (join points) that modify the IterationPlan artifact.

These qualifier names will become clearer later in the article when I discuss the RUP meta-model.

You can take a more relaxed approach to describing pointcuts by using free-text description. For example, the pointcut shown above can be described like this: "Find all tasks that modify the Iteration Plan artifact." This sentence presents an adequate requirement for a process engineer to identify tasks that must be looked at and potentially extended.

Aspect

In AOP an "aspect" is a structure (usually a method, module, or class) that encapsulates concern-specific behavior.

AOP example:

public aspect logTransaction{ pointcut employeeFinanceUpdates(Employer e, User u) : 
call(public void updateEmployerFinancials* ()) && args(e, u); after (Employer e) 
returning : employerFinanceUpdates(e, u) {<< Advice >>} 
}

Implementation of <<Advice>> is provided below.

RUP equivalents:

Extension Work Product (Artifact, Deliverable)
Extension Activity (Task, Activity, Iteration, Phase)
Extension Role
Extension Step
Extension Capability Pattern
Extension Delivery Process

RUP examples:
"Rationalization phase" (extended phase)
"Program update memo" (extended artifact)

Advice

"Advice" is a physical implementation of the additional behavior that solves the concern.

AOP example:

System.out.println("\t>User : " +u.getFullUserName() + 
" has made a financial transaction through "); System.out.println("\t>method " + thisJoinPoint.getSignature());

This implementation code prints the name of the user accessing the method and the method name. RUP example:
The purpose of the task is:

• To identify the classes that perform a use case's flow of events
• To distribute the use-case behavior to those classes, using analysis use-case realizations
• To identify the responsibilities, attributes, and associations of the classes
• To note the usage of architectural mechanisms

For a more comprehensive review of the AOP approach, consult the resources provided in the "References" section at the end of this article.

Implementing AO extensions with RMC

The process of applying an advice to a base module is known as "weaving." AOP implementations of weaving in use today range from source-level weaving, typically implemented using preprocessors, to load-time and run-time weaving, normally implemented using intelligent middleware platforms. Examples of run-time weaving include AO-ready application servers and virtual machines.

Because RMC does not include a process runtime environment (I discuss this limitation in the "RMC wish list" section), it can only support source level weaving. In this case, a "source" is an instance of a delivery process that is to be extended.

Implementation prerequisites

Although not a definitive requirement for an AOA implementation, an organization should consider using a process authoring tool to maintain descriptions of its existing implementation processes. RMC is a standard process customization tool that, among other things, supports creation of specialized method plug-ins and process configurations. A process model in RMC augments the purposes of an AOA implementation by improving overall manageability and understanding of the existing implementation processes.

RMC's import capability allows you to bring work previously authored by Rational Process Workbench into the tool.

RMC process-extension capabilities

RMC supports several process extension techniques:

Process plug-ins

RMC plug-ins (formerly, RUP plug-ins) provide a standard way to build and distribute custom process extensions. The plug-in approach uses modular architecture that supports expanding and extending existing method content with new methodology and technology guidance. You can use plug-ins in a Lego-like fashion to assemble new processes and modify existing ones. A large number of specialized plug-ins are available from IBM, its partners, and the open source community. Along with method configurations (discussed below), plug-ins also provide a solution for modularizing existing process content and allow you to incrementally create process extensions.

Method configurations

A method configuration forms a thin layer between method content and delivery processes. It may span multiple plug-ins, making inclusion of only required content a simple matter. Method configurations make it easy to assemble processes from logical building blocks, which may consist of both content and processes. Using method configurations, you can publish a delivery process as a navigable HTML structure that implementation teams can access.

Content variability

Content variability mechanisms built into RMC come in handy when creating new method content elements from existing ones. The tool supports easy content updates and replacements by automatically propagating changes throughout the entire content library, as well as updating references to the updated content in the delivery processes. This feature simplifies design-time implementation of cross-cutting concerns (discussed below), because actual content modification happens in a single place, with the tool taking care of the weaving.

The three different variability patterns supported by RMC are contribution, extension, and replacement.

When used through the "contribution" pattern, an element can add new content to a base element without directly modifying any of the existing properties. When supplemented using the contribution pattern, the base element appears in the method configuration with added content.

By applying the "replaces" pattern, you can modify parts of the element without affecting an original element definition in the content library. "Replaces" is most useful for developing new plug-ins intended to hide or change aspects of the base content. The net effect of replacing an element is the creation of a new element with a different content that is still referenced by all the same delivery processes and capability patterns.

"Extends" allows an extending element to inherit characteristics of the base element. In this scenario two elements will appear in the method configuration -- a base element and the extended element. Unlike the "contributes" pattern, which adds new content to the base element and allows its modification in a context of the delivery process or capability pattern without modifying the base element, "extends" creates a brand new element that references the base element while contributing new content.

Capability patterns

A "capability pattern" is a mini-process that defines a reusable set of activities. Examples of a capability pattern from the base RUP include "use-case based requirements management" and "validate build." RMC process variability allows you to dynamically nest capability patterns in other capability patterns and delivery processes. When a capability pattern is dynamically nested, any change that affects its structure is automatically propagated to all referencing processes and capability patterns.

Process contributions

RMC process variability allows you to create custom delivery processes that contain differential changes only to the existing delivery processes and capability patterns. Because it does not require changing corresponding method configurations, this feature is handy for making changes to a delivery process. You can create process contributions from both capability patterns and other delivery processes by using one of the two principle methods: copy or extend.

The "copy" method allows you to replicate content from other processes or capability patterns. Copy is not a dynamic facility because no link between the base content element and the destination delivery process or capability pattern is created.

The "extend" method provides a way to dynamically extend the process. When a process is extended, all changes to the base process or capability pattern are automatically carried over to the destination process (the user has to manually initiate synchronization), which provides a good vehicle for process upgrades and maintenance purposes. One limitation of this method is all linked content appears in the resulting process as "read-only" and cannot be modified directly.

Integrated search

The RMC search functionality may significantly aid process engineers during AOA implementation. Figure 3 below shows RMC's context-sensitive search capability that allows you to look for an entry within a select scope that may comprise both process and method content. Note that the scope elements shown in Figure 2 somewhat resemble the elements of the RUP meta-model, which is not surprising considering many searches must happen through only selected parts of the method or process content.

Figure 3: RMC search dialog

RMC navigability

RMC's navigability helps you identify and trace content dependencies. The Element Preview tab shows all relationships for a given RUP element. During a RUP extension exercise, properly targeting an extension often necessitates knowing what dependencies an element has. Figure 4 below, for example, depicts the element dependencies you may need to know to modify a work product.

Figure 4: Element dependencies in RMC

RUP meta-model

To describe process concerns (extensions) as aspects, and to potentially create process pointcuts (see below), you must have a good understanding of RUP structure. The tool structure is based on IBM Rational's Unified Method Architecture (UMA), which evolved from the RUP 2003 schema that was based on the Object Management Group (OMG) Software Process Engineering Meta-model (SPEM) 1.1. The tool structure took into account the latest SPEM ⁶ standard (2.0) and incorporated elements and features from other processes, such as the IBM Global Services Method and SUMMIT Ascendant.

A sample hierarchical representation of the RUP meta-model is shown in Table 4 below. This structure is based on the RMC physical grouping of elements and is suited for any AOA implementation.

For a more comprehensive description of the RUP meta-model see http://www.eclipse.org/epf/.

Process extensions with RMC

Process-extension capturing is an essential part of the Process Tailoring discipline, as shown in Figure 5 below. Concern capturing normally happens throughout the three initial process activities: Process Analysis (in the form of concern identification, analysis, and capturing), Process Modeling (in the form of join point identification and pointcut declaration), and Process Description (in the form of aspect definition and advice writing). Implementation of the extension aspects may continue through the Process Configuration activity in cases where RMC process configurations are used as a technique for merging content from several different plug-ins.

Figure 5: Concern definition in the Process Tailoring discipline

Below I provide several examples of how you can use the Extension-Definition template to capture RUP customization requirements.

Requirement: Produce a work product at the wrap-up of a repeatable activity

RUP iteration is a classic example of repeatable activity. A RUP-based project may have anything from one (generally a bad practice) to a dozen or more iterations.

It is often necessary to produce a new work product at the onset of an iteration, such as when a stakeholder wants to receive an "iteration report" or "integrated-data model" or take part in a "product demonstration," when a large amount of new functionality is put in production. Table 5 below shows how the "iteration report" may be described using the Extension-Definition template:

Requirement: Perform an action when a work product changes

As shown in Table 6 below, an example of the need to perform an action when a work product changes is a case where an internal or external stakeholder wants to be immediately informed about planned changes to be made to a work product or a number of work products. Another example is when you want to track changes to a project's critical work products in a separate document.

Requirement: Replace a work product throughout the process lifecycle

Substituting a standard work product with a custom one is a common requirement during RUP tailoring. For example, as shown in below in Table 7 below, some organizations want to produce an "Architecture Blueprint" instead of the Software Architecture document. While this often involves a simple name change, this requirement may entail changing the document structure and relationships with other process elements.

RMC wish list

Process enactment engine

There is no industry standard RUP runtime environment, i.e., an application that supports managing and monitoring the state of the RUP-based project. Usually this task is assumed by the combination of project management and portfolio management tools, provided that all RUP activities regularly report their state to the anchoring project management process, which then updates the portfolio management process.

It wouldn't hurt for the IBM/Rational process bundle to include an environment for running RMC-generated delivery process instances. Some proponents of the Agile movement may disagree; however, I often encounter the need for such a feature, even in the smallest projects.

Hierarchical search

To become a real value to AOA-equipped process engineers, the existing search functionality must be expanded to fully support the RUP meta-model. Although the RMC search dialog (see Figure 3) does make a distinction between method content and processes, it does not go far enough to support a hierarchical search through the content loaded into the tool.

For example, a query, built using either a search "wizard" UI or pointcut definition language, would allow users to perform hierarchical searches with a specified criteria. A similar functionality could be helpful for pointcut debugging purposes.

Embedded language for defining pointcuts

To fully support dynamic AOA weaving, RMC requires an embedded language for declaring process pointcuts. Pointcuts written using a template language rather than plain text could be fed to a process enactment engine in order to generate real-time process events. Of course, such a dynamic syntax is only possible if a process enactment engine or hierarchical search functionality that can take advantage of it is made available.

Can AOA be Agile?

In the global IT environment, where the Agile movement is gaining increasing attention, the thought of introducing another formality may send shivers down the spines of some practitioners. Although I share most, if not all, Agile principles, I prefer to make a clear distinction between the desire to travel light whenever possible and the need to have a well-documented process description that may reduce ambiguity inherent in many implementation projects -- especially if those projects are comprised of a significant number of stakeholders, stakeholders with special needs, or team members with limited expertise in the technology and/or methodology at use. While the Agile approach works very well in a setting of experienced, highly motivated, or very closely connected individuals, it may not work "out of the box" in other cases. The EPF effort is underway to describe the Agile form of the Unified Process (UP) ⁶ that will involve contained and co-located teams to develop business applications. When completed, the process and the AOA will be highly complementary.

Agile practitioners should not be concerned with the perceived high degree of ceremony involved in formulating and capturing process extensions. For example, it is not necessary to capture extensions on multiple pages to the extent that they are made more detailed than the actual delivery process they extend. You may choose to follow the strategy for capturing extensions proposed by the Active Stakeholder Participation, i.e., to involve stakeholders early. Or, you may opt to use Inclusive Modeling techniques if they better serve the goal of concisely and clearly describing the concern or its implementation. You may even choose to embed the schematics or pictures drawn using any of the techniques right into the process extension definition template. However, if you do not capture your extensions with enough detail, or fail to capture them at all, implementation teams may be left with so much freedom of choice that they may not be able to use the extensions created for the benefit of the project.

Although capturing the extensions requires some work, the amount is minimal when compared to the labor that may go into fixing problems that may arise as result of missing important implementation activities.

Summary

AOP has proven to be a flexible approach to building program extensions. Its principles may be applied to building process extensions in the manner described in this article. A process engineering task requires good understanding of RUP taxonomy (meta-model) and availability of a consistent extension mechanism. This article provided a template that can be used to capture content and process extensions in a consistent and repeatable manner. To make customization, tailoring, and implementation processes more effective and to take advantage of the tool's embedded extensibility mechanisms, an organization must build a model of the existing implementation processes in RMC. RMC and its free cousin, EPF, are both excellent candidates for the task because they include a comprehensive method content library and flexible extensibility patterns and they are based on the SPEM standard.

Acknowledgements

I would like to compliment Scott W. Ambler for his insightful remarks and ideas.

Notes

¹ http://www.itil.co.uk/

² http://www.pmi.org/

³ http://www.ibm.com/software/awdtools/summitcoe/

⁴ http://www.eclipse.org/epf/

⁵ RUP/RMC plug-ins provide a standard way to implement process extensions

⁶ See http://www.ambysoft.com/unifiedprocess/agileUP.html for an update on the status of the effort

Resources

Learn

• "How to jumpstart your process development effort using IBM Rational Method Composer" is a short article that provides a practical example of overloading RUP with a project management process. http://www.ibm.com/developerworks/rational/library/jul06/smith-popescu/index.html
  
  
• This article by G. Pollice should give you a good basic understanding of AOP. http://www.ibm.com/developerworks/rational/library/2782.html
  
  
• To learn more about the IBM Rational Method Composer, read this two-part series by IBM Solution Architect Peter Haumer. Part one: http://www-128.ibm.com/developerworks/rational/library/dec05/haumer/index.html. Part two is available here: http://www.ibm.com/developerworks/rational/library/jan06/haumer/index.html?S_TACT=105AGX15&S_CMP=EDU
  
  
• "Extending the RUP series" by A. Bencomo contains hands-on guidance for customizing RUP using plug-ins. http://www.ibm.com/developerworks/rational/library/05/323_extrup1/index.html
  
  
• SPEM meta-model for defining software-engineering processes. http://www.omg.org/technology/documents/formal/spem.htm
  
  

Discuss

• Participate in the discussion forum.
  
  
• A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
  
  
• Global Rational User Group Community
  
  

About the author

Vitalie Temnenco is a software architect with Sierra Systems Inc., where he provides technology and methodology consulting to Sierra’s clients. Previously, he was an architect for the Ontario, Canada government's Workplace Safety and Insurance Board, where he provided architectural mentoring on implementation projects and helped teams embrace RUP and Enterprise Architecture concepts. His experience includes architecting and building solutions for clients in a variety of business domains, such as banking, finance, insurance, retail, and telecommunications, and he teaches UML and RUP for business and systems analysis as well as in construction of new systems. He can be reached at vit@umlconsulting.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Reasons for Aspect-Orientation
• Overview of the AOA
• Implementing AO extensions with RMC
• RMC navigability
• RMC wish list
• Can AOA be Agile?
• Summary
• Acknowledgements
• Notes
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Method Composer
• Webcast: Streamline software delivery to gain market advantage: Series overview
• Briefing: Jazz and Rational Team Concert
• Buy: Rational Method Composer

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers