PhD Research Proposal Aspects to Support the Software Process

Oren Mishali
Advisor: Prof. Shmuel Katz
Abstract We have suggested [14] using the aspect-oriented paradigm to support the software development process by composing (weaving) aspects into the software development environment. In the rst part of our research we have dened aspects to support the Extreme Programming (XP) development methodology and then wove them into the Eclipse platform. Several directions for future research have been identied and are presented in this document as a proposal for a PhD research on this topic.

Introduction

Aspect-Oriented Programming (AOP) [12] is a paradigm suggested due to the inability of object-oriented constructs to modularize cross-cutting concerns (i.e., concerns that span multiple modules). This inability causes these concerns to be scattered across several system modules and tangled with other concerns, which makes program comprehension and maintenance harder. AOP attempts to solve this problem by introducing new language constructs (aspects) that modularize and separate the cross-cutting concerns from the objectoriented system and also provide a mechanism to compose (weave) these aspects into the underlying system. Aspects are usually used as direct support for the software product under development by being woven into it. In [14] we have suggested using aspects to support the Software Process (SP) [10], that is, the methods and practices that are used in order to produce the software product. These process-supportive aspects, which we call SP-aspects, are not intended to be woven into the software product but into the development environment where the product is developed. In other words, SP-aspects modify the development environment and adapt it to a specic development methodology. SP-aspects are primarily suggested to support Software Process Management. That is, by being woven into the development environment, they can help to minimize the gap between the actual behavior of the participants (actual process) and the dened process by recognizing deviations from the process, enforcing policies and standards, and even automating procedures. Furthermore, SP-aspects can support Software Process Modeling [5], i.e., they can be a basis for a formal description of the software process. In the rst stage of our research we conducted a case-study to examine the feasibility of the idea. In the case-study, aspects to support a specic development methodology (Extreme Programming [4]) were developed and woven into a specic development environment (the Eclipse platform [1]). The idea has been proven to be feasible and several research directions have been recognized. In the rst direction more aspects to support Extreme Programming (XP) will be developed as well as aspects to support other methodologies (e.g., Rational Unied Process [13]) over dierent development platforms. The second direction involves the development of a repository for SP-aspects that will allow automatic generation of aspects for dierent methodologies. Challenges and diculties during the implementation of XP-aspects over Eclipse have motivated the third research direction; weaving aspects into an existing complex system is dicult, mainly since these objectoriented systems are not designed (yet) with any awareness to AOP. In this direction we will analyze these diculties and will propose dierent strategies to cope with them. The rst two directions mentioned above are elaborated in Section 2. Section 3 presents the third direction and nally a secondary possible direction is mentioned and related works are surveyed.

Software process management

As stated earlier, in the rst stage of our research, XP-aspects were developed over Eclipse. Several XP principles such as test-rst, collective ownership and rapid feedback are already supported by corresponding XP-aspects, and the future plan is to have a full set of aspects to support XP. It is also planned to partially implement support for other methodologies and to examine the connection of these aspects to other development platforms besides Eclipse. For each methodology a set of abstract aspects covering several the facets of the methodology will be developed. In general, an abstract aspect contains pointcuts and an advice. Pointcuts represent key-events derived from the relevant supported policy and an advice is the action part that tells what to do when those events occur. Both advice and pointcuts are abstract, that is, they dene complex pointcuts in terms of more primitive (but still abstract) events, and provide intuitive names as placeholders for advice. A further renement will later be needed to make these declarations usable. The reason for taking such an approach is that usually dierent development teams need dierent kinds of process support even for the same policy. In such a case, they can share the same abstract aspect but use a dierent concrete aspect that suits their own specic process. For a concrete aspect to implement an abstract aspect, it needs to provide implementations for the abstract parts of the aspect. The plan is to dene for each abstract aspect belonging to a specic methodology a variety of concrete renements for its abstract parts. Those elements, namely concrete join-points and advices, comprise a signicant contribution to the management of the software process and can be composed and reused in various ways to provide a exible process support. The second research direction in this context (of managing the software process) is related to the development of the SP-aspects repository. This novel component, which is in its very early stages of development, will store abstract SP-aspects supporting dierent methodologies. In addition, it will store a collection of concrete join-points and advices that correspond to the abstract aspects. The repository will provide means to generate concrete aspects based on the abstract ones. A typical user of the repository will specify the desired methodology to be supported, the target development platform, and the way in which the abstract policy should be realized. Based on these parameters, relevant concrete join-points and advices will be collected and the desired concrete aspects will be generated, ready for use. The concrete advices kept in the repository can be classied into three main categories that correspond to dierent management strategies: monitoring, enforcement or automation. An aspect having a monitoring strategy is one that recognizes deviations from a practice and perhaps reports to management, an enforcement strategy forbids any violations from the practice, and an automation strategy automates the practice, i.e., puts conformance activities in the aspect itself. For feedback and evaluation purposes user experiments will be made, where users of the development environment will be requested to perform scenarios with and without the aspects and then to ll in related surveys. Preliminary experiments have already been made and indeed they provide valuable feedback. To conclude, the contribution of this part is in dening abstract aspects to support several methodologies (including XP) over several development platforms (mainly Eclipse), developing a variety of concrete join-points and advices for those abstract aspects, and the development of the SP-aspects repository that will introduce a novel, rapid and exible way to generate process support by means of aspects.

Oblivious or not?

Aspects introduce a novel capability of augmenting an existing system with new functionality in a modular fashion. Aspects are meant to augment systems which were not designed with AOP in mind. This property, known as obliviousness [6], means that the fact that aspects will be woven into a system should not aect the design of this system. However, during our experience of weaving aspects into Eclipse, several diculties have been encountered that raise the question whether aspects can indeed be successfully applied to a system not designed with awareness to AOP. The purpose of this research direction is to recognize problems associated with weaving aspects into an oblivious system and to suggest directions for possible solutions. Usually, one who wishes to implement an aspect has in mind high-level events in the ow of the program to which the advice part of the aspect should be applied. The task before him is to nd the exact places 2

in the code (a.k.a join-points, e.g., method calls, assignments to variables) that correspond to those events. A suitable join-point needs to be activated during the relevant high-level event, several assertions need to be satised before and after it, and the relevant context that we wish to expose should be accessible. As a result, for a developer to nd such a join-point, he needs to have expert knowledge of the underlying system. Since the implementor of the aspect is not necessarily the one who implemented the basic system this could be dicult and time consuming. In this context we will characterize the (minimal) knowledge of the underlying system required for weaving aspects into it and based on that knowledge will suggest methods to help implementors of aspects to nd join-points in an underlying system. One method to consider is having a proper aspect-oriented documentation of the base system that facilitates weaving of aspects into it. A dierent approach to this problem is to have automatic tools. It has also become evident to us that some natural candidates for join-points are in fact unsuitable. The main reason is the inability to expose part of the relevant context in these join-points. For instance, the natural place to nd a join-point that corresponds to creation of a Java class is within the code of the Java-classcreation-wizard. There, we found it impossible to expose part of the context (i.e. information lled-in by the user) since the aspect didnt have sucient access privileges. In a dierent case we were interested in monitoring the execution of a refactoring operation. Exposing the context from within the run() method of the refactoring class was similarly impossible but here an elegant solution was found. Since the desired context is passed to the constructor of the class, we advised the constructor and extracted the context into special variables that were added to the class by the aspect. Then, upon invocation of the run() method, the context was now accessible from the variables. Our purpose is to recognize places where there is a diculty to weave aspects due to inappropriate (at least from the aspects perspective) design of the underlying system as well as suggesting relevant solutions. In addition, code patterns like the one mentioned above that have been found to be widely applicable for weaving will be identied and reported. We believe that the potential contribution of this research direction is of great importance since the success of the aspect-oriented paradigm is signicantly dependent on the ability to smoothly weave aspects into an existing underlying system. The results of this part may lead to an improved understanding of the relationship between aspects and an underlying system and perhaps to the conclusion that an underlying system should be designed with some sort of AOP awareness.

Waiting room: Software process modeling

A Software Process Model [5] is a formal description of the process with its activities, policies, tools, and participants. This model has several purposes: by being formal it facilitates automatic process support, it helps to dene the process, encourages communication among the participants and can be used for training of employees. Many process modeling formalisms also known as Process Modeling Languages (PMLs) exist, and they have various modes of expression such as programming-languages based (APPL/A [17]), Petri-net based (SPADE [3]) and rule based (Marvel [11]). However, dening a successful process model is not easy. The challenge is to dene a model that is both formal and comprehensible to the process participants. Curtis et al. [5] pointed out that PMLs cannot be used if they cannot be understood. They also mentioned that facilitating human understanding has received less attention from the research community than has machine automation. However, eight years after the above remark, Fuggetta stated [7]: Existing PMLs are complex, extremely sophisticated and strongly oriented toward detailed modeling of processes. We believe that aspects, with their simple event-action model, can be a basis for a successful process model. Still, a modeling notation cannot by itself automatically provide improved comprehensibility. To do that, the process model should be dened considering also cognitive techniques. The purpose of this research direction is to characterize techniques for process modeling with aspects. So far, it was not the focus of our research although several cognitive techniques were put into use such as eliminating details from the modeling layer (abstract aspects and strategies) and using natural terminology of the development methodology (ontology).

Related work

The idea of integrating process support into development environments is not new, and is realized in one way or another in most software development environments [15]. In general, for such integration two approaches exist. The rst is to code the environment with software process support, a common approach that has several disadvantages: the process support is limited due to the inability to foresee all the points for support, the support is usually restricted to a small family of similar software processes, and software process concerns are scattered and tangled with other concerns. The second approach resulted in the creation of Process Centered Engineering Environments (PCEs) [9]. PCEs are development environments that aimed to provide exible process support by considering a description of the desired process as an input and behaving accordingly. In practice PCEs are not very popular, mostly because of their complexity and since they do not seamlessly integrate into an existing environment (usually PCEs are intended to replace an existing environment). SP-aspects have several signicant advantages over the above approaches: they seamlessly integrate into an existing environment, there is no need to design for process support in advance, they are easy to extend, update, or remove, and they modularize and separate the software process concerns from the basic system. In [16] aspect-oriented concepts were proposed to complement and to assist the design of existing process modeling languages. The idea is investigated in the context of a specic PCE and PML called APSEE. The main dierence from our work is that we use aspects as the process model itself acting directly on the development environment, whereas in the cited work AOP is used to complement an existing PML, which still requires the involvement of a special-purpose environment. Moreover, that work investigates only the functional level, whereas as mentioned in Section 4, we also deal with the non-functional level, i.e., formulating techniques for process modeling with aspects. Several works have already pointed out problems with connecting aspects to an underlying system. XPI [8], for example, is a mid-layer between aspects and an underlying system suggested to decouple the aspects from the base code. Open Modules [2] extend the familiar API with pointcuts that represent internal events that are semantically important. That solution does indeed solve part of the above-mentioned problems but signicantly restricts the power of AOP. We are not aware of other works trying to tackle the problems mentioned in Section 3 such as nding the join-points or recognizing inappropriate design decisions in the base system. In any case, the experience gained so far with AOP is somewhat limited and there is much more to be learned about the relationship between aspects and the underlying system.

References
[1] Eclipse homepage: http: //www.eclipse.org. [2] J. Aldrich. Open modules: A proposal for modular reasoning in aspect-oriented programming. In C. Clifton, R. Lmmel, and G. T. Leavens, editors, FOAL: Foundations Of Aspect-Oriented Languages, pages 718, a Mar. 2004. [3] S. Bandinelli, M. Braga, A. Fuggetta, and L. Lavazza. The architecture of SPADE-1 process-centered SEE. j-LECT-NOTES-COMP-SCI, 772:15??, 1994. [4] K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, Reading, Massachusetts, 2000. [5] B. Curtis, M. Kellner, and J. Over. Process modeling. Communications of the ACM, 35(9):7590, Sept. 1992. [6] R. E. Filman and D. P. Friedman. Aspect-oriented programming is quantication and obliviousness. In R. E. Filman, T. Elrad, S. Clarke, and M. Akit, editors, Aspect-Oriented Software Development, pages s 2135. Addison-Wesley, Boston, 2005. [7] A. Fuggetta. Software process: a roadmap. In ICSE - Future of SE Track, pages 2534, 2000.

[8] W. Griswold, K. Sullivan, Y. Song, M. Shonle, and N. Tewari. Modular software design with crosscutting interfaces. In IEEE-SOFTWARE, volume 14, pages 5160. 2006. [9] V. Gruhn. Process-centered software engineering environments, A brief history and future challenges. Ann. Software Eng, 14(1-4):363382, 2002. [10] Humphrey. Managing the Software Process. Addison-Wesley, 1989. [11] G. E. Kaiser. Experience with marvel. In D. E. Perry, editor, Proceedings of the 5th International Software Process Workshop, pages 8284, Oct. 1989. [12] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspectoriented programming. In M. Akit and S. Matsuoka, editors, Proceedings European Conference on Objects Oriented Programming, volume 1241, pages 220242. Springer-Verlag, Berlin, Heidelberg, and New York, 1997. [13] P. Kruchten. The Rational Unied Process. Addison-Wesley, third edition, 2004. [14] O. Mishali and S. Katz. Using Aspects to Support the Software Process: XP over Eclipse. In Proceedings of the 5th International Conference on Aspect Oriented Software Development (AOSD), pages 169179, 2006. [15] H. Ossher, W. H. Harrison, and P. L. Tarr. Software engineering tools and environments: a roadmap. In ICSE - Future of SE Track, pages 261277, 2000. [16] R. Q. Reis, C. A. Lima Reis, H. Schlebbe, and D. J. Nunes. Towards an aspect-oriented approach to improve the reusability of software process models. In A. Rashid, B. Tekinerdoan, A. Moreira, J. Arajo, J. Gray, g u J. G. Wijnstra, and P. Clements, editors, Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design (AOSD-2002), Mar. 2002. [17] S. M. Sutton, Jr. APPL/A: A Prototype Language for SoftwareProcess Programming. PhD thesis, University of Colorado, Boulder, CO, Aug. 1990.