Theme/UML is an existing approach to aspect-oriented modelling that supports the modularisation and composition of concerns, including crosscutting ones, in design. To date, its lack of integration with model-driven engineering (MDE) techniques has limited its benefits across the development lifecycle. Here, we describe our work on facilitating the use of Theme/UML as part of an MDE process. We have developed a transformation tool that adopts model-driven architecture (MDA) standards. It defines a concern composition mechanism, implemented as a model transformation, to support the enhanced modularisation features of Theme/UML. We evaluate our approach by applying it to the development of mobile, context-aware applications-an application area characterised by many non-functional requirements that manifest themselves as crosscutting concerns.

The ability to follow and examine (i.e., trace) the life of a artifact throughout software evolution can greatly improve overall system comprehension. In this deliverable, we present material directed towards a traceability framework for tracing between software engineering-related artifacts, such as software requirements, software architecture, and software design. This work relies on previous efforts documented in D36, D37, D38 and D63, and has as its primary aim of providing traceability support to the Aspect-Oriented requirements, architecture, and design approaches developed in the laboratory. The main intention of this framework is to provide support for analysis of cross-life-cycle concern representations and the assessment of the impact of their changes throughout system evolution. Document ID: AOSD-Europe-ULANC-43 Deliverable/Milestone No: D126 Workpackage No: 6 Type: Research Status: COMPLETED Version: V4 Date: July 18, 2008 Author(s): Mónica Pinto, Lidia Fuentes (University of Malaga, Spain) Ruzanna Chitchyan, Awais Rashid (Lancaster University, UK) Andrew Jackson, Siobhán Clarke (Trinity College, Dublin, Ireland) Boris Shishkov, Bedir Tekinerdogan, Mehmet Aksit (University of Twente, Enschede, The Netherlands) Editor(s): Phil Greenwood, Raffi T. Khatchadourian (Lancaster University, UK)

The impact of Aspect-Oriented Software Development (AOSD) on testability must be quantified before it can be considered for widespread adoption by industry. One way to measure testability is through mutation analysis (MA). In MA, a mutation tool generates faults for locations in software. Each fault is created in a new version of the software called a mutant. Testability of a location is measured by executing tests against mutants and counting the proportion of mutants that cause test failure. To quantify the testability of approaches to AOSD through MA, mutant generation tools are needed. This paper introduces MuAspectJ, a tool for generating mutants for AspectJ programs, to satisfy this need. The tool is evaluated in terms of the quality of mutants it generates. Assertions reached about the testability of the software under MA are derived by aggregating the testability of each location. The quality of the assertions that can be derived from MA results is only as good as the mutants on which the analysis is based. MuAspectJ is evaluated by benchmarking metrics that indicate the quality of generated mutants against the existing well known Java mutation tool, MuJava. The results validate the quality of the mutants generated by MuAspectJ.

Large models for complex systems can be decomposed in separate pieces corresponding to different perspectives on the system. This decomposition allows the modeller to check properties locally on some aspects of the system before considering the global complexity of the model. In this paper we consider two types of decomposition: according to the concerns identified in the requirements and according to structural and behavioural perspectives. Once the separate models are available and have been checked separately, they have to be composed to check global properties. In this work, we propose automatic composition operators for symmetric and asymmetric concern models, each concern being modelled from a structural and behavioural point of view.

This report summarizes the presentations and discussions of the Third Workshop on Models and Aspects Handling Crosscutting Concerns in MDSD, held in conjunction with the 21st European Conference on Object-Oriented Programming (ECOOP) in Berlin, Germany on July, 31, 2007. This workshop was motivated by the fact that both Model-Driven Software Development (MDSD) and Aspect-Oriented Software Development (AOSD) are important new paradigms that both promise to change the way software is developed. Both approaches provide opportunities for concern separation. AOSD separates concerns horizontally and MDSD enables concern separation vertically. This workshop identified two key integration strategies to achieve the complementary benefits of both aspect-oriented and model-driven development. The first is the use of aspects within transformation languages to separate transformational concerns making model transformations easier to write. The second is the separation of concerns within models defined as aspects. This workshop established the key benefits of these. The major benefit of the first is easing the complexity of development and maintainability of transformations. The major benefit of the second is means to reduce the problems associated with aspects, such as, aspect interactions, fragile pointcuts and understandability.

Although Aspect-Oriented Software Development (AOSD) has been a topic of research for more than ten years, there is still little empirical proof of its actual benefits. In particular, few empirical studies have been conducted to illustrate the value of aspect orientation in the earlier phases of the software life-cycle. To move towards filling this gap in the current state-of-the-art, we focus on the empirical validation of aspect orientation during the design phases of software development. This paper describes an experiment we conducted to quantify the maintainability of aspect-oriented design. In this experiment an aspect-oriented and a componentbased design approach were adopted by two strictly separated teams, starting from the same set of requirements for a real-world digital publishing system. By applying wellestablished metrics on these designs we attempt to evaluate how they differ with respect to maintainability.

This report summarizes the presentations and discussions of the ThirdWorkshop on Models and Aspects Handling Crosscutting Concerns in MDSD, held in conjunction with the 21st European Conference on Object-Oriented Programming (ECOOP) in Berlin, Germany on July, 31, 2007. This workshop was motivated by the fact that both Model-Driven Software Development (MDSD) and Aspect-Oriented Software Development (AOSD) are important new paradigms that both promise to change the way software is developed. Both approaches provide opportunities for concern separation. AOSD separates concerns horizontally and MDSD enables concern separation vertically. This workshop identified two key integration strategies to achieve the complementary benefits of both aspect-oriented and model-driven development. The first is the use of aspects within transformation languages to separate transformational concerns making model transformations easier to write. The second is the separation of concerns within models defined as aspects. This workshop established the key benefits of these. The major benefit of the first is easing the complexity of development and maintainability of transformations. The major benefit of the second is means to reduce the problems associated with aspects, such as, aspect interactions, fragile pointcuts and understandability.

At different stages of the aspect development lifecycle, there are different properties of aspects that need to be considered. Currently, there is no integrated approach to defining the appropriate characteristics of aspects at the appropriate stage, or of tracing decisions made for evolution purposes. Our focus is on the early aspects stages of development -- requirements analysis, architecture design, and detailed design -- where there are already many different approaches that provide useful constructs and mechanisms to capture the different properties of aspects that are in play at the relevant stage. However, it is difficult to move between stages using different approaches. In this paper, we describe an aspect mapping from requirements to architecture to design: in particular, Theme/Doc (requirements), CAM (architecture) and Theme/UML (design). The mapping includes heuristics to guide as to the right time to specify the right aspect properties. In addition, it allows aspect decisions captured at each stage to be refined at later stages as appropriate. While this provides an integrated approach for aspect specification, it is not enough to facilitate the traceability of aspect decisions. To this end, we also describe a means to record decisions that capture the alternatives considered and the decision justification. This information is crucial for managing aspect evolution at the right time.

In Model-Driven Software Development (MDSD), models represent views of software at different levels of abstraction and transformations specify refinements from one level of abstraction to another. Aspect Oriented Modelling (AOM) complements MDSD by extending the decomposition capabilities with separation of concerns at the same level of abstraction. Using transformations in software development has many benefits, but when an error is introduced into a model, it is propagated to later refinements. Such propagation makes it harder to trace errors to their source and consequently more difficult to correct. Concern models reduce the scope for error propagation as errors are localised. However, to ensure that errors are not propagated between concern models at different levels of abstraction, a technique for detecting errors in concern models is required. In this paper we present KerTheme, an approach to supporting error detection in AO models through testing. In KerTheme, testing is supported by defining two views of a concern: an executable model and a model of its expected behaviour. The testing process consists of checking the consistency between a trace from executing the concern model and the expected behaviour of the concern.

Design validation is important for detecting errors early in the development life cycle. Testing the design is one significant means to achieve design validation. In this paper we present initial work to make Theme/UML models executable and therefore testable.

A significant challenge of software engineering is dealing with change. Traceability is a key issue when designing and maintaining large systems that are prone to change. Although AOSD is gaining maturity, variances in how AOSD concepts are realized still exist. This means that traceability for AOSD is problematic. In this paper we fo- cus on providing traceability support from AO Architecture Design (AOAD) to AO design (AOD). To concretely illus- trate traceability, we focus on particular scenarios and cen- tre on two specific approaches - DAOP-ADL for AOAD and Theme/UML for AOD.

Aspect oriented design (AOD) research is fragmented. Barriers to AOD adoption are, in part, due to this fragmentation. Individually, many approaches provide elegant solutions to subsets of particular key issues related to AOD. Collectively, a significant set of these issues are addressed. We propose integrating existing AOD approaches through a generic AOD process. It is our intuition that such integration will consistently address the issues relevant to AOD.

XP is a lightweight process that provides principles for guiding projects and relies on the participants for its success. However, despite these guidelines, projects can be unsuccessful. We have previously identified that participants' levels of "buy-in" into the ethos of the methodology is a significant determinant of project success. This paper investigates how team formation influences buy-in and how buy-in, in turn, effects success, learning and working attitude within an academic environment. The empirical study shows that teams comprised of people with similar understandings of, and attitudes towards, the process tend to have a higher level of buy-in and, as a result, exceed their expected performance potential.

Design validation is important for detecting errors early in the development life cycle. Testing the design is one significant means to achieve design validation. In this paper we introduce the KerTheme model. KerTheme provides a means for symmetrically decomposing concern based executable class diagrams and concern test scenarios. KerTheme also facilitates synchronised merging of these decomposed models into a coherent composite concern based executable class model and corresponding test scenarios. The KerTheme model allows us to investigate whether decomposed concern based executable class diagrams simplifies the definition of concern test scenarios. This will also allow us to investigate whether this approach ensures more rigorous testing of a complete system.

Design validation is important for detecting errors early in the development life cycle. Testing the design is one significant means to achieve design validation. In this paper we introduce the KerTheme model. KerTheme provides a means symmetrically decomposing concern based executable class diagrams and concern test scenarios. KerTheme also facilitates simultaneous merging of these decomposed models into a coherent composite concern based executable class model and corresponding test scenarios. The KerTheme model allows us to investigate weather decomposed concern based executable class diagrams simplifies the definition of concern test scenarios. This will also allow us to investigate weather this approach ensures more rigorous testing of a complete system.

Aspect-oriented design (AOD) is an active field of research, reflecting the stage of (im)maturity of the aspect-oriented paradigm in general. A number of different approaches to AOD have emerged that have strengths in different areas. For example, Theme/UML provides a means for symmetric decomposition and composition of concern designs, and defines a composition relationship through which the designer can specify how separated design models can be composed. Join point designation diagrams (JPDDs) provide extensive support for constraining join point selection. In this paper, we explore integrating Theme/UML and JPDDs and in so doing, improving join point selection specification for the Theme/UML designer. The integration is described by means of a number of scenarios.

Aspect-Oriented Programming (AOP) addresses limitations in the Object-Oriented (OO) paradigm relating to modularisation of crosscutting behaviour. In AOP, crosscutting behaviour is expressed as aspects that are integrated with a base program through a weaving process. Many language-specific AOP models already exist, requiring the programmer to work with a single language for base and aspect programs. The NET framework, with its multi-language standards and architecture, has presented a new opportunity for cross-language AOP within NET. Advances have been made to take advantage of this opportunity, but at the expense of qualities such as the ability to debug executing code, or define some kinds of weaving capabilities. This paper describes an investigation into providing cross-language AOP in NET without making such compromises. The approach, called SourceWeave.NET, allows debugging because it weaves source code, and also provides an extensive weaving model. We describe what can be learned from SourceWeave.NET, in terms of both its benefits, and also its limitations.

Agile processes such as XP (extreme programming) have been recognised for their potential benefits of improving software. During adoption of the XP process, teams can misapply the XP principles by following them verbatim, ignoring the context in which they are applied. In this paper we document our experiences where naive applications of XP principles were altered in recognition of context. We detail our observations of how teams "looked behind" the rules and began fitting XP to the problem rather than attempting to fit the problem to XP. We conclude by reflectively focusing on how this transformation occurred and suggest that it is buying into the XP ethos that drives this change of perspective on the XP process and principles.

Merging is a common way to compose both crosscutting and non- crosscutting models. In this paper, we argue that merge can be defined more generically as an operator at the meta-modelling level. By describing merge at this level, a merge operator can be used to compose models based on meta-models other than UML. There are various merge variants and we concede that a full unification of all merge semantics may be infeasible. To define a common merge, we propose the definition of a common merge kernel as a semantic base that can be extended to realise the different expressions of merge.