On Getting Use Cases and Aspects to Work Together

Renaud Pawlak and Houman Younessi
Rensselaer Initiative in Software Engineering (RISE), Rensselaer Polytechnic Institute - Hartford Graduate Campus, USA

COLUMN

PDF Version

Abstract

Aspect orientation (AO) as an underlying logical model deduced from Aspect Oriented Programming (AOP) [Kiczales97] is attracting attention and gaining in popularity. A number of authors have recently written about how ideas of aspect orientation might be used in connection or in conjunction with existing modeling techniques or technologies in order to enhance the capabilities of the latter. For example, in a recent JOT article Ivar Jacobson writes about the relationship between use cases and AOP [Jacobson03] claiming essentially that the two can be viewed as equivalent. It is however critical for those of us proposing these ideas and connections to ensure that such claims are based on a foundation of adequate comparison and analysis. As investigators who have been working on similar ideas for some time, we would like to take the opportunity of this short paper to provide a constructive critique of what such comparisons need to entail and where the critical issues lie. The Jacobson paper would be used as an exemplar to raise and discuss some common issues and shortcomings. We will explain that although we agree with the essence of Jacobson’s overall statement, we also believe that such assertion is – as it stands – neither new in its essence, nor is it complete and needs to be complemented by crucial improvements if we really want to bring new answers to software engineering.

1 USECASES AND ASPECTS

In a recent JOT paper [Jacobson03], Ivar Jacobson argues that there is a correlation between use cases and AOP [Kiczales97]. He explains that a use case crosscuts a set of components, which is intuitively true, because the essence of a use case is to describe a protocol between several components. He goes further to explain that a design using component-based techniques will achieve component modularity but will fail to achieve use case modularity. Indeed, since several use cases may work on the same set of components, the implementation of the components will eventually have the following properties:

a given component will contain the code coming from the implementation of several use cases (code tangling property)
a set of components will be required to implement a given use case so the use case implementation will not be well modularized (crosscutting property).

We agree with all these statements. Moreover, our own work in this area is based on the same interesting yet obvious logical relationship between use cases and aspects: that they both overlap the components with tangling and crosscutting. We therefore contend that in the future, aspect orientation and use cases will eventually work together to greatly simplify the development life-cycle. In other words, our goals for a methodology we are actively developing is based on this very basic and intuitive idea we share with Jacobson. In theory, developing an application will be done in two main steps:

find the use cases and specify each use case,
design, code, and test each use case.

As expressed here, a component design step will be completely removed from the design, making the applications and the process of creating them much more convenient, simple, and powerful. As Jacobson states, this is possible because AO will allow the modularization of use cases in the implementation, so that there will be a direct match between the analysis/design level and the implementation level. Separation of concerns will be optimal during the whole application development cycle.

Where is it incomplete?

After introducing this main statement, Jacobson then presents his vision of solving the modularity problem of use cases. He re-presents a proposal originally made in a different context in 1979. In doing so he introduces the notions of existion: an existing functional use case, and of extension: a use case that extends the existion. The extension mechanism is based on a very simple technique that consists of designating extension points in the existion, and to switch to possible extensions before and after these points [Jacobson79].

It is easy to note that this mechanism is obviously very similar to a core mechanism that we find in AOP, called before and after advising. In short, this mechanism consists of adding advice code before or after a joinpoint, a joinpoint being, for instance, the invocation or execution of a given method.

On the strength of this observation, Jacobson proceeds to set up a mapping between his use case extension technique, and AOP. Whilst we understand this mapping, we believe it to be a dangerous assertion as it could lead to the conclusion that the two techniques are similar, even equivalent, which is inherently fallacious. Indeed, even if we show that the extension mechanism is entirely covered by AOP (AOP includes Extensions) it does not mean that the reverse is also true.

In the next section, we will show why Extensions do not include AOP, and consequently demonstrate that AOP is different from Extensions. The reader should note here that we do not wish to contradict Jacobson’s core idea, but only to complement it with a set of important concepts that are crucially needed to achieve our common goal: make ideas from AO and use cases work together.

2 WHY EXTENSIONS DO NOT CONTAIN AOP?

The essence of AO is modularization of crosscutting concerns. To this end, AO defines a set of concepts that can be used to handle the modularization, and subsequent re-composition of these concerns. The piece of software that performs the re-composition is called a weaver. Composing all the concerns together is a complex task. Uncovering techniques to do so remain one of the main challenges of AOP.

However, Jacobson’s proposal mainly relies on the simple before/after mechanism, which is certainly a necessary mechanism of AOP, but obviously not a sufficient one to achieve the essence of AOP in a straightforward way. Besides, the before/after insertion of code is not new and has been widely recognized and used even before AOP. Flavors [Cannon82], New Flavors [Moon86] ,CommonLoops [Bobrow86] and CLOS [Steele90] all support the before, and after constructs. Reflective language, and especially behavioral reflection [Maes87, Ferber89, Foot89, Smith84], compile-time reflection [Chiba95], and metaobject protocols [Kiczales91], are well-known candidates to support the before and after mechanisms [Sullivan01]. Knowing that, we should ask ourselves (i) why does Jacobson not refer to these techniques as implementation candidates available much before AOP, and (ii) if AOP can be reduced to after and before mechanisms, why AOP is not simply called “behavioral reflection” or “interception” or “method composition”?

The answer is obvious: AOP and therefore AO is more than just introducing before/after mechanisms in an existing paradigm. In the following section, we will depict the important concepts that are needed in AO and that need to be handled at a use case level if we really want to achieve our goal.

AOP implies pointcuts

Having the ability to add behaviors before and after insertion points introduces an additional dimension: to define and combine behaviors. This new dimension is not easy to represent since it is a reverse dependency: the base program will not know explicitly about the added behavior. As a consequence, handling this complexity within a consistent methodology and providing the adequate abstractions is one of the main challenges of AOP. If an AOP solution does not manage this issue, then why not use metaobject protocols, or CLOS-like languages in place of AOP?

AOP proposes a concrete solution to this problem: the pointcut construct (which Jacobson only briefly mentions in passing). A pointcut is a construct which is held by an aspect and that literally defines a cut within the base program elements. By cutting the base-program elements, the pointcut defines a set of joinpoints (insertion points) that corresponds to the intersection of the cut and the base-program elements. Consequently, the pointcut is able to crosscut a set of base components thus making it possible to introduce a crosscutting concern in a simple way.

Without the pointcut mechanism, the programmer/designer, would have to define these joinpoints manually, thus making the before/after dimension complexity too difficult to control to be actually usable and scalable. Simple AOP-ized extensions as defined by Jacobson do not provide the pointcut facility. One may note also that Jacobson is not alone here; many works claiming to implement AOP have made the same mistake. For instance, most of the early AOP works targeted for the J2EE environment, such as JBoss-AOP, Spring, or Nanning would not provide pointcut definition features, or, at best, ones based on regular expressions. One should not be surprised then, if only the logging-like examples can be straightforwardly implemented in these environments.

Figure 1 – AOP base program extension with the pointcut notion

Figure 1 shows the importance of the pointcut notion of AOP. In this figure, the base program is represented by the inner cylindrical components (yellow cylinders). A pointcut can be represented by a cut in the whole program cylinder, thus cutting all the components. The additional behavior, which is defined independently from the pointcut, by using the before/after mechanism can then be added in a consistent way to the base program in order to add a whole concern at once. One of the main challenges of AOP is to allow the programmer/designer to define meaningful pointcuts so that he or she would be able to easily define and manipulate them (this may imply, in an ideal AOP, the ability to define, abstract, and reuse pointcuts).

Figure 1 is only a simplistic representation of the pointcut notion. However, in real-world applications, the pointcuts can be very complicated. This is why we need powerful pointcut definitions capabilities. For instance, Figure 2 helps in visualization of a very simple pointcut within the AJDT (AspectJ Development Tool) [Kiczales01] of Eclipse. It corresponds to the points where the SUN Blueprint Petstore well-known J2EE example uses a part of the naming API. Each vertical bar corresponds to a class of the Petstore example, and each red line corresponds to a code location where the class actually uses the naming API to resolve an EJB component reference. As one can easily see here, it is impractical to do this manually even in a program of moderate size and complexity.

Figure 2 – a simple pointcut visualization with the AJDT Eclipse plugin.

We need advanced pointcut definition and implementation mechanisms. As good examples of such advanced pointcut definition mechanisms, we can cite the cflow and the semantics based pointcuts. The cflow construct of AspectJ [Kiczales01], allows the programmer to define cuts that depend on the control flow of some methods. The semantics based pointcuts of the JAC framework [Pawlak01] allow the programmer to write pointcuts that will cut the methods based on what they are doing in the program (for instance, the programmer can include/exclude a whole method set depending on whether it modifies a given object state or not).

AOP implies composition

AOP is about (i) modularizing several crosscutting concerns, but it is also about (ii) reusing them and composing them to produce the final application. Jacobson completely ignores the second point in his paper (but again he is not the only one). In modern large-scale application development, the integration of existing components to address specific concerns is very important. It is not reasonable, nowadays, to build the applications from scratch, when so many middleware components can be reused to deal with technical concerns such as persistence, transaction, scalability, fault-detection and recovery, etc. and when several software components provide business-oriented capabilities that can be reused to solve business-traversal issues such as workflow control, profiled presentation, access rights, mobile and cooperative work.

One of the main goals of AOP consists of providing means to reuse and compose different concerns. As a consequence, a use case based methodology should provide a way to (i) make the different identified concerns explicit, (ii) reuse existing components when available, (iii) specify the composition of these different concerns so that the final application specification is complete.

Figure 3 – the composition issue of AOP

Figure 3 shows a simple representation of the AOP composition issue. This issue is very similar to the general issue of integration in software engineering. The main idea consists of being able to check the correctness of the new formed system once the integration or composition step is performed. Of course, most of the difficulties arise from the fact that the composed components may have been developed independently and present incompatibilities when used together in a certain way.

Despite availability of simple composition support in AOP languages (e.g. the precedence notion in AspectJ), AOP still provides incomplete means to this end. Resolving this issue in general is still an open research question. However, there are several efforts in progress that are showing promise [Pawlak99, Sihman02].

Within a use case driven development process, some particular attention should also be given to composition. For instance, the composition of technical and functional concerns will certainly be a frequent task in such a process. Some methodological support would certainly be needed and have to be investigated.

3 ACTUALLY MAKE USE CASES AND AOP WORK TOGETHER: THE ELSA PROJECT

As mentioned in the previous sections, we agree that use cases are a promising basis for a methodology that would greatly simplify the development of large-scale applications. Indeed, by modularizing each concern in a use case model and by having a straightforward correspondence between the design level and implementation, we can improve the development process of large-scale systems.

To achieve this, we need to define an environment that relies on a methodology, formalisms, and tools that enhance the idea of usefulness of usecases as put forth. Enhancements need to be aligned with the two aforementioned crucial issues: (i) the ability to define meaningful pointcuts, and (ii) the ability to compose extensions not only in order to improve our control on the final application behavior, but also in order to be able to integrate existing components (e.g. technical middleware components).

These are the goals of the ELSA project (stands for Environment for Large Scale Applications). ELSA is an on-going project to develop and validate an innovative software process and its associated automation tool. ELSA integrates the strengths of the Object oriented/Component Based (OO/CB) paradigm, formal usecase modeling and Aspect Orientation (AO) in a novel and innovative fashion in order to provide a robust but quick to market process for development of software. ELSA is based on early, disciplined and automated integration of architectural concerns into the product model. Such an approach has enormous potential to positively impact budget, schedule and product quality of all and particularly large-scale software projects. As the project specifically targets architectural concerns, ELSA stands to significantly improve our ability to design for products attributes such as reliability, scalability, robustness, security and maintainability. Potential for technology transfer and commercialization would be significant.

In the next sections, we will give some indications on how the ELSA methodology provides a workable environment based on both AO ideas and usecases.

Use case sets: a basis for pointcut definition

As stated above, a use case based methodology would need a straightforward means to define pointcuts. To us, the most important thing about pointcut support at an analysis/design level is that they be easily represented (maybe graphically), and easily understood. Consequently, we do not think that an AspectJ-like syntax would be appropriate, even if its succinctness is well-suited at a programming level. Therefore, we are currently investigating other means to define pointcuts in ELSA. Our main approach consists of relying on the global use case set structure.

The ELSA methodology proposes a set of use case writing rules that helps the designer to write clean and unambiguous use cases. These rules induce organization of the use cases into hierarchical use case sets (each use case is described by a set of child use cases and each child use case is described likewise). Since our methodology is influenced by AO ideas, the original use case set will only describe the pure functional behavior of the application. Thanks to the hierarchical decomposition, the complexity of the system is easy to handle and separation of concerns is adequately provided.

The interesting point about this use case based decomposition of the system is that it is a behavioral decomposition rather than a component-based one. Even though the two points of view are dependent (we can automatically generate the component view from the use case view), the borders of the modules are completely distinct. The use case point of view thus opens up a new dimension that will allow the definition of pointcuts.

Figure 4 – flow of control in a hierarchical UC set

Figure 4 shows the flow of control (doted curve) in a hierarchical use case set (that follows the ELSA use case writing rules). As shown in the figure, the separation between a level and another (dashed horizontal lines) are crossed by the flow of control several times at multiple points that may correspond to various service requests in the system. Consequently, these separations seem to be a natural location to introduce aspects. Indeed, in the AO sense, level separation can be regarded equivalent to pointcut since they actually crosscut a set of heterogeneous base components.

Contrary to classical AOP, these separations crosscut the behavior of the system rather than its modularized structures. Therefore we can refer to this kind of AOP as behavioral AOP.

Note that the definition of behavioral AOP is a work in progress but it is very promising. Pointcuts will certainly be defined on the two points of view (the use case and the component ones) in an intuitive way. The combination of the two partial definitions will entirely define the pointcut. Once the pointcuts are defined, it will be easy to apply some extension mechanism to it.

Composition of aspects

Beyond pointcut definitions, the second important issue that ELSA deals with is the composition issue. Automatic composition is also an open research issue, but we think that most of the problems can be solved if the methodology provides suitable guidelines and the environment provides simple tools for system reorganization and reengineering. Therefore, we are currently working towards defining the aspect weaving mechanism as intermediate use case level insertion in the functional use case set hierarchy.

Figure 5 –aspect insertion line

Figure 5 shows a simple use case hierarchy. Separation between any two levels of the hierarchy (shown as a dotted lines) is a potential aspect insertion line. In other words, some intermediate use case level(s) can be inserted here in order to implement a crosscutting concern. Note that the use cases are numbered with a convention that allows the designer to easily know the place of the module in the use case set hierarchy.

Figure 6 – composition behavioral aspects

Figure 6 show a composition example involving two behavioral aspects. On the left part, the use cases deal with the composition of the new inserted use cases. On the right hand side, one can see the actually inserted new use cases. By using an appropriate simple tool that would allow use case renumbering, it would be possible to control the composition process so that it is (i) automatic in the simple cases, (ii) configurable in the more complex or difficult cases – simply by defining specific composition use cases, and (iii) traceable. Traceability is very important, since an effective methodology should be able to support the easy adding or removing of an aspect in a controlled way. Additionally, the underlying tools must be able to perform the mapping between the design-level aspects and the implementation-level aspects.

4 CONCLUSION

In this short paper, we showed that the interesting and intuitive ideas put forth by Jacobson in his recently published paper need enhancement. Although at a fundamental level we agree with him, it is important to recognize in the larger context that ideas put forth in AO do go beyond the before/after notions used therein and that if we really wished to make use cases and AO work together then the pointcut definition issues and the composition issue are also to be considered.

In the last section of this paper, we give a short overview of our ongoing project called ELSA. We show how ELSA deals with the aforementioned issues. Whilst the project is still on-going, indications are there that such an approach has a good chance to succeed. We also agree with Jacobson that this approach would actually bring up an entirely new perspective to software engineering and would really have deep positive impacts on all the phases of developing large-scale applications.

REFERENCES

[Bobrow86] D. Bobrow et al.: “CommonLoops: Merging Common Lisp and object-oriented programming”, ACM Conference on Object-Oriented Systems, Programming, Languages and Applications, September 1986, pp. 17-29.

[Cannon82] H. I. Cannon. Flavors: “A non-hierarchical approach to Object Oriented Programming”, Symbolics, Inc., 1982.

[Chiba95] S. Chiba, “A Metaobject Protocol for C++”, Proceedings of the 10th Annual Conference on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA'95), pages 285-299, 1995.

[Ferber89] J. Ferber, “Computational Reflection in Class Based Object Oriented Languages”, Proceedings of the 4th Conference on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA'89), pages 317-326, 1989.

[Foot89] B. Foot and R. E. Johnson, “Reflective Facilities in Smalltalk-80”, Proceedings of ACM Conference on Object-Oriented Programming System, Languages and Applications, pages 327-335, 1989.

[Jacobson03] I. Jacobson: “Use Cases and Aspects – Working Seamlessly Together”, in Journal of Object Technology, vol. 2, no. 4, July-August 2003, pages 7-28. http://www.jot.fm/issues/issue_2003_07/column1

[Jacobson79] I. Jacobson: “Use Case Modularity”. Ericsson internal document X/Tg 2618, 1979.

[Kiczales91] G. Kiczales, J. des Rivieres and D.G. Bobrow, "The Art of the Metaobject Protocol”, MIT Press, 1991.

[Kiczales97] G. Kiczales et al., “Aspect-Oriented Programming”, Proceedings of the European Conference on Object-Oriented Programming (ECOOP'97), 1997.

[Kiczales01] G. Kiczales et al., “An Overview of AspectJ”, Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP'01), pages 327-353, 2001.

[Maes87] P. Maes, “Concepts and Experiments in Computational Reflection”, Proceedings of the 2nd Conference on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA'87), pages 147-155, 1987.

[Moon86] D. A. Moon: “Object-oriented programming with Flavors”, Norman Meyrowitz, editor, Proceedings ACM Conference on Object-Oriented Programming Systems, Languages, and Applications, pages 1-8, New York, NY, November 1986. ACM Press.

[Pawlak99] R. Pawlak, L. Duchien and G. Florin, “An Automatic Aspect Weaver with a Reflective Programming Language”, Proceedings of Reflection'99, 1999. Note that the main results of this research have been submitted to AOSD04.

[Pawlak01] R. Pawlak et al., “JAC: A Flexible Solution for Aspect-Oriented Programming in Java”, Proceedings of Reflection 2001, pages 1-21, 2001.

[Sihman02] M. Sihman and S. Katz, “A Calculus of Superimpositions for Distributed Systems”, Proceedings of the 1st International Conference on Aspect-Oriented Software Development (AOSD'02), pages 28-40, 2002.

[Smith84] B. C. Smith.: “Reflection and semantics in Lisp”, Conf. Rec. 11th ACM Symposium on Principles of Programming Languages, pages 23--35, 1984.

[Steele90] G. L. Steele, Jr.: Common Lisp: The Language, Second Edition, Bedford, Mass.: Digital Press, 1990.

[Sullivan01] G. T. Sullivan, “Aspect-Oriented Programming using Reflection and Metaobject Protocols”, Communications of the ACM, pages 95-97, 2001.

About the authors
Renaud Pawlak (pawlakr@rh.edu) is a research fellow at the RPI Hartford graduate campus. He holds a Ph.D. from the CNAM of Paris, France. His main subjects of interest are Reflection and AOP. He is the founder of the JAC project (http://jac.objectweb.org), an AO framework in Java, and tries to focus the Java and J2EE community interest to AOP with the AOP Alliance project (http://aopalliance.sf.net).

Houman Younessi (houman@rh.edu) is professor of computer science at the RPI Hartford graduate campus and the director of Rensselaer Initiative in Software Engineering (RISE). He holds a PhD in computer science from Swinburne University of Technology in Melbourne Australia. His main areas of interest include object and component technologies, aspect orientation and software architecture, particularly integration and platform issues.

About the authors

		Renaud Pawlak (pawlakr@rh.edu) is a research fellow at the RPI Hartford graduate campus. He holds a Ph.D. from the CNAM of Paris, France. His main subjects of interest are Reflection and AOP. He is the founder of the JAC project (http://jac.objectweb.org), an AO framework in Java, and tries to focus the Java and J2EE community interest to AOP with the AOP Alliance project (http://aopalliance.sf.net).
		Houman Younessi (houman@rh.edu) is professor of computer science at the RPI Hartford graduate campus and the director of Rensselaer Initiative in Software Engineering (RISE). He holds a PhD in computer science from Swinburne University of Technology in Melbourne Australia. His main areas of interest include object and component technologies, aspect orientation and software architecture, particularly integration and platform issues.

Cite this column as follows: Renaud Pawlak, Houman Younessi: “On Getting Use Cases and Aspects to Work Together”, in Journal of Object Technology, vol. 3, no. 1, January-February 2004, pp. 15-26. http://www.jot.fm/issues/issue_2004_01/column2

Previous column

Next column

Comments about this article