Unifying Abstractions and Code with Concern Maps

Patrick Cooney Bachelor of Arts (Journalism) QUT 1998 Graduate Diploma in Information Technology QUT 2001

Submitted to the School of Software Engineering and Data Communications in partial fulfilment of the requirements for the degree of Master of Information Technology at the

QUEENSLAND UNIVERSITY OF TECHNOLOGY

July 2006

The author hereby grants to QUT permission to reproduce and to distribute copies of this thesis document in whole or in part.

i Keywords Separation of Concerns and Feature Interaction, Software Engineering Tools and Environments, Software Evolution and Change Management, Software Architectures and Design.

Statement of Original Authorship

The work contained in this thesis has not been previously submitted for a degree or diploma at any other higher education institution. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made.

Signature:

Date: 6/8/2006

ii Unifying Abstractions and Code with Concern Maps by Patrick Cooney Abstract People trying to understand, develop and maintain software have faced greater challenges as the complexity of software systems has increased. These challenges include the difficulty of cleanly separating different intertwined parts of a system, or relating parts of the system spread across many modules. This makes it difficult to neatly identify an area of interest, which in turn makes it difficult to understand or edit that area. The ability to separate these areas of interest, called concerns, into their own modules has been shown to improve the situation.

Several approaches have been developed to enable this separation: aspect-oriented programming allows program code to be divided into smaller modules that better match areas of interest; reverse engineering tools help programmers extract information from an existing system; requirements traceability tools track individual requirements through the development process. This thesis describes a technique that works in a wide variety of circumstances.

This technique allows users to create simple diagrams that describe the concern and then annotate this diagram with query expressions which link the diagram to related development artefacts like source code or documents. This research has used the tool in a set of common scenarios and compared the results to those achieved using other approaches.

iii List of Figures Figure 1 Simple Concern Map...... 31 Figure 2 MVC Concern Map ...... 34 Figure 3 Customer Order Entity Concern Map...... 38 Figure 4 Populated Concern Map ...... 38 Figure 5 Artefact listing for Customer...... 40 Figure 6 Open Concern Map file ...... 41 Figure 7 Concern Map toolbox...... 42 Figure 8 Results window ...... 43 Figure 9 Collapsed Concept Node ...... 43 Figure 10 Partial Health Watcher class diagram...... 53 Figure 11 Persistence concerns...... 55 Figure 12 Core persistence concern...... 56 Figure 13 Mechanism Control & Variation concern ...... 57 Figure 14 Transaction concern...... 58 Figure 15 Persisting data concern...... 60 Figure 16 Data Collection Variation Point concern...... 61 Figure 17 Order, product and customer concerns...... 65 Figure 18 Observer Concern Map...... 71 Figure 19 UML Package diagram...... 74 Figure 20 UML Deployment diagram ...... 75 Figure 21 Models and Implementation Concern Map ...... 76 Figure 22 Layers Concern Map ...... 77 Figure 23 Hierarchy of artefacts ...... 80 Figure 24 Core Cost Algorithm Concern...... 82 Figure 25 Discounts concern ...... 84 Figure 26 Equality and Addition Concerns ...... 87

iv List of Tables Table 1 Separation of concerns scenarios...... 5 Table 2 Examples scenarios...... 6 Table 3 Areas of crosscutting ...... 11 Table 4 Shortcut Selector types ...... 37 Table 5 Major components ...... 45 Table 6 Summary of Concern Maps...... 54 Table 7 Selectors for persistence Concern Map ...... 55 Table 8 Selectors for core persistence Concern Map ...... 56 Table 9 Selectors for mechanism control & variation Concern Map ...... 57 Table 10 Selectors for transaction Concern Map ...... 59 Table 11 Selectors for persisting data Concern Map...... 60 Table 12 Selectors for data collection variation Concern Map ...... 61 Table 13 Selectors for order, product and customer Concern Map...... 67 Table 14 Selectors for observer Concern Map ...... 72 Table 15 Selectors for models and implementation Concern Map...... 76 Table 16 Selectors for layers Concern Map ...... 77 Table 17 Selectors for cost algorithm Concern Map...... 83 Table 18 Selectors for discounts Concern Map...... 84 Table 19 Selectors for equality and addition Concern Map ...... 88

v Contents Chapter 1. Overview of Thesis and Research...... 1 1.1. Problem Definition...... 1 1.2. Overview of the Project ...... 3 1.2.1. Aims of the Research...... 3 1.2.2. Methodology...... 5 1.2.3. Summary of findings...... 7 1.3. Overview of Chapters ...... 7 Chapter 2. Related Research...... 9 2.1. Introduction to Related Research...... 9 2.2. Separation of Concerns...... 11 2.3. Crosscutting in Source Code...... 12 2.3.1. Code tangling and scattering...... 12 2.3.2. Design Patterns ...... 13 2.3.3. Code and Tests...... 14 2.4. Crosscutting Concerns beyond Source Code...... 14 2.4.1. A Broader Perspective ...... 14 2.4.2. Software Design...... 15 2.4.3. System Requirements...... 16 2.5. Managing Crosscutting ...... 17 2.5.1. Overview...... 17 2.5.2. Aspect-Oriented Programming ...... 17 2.5.3. Refactoring Browsers...... 20 2.5.4. Views and Separation of Concerns...... 21 2.5.5. Reverse Engineering ...... 22 2.5.6. Model-Driven Development ...... 23 2.5.7. Requirements Traceability...... 25 2.6. Comparing the Approaches...... 26 Chapter 3. Concern Maps ...... 29 3.1. Influences and Goals...... 29 3.2. A Quick Tour of Concern Maps ...... 31 3.3. The Concern Map Language in Detail...... 32 3.3.1. Visual Language ...... 32

vi 3.3.2. Selector Languages...... 34 3.4. Using Concern Maps – Create, Populate and Navigate...... 38 3.5. The Concern Map Tool...... 41 3.5.1. Loading a Concern Map ...... 41 3.5.2. Adding a Concept Node...... 42 3.5.3. Adding a Relationship ...... 42 3.5.4. Deleting a Concept Node, Relationship or Selector ...... 42 3.5.5. Adding or editing a Selector...... 42 3.5.6. Navigating...... 43 3.5.7. Changing the display ...... 43 3.6. Architecture and Implementation ...... 44 3.6.1. Overview...... 44 3.6.2. Major Components ...... 44 3.6.3. Designer and Domain Model...... 45 3.6.4. Editors and Output Handlers ...... 46 3.6.5. Controller...... 46 3.6.6. Selector Languages...... 46 3.7. Extensibility...... 46 3.8. Comparison to View-based Approaches ...... 47 Chapter 4. Applying Concern Maps ...... 50 4.1. Research Methodology...... 50 4.2. Scenario 1 – Crosscutting Concerns in Source Code ...... 52 4.2.1. Scenario overview ...... 52 4.2.2. Example ...... 52 4.2.3. Applying Concern Maps...... 54 4.2.4. Other Approaches ...... 61 4.2.5. Evaluation and Comparison...... 62 4.3. Scenario 2 – Feature De-Localisation...... 63 4.3.1. Scenario overview ...... 63 4.3.2. Example ...... 63 4.3.3. Applying Concern Maps...... 64 4.3.4. Other Approaches ...... 67 4.3.5. Evaluation and Comparison...... 68 4.4. Scenario 3 – Design Pattern Implementation ...... 69

vii 4.4.1. Scenario overview...... 69 4.4.2. Example ...... 69 4.4.3. Applying Concern Maps...... 70 4.4.4. Other Approaches ...... 72 4.4.5. Evaluation and Comparison...... 73 4.5. Scenario 4 – Architecture and Code ...... 73 4.5.1. Scenario Overview...... 73 4.5.2. Example ...... 74 4.5.3. Applying Concern Maps...... 75 4.5.4. Other Approaches ...... 78 4.5.5. Evaluation and Comparison...... 78 4.6. Scenario 5 – Documents and Code ...... 78 4.6.1. Scenario overview...... 78 4.6.2. Example ...... 79 4.6.3. Applying Concern Maps...... 81 4.6.4. Other Approaches ...... 85 4.6.5. Evaluation and Comparison...... 85 4.7. Scenario 6 – Tests and Code...... 85 4.7.1. Scenario overview...... 85 4.7.2. Example ...... 86 4.7.3. Applying Concern Maps...... 87 4.7.4. Other Approaches ...... 88 4.7.5. Evaluation and Comparison...... 89 4.8. Evaluation of Concern Maps ...... 90 4.8.1. Assessment of Goals...... 90 4.8.2. Comparison to Other Tools...... 92 Chapter 5. Conclusions and Further Work ...... 95 5.1.1. Conclusions...... 95 5.1.2. Further Work...... 95 Appendix 1 – Project Source Code...... 105

viii

Chapter 1. Overview of Thesis and Research

This chapter introduces the concept of separation of concerns and this research. Section 1.1 introduces the idea of separating concerns. Section 1.2 explains the approach taken by this project. Section 1.3 outlines the content of following chapters.

1.1. Problem Definition

A concern is a distinct concept within a software system that someone must consider separately during the lifetime of the system. To illustrate the breadth of concerns in software, consider the property of fault tolerance in a large-scale distributed system; order-processing rules in an e-commerce system; synchronisation in a multi-threaded program; error handling and logging; a user-interface; the MVC pattern. Different people will want to understand and alter these concerns at various times.

However, the increasing complexity of software decreases our ability to effectively understand and alter concerns. The way software is built makes some concerns difficult to consider separately. Concerns can be spread across several different classes or modules of source code. Consider the example of error handling: In modern object- oriented systems this functionality involves catch blocks and code within those catch blocks, spread over many classes. This spreading out of functionality makes understanding and changing the error handling code tedious at best.

Concerns might even span more than one programming language. Consider the case of order processing logic in a web e-commerce system. In this system some logic would be included in a HTML user interface. They would be duplicated in software components implemented in a language like Java or C++. There would be another overlapping set of rules within the database and SQL stored procedures. A concern could also span multiple documents. In the case of a user interface the concern would be made up of requirements documentation, a design in a language like UML, and implementation in

1 source code. These documents are often created by different people and use different formalisms. This is a problem when people need to understand or change concerns because the concerns are not neatly contained in any single document, diagram or class.

The separation of concerns is seen as the key to solving this problem. Separating a concern means somehow slicing the concern away from unrelated material, making it a standalone element of a system. There are two broad approaches to separating concerns:

• De-compositional, where source code or documents are developed as small parts to each match a particular concern. These are then re- combined using composition specifications to form final programs or documents. • View based, where source code and documents are not altered to reflect a concern, but programs extract information from them to produce graphical or textual views of the concern.

Aspect-oriented programming takes a de-compositional approach to separating concerns in source code. Aspect-oriented languages allow systems to be developed using classes as well as small modules called aspects. These aspects are composed along with classes during program compilation. The view based approach encompasses model-driven development, reverse engineering, requirements traceability and code visualisation tools. These approaches use whatever documents are involved in the concern and attempt to extract information from them to create some view of the concern for the user. This view might be a diagram, a list of related elements or a graphical highlight applied to a section of source code.

A number of tradeoffs are evident in the choice of de-compositional or view-based approaches. De-compositional approaches make it easy to change a concern, but also increase the disruption felt by the user in adopting the approach. They help users to change concerns by centralising them in one module. Changes to this module can take effect in many places in the final composed program. In this situation the disruption to

2 the user is increased because the user has to start creating source code or documents in some new way.

View-based approaches minimise user disruption, but are less effective when changing a concern. They minimise disruption because they use artefacts in their existing formats, or with very small changes. This means views can be created 'on top of' the existing work. However, users often still need to deal with many different artefacts if they want to change a concern. This means that views can help to separate a concern for the purpose of comprehension, but are less useful for changing a concern.

The various de-compositional and view based approaches focus on separating one particular type of concern, or concerns in one type of artefact. Aspect-oriented programming deals with concerns in source code. Requirements traceability tools separate requirements concerns, dealing with many types of artefacts. Reverse engineering tools enable standard views of systems like component connector graphs or data structures. They are narrowly focussed and tend to address a particular type of concern very effectively.

1.2. Overview of the Project

1.2.1. Aims of the Research

This research aims to develop a separation of concerns tool that is broadly applicable and easy to adopt. To achieve this, the tool should meet the following goals:

Go beyond source code, support many languages and documents Concerns in many large applications are not confined to any one programming language, and span different project stages and artefacts. To effectively separate concerns the tool must be able to include information from source code in different programming languages as well as information from other documents.

3 Reflect the structure of concerns A concern can comprise several parts. This is demonstrated by the different roles that make up a design pattern. Within an MVC pattern implementation there are three interacting roles: the model, view and controller. The tool must be able to capture and represent these parts of a concern as well as the artefacts related to them.

Produce development artefacts that describe a concern A description of a concern should be a development artefact, just like any other document, so that a concern description can refer to another concern description.

Complement existing techniques Proven techniques like object-oriented programming, UML and test-driven development are established parts of the development process. The tool must complement rather than disrupt these existing techniques.

Support non-invasive modularisation The tool must not force artefacts to be re-modularised. In other words, concerns must be able to be viewed as if separated, but actually remain in place within documents and source code.

Integrate with existing developer tools The tool must work seamlessly with an existing integrated development environment. This encourages use of the tool by keeping it within easy reach during the development process.

Extensible implementation This research should produce a working implementation. To encourage ongoing development of the tool this implementation should be extensible. This extensibility would allow different types of concerns and strategies to be tried in future work.

4 1.2.2. Methodology

Six scenarios were drawn from related research to represent typical situations where separating concerns is difficult. These six scenarios are summarised in the following table.

Scenario Description Crosscutting source code A single module, e.g. class or method, contains several different intertwined concerns. Feature de-localisation A single concern is spread across several modules. Design pattern A design pattern, which can be considered a implementation concern, is implemented in combination with an object-oriented domain model. Architecture and code A concern is related to architectural designs and source code. Documents and code A concern is made up of documents, like requirements or test plans, as well as source code. Tests and code A concern is made up of source code that implements the functionality and automated tests for that functionality.

Table 1 Separation of concerns scenarios

A set of requirements for the separation of concerns tool were then created based on these scenarios and the previously stated aims. The separation of concerns tool, christened Concern Maps, was then designed and implemented. The tool was built to extend the Visual Studio 2005 Integrated Development Environment [1] using the Microsoft Domain Specific Language Tools [2].

5 The six scenarios were then used to assess the capabilities of the separation of concerns tool. An example situation exhibiting the particular separation of concerns challenge was developed to assess each scenario.

Scenario Example Crosscutting source code A health care system containing crosscutting data access concerns. Feature de-localisation An order management web application, with logic to do with order, product and customer entities spread across web pages, components and stored procedures. Design pattern The observer pattern implemented across basic implementation geometry classes. Architecture and code A three-layer architecture documented by a UML model and implemented in C#. The layering concern crosscuts the UML and implementation. Documents and code A set of system specifications, a test plan and system implementation for an order management system. The example uses the order pricing concern that crosscuts all these artefacts. Tests and code A class representing money, with features to add and compare monies. These features are tested by automated unit tests in a separate file.

Table 2 Examples scenarios

The Concern Map tool was then applied in the example situation. The effectiveness of the tool was assessed based on the separation of concerns achieved in each example. In each scenario the results achieved with the Concern Map tool are compared to other research projects. These research projects either directly address the example scenario in

6 published work, or have been used in similar examples. This allows the results to be easily compared.

1.2.3. Summary of findings

• The Concern Map tool improves the separation of concerns when dealing with crosscutting concerns, feature delocalisation, pattern implementation, architectural concerns, requirements and automated tests.

• The tool allows non-invasive separation of concerns, supporting existing practices like test-driven development and object-orientation.

• Concern Maps can be used to separate concerns spread across several source code languages, and can also be applied to concerns in requirements, design documents and other types of non-code documents.

• The limitations of the query languages and poor integration with external programs reduce the effectiveness of the Concern Map tool when dealing with artefacts like word processing documents and spreadsheets.

• The extensibility of the tool could be used to address this shortcoming by adding new query languages.

1.3. Overview of Chapters

This chapter has provided an overview of the separation of concerns problem, and described the direction of this research and research methodology. Chapter two discusses related research, first into the separation of concerns problem and then into solutions to this problem. It then compares and analyses the various solutions. Chapter three describes the solution proposed by this research, called Concern Maps. This begins with a discussion of influences and trends in other separation of concerns solutions, and then discusses the details of the Concern Map technique. Chapter four

7 presents the findings of this research, comparing Concern Maps and other solutions in the six different scenarios. A summary and discussion of future research directions is presented in chapter five.

Chapter 2. Related Research

This chapter discusses the problems caused by poor separation of concerns and techniques and tools for improving separation of concerns. Section 2.1 introduces existing research by summarising the problem areas and solutions. Section 2.2 explains the term concern. Section 2.3 discusses research into crosscutting concerns in program source code, covering concern scattering and tangling, design patterns, test-driven development and feature de-localisation. Section 2.4 discussed concerns that go beyond source code, specifically concerns within the design and specification of software.

Section 2.5 explores different approaches to improving separation of concerns. This covers techniques like aspect-oriented programming, view-based tools, reverse engineering programs, model-driven development and traceability tools. Section 2.6 compares these different approaches.

2.1. Introduction to Related Research

The "divide and conquer" approach to problem solving allows people to build complex software systems. This approach is evident in two different decompositions. Firstly, the division of the development process into distinct activities like design, coding and testing. Secondly, the division of systems into separate software modules.

The de-composition of software code into modules is fundamental to software development. Benefits seen by Parnas [3] include manageability, flexibility and comprehensibility. The organisation of software development into a process also produces specialised activities, like project planning, requirements gathering, design and development. These in turn make specialised artefacts like test plans, requirements documents, design models and source code.

This specialisation produces the following benefits:

9 • A project or system can be de-composed into smaller items of work • Items of work can be completed by people with specialised skills • Items of work can be monitored separately

This decomposition optimises the ability of people to focus on one part of a problem at once. As noted by Parnas [3], one modularisation of source code will optimise one part of a system, usually de-optimising another. This tension is played out in the organisation of software into modules, projects into phases, and information into documents. It is useful to consider this trade-off using the idea of a concern, defined as some part of a system relevant to a particular goal, purpose or concept [4]. By dividing the software development process into stages (for example requirements, then design, then development, then implementation), the process optimises concerns like "the requirements" and "the design" over other concerns made up of slices of related work, like "bank account withdrawal".

It is also interesting to consider the things that are optimised by the de-composition of software into modules. Classes, components and services all optimise a few particular concerns. Classes optimise the unification of data and related functionality. Components optimise the encapsulation of cohesive functionality. Services optimise the encapsulation and management of functionality through a coarse-grained distributed interface. This section examines the concerns that are de-optimised by process and software design so that they are not neatly modularised. These are called crosscutting concerns. The following table summarises these areas of crosscutting concern, the specific problems within these areas, and the related tools and methods for separating the crosscutting concern.

Effected Area Problems Caused Tools and Methods Within source code Code tangling Aspect orientation Code scattering Code visualisation Design patterns Model-driven development Relating code and tests Between design and Disconnected models Model-driven development

10 source code Reverse-engineering models Requirements and code Traceability between Traceability tools and design stages

Table 3 Areas of crosscutting

This chapter reviews research into the areas where crosscutting concerns occur, first defining the concept of a concern, then looking at the problems caused by crosscutting concerns, and finally exploring and comparing different approaches for addressing these problems.

2.2. Separation of Concerns

A concern is a distinct concept within a software system that someone must consider separately during the lifetime of the system. Ossher and Tarr [4] suggest that different people need to consider different concerns, and these concerns vary over the course of the software development process. Some example concerns are software features [5], design patterns [6, 7], high-level architectural rules [8], the non-functional parts of software like persistence and distribution [9, 10], and variation points used to customise an application [11]. Separation of concerns involves isolating these concerns in dedicated modules. Lopes and Hursch [12], Kiczales [13], Tarr, Ossher, Harrison and Sutton [14] all explain the benefits associated with separating concerns. These can be summarised as:

Separate concerns are easier to understand – Putting all the information about a concern in one place makes it easier for someone to understand that concern.

Separate concerns are easier to change – A well modularised concern will contain less duplicate information than one spread across several modules. This makes it easier to change the concern, as only one module needs to be altered.

Separate concerns are easier to reuse – Concerns that are cleanly isolated are easier to use in different contexts because they do not contain any extra elements that might not be helpful in that new context.

These benefits are only realised when concerns are separated. Concerns that are poorly separated are more difficult to understand, change and reuse.

2.3. Crosscutting in Source Code

2.3.1. Code tangling and scattering

Lopes and Hursch [12] note that increasing complexity of software applications means that software developers must deal with concerns like concurrency, distribution and persistence in addition to the fundamental algorithm of a program. Combining these concerns in one module leads to intertwined code which is hard to understand, maintain and modify. While these concerns are distinct concepts, they are not separate in source code. Examples of this include a call-timing concern in an object-oriented telecommunications application [15], transactions in a banking application [16], and loops processing data in an image filtering application [17, 18].

Kiczales, Lamping, Mendhekar, Maeda, Lopes, Loingtier and Irwin [17] call this problem tangling, and trace it to the fundamental decomposition of procedural and object-oriented software by function. Tarr, Ossher, Harrison and Sutton [14] call this problem the "tyranny of the dominant decomposition". They note two distinct variations of the problem. The first variation is called scattering, where a single requirement affects many design and code modules. The second variation is called tangling, where material related to more than one requirement is intertwined in a single module. They note the problems caused by tangling and scattering when trying to update source code. Particularly, that the comprehensibility of source code reduces over time, and that changes to existing software are often widespread and invasive to existing modules. This is because the units of change are not the same as the units of abstraction.

Greenfield and Short [19] discuss a similar problem to the scattering seen by Tarr, Ossher, Harrison and Sutton [14], calling the problem feature de-localisation. They specifically draw attention to the potential for different languages to be used within the

12 implementation of a single system. They provide an example architecture made up of a web server page, distributed component and database to illustrate the problem. Within this architecture functionality related to one analysis class is implemented across all three components. This causes the same problems understanding and maintaining systems as found in code tangling. The fact that several languages are involved makes separating a concern more complicated.

2.3.2. Design Patterns

Design patterns have been proposed as a way of re-using effective approaches to software design, popularised by Gamma, Helm, Johnson and Vlissides [20]. Hanneman and Kiczales [7] suggest that a number of the classic design patterns in [20] produce crosscutting structures between roles within a pattern. They propose some code tangling problems caused by patterns. Firstly, the pattern can disappear into the code, making it difficult to tell the pattern implementation from the object model it is applied to. Secondly, it can be difficult to document systems where multiple patterns are overlayed. Lastly, the composition of classes becomes difficult when large clusters of dependent classes form because of patterns.

Hachani and Bardou [6] find four problems in design pattern implementation: Confusion in finding out what is and is not part of a pattern implementation; Indirection in patterns making them more difficult to understand; Encapsulation breaches in explicit delegation scenarios; Inheritance problems, when multiple implementation inheritance is required to re-use a pattern effectively. Hirschfeld, Lammel and Wagner [21] also note the performance issues caused by layers of indirection in design pattern implementations.

Hannemann and Kiczales [7] discuss 23 design patterns from [20] in their assessment of design pattern re-modularisation, finding separation of concerns problems when implementing these patterns in 17 of the 23 cases. Other discussions of pattern-induced crosscutting involve the Visitor [6, 14, 22], Observer [22] and Strategy [23] patterns.

13 2.3.3. Code and Tests

Beck and Gamma [24] describe the use of automated unit tests during development, whereby programmers iteratively write code and then tests for that code. Martin [25] refines this approach into what he calls Test-Driven Development. This approach involves first writing automated tests, then writing the code that will pass those tests. He suggests this approach makes the tests into documentation of the functionality. Tests also highlight when changes break existing functionality.

The jUnit [26] program has been developed to support this style of test-driven development with the Java language. Derivative programs have since been developed for other languages, including NUnit from Microsoft .Net [27], PyUnit for Python [28] and RubyUnit for Ruby [29].

Galli, Nierstrasz and Ducasse [30] describe some problems with clearly identifying concerns when using these test-driven development programs. They suggest that there is a lack of traceability between implementation and test code. They find that tests and implementation code are usually related through naming conventions, and that it is difficult to keep these names synchronised over time. They note that it is difficult to tell if a method has unit tests or to move easily to those tests from source code. This is an example of crosscutting, where a concern is spread between implementation and automated tests.

2.4. Crosscutting Concerns beyond Source Code

2.4.1. A Broader Perspective

Research covered so far has only looked at crosscutting within source code. However, concerns extend beyond source code into other products of software development. Crosscutting between design models, requirement documents and source code demonstrates that artefacts are optimised for particular process stages, and de-optimised at their interfaces so that concerns crosscut the various artefacts.

14 Tarr, Ossher, Harrison and Sutton [14] suggest reuse is limited by the combination of tangled concerns, coupling of features and weak adaptation and customisation capabilities, and occurs mostly with source code, rather than requirements or design. This is because large scale artefacts have a number of tangled design and implementation decisions, which makes them less reusable. They also find that different artefacts are created using different formalisms, so no clear correspondence exists. When developers manually create connections between artefacts, these connections are fragile, complex, and do not reduce the level of scattering or tangling.

Software architecture research discusses problems resulting from a disconnection between models and implementations. This is similar to the code scattering problem. It happens when information is scattered between the architecture documentation and its implementation in code. Research into the requirements process shows that a similar scattering problem occurs between requirements documentation and other artefacts.

2.4.2. Software Design

Shaw and Garlan [31] define software architecture as design at certain level, taking in concerns like the organisation of a system as a composition of components, global control structures, communication protocols and physical distribution. Bachmann, Bass, Carriere, Clements, Garlan, Ivers, Nord and Little [32] identify a number of characteristics of architecture – it is a blueprint for a system and the project that develops it, deals with concerns like modifiability, security and performance, is a vehicle for early analysis, and is a key to understanding systems once they have been developed. In this way, documenting the architecture is the crowning step in the architecture process. There are a number of standardised approaches to devising and communicating architecture, including the Unified Modelling Language [33], Zachman Framework [34] and the Reference Model for Open Distributed Processing [35].

Greenfield and Short [19] observe that these forms of architectural documentation tend to diverge quickly from the actual implementation. This happens because of the cost of keeping designs synchronised with source code. It is exacerbated by iterative

15 development practices that introduce new features frequently. They identify two problems stemming from this divergence. The traceability problem occurs when it is difficult to identify which parts of a solution implement a particular part of the solution's design. The reconstruction problem occurs when design information is lost and cannot easily be re-created. The traceability and reconstruction problems are symptoms of scattering, where related information about a concern is scattered across many different types of documents. This scattering means that concerns are poorly separated.

2.4.3. System Requirements

System requirements describe what a system should do. Gotel and Finkelstein [36] find that tracing these system requirements through the software lifecycle is difficult. Clarke, Harrison, Tarr and Ossher [37] say that scattering and tangling of information inhibits requirements traceability and make it difficult to work out the relationships between artefacts. They suggest that it is inevitable that artefacts from different paradigms will not easily match up.

Olsson and Grundy [38] suggest that developers don't have the right tools to manage the interrelationships between several evolving documents. Their study found that developers require high-level traceability and consistency management. This would help them understand the relationships and dependencies between artefacts. In the absence of these tools Hayes, Dekhtyar and Osborne [39] suggest that tracing requirements through artefacts is currently a mundane and person-intensive activity. Ramesh [40] also concludes that a class of IT worker, characterised as a low end user, does not have standardised processes and tools for traceability, and when they do conduct ad-hoc investigations these do not benefit their organisation because they are not shared. Examples of traceability problems cover use cases, test plans and requirements [38], and specifications, tests and implementation code [41].

16 2.5. Managing Crosscutting

2.5.1. Overview

A number of approaches have been developed to improve the separation of concerns in various situations. These approaches use two strategies, either de-composing or creating views of artefacts to match concerns. De-compositional approaches split the system into smaller artefacts that reflect an individual concern. The artefacts are re-combined to form the final program. This combination can be achieved during compilation, as in AspectJ [42], at runtime, as in ilaC# [43], or at design time using a virtual source file, as in Aspect-jEdit [44]. View-based approaches create virtual representations of concerns based on existing artefacts. This involves identifying parts of program text or documentation relevant to a concern and presenting these parts to the user.

Most of these approaches are highly focussed, either dealing with a single type of concern or concerns in a single type of artefact. Model-driven development is an exception, in that it deals with a wide range of concerns and different types of artefacts. The following sections explore these various approaches in more detail.

2.5.2. Aspect-Oriented Programming

This section discusses research into aspect-oriented programming (AOP). AOP describes an approach to managing and modularising crosscutting concerns in source code. Douence, Motelet and Sudholt [45] define AOP by the ability to identify and abstract points of interest within a program, and then add behaviour at these points through a framework. This is similar to Filman and Friedman [46] who characterise AOP by the ability to make quantified programmatic assertions over programs that are not aware of these assertions. This definition is close to the essential characteristics of AOP in Walker, Zdancewic and Ligatti [47]: firstly, a means of designating control- flow points in a program, and secondly, a way of manipulating behaviour at these points.

There are several different approaches to AOP, including combinations of new languages, compilers and interception frameworks. The AspectJ language [48] is an

17 extension to the Java language (see [49]) that aims to improve the separation of concerns in software by supporting modularisation of crosscutting concerns. AspectJ was motivated by crosscutting in code, such as [17, 18]. AspectJ is a general-purpose aspect language. It is upward-compatible with the Java type system, meaning all legal Java types are legal AspectJ types. AspectJ code executes on standard Java virtual machines. AspectJ extensions are available for the popular Java IDE Eclipse [42]. Lastly, AspectJ was designed to feel like a natural extension of the Java language. The language introduces four new programming constructs to manage crosscutting:

• Join point, a well defined point in a program's execution. • Pointcut, a collection of join points, and values at those join points. • Advice, a method-like construct for adding behaviour at join points. • Aspect, a composition of java code, advice and pointcuts.

Users define advice that specifies some behaviour, and then define a pointcut which associates that advice with a certain point in a program's execution. A special AspectJ compiler is then used to weave the advice into the program, generating a compiled Java program. A number of AspectJ-like languages have been developed for use with other programming languages. These include an implementation for Scheme [50], AspectS for Smalltalk [51], AspectC++ for C++ [52], AspectC# for C# [53] and AspectC for C [54].

A number of AOP systems have also been developed as variations of AspectJ. JMangler [55] has been developed to allow weaving of aspects at load time, rather than during compilation. This allows dynamically loaded classes to be included in the weaving process, as well as classes that are not available as source code. Rajan and Sullivan's ilaC# [43] allows aspects to be woven at runtime and associated on a per-object basis, rather than per-class as in AspectJ. Lafferty and Cahill's Weave.NET [56] supports load-time weaving of aspects into any .Net type. Weave.NET uses a very similar programming model to AspectJ, but has XML syntax for integrating aspects. Similarly,

18 JBoss AOP [57] and Spring AOP [58] use XML declarations to combine advice written in regular Java with the main program.

The theory of multi-dimensional separation of concerns (MDSOC) proposes that concerns in software are simultaneous, overlapping and multi-dimensional. Tarr, Ossher, Harrison and Sutton [14] suggest the ability to separate concerns is constrained by the mechanisms used to de-compose and then compose modules. In most formalisms this de-composition and composition is only enabled in a single dimension, for example functional decomposition in procedural programming. Ossher and Tarr's Hyper/J system [59] allows the parts of a program that make up a dimension of concern to be encapsulated in a hyperslice. These hyperslices can then be combined into a hypermodule using a set of composition rules. The Hyper/J system only allows units of Java code (package, class, interface and member) within hyperslices. Hyper/J uses a mixture of standard Java for defining functionality, and an entirely separate and new language with Java-like syntax for defining hyperslices and modules.

Mezini, Seiter and Lieberherr [60], Bergmans and Aksit [61], and Constantinides, Bader and Elrad [62] use message interception to separate concerns. This interception approach adds functionality to objects by intercepting messages between them and carrying out additional functions based on these intercepted messages. Constantinides, Bader and Elrad [62] note several problems with the extension of existing languages and use of weaving compilers exemplified by AspectJ. These can be reduced to a few key issues – the complexity of general-purpose aspect languages and weavers, problems ordering aspects, and problems understanding woven programs. They suggest an aspect implementation where a proxy object intercepts calls and re-directs them to an aspect moderator, responsible for creating aspect objects and invoking them. Mezini, Seiter and Lieberherr [60] use language extension as a standard way of applying an adapter pattern. Bergmans and Aksit [61] propose a declarative language for defining message filters that can manipulate messages to and from objects. The concept of interception is extended to distributed computing environments by Popovici, Alonso and Gross [63] who propose extending applications by making common functionality part of the

19 computing environment. This is used by the same authors in [64] as a way of supporting dynamic adaptation of functionality on mobile devices entering and leaving a network.

A number of domain specific aspect languages have been developed, although this approach is not as prominent. Domain-specific aspect languages using higher-level joinpoint models, rather than general-purpose aspect languages, are proposed by Lopes, Dourish, Lorenz and Lieberherr [65]. Lieberherr and Orleans [66] describe the Demeter / Java system that supports aspect-orientation for object traversals. This domain-specific aspect language approach allows traversals through object graphs to be abstracted away from the work that is done with those objects. The XAspects system [67] extends AspectJ to allow the use of domain-specific aspect languages. An early AspectJ implementation assessed in [68] used two domain-specific aspect language: Cool for expressing synchronisation concerns, and Ridl for expressing distributed programming concerns.

2.5.3. Refactoring Browsers

Refactoring browsers are tools that automate particular types of changes to software. Although they do not address the separation of concerns problem directly, they do make it easier to manage crosscutting concerns in source code. Opdyke [69] defines a refactoring as a program restructuring operation that does not change the behaviour of a program, performed at an intermediate level of detail somewhere between design and low level code. Fowler [70] describes the motivation and mechanics of 72 different patterns of change to source code. A simple example is Move Method, where a method is moved from one class to another to reduce coupling or reduce the responsibilities of a class. Roberts, Brant and Johnson [71] define three common properties of all refactorings:

1. They can be completely automated 2. They are provably correct 3. They can be composed to form more complex refactorings

20 Refactoring browsers are programs that automate these changes to source code. They allow automatic and widespread changes to source code in particular circumstances. Numerous refactoring browsers have been implemented, including the Refactoring Browser for Smalltalk [71, 72], ReSharper for C# [73], the IntelliJ integrated development environment [74], and Microsoft Visual Studio 2005 [1].

2.5.4. Views and Separation of Concerns

While aspect-oriented programming addresses the separation of concerns problem in source code, some authors [75, 76] have suggested the widespread adoption of AOP has been hampered by its immaturity and the complexities it introduces. They particularly note the complexity of understanding the effects of aspects on other source code. Systems that use views of source code have been developed to provide 'virtual aspects', somehow highlighting sections of tangled code that relate to a particular concern. This approach improves the separation of concerns and avoids some of the complexities of AOP. This approach has the advantage of not requiring new compilers, and not mandating new source files or design approaches. This non-invasive approach allows programmers to isolate and manage crosscutting concerns without using AOP tools like AspectJ.

The SOUL language and tools [77] are based on a logic meta-programming language which can be used to describe views of source code as described by Mens, Mens and Wermelinger [75] and Mens and Poll [78]. These views are virtual modules, based on some underlying system. Mens [79] proposes the use of intentional views to document concerns in software. These intentional views are described by rules, which are executable specifications that match classes, instance variables, methods and method statements. The intentional view approach is implemented by the Intentional View Browser. This browser is a plug-in for the StarBrowser Smalltalk environment. It uses logic expressions in the SOUL language to specify rules. Six usage patterns are proposed for this tool in [79]: Conceptual structuring, where hidden structures are made explicit through views; Verifying coding standards; Verifying test suite completeness; Checking design consistency; Detecting manually generated code among automatically

21 generated code; Software customisation views, which show functionality for a particular adaptation. The Software Views Inducer (SVI) [80] extends this approach, allowing programmers to manually create views by dragging and dropping software entities, which are then generalised into SOUL rules by the SVI. This allows programmers to create robust SOUL descriptions of views without learning the SOUL language.

The Feature Exploration and Analysis Tool (FEAT) [81] allows developers to iteratively edit and view a tree graph that describes a concern within the system. This graph is created using queries executed against source files, and provides a mapping from graph nodes to source code. The AspectBrowser tool [82, 83] uses a map metaphor to display aspects and related modules, with aspects highlighted using a particular colour designated by the user. Aspect-jEdit [44] allows users to name aspects within code and highlight them with a particular colour. These aspects do not need to be program statements, so can include comments. Users can then edit these aspects either as a standalone virtual module or within the context of surrounding source code. The tool also allows users to automatically move aspects inline or into dedicated AspectJ modules.

The Visual Separation of Concerns (VSC) system proposed by Chu-Carroll, Wright and Ying [76] is a view-based tool, but does change underlying artefacts. The VSC tool splits programs into smaller fragments which are stored in a source code repository. These fragments are retrieved and aggregated into virtual source files. The virtual source files can be created using a query language, and can be used to edit aspect code in isolation, or display it in the context of the complete program.

2.5.5. Reverse Engineering

The techniques of querying and visualisation adopted by the view-based tools are also found in reverse engineering systems. The RIGI system [84, 85] is a software tool that allows programmers to extract, navigate, analyse and document the structure of software systems . The system uses a semi-automatic discovery process, which captures the components (modules, procedures, or some other structure), dependencies between

22 components, and attributes (component types and other information) of a target software system. RIGI stores and displays this information in a graph structure.

This graph can be used to create views that hide and emphasise aspects of the system. Selection options allow users to display a subset of components, such as all components dependent on another component. This functionality is achieved through a graphical user interface which can be used to traverse the graph. The SHRimP system [86, 87] extends RIGI, employing a fish-eye view of system graphs.

GEVOL [88] helps programmers discover the structure of systems. GEVOL inspects source code repositories and produces a graphical representation of this source code. The graphical representation augments program structure with colours to indicate parts of a program that change frequently. The MANSART system [89] analyses program source code, and organises a representation of the system showing a component- connector graph, links to source code, and a link to a conceptual framework for the particular architectural style.

Walker, Murphy, Steinbok and Robillard [90] describe a visualisation tool that allows architecture-level views of trace information. This involved collecting fine-grained information during system execution, which is then mapped to a high-level visualisation. This visualisation uses rectangles to group related classes. These rectangles are linked by arrows that reflect method calls between groups. A query language allows users to query trace information to determine if a particular path was executed. The Hy+ system developed by Consens, Mendelzon and Ryman [91] enables visualisation and reverse engineering of data. Hy+ uses a directed graph, called a hypergraph, to display data structures, with queries to display data related to each node.

2.5.6. Model-Driven Development

The term model-driven development is used here to describe two related approaches: Model Driven Architecture (MDA) and Software Factories. These two approaches differ significantly in their implementation but share a common motivation: To raise the

23 level of abstraction through modelling languages and enable development through models by transformation from the higher-level models to lower-level models or code. This improves the separation of concerns by providing traceability between artefacts at different levels of abstraction, and by using several complementary languages to define different aspects of a system.

MDA is proposed as a solution to the gap between system design and implementation. This is achieved by generating the implementation from the model. The MDA standard [92] provides a framework for turning platform independent models to implementations in software. MDA is built on the complementary XML Metadata Interchange (XMI) and Meta Object Facility (MOF) standards. The XMI specification [93] aims to enable the easy sharing of metadata between modelling tools. The MOF specification [94] aims to provide an open-ended facility for defining meta-models. MDA can support a variety of modelling languages, but much attention has been given to the combination of MDA and UML [33].

Mellor, Scott, Uhl and Weise [95] suggest that the MDA approach will have numerous positive impacts on software development, including the ability to work at a higher level of abstraction, maintaining a degree of platform neutrality, increasing the level of software reuse, and better ascertaining how system will interoperate at design time. Bezivin [96] notes the potential for MDA to provide a separation of aspects within systems, with an example system made up of business, usage, resource, design, test, deployment, execution, exception and architecture models. A number of MDA tools have been developed, including ArcStyler [97], AndroMDA [98], OpenMDX [99] and OptimaJ [100].

Tools have also been developed that offer code generation capabilities based on higher- level models or templates. These tools do not realise the full extent of MDA, but provide advanced abstraction capabilities through higher level languages. Examples include IBM's Rational Rose [101], CodeSmith [102] and Fabrique [103]. Rational Rose allows users to develop classes using UML; CodeSmith provides a powerful templating

24 framework that can be applied to all sorts of programming tasks; Fabrique uses a set of domain specific languages for web application development.

Software Factories as explained in [19] extend the concept of a software product line from [104]. Software Factories specify a set of related assets like Domain Specific Languages, patterns, frameworks and guidance in a Software Factory Schema. This schema is then configured for use with a particular scenario, forming a Software Factory Template. The Software Factories approach does not use the UML, XMI or MOF standards. Greenfield and Short [19] contend there are several problems with the MDA approach: - Over-emphasis on platform independence, which necessarily reduces productivity, performance and usability - Use of UML, which lacks the semantic precision needed for development and has weak extensibility mechanisms - Purely model-driven, rather than a hybrid approach using DSLs and programming languages - Unanswered questions around what models to use, how to relate models, how models relate to source, patterns, frameworks, and architectural styles, how to reuse models, and the development process and lifecycle

2.5.7. Requirements Traceability

Requirements traceability tools support the identification and correlation of documents, source code, tests and other artefacts that relate to a single system requirement. Jackson [41] describes a simple key-phrase tagging and extraction that covers a hierarchy of specifications including test specifications, source code, and a test harness that implements the test specification.

Olsson and Grundy [38] present a more sophisticated system that extracts information from use-case models, test plans and requirements. This information is stored in a custom data store, and requirements are related using various relationships reflecting exact mappings, specialisation and generalisation. Lefering [105] takes a similar

25 approach in extracting data flow, entity-relationship and state-transition diagrams into a database and performing automatic consistency checking between them. In addition, the system semi-automatically generates system design documentation and Eiffel code based on this database. Ambriola and Gervasi [106] use a similar approach to extracting and then storing fragments of requirements in a semantic repository. These fragments are validated and then re-combined into views tailored to individual stakeholders.

Clarke, Harrison, Tarr and Ossher [37] propose subject-oriented design as an approach to separating feature concerns at the design level. Using the subject-oriented approach, a design subject specifies the design of a single concern, and different design subjects are related using integration specifications to form one final specification. Grünbacher [107] suggests that separation of requirements concerns is important not only to relate information from different stages, but also to provide stakeholder-specific views of requirements, particularly for software architects beginning design work.

2.6. Comparing the Approaches

Several authors have noted crosscutting in source code, between design and source code, and between documentation like requirements and source code. A number of approaches have been proposed to address this, including aspect-oriented programming, views of source code, model-driven development, and traceability tools. These approaches to separating concerns can be divided into de-compositional, where new modules are created to match concerns, and view based, where some virtual module is created to provide a view of the concern as situated in other artefacts.

The model-driven development vision of MDA and Software Factories as presented in [19, 95] is ambitious and compelling. However, model-driven development is seen as immature and lacking tool support from major vendors [108]. Traceability tools are mature but are not widely used: Gotel and Finkelstein [36] comment that the traceability problem is not well supported by existing tools because it is fundamentally complex, and tools must address a range of different uses. More recently, Hayes, Dekhtyar and Osborne [39] find that traceability is still a very labour-intensive process,

26 and that users of traceability tools must contend with a high amount of drudgery in tagging documents and then sifting through results.

Refactoring browsers are capable of dealing with simple changes to source code, but cannot automate changes to complex concerns. Aspect-oriented programming presents clear benefits managing the complex tangled concerns in studies like [7, 14, 18, 54]. Other studies [16, 109] have found some limitations to the aspect-oriented approach for some types of crosscutting concern. Kienzle and Guerraoui [16] found that while aspects could be applied to separate transaction control from other application code, this separation did not lessen the strong logical coupling between the two, and that guidelines and tool support was required to handle these tightly coupled aspects. DeWin, Joosen and Piessens [109] found that separating security concerns in an FTP problem resulted in seemingly random pointcuts, called “dirty pointcuts”, with a proliferation of subtly different aspects. Simonyi [110] notes that fine-grained decomposition removes complexity in one way by untangling code, but introduces new complexity in the way modules are recombined. This leads to the increased indirection in AOP systems noted in [76]. AOP implementations are limited to a single language, like Java in the case of AspectJ, and cannot deal with concerns scattered across a system using different languages like HTML, Java and T-SQL. However, the AOP approach is useful when only one language is involved.

Authors have noted several practical barriers to adoption of AOP: • Resistance to programming language changes [111] • Lack of integration with existing development tools and processes [111, 112] • Resistance to modified runtimes [111] • Lack of support for industrial scale build processes [111] • Lack of support for the full development cycle [111, 113] • Difficulty debugging code in many modules [68]

27 View-based approaches do not face these barriers, but do not deliver the modularisation benefits of AOP. These benefits are important when changing concerns, since the view only serves as a starting point for changes in multiple artefacts. As noted by Tarr, Ossher, Harrison and Sutton [14], providing traceability between parts of a concern does not localise changes to that concern. View systems cannot enable the reuse of aspects between applications in the same way as AOP. However, view solutions have a number of strengths in comparison to AOP: • Not intrusive to existing source code or languages [75] • Do not require a new style of programming [75, 83] • Can support arbitrary or overlapping views of source code not suited to AOP [44] • Require no new language constructs in source code [83] • Work with old systems without alteration [83]

Chapter 3. Concern Maps

This chapter introduces the tool developed during this research, called Concern Maps. Section 3.1 discusses ideas from related research that have influenced the direction of the project. It then establishes the goals of the Concern Map tool. Section 3.2 is a quick overview of Concern Maps, explaining the key concepts and demonstrating how the tool can be used to separate concerns. Section 3.3 explains the Concern Map languages in detail. It explains the graphical language along with other languages used to build maps. Section 3.4 describes the way Concern Maps are used, split into three activities: creation, population and navigation. Section 3.5 discusses the integration of the tools with the Visual Studio 2005 development environment. Section 3.6 covers the design and development of the Concern Map program in detail. Section 3.7 describes extending the tool to enable new types of documents and concerns. Section 3.8 compares the Concern Map tool to the most closely related view-based tools, highlighting the similarities and differences.

3.1. Influences and Goals

The following themes have emerged from reviewing related work and have influenced the direction taken by this research. Firstly, the various approaches tend to be narrowly focussed. They deal with a fixed set of concerns, like requirements in the case of traceability tools, or a fixed set of artefacts, like source code in the case of AOP tools. Secondly, the lower adoption barriers of view-based tools make them attractive, although they are less useful when concerns need to be changed. Lastly, most view- based tools do not offer visually rich descriptions of concerns, instead highlighting concerns inline. These themes suggest that a broadly applicable tool with low barriers to adoption and basic separation of concerns capabilities would be useful. It is important to note that such a broadly applicable tool cannot provide the same level of functionality as a narrowly focussed one. The generality of such a tool means it cannot be ideally suited to any particular concern. However, this drawback is balanced

29 by the benefits of users only having to install and learn one tool. Based on these influences, the following goals were developed for this research.

Go beyond source code, support many languages and documents Concerns in many large applications are not confined to any one programming language. They also span different project stages and artefacts. To effectively separate concerns the tool must be able to include information from source code in different programming languages as well as information from other documents. Concern Maps should be able to relate different parts of the concern to their realisation. This may be in word processing documents, source code files, or some other development artefact.

Reflect the structure of concerns There can be several parts to a concern. Within an MVC pattern implementation there are three interacting parts: the model, view and controller. The tool must be able to capture and represent the structure of a concern as well as the artefacts that it comprises. Concern Maps should be equally useful for describing different sorts of concerns, for example an architecture viewpoint, a low-level implementation concern or system requirement.

Produce development artefacts that describe a concern The description of a concern should be a development artefact, just like any other document. This allows a concern description to refer to another concern description.

Complement existing techniques Proven techniques like object-oriented programming, use cases and test-driven development are established parts of the development process. The tool must not disrupt these existing techniques.

Support non-invasive modularisation

30 To minimise the disruption to developers the tool must not force source code to be re- modularised. In other words, concerns must be able to be viewed as if separated, but actually remain in place within documents and source code.

Integrate with existing developer tools The tool must work seamlessly with an existing integrated development environment. This encourages the use of the tool by keeping it within easy reach during the development process. Particularly, Concern Maps should automate the relationship between the concern description and related artefacts, so users can easily jump from the Concern Map to the realisation.

Extensible implementation The research aims to produce a working implementation. To drive ongoing development of the tool, this implementation should be extensible, so different types of concerns and strategies can be tried in future work.

3.2. A Quick Tour of Concern Maps

The Concern Map tool was developed to meet these goals. It is an extension of the Visual Studio development environment that supports the separation of concerns using a simple visual language and a set of query languages that relate visual elements to development artefacts. This visual language is used to create simple diagrams of software development concerns called Concern Maps. They look like this:

Figure 1 Simple Concern Map

31 Shapes are used to represent parts of a concern. This Concern Map divides an application up into two groups, User Interface and Business Logic, represented by the rectangular shapes. These shapes can be related using arrows to add meaning. This Concern Map says something about the relationship between the two groups; the user interface “Posts into” the business logic. The arrow and its label describe this relationship. The text within the rectangles says that the files CustomerForm.aspx, EnquiryForm.aspx and OrderForm.aspx are part of the user interface, and FormHandler.cs is part of the business logic.

These diagrams are created and used within the Visual Studio 2005 development environment. Users drag and drop rectangles and arrows onto a canvas to build a diagram. They can set the labels on the rectangles and arrows by typing directly onto them. Users can click on a rectangle and enter information into a customised form to associate something like a file, class or method with that rectangle.

This association information can be simple file names, as in the example above, or more complex expressions, queries, which are evaluated against files. When a user double clicks a rectangle, the Concern Map assesses the associations and displays a list of matching items. Users can open items from the list, jumping straight to the position that is relevant to the concern. This allows users to move from the high-level view of the concern in the diagram to the actual things that make up the concern.

3.3. The Concern Map Language in Detail

3.3.1. Visual Language

There is a great deal of existing work on visual representations of concerns in software. Groher and Schulze [114], Katara and Katz [115] and Kienzle, Yu and Xiong [116] propose adaptations to the UML to provide a visual representation of aspects. A number of view-based separation of concern tools use inline highlighting or lists to present the artefacts are part of a view. AspectBrowser [82] and Aspect-jEdit [44] highlight results inline using colours. FEAT [81] uses a tree representation. The Intentional View

32 Browser [79] uses a list of results to display each view. However, the use of graph diagrams in tools like RIGI [117] and MANSART [89] presents another useful level of abstraction in comparison to text highlighting.

The Hy+ system [118] takes a generic approach to representing data. Hy+ uses a directed graph to visualise data, with queries associated with each node to select data and associate it with that node. Hy+ generalises other diagrammatic conventions into a simple language without any semantics associated with edges and nodes. Issarny, Saridakis and Zarras [119] suggest that different languages should be used for each viewpoint on a system. In contrast, the Hy+ approach is not optimal for any particular viewpoint. However, the simplicity of the Hy+ language is appealing, particularly given the popularity of the minimal diagramming technique called sketch modelling described by Fowler [120].

Concern Maps use a similarly simple, very minimal visual language with no firm semantics. Concern Maps use a graph to represent the structure of a concern. The nodes of the graph represent some significant logical group within the concern. The edges are used to represent the relationships between these logical groups. Nodes are referred to as Concept Nodes and edges as Relationships. Concept Nodes can have Relationships to zero or more other Concept Nodes. Concept Nodes and Relationships can be labelled with descriptive text, like "User Interface" in Figure 1.

Concept Nodes can be annotated with expressions called Selectors, which express the association between a Concept Node and some artefacts. Selectors are textual expressions in a particular programming language. A Concept Node can have zero or more Selectors, which are explained in detail in the following section.

Figure 2 shows an example Concern Map for a program using the Model-View- Controller pattern. The Concern Map has three Concept Nodes, labelled "Model", "View" and "Controller". They are linked by relationships, "Observes" and "Sends Commands".

Figure 2 MVC Concern Map

3.3.2. Selector Languages

Several authors have proposed using queries to create views of software development artefacts. The approach can be seen in reverse engineering systems like [38, 41]. Tourwe, Brichau, Kellens and Gybels [121] divide source code views into two categories: extensional views, where queries enumerate the various artefacts, and intentional views, where expressions describe the properties of matching artefacts. Gybels and Brichau [122] note the fragility of aspect-oriented programs based on enumeration, suggesting that enumerations are more prone to invalidation than property-based descriptions of the type of things that belong to a certain concern.

A number of different approaches for writing these property-based descriptions have been demonstrated. The ASTLog system described by Crew [123] uses the Prolog language to query tree representations of C++ code. JQuery [124] also extends Prolog and provides a browser interface that allows several layers of refinement through queries. The PatternLint tool [8] described by Sefika again uses Prolog to describe architectural patterns and check conformance against these. Eichberg [125] describes using the XQuery language to identify AOP joinpoints using an XML representation of

34 Java bytecode. The transformation of program source code to XML to create views is discussed in depth by Collard and Maletic [126].

The many different approaches to querying artefacts influenced the Concern Map system towards a framework for Selector languages. This allows different languages to be plugged in to the framework and used with the system. These different Selector languages enable allow Concern Maps to be extended to deal with a broad range of concerns. The following languages have currently been developed for use within the framework:

1. Regular expressions, used to select sections of text within any text file based on pattern matching. 2. File names, used to select entire files. 3. XPath or XQuery code query expressions, used to select source code elements like classes, methods, interfaces or expressions based on properties of these elements. 4. Shortcut code query expressions, used to provide simplified selection of source code elements for common scenarios.

The XPath, XQuery and shortcut expressions provide a range of options for querying source code. XPath and XQuery expressions allow users to write custom expressions with complicated logic and multiple code elements when necessary. Shortcut expressions allow users to avoid the complexity of XPath or XQuery in common situations.

These different languages can be mixed within the same Concept Node. For example, a Concept Node could use an XPath Selector to choose a class with a particular name, and another File selector to relate a document to the same Concept Node. Concern Maps uses the XML approach described by Eichberg, Mezini and Ostermann [125] to query program structure. In the Concern Map tool, XPath and XQuery expressions are evaluated against an XML representation of .Net programs. This XML representation provides access to code elements like classes, fields, methods and interfaces, along with

35 the properties of these, like names, visibility, inheritance relationships, interface implementation, calls to methods, and custom attributes.

The system evaluates shortcut code query expressions using the same underlying XML representation of source code, but they give a much simpler syntax to users. The following shortcut expressions have been developed to handle common queries:

CallsMethod [method name]

Matches any method that calls into a method with the specified name.

HasMethod [method name] Matches any class that has a method with the specified name.

InNamespace [namespace]

Matches any class or interface within the specified namespace.

TypeNamed [class name]

Matches any class with the specified name.

ExtendsType [class name]

Matches any class which extends the specified class.

ImplementsInterface [interface name]

Matches any class which implements the specified interface.

GetsField [field name]

Matches any method which gets the specified field.

SetsField [field name]

Matches any method which sets the specified field.

HasField [field name]

Matches any class which has a field with the specified name.

UsesType [type name]

Matches any class which calls a method, gets or sets a field on the specified type.

HasAttribute[type name]

Matches any class, interface, method or field with an attribute of the specified type.

Table 4 Shortcut Selector types

These different Selector languages allow sophisticated selection of code elements through different code query expressions. They also allow less advanced capabilities for dealing with other documents through regular expressions and file names.

37 3.4. Using Concern Maps – Create, Populate and Navigate

There are three steps in the use of Concern Maps. First, Concern Maps are created to reflect a particular concern structure. Next, they are populated with information about which artefacts make up which parts of the concern. They can then be used to navigate to these artefacts.

Users create a Concern Map that reflects the structure of a concern. Figure 3 shows a Concern Map that has been created to represent an entity model for a simple customer management system. This model contains two Concept Nodes, an “Order” and a “Customer”, as well as a Relationship "Customer has orders" between these elements.

Figure 3 Customer Order Entity Concern Map

Users then populate the Concern Map with Selectors which relate parts of the map to artefacts. Figure 4 shows the entity model Concern Map, with Selectors added to the Order and Customer Concept Nodes. These Selectors relate the Customer and Order Concept Nodes to classes named "Acme.Customer" and "Acme.Order" respectively.

Figure 4 Populated Concern Map

38 Lastly, they use the Concern Map to navigate through to view related artefacts by double-clicking a Concept Node. This causes the Concern Map tool to evaluate the Selectors associated with a Concept Node against files loaded within the IDE. The Concern Map tool then produces a listing of all matching artefacts. The listing is displayed next to the map. Users can click any of the individual items within this listing to load the related file. Source code files are loaded directly within the IDE and opened at the matching position within that file. Documents that are opened in external programs, for example Microsoft Excel spreadsheets are loaded in Excel, outside of the IDE. They are opened at the start of the document. Users can then edit the file if necessary.

Figure 5 Artefact listing for Customer

Figure 5 shows the listing following the evaluation of the “Customer” Concept Node. The Customer class, its source file and position within the file are shown within the tree view.

40 3.5. The Concern Map Tool

This section describes the general features used to create, populate and navigate a Concern Map using the Concern Map tool.

3.5.1. Loading a Concern Map

Concern Maps are stored as XML documents. These XML documents are created and used with a tool developed as part of this project that operates within and extends the Visual Studio IDE. This tool allows users to open a Concern Map file that was previously created and saved. It also allows users to add a new Concern Map to a Visual Studio project. When a file is created or opened it is displayed in the main window of the IDE as in Figure 6. Opening a Concern Map also adds relevant icons to the toolbox as in Figure 7. The tool allows users to save the Concern Map by pressing “Control + S” or choosing “File” then “Save” from the IDE drop down menus.

Figure 6 Open Concern Map file

Figure 7 Concern Map toolbox

3.5.2. Adding a Concept Node

Users can add a new Concept Node by: • Dragging a Concept Node icon from the toolbox onto the canvas. • Naming the Concept Node by clicking on it and editing the text label.

3.5.3. Adding a Relationship

Users add a Relationship between two Concept Nodes by: • Clicking on the Relationship icon in the toolbox. • Clicking on the Concept Node where the relationship starts. • Clicking on the Concept Node where the relationship ends. • Naming the Relationship, in the same way as naming a Concept Node.

3.5.4. Deleting a Concept Node, Relationship or Selector

Users can delete a Concept Node, Relationship or Selector by right clicking on the shape and selecting “Delete” or pressing the delete key.

3.5.5. Adding or editing a Selector

Users can add a Selector to a Concept Node by: • Right-clicking the Concept Node and choosing “Add Selector”. • The tool then presents the user a form that allows them to: o Choose a Selector language, from a list of supported languages. o Input the Selector expression text.

Users can edit a Selector by clicking on the Concept Node that contains the Selector. This opens a form that allows them to change the Selector language or expression. The tool allows more than one Selector within a single Concept Node, as well as different Selector languages.

3.5.6. Navigating

Users can drill down and view the artefacts associated with a Concept Node by double- clicking on the Concept Node shape. This opens a new window that displays matching artefacts as shown in Figure 8. Users can double click any item in this window to open the artefact at the corresponding position.

Figure 8 Results window

3.5.7. Changing the display

Concept Nodes can be collapsed to hide the associated Selectors, as shown in Figure 9. This simplifies the diagram for users not interested in editing Selectors.

Figure 9 Collapsed Concept Node

Concern Maps can be magnified or reduced in the IDE by pressing control-shift-'+' to magnify or control-shift-'-' to shrink.

3.6. Architecture and Implementation

3.6.1. Overview

The Concern Map tool was developed as an extension to the Microsoft Visual Studio 2005 development environment. This development involved two significant strands of work. Firstly, the ability to draw and interact with Concern Map diagrams within Visual Studio. This involved specifying and then implementing the visual language using the Visual Studio extensibility capabilities and tools for designing domain specific languages.

Secondly, the ability to query development artefacts based on information stored in the Concern Map diagram. This involved designing a generic mechanism for taking Concern Map information and passing it to a specialised provider for each type of Selector. These specialised providers were developed for a range of languages: regular expressions, file names, XPath, XQuery and a range of syntactic shortcuts for more complicated XPath and XQuery expressions.

3.6.2. Major Components

The Concern Map tool has a modular design, and is made up of the following major components:

Component Responsibilities Designer Integrates with the Visual Studio IDE Loads, saves and edits Concern Maps Provides a graphical interface for using Concern Maps Domain Model Implements the Concern Map language structure Editors Provides advanced editing capabilities for Selectors Output Handlers Provides output functionality for navigation to artefacts

Controller Handles events from the Designer and Editor Maps events to the Domain Model, Selector Languages Manages updates to dependent parts of the Designer and Editor Selector Evaluates Selector expressions Languages Returns lists of matching artefacts to the Controller components

Table 5 Major components

3.6.3. Designer and Domain Model

The Designer and Domain Model were produced with the Microsoft Domain Specific Language Tools [2]. The Microsoft Domain Specific Language (DSL) Tools were used because they significantly simplify the process of building a graphical designer for Visual Studio. The basic designer generated by the DSL Tools was then manually adapted at the source code level to produce the interactive behaviour required for editing and evaluating Concept Nodes.

Development with the DSL Tools provided several challenges. The project used several beta versions of the product. These had minor defects that required some investigation and intervention over the course of the development. The gradual introduction of new and valuable features into subsequent beta versions also meant that the project went through several upgrades to those newer beta versions. However, these challenges still

45 meant a huge saving of time in comparison to writing the designer functionality from scratch.

3.6.4. Editors and Output Handlers

The editors and output handlers provide additional user-interface functionality, beyond that provided by the Designer. This component was implemented using Microsoft C#. The tree of results in Figure 8 is an example of an output handler. During the course of the project several progressively more advanced output handlers were developed, starting with a very basic text output listing artefacts.

3.6.5. Controller

The Controller acts as an integration point for the various user-interface and core logic components. It was implemented using Microsoft C#.

3.6.6. Selector Languages

The Selector Languages component implements query capabilities for each selector language. For the regular expression and file name selector languages this component provides minimal logic on top of .Net Framework Base Class Library components. The component provides more sophisticated functionality for the various code query languages, ultimately based on XPath and XQuery. The component interfaces with Visual Studio's CodeModel and the PERWAPI component [127] to create an XML representation of source code. Shortcut queries go through an intermediate step where they are converted into XPath or XQuery expressions. The final XPath or XQuery is then evaluated against the XML, either using Base Class Library functionality in the case of XPath or Saxon.Net [128] in the case of XQuery.

3.7. Extensibility

New Selector languages can be added to the Concern Map tool. This extensibility allows the tool to be changed to better address particular types of concerns or artefacts.

46 The history of the Concern Map project demonstrates this extensibility. The XPath Selector language was developed first. At this point there was no extensibility point to use other languages. Then the system was refactored to allow new languages to be added. This changed the system so that it dynamically determined which component to use to evaluate a Selector expression. After this refactoring was completed the file name, Regular Expression, XQuery and finally the shortcut Selector languages were added. This extensibility could be used to add further languages or integrate with other programs.

For example, the Concern Map tool currently has limited capabilities to search word processing documents. Users can include an entire word processing document using a file name Selector. They can also search word processing documents for certain words or patterns using a regular expression Selector. These approaches would not be ideal in many situations: • Selecting an entire document may be too coarse if only part of that file is relevant to a particular Concept Node • Matching based on key words may produce many results of different relevancy, which must be examined manually by the user

The Concern Map tool could be extended to improve this by introducing a new Selector language. A useful Selector language could recognise the structure of word processing documents and allow users to select portions of documents based on content and structure. For example, a Selector expression in this language could be "Select section from document where heading contains the phrase 'Customer Entity'". The Concern Map tool could also be extended to integrate a search program like Google Desktop Search [129] or MSN Desktop Search [130]. This would take advantage of the advanced abilities of these programs to decide the relevancy of documents based on keywords.

3.8. Comparison to View-based Approaches

Concern Maps approaches the separation of concerns problem in a similar way to view- based approaches like FEAT [81], AspectBrowser [82], Intentional View Browser [75]

47 and Aspect-jEdit [44]. These systems all allow users to specify query expressions that point to the artefacts that make up a concern. Concern Maps provides extra capabilities in comparison to view-based approaches:

- Separates concerns in a range of artefacts, not limited to source code - Provides different query languages to select artefacts - Uses a flexible visual modelling language for describing concerns

Concern Maps are capable of dealing with a broad range of documents through different query languages. This differs from other view-based tools which only address source code concerns and allow one way to select concerns. AspectBrowser selects sections of text using regular expressions. Aspect-jEdit allows users to manually select sections of source code and mark them using a name and colour. The Intentional View Browser uses the prolog-based SOUL language to select parts of programs. FEAT provides a similar code query capability for describing source code modules like classes and methods based on their properties. It also allows users to manually exclude results.

Concern Maps also takes a different approach to displaying results. The Concern Map visual language allows users to create graph diagrams to represent concerns. View- based tools use more constrained representations. Aspect-jEdit highlights colours sections of source code that make up a particular aspect. AspectBrowser also uses colours to highlight aspects, as well as providing a zoomed out view of all source code files to reveal patterns of colour. The Intentional View Browser uses a text listing of source code elements that make up a concern. FEAT employs a tree listing of related source code elements.

View-based approaches do provide some capabilities not available in Concern Maps. Aspect-jEdit allows users to automatically extract a highlighted aspect into an AspectJ aspect declaration. The Software View Inducer [80] extends the Intentional View Browser by allowing users to drag and drop program elements to create a description of a concern. This description is then converted into a SOUL rule using inductive logic

48 techniques. The AspectBrowser uses a range of folding techniques to show and hide different parts of program source code, allowing users to view the concern source code in isolation or in context. It also allows concerns to be folded to view the core logic of a program.

Chapter 4. Applying Concern Maps

This chapter applies Concern Maps in six scenarios and evaluates the results. Section 4.1 explains the research methodology used to create the scenarios and evaluate the Concern Map tool. The first three scenarios involve separation of concerns in source code: Section 4.2 examines crosscutting concerns, section 4.3 examines feature delocalisation, and section 4.4 examines design pattern implementation. The next two sections examine separation of concerns between source code and other artefacts: Section 4.5 examines separation of concerns within architecture documents and code, and section 4.6 examines the separation of concerns spanning documents and code. Section 4.7 examines the separation of concerns within automated tests and their implementation. Section 4.8 evaluates the goals of Concern Maps based on the results of the scenarios and compares Concern Maps to other approaches.

4.1. Research Methodology

Concern Maps were assessed by building real software systems and then using Concern Maps to address some separation of concerns problem exhibited by the system. The real software systems were chosen from existing publications that dealt with separation of concerns, and this approach allowed Concern Maps to be readily compared to existing separation of concerns languages and tools.

Six scenarios were chosen to reflect the different separation of concerns problems discussed in sections 2.3 and 2.4. These scenarios were chosen to illustrate distinct circumstances where concerns are not adequately separated. The scenarios were then used to create specific example systems that exhibited the particular separation of concerns problem. The example systems were built using Visual Studio and Microsoft.Net. The scenarios and example systems were based on examples in existing publications.

50 Concern Maps were then applied to the example system to separate the particular concern. The strengths and weaknesses of the Concern Map solution were then analysed for each example. Where appropriate the Concern Map approach was compared to other approaches to highlight these strengths and weaknesses. The re-use of example scenarios and systems from existing work allowed results achieved with Concern Maps to be more easily compared with results achieved using alternative approaches, even when the approaches differed significantly, for example the use of dedicated languages like AspectJ discussed in section 4.2. The following format is used to explain the examples and present findings.

Scenario overview - A description of the scenario presented in a few paragraphs of text and then summarised using the format:

Problem: Reason the right separation of concerns cannot be achieved. Artefacts: The types of artefacts involved.

Example – An example system that embodies the scenario, describing the artefacts and concerns involved.

Applying Concern Maps – Application of the Concern Maps tool to improve the separation of concerns in the example. This includes the various Concern Maps created, Selectors used to query artefacts, and any difficulties encountered.

Other Approaches - Describes how other tools have been used to address the example.

Evaluation and Comparison - The various approaches are discussed and compared to the application of Concern Maps.

51 4.2. Scenario 1 – Crosscutting Concerns in Source Code

4.2.1. Scenario overview

Crosscutting concerns in source code take two forms: code scattering and code tangling. Code scattering occurs when code related to one concern is spread across several modules in a system. Code tangling occurs when code related to many concerns is intertwined within a single module. This crosscutting makes it difficult to understand and edit a concern. The problems of code tangling and scattering are discussed in more detail in section 2.2.1.

Summary Problem: Concerns intertwined within modules like classes or methods, and some concerns spread across many modules. Artefacts: Source code modules, for example Java or .Net classes.

4.2.2. Example

Example System Soares, Laureano and Borba [9] describe a complaint management system called Health Watcher containing many crosscutting concerns. The example used here is a tangled implementation of the Health Watcher, re-creating problems and poor design found in the original. The design and implementation uses Microsoft.Net, whereas the original Health Watcher was implemented in Java.

The application is made up of several classes: • A web server page providing a user interface for updating complaints • A façade providing access to functionality for making the update • The IPersistenceMechanism interface, abstracting persistence functionality • An implementation of this interface • The IBusinessData interface, abstracting add, update, remove, find functions

52 • Several implementations of this interface, reflecting different persistence schemes

Figure 10 Partial Health Watcher class diagram

The UML sketch in Figure 10 describes these classes, interfaces and their relationships.

Crosscutting Concerns Soares, Laureano and Borba [9] identify several distinct concerns to do with persistence within the system1.

Core persistence functionality concern – The IPersistenceMechanism, PersistentComplaintData and VolatileComplaintData classes contain the core data access functionality.

1 The partial loading of Complaints based on usage scenario is also discussed in Soares et al., but in too little detail to include within this example.

Persistence mechanism control and variation point concern – An IPersistenceMechanism is initialised in the HealthWatcherFacade. The façade is then responsible for handling errors and releasing resources on the IPersistenceMechanism.

Transaction control concern – All public methods on the HealthWatcherFacade are transactional. These methods are responsible for starting transactions, committing them or rolling back based on the success of the operation.

Persisting data concern – Dirty Complaint objects are tracked by the ComplaintRecord and persisted at once when the operation has completed.

Data collection variation point concern - The façade varies the concrete data collection to use a persistent, database-backed collection or a non-persistent version for testing purposes.

4.2.3. Applying Concern Maps

Concern Maps were applied to the Health Watcher to separate the various persistence concerns. A top-level Concern Map was created to organise the persistence concerns. An individual Concern Map was then created for each of the individual persistence concerns. The following table summarises the Concern Maps: Concern Concern Map Top level view of all concerns Figure 11 Core persistence functionality Figure 12 Persistence mechanism control and variation point Figure 13 Transaction control Figure 14 Persisting data Figure 15 Data collection variation point Figure 16

Table 6 Summary of Concern Maps

54 All Concerns This Concern Map shows all five concerns and their relationships. Each Concept Node contains a single Selector expression that points to the related Concern Map file for that concern. For example, the Concept Node labelled 'Core Persistence Functionality' contains a single file name Selector, with the expression 'CorePersistence.cmp'.

Figure 11 Persistence concerns

Concept Node Selector Type & Expression Selects Mechanism Control File Concern Map file mechanism.cmp. & Variation Mechanism.cmp

Core Persistence File Concern Map file

Functionality CorePersistence.cmp corepersistence.cmp. Data Collection File Concern Map file Variation Collection_variation.cmp collection_variation.cmp. Persisting Data File Concern Map file transaction.cmp. Transaction.cmp Transaction Control File Concern Map file persisting.cmp. Persisting.cmp

Table 7 Selectors for persistence Concern Map

Core Persistence Functionality

55 The core persistence Concern Map describes the two parts of the concern: the persistence mechanism and data collections.

Figure 12 Core persistence concern

The persistence mechanism Concept Node contains two Selectors. The first selects the interface named IPersistenceMechanism using an XPath code query. The second selects the class called DatabasePersistenceMechanism using a shortcut code query. The data collections Concept Node uses two shortcut code queries to identify the classes PersistentComplaintData and VolatileComplaintData.

Concept Node Selector Type & Expression Selects Persistence XPath Interface IPersistenceMechanism Mechanism //interface[@name='IPersistenceMechanism']

Persistence TypeNamed Class DatabasePersistenceMechanism

Mechanism DatabasePersistenceMechanism Data Collections TypeNamed Class PersistentComplaintData PersistentComplaintData Data Collections TypeNamed Class VolatileComplaintData VolatileComplaintData

Table 8 Selectors for core persistence Concern Map

Mechanism Control & Variation The Concern Map describes the configuration of the persistence mechanism in each public method of the façade through the Concept Node labelled 'Configuration'. It also captures the calls to clean up the resources for this object when the method exits in the Concept Node labelled 'Error handling cleanup'.

Figure 13 Mechanism Control & Variation concern

The configuration Concept Node uses an XPath code query to select methods in the façade class that call the persistence initialisation method. It uses a second shortcut code query to select that initialisation method. The error handling Concept Node uses a single XQuery code query to select any method in the façade that calls the rollback method.

Concept Node Selector Type & Expression Selects Configuration XPath Method GetAndInitialisePersistence //class[@name='HealthWatcherFacade'] in class HealthWatcherFacade. //method[@name='GetAndInitialisePersistence'] Configuration CallsMethod All calls to method

GetAndInitialisePersistence GetAndInitialisePersistence, in this case matching three methods within the façade: AddComplaint, UpdateComplaint, DeleteComplaint. Error handling XQuery Within class HealthWatcherFacade, cleanup for $m in any method that calls the method //class[@name='HealthWatcherFacade']//method Cleanup on the type where $m//methodCall[@name='Cleanup'] IPersistenceMechanism, in this case [@type='IPersistenceMechanism'] the three methods listed in the return $m previous Selector.

Table 9 Selectors for mechanism control & variation Concern Map

Transaction Control The transaction control concern is separated using three Concept Nodes, representing actions to start, commit and roll back a transaction.

Figure 14 Transaction concern

The three Concept Nodes use similar XQuery code query expressions to select relevant methods. The start transaction Concept Node uses XQuery to select any method in the façade that calls into the StartTransaction method of the persistence mechanism. The commit and rollback Concept Nodes use as similar XQuery to select methods calling the CommitTransaction and RollbackTransaction methods.

Concept Node Selector Type & Expression Selects Start Transaction XQuery Any methods in class for $m in HealthWatcherFacade that call into //class[@name='HealthWatcherFacade']//method StartTransaction on type where IPersistenceMechanism. In this case, $m//methodCall[@name='StartTransaction'] matching three methods [@type='IPersistenceMechanism'] return $m AddComplaint, UpdateComplaint and DeleteComplaint. Commit XQuery As per the previous section, but

Transaction for $m in matching calls to //class[@name='HealthWatcherFacade']//method CommitTransaction. where $m//methodCall[@name='CommitTransaction'] [@type='IPersistenceMechanism'] return $m Rollback XQuery As per the previous section, but Transaction for $m in matching calls to //class[@name='HealthWatcherFacade']//method RollbackTransaction. where $m//methodCall[@name='RollbackTransaction'] [@type='IPersistenceMechanism'] return $m

Table 10 Selectors for transaction Concern Map

Persisting Data The ComplaintRecord class is responsible for inserting and updating changed Complaint objects. The add and update Concept Nodes represent these two actions.

Figure 15 Persisting data concern

Both Concept Nodes use XQuery code query expressions to find methods that call into the relevant methods on the interface IBusinessData.

Concept Node Selector Type & Expression Selects Add XQuery Any method that calls the method for $m in //method where Add on the type IBusinessData. In $m//methodCall[@name='Add'] this case, matches method Add in [@type='IBusinessData'] class ComplaintRecord return $m Update XQuery Any method that calls the method

for $m in //method where Update on the type IBusinessData. $m//methodCall[@name='Update'] In this case, matches method Update [@type='IBusinessData'] in class ComplaintRecord return $m

Table 11 Selectors for persisting data Concern Map

Data Collection Variation The data collection variation concern comprises any point where client code chooses a particular implementation of the IBusinessData interface (the abstract definition of a data collection in the Health Watcher). In the example implementation this decision is localised within one method – the GetBusinessData method of the façade. However, the Concern Map uses a broad Selector to catch any instantiations of classes that implement IBusinessData, making the Concern Map more robust in case of changes to the implementation.

Figure 16 Data Collection Variation Point concern

Concept Node Selector Type & Expression Selects Data Collection XQuery Any method that calls a constructor Variation Point for $m in //method (.ctor) on a type that implements the for $tname in interface IBusinessData. In this $m//methodCall[@name='.ctor']/@type example matches the method for $c in //class[@name=$tname] GetBusinessData in class where $c[implements='IBusinessData'] HealthWatcherFacade. return $m

Table 12 Selectors for data collection variation Concern Map

4.2.4. Other Approaches

Soares, Laureano and Borba apply AspectJ to the Health Watcher application in [9]. They use aspect declarations to encapsulate the tangled persistence concerns. The persistence mechanism control and variation point is separated into two aspects. An abstract aspect is used to define initialisation and clean up behaviour using some persistence manager. A concrete aspect then extends this, defining which persistence manager to use along with the point in the program to perform initialisation. Similarly, the transaction control concern is encapsulated using an abstract aspect to define the start, commit and rollback of transactions. This is then applied to the façade through a concrete aspect.

The persisting data concern is implemented by introducing an interface PersistentObject to the entity class Complaint. Pointcuts are defined to identify updates to this object, and an aspect is used to add the updated object to a collection of objects. The aspect then persists the updated objects at the end of the operation. The data collection variation

61 point concern is implemented using an aspect that initialises a particular collection when the façade is created. This means the system must be re-compiled to vary the collection.

4.2.5. Evaluation and Comparison

Concern Maps effectively identify each concern and provide an easy way of navigating through tangled source code. They also allow the concern implementation to be viewed in the context of other source code. This is useful when concerns like the transaction control and the persistence mechanism control are closely related and adjacent in source code. They also provide a top-level view of concerns and the relationship between these concerns, not available using AspectJ. This top-level view demonstrates the value of storing Concern Maps as XML files, rather than as part of a metadata database. Since they are unique files, individual Concern Maps can be identified using file names in Selector expressions.

The Concern Map tool assesses Selector expressions every time a user double-clicks a Concept Node. In this example, seven XQuery and two XPath Selectors were used to match sections of source code based on their properties. This dynamic assessment of Selectors and the use of property-based code queries make the Concern Maps solution more robust if the implementation were to change in future. In this example, long XQuery selector expressions like the one in Figure 16 were visually truncated by their containing shape. This truncation makes it difficult to understand the query without referring to the selector editing window described in 3.5.5.

AspectJ extracts the various concerns into dedicated modules, localising any changes to these modules. It also provides much greater scope for reuse of code through the declaration of abstract aspects for common concerns like transaction control.

62 4.3. Scenario 2 – Feature De-Localisation

4.3.1. Scenario overview

Feature de-localisation is a variation of code scattering where a concern is spread across many modules, spanning several different languages. For example, a set of related logic could be implemented in T-SQL stored procedures and Java code. The close relationship between the logic in these two modules would mean they need to be understood and altered in coordination. This causes the same problems as scattering between modules in the same language. Because different languages are used the concern cannot be modularised using tools specialised for one language like AspectJ. The feature de-localisation problem is discussed in more detail in section 2.2.1.

Summary Problem: Concerns spread across modules using different languages, so aspect tools cannot be used. Artefacts: Modules in different code languages, for example C# and T-SQL.

4.3.2. Example

Example System Greenfield and Short [19] describe a web application for managing orders, products and customers. The application is made up of three layers: a user interface, a distributed component and database connectivity.

User interface layer – Implemented using three ASP.Net pages: Order.aspx, Product.aspx and Customer.aspx. Each page provides the ability to add a new item (order, product or customer), or search for and then edit an existing item. Each page passes on requests to the distributed component.

Distributed component – All calls from the user interface layer are handled using a single façade class that is distributed using COM+. The façade forwards requests to dedicated classes for each item. Add, search and update functionality for each item is

63 implemented in the classes Order, Product and Customer. These classes perform validation and use the database connectivity component to access the database. All four classes are packaged in the assembly Operations.dll.

Database connectivity – The database connectivity component contains add, search and update methods in classes called OrderDB, ProductDB and CustomerDB. These classes use a helper class to execute stored procedures for each operation. The four classes are packages in the assembly Database.dll. The stored procedures are stored in dedicated files, for example UpdateOrder.sql. These stored procedures are part of a separate database project.

Crosscutting Concerns Orders, products and customers are concerns that crosscut the three layers. These three concerns are detailed below.

Order concern – Contains data and functionality related to the order entity. Includes the Order.aspx web page, the Order class within the distributed component, and the OrderDB class and related stored procedures within the database connectivity layer.

Product concern – Contains data and functionality for products. Includes the Product.aspx web page, Product class within the distributed component, ProductDB class and related stored procedures within the database connectivity layer.

Customer concern – Contains data and functionality for a customer. Includes the Customer.aspx web page, Customer class within the distributed component, CustomerDB class and related stored procedures within the database connectivity layer.

4.3.3. Applying Concern Maps

A single Concern Map was created to represent the three Concerns – Order, Product and Customer. A Concept Node was created for each, with Selectors to link to artefacts from the user interface, distributed component and database connectivity.

Figure 17 Order, product and customer concerns

Each Concept Node uses a similar set of Selectors. A file name Selector is used to select the appropriate ASPX file. An XPath code query is used to select the relevant methods in the façade class. A shortcut code query is used to select the matching class in the distributed component, for example within the order Concept Node the XPath selects the class called Order. Another shortcut code query is used to select the matching database class. Three file name Selectors are used to select the stored procedures used to add, search and update the item.

65 Concept Selector Type & Expression Selects Node Order File The file Order.aspx stored in the web site ..\..\Order.aspx project directory.

Order XPath Any method in the class Façade containing //class[@name='Facade'] the phrase 'Order'. In this case, matches the //method[contains(@name,'Order')] three methods AddOrder, UpdateOrder and SearchForOrder. Order TypeNamed Class named Operations.Order. Operations.Order

Order TypeNamed Class named DatabaseOps.OrderDB DatabaseOps.OrderDB

Order File The files AddOrder.sql, SearchOrder.sql ..\Database\Queries\AddOrder.sql and UpdateOrder.sql in the Queries ..\Database\Queries\SearchOrder.sql directory of the Database project. ..\Database\Queries\UpdateOrder.sql Product File The file Product.aspx stored in the web site ..\..\Product.aspx project directory.

Product XPath Any method in the class Façade containing //class[@name='Facade'] the phrase 'Product'. In this case, matches //method[contains(@name,'Product')] the three methods AddProduct, UpdateProduct and SearchForProduct. Product TypeNamed Class named Operations.Product. Operations.Product

Concept Selector Type & Expression Selects Node Product TypeNamed Class named DatabaseOps.ProductDB DatabaseOps.ProductDB

Product File The files AddProduct.sql, SearchProduct.sql ..\Database\Queries\AddProduct.sql and UpdateProduct.sql in the Queries ..\Database\Queries\SearchProduct.sql directory of the Database project. ..\Database\Queries\UpdateProduct.sql Customer File The file Customer.aspx stored in the web ..\..\Customer.aspx site project directory.

Customer XPath Any method in the class Façade containing //class[@name='Facade'] the phrase 'Customer'. In this case, matches //method[contains(@name,'Customer')] the three methods AddCustomer, UpdateCustomer and SearchForCustomer. Customer TypeNamed Class named Operations.Customer. Operations.Customer

Customer TypeNamed Class named DatabaseOps.CustomerDB DatabaseOps.CustomerDB

Customer File The files AddCustomer.sql, SearchCustomer.sql and ..\Database\Queries\AddCustomer.sql UpdateCustomer.sql in the Queries ..\Database\Queries\SearchCustomer.sql directory of the Database project. ..\Database\Queries\UpdateCustomer.sql

Table 13 Selectors for order, product and customer Concern Map

4.3.4. Other Approaches

The model-driven development approach produces high-level views of systems that can be used to generate artefacts spanning multiple languages. Several code generation systems have been created or specialised to deal with this sort of web application. Example systems include CodeSmith [102], CodeCharge [131], DeKlarit [132] and Fabrique [103].

CodeSmith is a code generation and template framework that can be used to generate text based on data schemas in XML or a database. In this example, CodeSmith could be used to generate ASPX pages and classes for each of the Order, Product and Customer entities based on their underlying tables in the database. This approach would involve creating custom templates to generate each type of artefact. These templates would use information from the schema during generation to tailor the class or stored procedure the particular entity. This approach allows changes to the entities to be localised within the database, although the Order, Product and Customer concerns would still be scattered in the final generated code.

4.3.5. Evaluation and Comparison

Concern Maps identifies all relevant parts of the Customer, Order and Product. However, the four File and two TypeNamed selectors are enumerations of class and file names, rather than queries that select artefacts based on other properties. This enumeration is fragile because file and class names may be altered in future. This would cause the Concern Map to become inaccurate. Although Concern Maps offer more advanced code query capabilities that could be used in place of enumeration, in this situation it is more convenient to identifying roles by name rather than by more complex properties. The XPath query used to identify relevant methods in the façade is more robust.

The generation of code in this scenario would produce a more effective separation of concerns, since changes would be localised to the entity definition. However, scattering in the generated code would cause problems for users trying to trace the concern through the related artefacts.

68 4.4. Scenario 3 – Design Pattern Implementation

4.4.1. Scenario overview

Crosscutting concerns occur in the implementation of many design patterns because the pattern introduces new functionality to several classes. The pattern is not well modularised because it is part of several classes. This causes problems when maintaining software because it can be difficult to view pattern or core object model code in isolation. Crosscutting concerns in design pattern implementations are discussed in detail in section 2.2.2.

Summary Problem: Pattern and program object model intertwined. Artefacts: Modules in a single language, for example Java classes.

4.4.2. Example

Example System The Observer pattern was proposed in [20] to encourage loose coupling between objects when one object relies on another for updates when state changes. The pattern uses the publish-subscribe model based on standard interfaces for communicating between objects called subject (the publisher) and observer (the subscribers). In this way subjects and observers can be reasonably de-coupled from the objects they interact with. Implementing the Observer pattern involves introducing code to subject and observer classes, either through inheritance or direct implementation.

This example uses a standard implementation of the Observer pattern applied to a simple Graphical Figure Element system as described in Hanneman and Kiczales [7]. This system contains Point and Line classes which model geometric elements. They both extend the abstract Subject class, which implements the Subject role. The Point and Line classes are observed by the Screen class, which implements the IObserver interface.

69 Crosscutting Concerns The entire pattern implementation can be considered a concern that crosscuts the system. This encompasses subjects, observers and code to notify, attach and detach observers. This concern would be relevant to a programmer interested in understanding the application of the pattern to the object model, or apply pattern-level changes to the implementation.

In addition, the pattern roles Subject and Observer could also be considered concerns that crosscut the entity classes point and line within the system. This narrower concern would be relevant to a programmer changing the internal implementations of these roles.

Pattern concern – Comprises the entire pattern implementation.

Subject concern – Comprises the abstract and concrete implementations of the subject. Within the concrete implementation, this concern includes the calls to notify observers after actions that change the state of the object.

Observer concern – Comprises the concrete implementations of the observer interface.

4.4.3. Applying Concern Maps

A single Concern Map, shown in Figure 18, was created to separate the three concerns described in the previous section. The single Concept Node was used to represent the Observer concern. Three Concept Nodes were used to represent the Subject concern. Firstly, the Concept Node labelled 'Abstract Subject' captures the abstract class that implements the basic notification functionality. The Concept Node labelled 'Concrete Subjects' captures any class that inherits from the abstract subject class. The Concept Node labelled 'Notifications' captures all calls to notify observers from concrete subjects. Lastly the overall pattern concern is captured by the four individual Concept Nodes and the relationships between them.

Figure 18 Observer Concern Map

The abstract subject Concept Node uses a shortcut code query to select the subject class. The concrete subjects Concept Node uses another shortcut code query to select any class that inherits from that subject class. In this example, this selects the Point and Line classes. The notifications Concept Node uses a single shortcut code query to select any method that calls into the Notify method, inherited from the subject class. Lastly, the observer Concept Node uses a shortcut code query to select any class that implements the IObserver interface. In this example, this selects the Screen class.

Concept Node Selector Type & Expression Selects Abstract Subject TypeNamed The type named Subject. Subject

Concrete Subjects ExtendsType Any class that inherits from Subject, Subject in this case the Point and Line classes. Notifications CallsMethod Any method calling into the method Notify Notify. In this case, the properties Colour, X and Y in the point class, and the properties Colour, P1 and P2 in the line class. Observer ImplementsInterface Any class implementing the IObserver interface IObserver, in this case the Screen class.

Table 14 Selectors for observer Concern Map

The Concern Map for this example was initially defined with just Subject and Observer concept nodes, but this level of abstraction hid the three parts of the subject role (abstract class, concrete classes and notifications). Dividing the subject into three Concept Nodes clarified these parts and gave more meaning to the overall view of the pattern.

4.4.4. Other Approaches

Hannemann and Kiczales [7] discuss using AspectJ to extract the Subject and Observer roles into aspects which are then woven into the Screen, Point and Line classes. They define an abstract aspect which is responsible for: • Defining the subject and observer roles • The maintenance of mappings between subject and observer through AddObserver and RemoveObserver methods • Updating observers at an abstract pointcut called subjectChange They then use concrete aspects to bind these to the Screen, Point and Line classes.

72 4.4.5. Evaluation and Comparison

The Concern Map provides a useful top-level view of the pattern implementation through use of Concept Nodes and Relationships to represent pattern roles and their interactions. Selectors effectively identify the parts of the code relevant to the pattern role within each Concept Node. Given the highly conventional nature of the observer pattern, this Concern Map could be reused in other implementations with very little or no modification.

The AspectJ implementation completely separates the implementation of the pattern from the Screen, Point and Line. In addition, the AspectJ implementation provides an abstract definition of the pattern which could be reused in other instances. As in previous examples, the AspectJ implementation localises changes to the concern to a single module. This is important in the case of the notifications, which occur in many places on each concrete subject.

4.5. Scenario 4 – Architecture and Code

4.5.1. Scenario Overview

Some concerns span design models and their implementation in code. These crosscutting concerns involve information about a concern within the design model, often in a language like UML, and implementation in source code. This crosscutting causes several problems. Firstly, it can be difficult to trace ideas from the source code to the design model. Secondly, the design model can become out of step with the implementation, and as a result design information is not trusted by users and is lost. Crosscutting concerns between design models and their implementation are discussed in detail in section 2.4.2. Summary Problem: Concerns spread across design model and implementation. Artefacts: Design models like UML or textual documents and source code.

73 4.5.2. Example

Example System Layering is a common approach to system design that decomposes a system into layers of functionality. As described by Shaw and Garlan [31], each layer provides services to the layer above it, and is a client to the layer below it. This example is based on the layered system described by Eeles [133]2 for managing orders, customers and products. The system comprises three layers: the presentation logic, business logic and data access logic. The presentation logic is responsible for presenting data and actions, and uses the business logic layer to get and update orders, customers and products. The business logic layer contains the functionality to carry out actions on orders, customers and products. It uses the data access layer to persist and retrieve data.

The layers are implemented using T-SQL and C#. They are distributed across two computers. A client PC hosts the presentation logic. A server hosts the business and data access logic. The system is designed using UML diagrams. The package diagram describes the three layers and their interactions. The deployment diagram maps these packages onto hardware. These diagrams were created using Microsoft Visio and are stored in separate files.

Figure 19 UML Package diagram

2 This example uses the same identically named classes as Eeles. However, it also includes stored procedures within the data access layer.

Figure 20 UML Deployment diagram

Crosscutting Concerns The three layers are each concerns within the system, spanning several files. For each layer design information is stored in the two UML diagrams, and additional implementation classes and files are listed below:

Presentation logic concern – Contains CustomerView, OrderView and ProductView classes.

Business logic concern – Contains Customer, Order and Product classes.

Data access layer concern – Contains CustomerData, OrderData and ProductData classes, as well as T-SQL stored procedures for adding and updating Customer, Order and Product database tables.

4.5.3. Applying Concern Maps

The layering concern is represented using two Concern Maps. The first relates the various artefacts:

Figure 21 Models and Implementation Concern Map

The deployment model Concept Node uses a file name Selector to select the Visio deployment diagram. The package model Concept Node similarly selects the package diagram. The implementation Concept Node also uses a file name Selector to select another Concern Map file.

Concept Node Selector Type & Expression Selects Deployment Model File The deployment.vsd file. ..\..\Deployment.vsd

Package Model File The package.vsd file. ..\..\Package.vsd

Implementation File The layers.cmp file. Layers.cmp

Table 15 Selectors for models and implementation Concern Map

The second Concern Map (the file layers.cmp referenced in the previous Concern Map) divides the implementation artefacts into layers:

Figure 22 Layers Concern Map

The presentation and business logic Concept Nodes use shortcut code queries to select any class within the relevant namespace. The data access logic Concept Node uses the same approach to include the related data access classes, but also uses six file name Selectors to include stored procedure files.

Concept Node Selector Type & Expression Selects Presentation Logic InNamespace Any class within the namespace Presentation Presentation, in this case the classes CustomerView, OrderView and ProductView. Business Logic InNamespace Any class within the namespace Business Business, in this case the classes Customer, Order and Product. Data Access Logic InNamespace Any class within the namespace DataAccess DataAccess, in this case the classes CustomerData, OrderData and ProductData. Implementation File Stored procedure files. ..\Database\Queries\AddCustomer.sql ..\Database\Queries\UpdateCustomer.sql ..\Database\Queries\AddOrdersql ..\Database\Queries\UpdateOrder.sql ..\Database\Queries\AddProduct.sql ..\Database\Queries\UpdateProduct.sql

Table 16 Selectors for layers Concern Map

77 4.5.4. Other Approaches

Eeles [133] demonstrates different strategies for modelling layers within the Rational Rose tool [101]. These include a per-layer grouping of model elements and a per-feature grouping that splits the models into order, customer and product in a similar way to scenario 2. While not specifically discussed by Eeles, the Rational Rose product allows the generation of code from UML and the synchronisation of models with code. It also allows users to navigate from model to code view. This would allow a programmer to use the three packages Presentation Logic, Business Logic and Data Access Logic to navigate to UML or source code representations of classes.

4.5.5. Evaluation and Comparison

The Concern Map in Figure 21 is able to relate design documents and the implementation of the layering concern. However it cannot identify particular elements within the model. It also cannot move to a particular point inside the model document when a user navigates from the Concern Map. Instead, it opens the model file at the default position defined by Visio. This limits the effectiveness of the Concern Map in this situation. An ideal solution would allow the packages in the Design Model to be related to individual concept nodes. For example, the Data Access Logic UML package in Figure 19 could be associated with the Data Access Logic concept node in Figure 22. The Concern Map tool does not have a selector language capable of providing this.

Rational Rose achieves this fine-grained linkage between model elements by generating source code from the UML model. This allows a more coherent relationship between UML elements and classes. In contrast, the UML diagrams are 'black box' artefacts to the Concern Map.

4.6. Scenario 5 – Documents and Code

4.6.1. Scenario overview

Some concerns involve information in specification documents and implementation in source code. This scattering of information makes it more difficult to understand the

78 concern. Users trying to relate part of an implementation to the relevant part of a specification need to find the right document and the right section within that document. The problem also occurs when going in the opposite direction. Users looking at a specification can find it difficult to locate the source code that realises that part of the specification. The separation of concerns in system requirements is discussed in more detail section 2.4.3.

Summary Problem: Concern spread between specification documents and code. Artefacts: Word processing documents, UML Use Case models and source code.

4.6.2. Example

Example System The development artefacts described in Jackson [41] are used as a starting point for this example. This involves a hierarchy of progressively more detailed documents, their implementation, and test specifications. The following diagram explains this hierarchy (as originally presented in Jackson).

Figure 23 Hierarchy of artefacts

This example uses the order management system from scenarios 2 and 4 and introduces new specification documents and test code to match the structure above. The following documents were created to support the example:

High Level Specifications – The Word document Order Management Functional Requirements describes the system functionality.

Detailed Specifications – The Word documents UI Requirements and Business Rule Requirements elaborate the functional system requirements.

Test Specifications – Tests based on the functional requirements are stored in a single Microsoft Excel spreadsheet.

80 Test Harness – A suite of automated tests implement the test specification using the NUnit framework [27].

Code – The implementation of the system used in scenario 4, comprising presentation logic, business logic and data-access logic layers.

Crosscutting Concerns The example focuses on one narrow area within the system: order cost calculation. The following concerns make up the order cost calculation functionality in the system:

Core cost algorithm – Defines the calculation of the cost of an order based on the products ordered and discounts applied with a particular precedence.

Discount types and setup – Elaborates the different types of discounts available (e.g. preferred customer, money off, percentage off, qualified spend, linked promotion) and defines which actual discounts should be set up within the system.

4.6.3. Applying Concern Maps

Jackson [41] describes tracing system requirements through a series of specification documents through metadata tagging. A similar approach is used here. A concern map is used to separate the core cost algorithm concern. This concern map has four nodes: the first identifies relevant requirements; the second identifies the implementation in source code; the third identifies the test specification for this algorithm; the fourth identifies the test harness that applies to the concern.

Figure 24 Core Cost Algorithm Concern

The implementation Concept Node uses an XPath code query to select the Cost method. The test implementation Concept Node uses an XPath code query to select all classes in the tests namespace that call into that Cost method. The requirements and test scenarios Concept Nodes uses regular expression Selectors that look for a particular pattern of text within a document. This pattern of text is not a normal part of the document, but a special metadata tag inserted in the document specifically for this purpose.

Concept Node Selector Type & Expression Selects Implementation XPath The Cost method within the Order //method[@name='Cost'] class.

Requirements Regular Expression The Word document 'Order >>>Pricing<<< Management Functional Requirements.doc' which contains the matching metadata tag. Test Scenarios Regular Expression The Excel document Tests.xls >>>PricingTests<<< containing the matching metadata tag. Test XPath Any method in the namespace Implementation //class[@namespace='Tests'] 'Tests' that calls into the method /method[//methodCall/@name='Cost'] 'Cost'.

Table 17 Selectors for cost algorithm Concern Map

A second concern map was created to separate the discount types and setup concern. This Concern Map uses three Concept Nodes: the first identifies the requirements using the same metadata scheme as the previous Concern Map; the second identifies classes that implement different discount schemes; the third identifies the stored procedure responsible for setting up different discounts in the database.

Figure 25 Discounts concern

The specification Concept Node also uses a Regular Expression Selector to match a particular metadata tag. The implementation Concept Node uses a shortcut code query to select specialised discount classes. The data setup Concept Node uses a file name Selector to select the SQL file used to initialise data.

Concept Node Selector Type & Expression Selects Implementation ExtendsType Any class that extends the class Business.Discount Business.Discount. In this case, matches the classes AmountOff and PercentageOff. Requirements Regular Expression The Word documents 'Order >>>DiscountTypes<<< Management Functional Requirements.doc' and 'Business Rule Requirements.doc' which contain the matching metadata tag. Data Setup File The SQL file used to set up discount ..\Database\Create Scripts\SetupDiscounts.sql data in the database.

Table 18 Selectors for discounts Concern Map

84 4.6.4. Other Approaches

Jackson [41] describes an approach and sophisticated tool for tracing metadata tags between documents produced during the development of a large scale defence system. Documents were tagged using specially formatted metadata to give unique names to elements like requirements or tests. The tagging format allowed the relationships between different elements to be established. The tool promotes consistency by publishing information about requirements missing from downstream specifications or artefacts.

4.6.5. Evaluation and Comparison

Concern Maps provide a limited capability to identify elements within word processing documents or spreadsheets. This is reflected in the need to specially tag documents, rather than writing queries that match the document content, for example looking for sub-headings in a particular section of a document. The limitation faced when opening model files discussed in section 4.5.5 is also noticeable here: rather than opening directly to the tag within the document, the Concern Map tool can only open to the first page or screen.

The system described by Jackson is similarly limited to using metadata tags to flag up elements of interest. However, it has the ability to automatically relate elements based on these tags, which Concern Maps does not provide.

4.7. Scenario 6 – Tests and Code

4.7.1. Scenario overview

When using the test-driven style of development a feature concern is usually located in two places: the implementation, and related tests. The linkage between tests and their implementation is based on naming conventions and is fragile to change. This means users must rely on naming conventions and prior knowledge of the structure of unit tests to find relevant tests for specific functionality. Crosscutting concerns in test-driven development are discussed in more detail in section 2.3.3.

Summary Problem: Concern encompasses tests and implemented functionality, but these are loosely related through naming conventions. Artefacts: Source code modules implementing tests and related functionality.

4.7.2. Example

Example System This example is based on the canonical unit testing example in Beck and Gamma [24], who describe the use of unit tests to develop a money class. The money class is a simple representation of a unit of money with the following features: • An integer amount • A string currency code, e.g. 'CHF' for Swiss Franc • A method to test equality of two currencies called Equals • A method to add two currencies called Add

The money class is implemented using the VB.Net language. Tests are implemented using the C# language, stored in a separate file. A single unit test is implemented for each of the Equals and Add methods. These unit tests are implemented using the NUnit framework.

Crosscutting Concerns In this example individual feature concerns crosscut tests and their implementation. While the features are implemented in a single place (e.g. in a single method in the Money class), the unit tests that go with them are located in a different class and file.

Equality concern - Equality functionality is tested in the TestEquality method of the Tests class. The functionality is implemented in the money class's Equals method.

Addition concern – Functionality to add two money instances is implemented in the Add method of the money class. It is tested by the TestAdd method in the Tests class.

86 4.7.3. Applying Concern Maps

A single Concern Map is used to separate the equality and addition concerns. This map uses a concept node to represent each concern.

Figure 26 Equality and Addition Concerns

The equality Concept Node uses two XPath Selectors. The first selects the Money class's Equals method. The second selects any test method that calls into this method. The addition Concept Node uses two similar Selectors dealing with the Add method.

Concept Node Selector Type & Expression Selects Equality XPath The Equals method within the //class[@name='Money']/method[@name='Equals'] Money class.

Equality XPath Any NUnit test (as indicated by //method the custom NUnit attribute) that [attribute/@type='NUnit.Framework.TestAttribute'] calls into a method Equals, in this [body/methodCall/@name='Equals'] case the method TestEquality in the tests class. Addition XPath The Add method within the //class[@name='Money']/method[@name='Add'] Money class.

Addition XPath Any NUnit test (as indicated by //method the custom NUnit attribute) that [attribute/@type='NUnit.Framework.TestAttribute'] calls into a method Add, in this [body/methodCall/@name='Add'] case the method TestAddition in the tests class.

Table 19 Selectors for equality and addition Concern Map

4.7.4. Other Approaches

While no other approach directly addresses the scenario, a number could easily be applied. View-based separation of concerns tools could be used to relate code and tests. The AspectBrowser program described by Griswold, Yuan and Kato [82] uses regular expressions to identify aspects within a system. These aspects can then be highlighted in a high-level view of all program source files using a particular colour. Users can navigate to individual source code files using this high-level view. Code and tests could be related using this tool by creating one regular expression to match on the method that implements the functionality, for example matching the method signature. Additional regular expressions could be used to match the signatures of test methods. These could all be configured to highlight matching source code using the same colour. This would cause the implementation and tests to be highlighted as a single concern in the high- level view.

88 The Feature Exploration and Analysis Tool (FEAT) described in [81] could also be used to create a unified view of a concern spanning automated tests and implementation. FEAT uses a textual concern description to produce a tree representation of a concern to a user. Users can manipulate this tree representation to add or remove elements from the concern, or navigate to associated source code. The FEAT tool allows users to define a concern using queries of code constructs, such as classes, methods and fields with particular names, and calls to particular methods. In this example FEAT could be used to identify test methods based on calls to the implementation methods. The implementation method could be identified my name.

4.7.5. Evaluation and Comparison

Each of the approaches provides a high-level view of the concern and allows users to navigate to the actual artefact from the high level view. They provide different mechanisms for identifying the parts of the concern and use different approaches for presenting the high level view.

The Concern Map effectively identifies and relates the unit tests and implementation that make up the concerns. In this case the unit tests and implementation are included within a single Concept Node. The XPath Selectors are written to identify related unit tests based on two properties. • They are NUnit tests. • They call into the particular method that implements the feature. This approach means that test can be added during development and will be automatically selected when the Concern Map is used. However, this Selector is also open to false positive results, for example if a test for the Add method used the Equals method to compare two currencies.

The AspectBrowser and FEAT tools provide contrasting query capabilities and visual representations to users. AspectBrowser uses regular expressions to identify parts of the concern. This is essentially an enumeration of method names. This approach is more

89 brittle than the Selectors used in the Concern Map because test methods might be added, removed or renamed. FEAT uses queries based on code structure. These queries are less brittle than regular expressions, and offer a similar level of functionality to the shortcut queries available in Concern Maps.

AspectBrowser provides a zoomed-out view of source code files, with concerns highlighted using a particular colour. FEAT uses a tree representation of the concern inside a window within the IDE. Given the basic structure of the concern, these approaches adequately separate the concern. However, the graph diagrams used by Concern Maps would be more effective in situations like the design pattern in scenario 3, where multiple parts of a concern need to be identified and related.

4.8. Evaluation of Concern Maps

Concern Maps improve the separation of concerns in each of the six scenarios. The examples in this chapter allow the evaluation of the Concern Map tool against its goals and a comparison to other tools. In summary, the Concern Map tool meets the goals established in section 3.1, with a few small exceptions. In comparison to other tools, Concern Maps offers less advanced functionality in some cases, particularly in dealing with requirements documents and models. However, the great variety of scenarios demonstrates the general applicability of Concern Maps.

4.8.1. Assessment of Goals

The Concern Map approach can be evaluated against the goals discussed in section 3.2 based on the results of the six examples.

Go beyond source code, support many languages and documents The examples demonstrate how Concern Maps can be used with a range of languages and documents. Scenario six demonstrates the use of the combination of VB.Net and C# within the same concern. Scenario two deals with T-SQL stored procedures and C# code. Scenarios four and five deal with word processing and modelling artefacts.

90 Although the tool enables the inclusion of different languages and documents, it provides different levels of functionality for each. The tool provides strong capabilities to query .Net source code, and navigates to the relevant position within source code documents. It offers less functionality when dealing with word processing documents. These can only be included as entire files, or using a regular expression to match them based on their content. Files opened outside of the Visual Studio IDE do not jump automatically to the correct position within the document. These limitations decrease the Concern Map tool's effectiveness when dealing with concerns outside of source code.

Reflect the structure of concerns The simple graphical language used by Concern Map is useful for describing the structure of concerns. The Concern Map used to separate Order, Product and Customer concerns in scenario 2 demonstrates the way a Concern Map can express structure. In this Concern Map, relationships are used to link the Order to the Product and Customer. These relationships are tagged with text that explains the relationship between the concerns. Similarly, the Concern Map used to reflect the implementation of the observer pattern in scenario three provides a handy top-level view of the pattern.

Produce development artefacts that describe a concern The tool stores Concern Maps as XML files. The application of Concern Maps in scenario one demonstrates how this allows one Concern Map to reference another using a Selector. In this example, the Concern Map in Figure 11 is used to show all concerns to do with data persistence. This Concern Map uses selectors that link to other Concern Map through their file names.

Complement existing paradigms The scenarios highlight how Concern Maps can be used alongside established practices. Scenario three shows how Concern Maps complement design patterns by separating pattern and core object model concerns. Scenario six shows how Concern Maps can improve the practice of test-driven development. Scenario four shows how architectural

91 modelling can be better supported. The object-oriented style of development is used in all six examples.

Support non-invasive modularisation The dynamically evaluated Selector expressions allow non-invasive modularisation of development artefacts. This modularisation is not as strong as the complete separation provided by aspect languages. However, it allows overlapping views like the entity and layer views taken on the order management system in scenarios two and four

Although Concern Maps enable non-invasive modularisation, in some situations it is necessary to change artefacts to allow a Selector to identify the correct document. In scenario five metadata tags were added to the requirement and test documents to allow them to be identified by a regular expression Selector. While this is sort of alteration is not strictly necessary, in this case it simplified the type of regular expression used to identify relevant the documents.

Integrate with existing developer tools The example system source code and Concern Maps were developed entirely using Microsoft Visual Studio 2005. The Concern Map tool integrates with Visual Studio's window and command structure, as discussed in section 3.5. In the case where word- processing documents and spreadsheets were used, Concern Maps provides a degree of integration through file name and regular expression Selector types.

Extensible implementation The successful application of Concern Maps in the six scenarios demonstrates the capabilities of the implementation. The history of the project discussed in section 3.7 demonstrates that the tool can be extended to use new Selector languages.

4.8.2. Comparison to Other Tools

The examples in this chapter and the comparison to tools discussed in chapter two illustrate the strengths and weaknesses of the Concern Maps approach. This can be

92 summarised as a trade off between applicability and effectiveness: Concern Maps are broadly applicable, but are often not as effective as more focussed tools. Concern Maps improve the separation of concerns in each example, but generally no more so than existing tools.

The one exception to this is model-driven development, which appears to offer broadly applicable development tools using high-level languages. It is more difficult to compare Concern Maps to model-driven development tools because of the complexity and relative immaturity of these tools.

Aspect Oriented Programming The examples illustrate some key benefits of Concern Maps in comparison to AOP languages: Concern Maps separate concerns without altering the underlying implementation; they provide a graphical view that relates the different parts of a concern; they can deal with multiple languages and documents. However, scenarios one and three show that AspectJ has advantages when concerns need to be edited or reused.

AspectJ makes it easy to change concerns by splitting them into separate source code modules. This creates a single point of change for a concern. Concern Maps do not offer this single point of change, although they do enable easy navigation from the map to the editable source code.

AspectJ allows the implementation of a concern to be reused by localising the concern in a source code module. The ability to declare abstract aspects is particularly useful in this respect. While Concern Maps can be reused in some situations, for example for the observer pattern in scenario three, this does not really help implementation reuse.

View-based Tools Concern Maps takes a similar approach to view-based tools, and has the same general strengths and weaknesses. Two key advantages over existing systems are evident when evaluating Concern Maps. Firstly, Concern Maps allows many different query

93 languages. This means Concern Maps can address a range of documents and languages. Secondly, the simple graphical language capable of showing the structure of concerns is useful when dealing with more complex concerns.

Concern Maps do not provide any functionality to derive query expressions from example artefacts as demonstrated by the Software Views Inducer [80]. This feature would make Concern Maps easier to create, particularly for inexperienced users. This capability is noted in the further work section of this thesis.

Reverse Engineering Tools Tools like GEVOL [88] and MANSART [89] provide a highly automated means of discovering the structure of software. Concern Maps does not provide this kind of automation. The ability to automatically generate Concern Maps for particular types of concerns would be useful for common concerns like design patterns. This capability is noted in the further work section of this thesis.

Requirements Traceability Scenario five demonstrates the relative weakness of Concern Maps when separating concerns stored in word processing documents. This contrasts with the results achieved by Olsson and Grundy [38] in separating concerns spanning requirements documents, UML models and test plans. However, the extensibility of the Concern Map tool means this shortcoming could be partially addressed by adding more advanced Selector languages. These new languages could also remove the need to add extra metadata to documents, as done when applying Concern Maps in scenario 5. However, further work is also needed so that documents opened outside of the IDE, for example Word documents, move automatically to the correct position within the document.

Chapter 5. Conclusions and Further Work

This research set out to develop a broadly applicable tool for separating concerns that was easy to adopt alongside existing development practices. This chapter summarises the findings of this research and discusses future directions for Concern Maps.

5.1.1. Conclusions

Concern Maps combine a lightweight graphical language with an extensible set of query languages for associating development artefacts with parts of a diagram. The Concern Map tool automates the process of moving from high-level concern description to related development artefacts. This unifies the abstract description of the concern provided by the diagram with its realisation, allowing users to understand the structure of a concern and view related development artefacts.

This approach was useful for separating concerns in a range of scenarios, including scenarios involving multiple programming languages and documents. The use of dynamically evaluated Selector expressions allowed Concern Maps to be applied to a range of software system exhibiting crosscutting concerns without changing system artefacts. This non-invasive approach removes many of the barriers to adoption experienced with aspect-oriented programming.

The Concern Map approach was less effective when dealing with word processing documents, UML models and spreadsheets. This was because of the limited capabilities of the Selector languages and less effective integration with programs like Microsoft Word, as described in 4.8.1. However, the ability to add new query languages to the tool means this situation could be improved.

5.1.2. Further Work

Integration with word processing and other documents lags behind source code in the Concern Map tool. New Selector languages could be developed to address individual

95 types of documents, or a search engine program could be integrated into the tool as discussed in section 3.7. Further work is also needed to open matching documents at the correct position, rather than at the start or default position, as discussed in 4.8.1.

The tool could also be improved by providing automatic generation of Selector expressions or entire Concern Maps. The generation of individual Selectors is suggested by work on the Software Views Inducer [80]. Techniques to reverse engineer patterns from source code, for example the recognisers described by Yeh, Harris and Chase [89], could be used to identify instances of particular cross-cutting patterns like the six scenarios used in this research. Concern Maps could then be automatically generated for those recognised patterns.

Lastly, the Concern Map tool suffers in comparison to AOP languages because of its weak editing capabilities as described in 4.8.2. The combination of Concern Maps with refactoring tools to automate repetitive edits could lessen the burden of change for Concern Map users.

Bibliography

1. Microsoft Corporation, Visual Studio 2005. 2005 http://lab.msdn.microsoft.com/vs2005/, last accessed July 17th 2006. 2. Microsoft Corporation, Domain Specific Language Tools. 2005 http://msdn.microsoft.com/vstudio/DSLTools/, last accessed July 17th 2006. 3. Parnas, D.L., On The Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 1972. 15(12): p. 1053 - 1058. 4. Ossher, H. and P. Tarr, Multi-dimensional Separation of Concerns and The Hyperspace Approach. Proceedings of the Symposium on Software Architectures and Component Technology: The State of the Art in Software Development, 2000. 5. Turner, C.R., A.L. Wolf, A. Fuggetta, and L. Lavazza. Feature Engineering. in International Workshop on Software Specifications & Design, Proceedings of the 9th international workshop on Software specification and design. 1998: IEEE Computer Society. 6. Hachani, O. and D. Bardou. Using Aspect-Oriented Programming for Design Patterns Implementation. in Position paper at the Reuse in Object-Oriented Information Systems Design workshop. 8th International Conference on Object-Oriented Information Systems (OOIS 2002). 2002. Montpellier, France. 7. Hannemann, J. and G. Kiczales, Design Pattern Implementation in Java and AspectJ. Proceedings of the 17th OOPSLA Conference, 2002: p. 161 - 173. 8. Sefika, M., A. Sane, and R.H. Campbell. Monitoring Compliance of a Software System With Its High-Level Design Models. in Proceedings of the 18th international conference on Software engineering. 1996. Berlin, Germany: IEEE Computer Society, Washington, DC, USA. 9. Soares, S., E. Laureano, and P. Borba. Implementing distribution and persistence aspects with AspectJ. in Proceedings of OOPSLA'02, Object Oriented Programming Systems Languages and Applications. 2002: ACM Press. 10. Duclos, F., J. Estublier, and P. Morat, Describing and Using Non Functional Aspects in Component Based Programs. Proceedings of AOSD 2002, 2002. 11. Dantas, A. and P. Borba, Developing Adaptive J2ME Applications Using AspectJ. 7th Brazilian Symposium on Programming Languages, Journal of Universal Computer Science, 2003. 9(8). 12. Lopes, C.V. and W.L. Hursch, Separation of Concerns. 1995, Northeastern University: Boston MA. 13. Kiczales, G., Aspect Oriented Programming The Fun Has Just Begun. Workshop on New Visions for Software Design and Productivity, 2001: p. 5. 14. Tarr, P., H. Ossher, W. Harrison, and S.M. Sutton. N Degrees of Separation: Multi- Dimensional Separation of Concerns. in Proceedings of the 21st international conference on Software engineering. 1999. Los Angeles, California, United States: IEEE Computer Society Press Los Alamitos, CA, USA. 15. Lopes, C.V., E. Hilsdale, J. Hugunin, M. Kersten, and G. Kiczales, Illustrations of Crosscutting. Workshop at ECOOP 2000, 2000.

97 16. Kienzle, J. and R. Guerraoui. AOP: Does it Make Sense? The Case of Concurrency and Failures. in Proceedings of the 16th European Conference on Object-Oriented Programming - ECOOP 2002. 2002: Springer-Verlag. 17. Kiczales, G., J. Lamping, A. Mendhekar, C. Maeda, C.V. Lopes, J.-M. Loingtier, and J. Irwin, Aspect-Oriented Programming. European Conference of Object Oriented Programming (ECOOP), 1997: p. 220 - 242. 18. Mendhekar, A., G. Kiczales, and J. Lamping, RG: A Case Study for Aspect-Oriented Programming. 1997, Xerox PARC: Palo Alto. 19. Greenfield, J., K. Short, S. Cook, and S. Kent, Software Factories. 2004, Indianapolis: Wiley Publishing, Inc. 666. 20. Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns. Addison-Wesley Professional Computing Series. 1995, Boston: Addison-Wesley. 21. Hirschfeld, R., R. Lammel, and M. Wagner. Design Patterns and Aspects Modular Designs with Seamless Run-Time Integration. in Proceedings of the Workshop on Aspect-Oriented Software Development of the German Informatics Society. 2003. Essen, Germany. 22. Nordberg, M.E. Aspect-oriented dependency inversion. in Proceedings of the OOPSLA Workshop on Advanced Separation of Concerns in Object-Oriented Systems. 2001. Tampa, Florida. 23. Hachani, O. and D. Bardou. On Aspect-Oriented Technology and Object-Oriented Design Patterns. in Position paper at the Analysis of Aspect-Oriented Software workshop. European Conference on Object-Oriented Programming (ECOOP 2003). 2003. Darmstadt, Germany. 24. Beck, K. and E. Gamma, Test Infected: Programmers Love Writing Tests. Java Report, 1998. 3(7): p. 37 - 50. 25. Martin, R., Agile Software Development Principles, Patterns, and Practices. 2003, Upper Saddle River: Prentice Hall. 529. 26. Gamma, E., E. Meade, and K. Beck, jUnit. 2005 http://sourceforge.net/projects/junit/, last accessed July 17th 2006. 27. Two, M.C., C. Poole, J. Cansdale, and G. Feldman, NUnit. 2005 http://www.nunit.org/, last accessed July 11th 2006. 28. Purcell, S., PyUnit. 2005 http://pyunit.sourceforge.net/, last accessed July 17th 2006. 29. Suketa, M., RubyUnit. 2005 http://homepage1.nifty.com/markey/ruby/rubyunit/index_e.html, last accessed July 17th 2006. 30. Gälli, M., O. Nierstrasz, and S. Ducasse, One-Method Commands: Linking Methods and Their Tests. OOPSLA'04 Workshop on Revival of Dynamic Languages, 2004. 31. Shaw, M. and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. 1996, London: Prentice Hall. 242. 32. Bachmann, F., L. Bass, J. Carriere, P. Clements, D. Garlan, J. Ivers, R. Nord, and R. Little, Software Architecture Documentation in Practice: Documenting Architectural Layers. 2000, Carnegie Mellon University, Software Engineering Institute. 33. Object Management Group, OMG Unified Modeling Language Specification Version 1.5. 2003, Object Management Group. 34. Zachman, J.A., A Framework for Information Systems Architecture. IBM Systems Journal, 1987. 26(3).

98 35. ISO, Reference Model of Open Distributed Processing Part 2: Foundations International Standard ISO/IEC 10746-2. 1995. 36. Gotel, O.C.Z. and C.W. Finkelstein, An analysis of the requirements traceability problem. Proceedings of the First International Conference on Requirements Engineering, 1994: p. 94 -101. 37. Clarke, S., W. Harrison, P. Tarr, and H. Ossher, The Dimension of Separating Requirements Concerns for the Duration of the Development Lifecycle. 1999. 38. Olsson, T. and J. Grundy. Supporting Traceability and Inconsistency Management between Software Artifacts. in SEA'02 - Software Engineering and Applications. 2002. Cambridge, Mass.: IASTED Press. 39. Hayes, J.H., A. Dekhtyar, and J. Osborne, Improving Requirements Tracing via Information Retrieval. Proceedings of the 11th IEEE International Conference on Requirements Engineering, 2003: p. 138. 40. Ramesh, B., Factors influencing requirements traceability practice. Communications of the ACM, 1998. 41(12): p. 37 - 44. 41. Jackson, J., A keyphrase based traceability scheme. Tools and Techniques for Maintaining Traceability During Design, IEE Colloquium on 2 Dec 1991, 1991: p. 2/1 - 2/4. 42. Eclipse.org, AspectJ Development Tools. 2004 http://eclipse.org/ajdt/, last accessed July 17th 2006. 43. Rajan, H. and K. Sullivan. Need for Instance Level Aspect Language with Rich Pointcut Language. in In the proceedings of the Workshop on Software Engineering Properties of Languages for Aspect Technologies (SPLAT) held in conjunction with International Conference on Aspect-Oriented Software Development. 2003. Boston, Massachusetts. 44. Panas, T., J. Karlsson, and M. Hogberg, Aspect-jEdit for Inline Aspect Support. Proceedings of the 3rd German Workshop on Aspect Oriented Software Development, Technical Report of the University of Essen, March 2003, 2003. 45. Douence, R., O. Motelet, and M. Sudholt, A formal definition of crosscuts. 2001, École des Mines de Nantes: Nantes. 46. Filman, R.E. and D.P. Friedman. Aspect-Oriented Programming is Quantification and Obliviousness. in Workshop on advanced separation of concerns, OOPSLA 2000. 2000. Minneapolis. 47. Walker, D., S. Zdancewic, and J. Ligatti, A Theory of Aspects. Proceedings of ICFP 2003, 2003: p. 127 - 139. 48. Kiczales, G., E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W.G. Griswold, An Overview of AspectJ. Proceedings of the European Conference on Object-Oriented Programming, Budapest, Hungary, 2001: p. 327 - 353. 49. Gosling, J., B. Joy, G. Steele, and G. Bracha, The Java Language Specification, Second Edition. 2000, Sun Microsystems, Inc.: Santa Clara. 50. Tucker, D. and S. Kirshnamurthi. Pointcuts and Advice in Higher Order Languages. in In Proceedings of the 2nd International Conference on Aspect-Oriented Software Development. 2003. Boston, Massachusetts: ACM Press New York, NY, USA. 51. Hirschfield, R., Aspect-Oriented Programming with AspectS. Lecture Notes in Computer Science: Objects, Components, Architectures, Services, and Applications for a NetworkedWorld: International Conference NetObjectDays, NODe 2002, 2002.

99 52. Spinczyk, O., A. Gal, and D. Lohman. Aspect-Oriented Programming with C++ and AspectC++. in Tutorial at AOSD 2004. 2004. Lancaster UK. 53. Kim, H., AspectC#: An AOSD implementation for C#. 2002. 54. Coady, Y., G. Kiczales, M. Feeley, and G. Smolyn, Using AspectC to Improve the Modularity of Path-Specific Customization in Operating System Code. Proceedings of ESEC/FSE 2001, 2001: p. 88 - 98. 55. Kniesel, G., P. Costanza, and M. Austermann, JMangler - A Powerful Back-End for Aspect-Oriented Programming, in Aspect-oriented Software Development, R.E. Filman, et al., Editors. 2004, Prentice Hall. 56. Lafferty, D. and V. Cahill, Language-Independent Aspect-Oriented Programming. 2003. 57. JBoss, JBoss AOP. 2005 http://labs.jboss.com/portal/jbossaop/index.html, last accessed July 17th 2006. 58. Johnson, R., J. Hoeller, A. Arendsen, C. Sampaleanu, R. Harrop, T. Risberg, D. Davison, D. Kopylenko, M. Pollack, and T. Templier, Spring - Java/J2EE Application Framework Reference Documentation Version 1.2.3. 2005, www.springframework.org, last accessed July . 59. Tarr, P. and H. Ossher, Hyper/J User and Installation Manual. 2000. 60. Mezini, M., L. Seiter, and K. Lieberherr, Component Integration with Pluggable Composite Adapters, in Software Architectures and Component Technology: The State of the Art in Research and Practice, M. Aksit, Editor. 2000, Kluwer. 61. Bergmans, L. and M. Aksit, Composing Multiple Concerns Using Composition Filters. Communications of the ACM, 2001(October 2001). 62. Constantinides, C., A. Bader, and T. Elrad, A framework to address two-dimensional composition of concerns. Position paper to the Object-Oriented Programming, Systems, Languages and Applications (OOSPLA'99). First Workshop on Multi-Dimensional Separation of Concerns in Object-Oriented Systems, 1999. 63. Popovici, A., G. Alonso, and T. Gross. Spontaneous Container Services. in Proceedings of the 17th European Conference for Object-Oriented Programming. 2003. Darmstadt, Germany. 64. Popovici, A., T. Gross, and G. Alonso. Just-In-Time Aspects: Efficient Dynamic Weaving For Java. in Proceedings of the 2nd International Conference on Aspect- Oriented Software Development. 2003. Boston MA. 65. Lopes, C.V., P. Dourish, D.H. Lorenz, and K. Lieberherr, Beyond AOP: Towards Naturalistic Programming. OOPSLA 2003, 2003. 66. Lieberherr, K. and D. Orleans, Preventive Program Maintenance In Demeter / Java. Proceedings of ICSE 97, 1997. 67. Shonle, M., K. Lieberherr, and A. Shah, XAspects: An Extensible System for Domain- Specific Aspect Languages. Proceedings of OOPSLA 2003, 2003: p. 28 - 37. 68. Walker, R.J., E.L.A. Baniassad, and G.C. Murphy. An Initial Assessment of Aspect- oriented Programming. in Proceedings of 21st International Conference on Software Engineering. 1999. Los Angeles, California, United States: IEEE Computer Society Press Los Alamitos, CA, USA. 69. Opdyke, W., Refactoring Object-Oriented Frameworks Tech. Report UIUCDCS-R-92- 1759, in Dept. of Computer Science. 1992, University of Illinois at Urbana-Champaign: Urbana-Champaign, IL, USA.

100 70. Fowler, M., Refactoring. Object Technology Series, ed. G. Booch, I. Jacobson, and J. Rumbaugh. 2000, Boston: Addison Wesley. 71. Roberts, D., J. Brant, and R. Johnson, A refactoring tool for Smalltalk. Theory and Practice of Object Systems, 1997. 3 Special issue object-oriented software evolution and re-engineering(4): p. 253 - 263. 72. Refactory Inc, Refactoring Browser. 2005 http://www.refactory.com/RefactoringBrowser/, last accessed July 17th 2006. 73. JetBrains, ReSharper 1.5. 2005 http://www.jetbrains.com/resharper/, last accessed July 17th 2006. 74. JetBrains, IntelliJ. 2005 http://www.intellij.org/, last accessed July 17th 2006. 75. Mens, K., T. Mens, and M. Wermelinger, Maintaining Software Through Intentional Source-code views. Proceedings of the 14th international conference on Software engineering and knowledge engineering, 2002: p. 289 - 296. 76. Chu-Carroll, M.C., J. Wright, and A. Ying, Visual separation of concerns through multidimensional program storage. Proceedings of the 2nd international conference on Aspect-oriented software development, 2003: p. 188 - 197. 77. Wuyts, R., Declarative Reasoning about the Structure of Object-Oriented Systems. Proceedings of TOOLS-USA 98, 1998: p. 13. 78. Mens, K. and B. Poll, Supporting Software Maintenance and Evolution with Intentional source-code Views. 2003: p. 6. 79. Mens, K., B. Poll, and S. Gonzalez, Using Intentional Source-Code Views To Aid Software Maintenance, in Proceedings of International Conference on Software Maintenance (ICSM'03). 2003: Amsterdam, The Netherlands. p. 169 - 178. 80. Kellens, A., Using Inductive Logic Programming to Derive Software Views, in Departement Informatica en Toegepaste Informatica. 2003, Vrije Universiteit: Brussels. 81. Robillard, M.P. and G.C. Murphy, Concern Graphs: Finding and Describing Concerns using Structural Program Dependencies. International Conference On Software Engineering 2002, 2002. 82. Griswold, W.G., J. Yuan, and Y. Kato, Exploiting the Map Metaphor in a Tool for Software Evolution. Proceedings of the 23rd International Conference on Software Engineering, 2001: p. 265-274. 83. Yuan, J., Using the Map Metaphor to Assist Cross-Cutting Software Changes, in Faculty of Science. 2000, University of California: San Diego. p. 62. 84. Muller, H.A., S.R. Tilley, M. Orgun, B.D. Corrie, and N.H. Madhavji, A reverse engineering environment based on spatial and visual software interconnection models. ACM SIGSOFT Software Engineering Notes , Proceedings of the fifth ACM SIGSOFT symposium on Software development environments, 1992. 17(5): p. 88 - 98. 85. Muller, H.A., S.R. Tilley, and K. Wong, Software evolution: Understanding software systems using reverse engineering technology perspectives from the Rigi project. Proceedings of the 1993 conference of the Centre for Advanced Studies on Collaborative research: software engineering - Volume 1, 1993. 86. Storey, M., K. Wong, F.D. Fracchia, and H.A. Muller, On Integrating Visualisation Techniques for Effective Software Exploration. Proceedings of IEEE Symposium on Information Visualization, 1997, 1997.

101 87. Storey, M.-A.D., H.A. Muller, and K. wong, Manipulating And Documenting Software Structures. Proceedings of the 1995 International Conference on Software Maintenance, 1995. 88. Collberg, C., S. Kobourov, J. Nagra, J. Pitts, and K. Wampler, Visualization for program understanding: A system for graph-based visualization of the evolution of software. Proceedings of the 2003 ACM symposium on Software visualization, 2003: p. 77 - 86. 89. Yeh, A.S., D.R. Harris, and M.P. Chase, Manipulating Recovered Software Architecture Views. Proceedings of ICSE 97, 1997: p. 184 - 194. 90. Walker, R.J., G.C. Murphy, J. Steinbok, and M.P. Robillard. Efficient Mapping Of Software System Traces To Architectural Views. in Proceedings of the 2000 conference of the Centre for Advanced Studies on Collaborative research. 2000. Mississauga, Ontario, Canada: IBM Press. 91. Consens, M., A. Mendelzon, and A. Ryman, Design technologies: Visualizing and querying software structures. Proceedings of the 1991 conference of the Centre for Advanced Studies on Collaborative research, 1991: p. 17 - 35. 92. Miller, J. and J. Mukerji, MDA Guide Version 1.0.1. 2003, Object Management Group. 93. Object Management Group, XML Metadata Interchange (XMI) Specification. 2003, Object Management Group. 94. Object Management Group, Meta Object Facility (MOF) Specification. 2002, Object Management Group. 95. Mellor, S.J., K. Scott, A. Uhl, and D. Weise, MDA Distilled. Object Technology Series, ed. G. Booch, J. Rumbaugh, and I. Jacobson. 2004, Boston: Addison Wesley. 96. Bezivin, J. From Object Composition to Model Transformation with the MDA. in TOOLS'USA. 2001. Santa Barbara. 97. Interactive Objects, ArcStyler. 2005 http://www.interactive-objects.com/, last accessed July 17th 2006. 98. Bohlen, M., C. Brandon, W. Zoons, M. West, C. Cuenca, and P. Friese, AndroMDA. 2005 http://www.andromda.org/, last accessed July 17th 2006. 99. Froidevaux, W., H. Burger, A. Nyffenegger, D. Mueller, B. Studer, and D. Mueller, OpenMDX. 2005 http://www.openmdx.org/, last accessed July 17th 2006. 100. Compuware, OptimaJ. 2005 http://www.compuware.com/products/optimalj/default.htm, last accessed July 16th 2006. 101. IBM Corporation, IBM Rational Rose. 2005 http://www-306.ibm.com/software/rational/, last accessed July 17th 2006. 102. Codesmith Tools, Codesmith. 2005 http://www.codesmithtools.com/, last accessed July 17th 2006. 103. JetBrains, Fabrique. 2005 http://www.jetbrains.com/fabrique/, last accessed July 17th 2006. 104. Bosch, J., Design & Use of Software Architectures. 2000, Harlow, England: ACM Press. 354. 105. Lefering, M., Software Document Integration Using Graph Grammar Specifications. Proceedings of the 6th International Conference on Computing and Information, Journal of Computing and Information, 1994: p. 1222 -1243. 106. Ambriola, V. and V. Gervasi. Supporting Multiple Views on Requirements. in Proceedings of the 6th Maghrebian Conference on Computer Sciences. 2000. Fes.

102 107. Grünbacher, P., A. Egyed, and N. Medvidovic. Dimensions of Concerns in Requirements Negotiation and Architecture Modeling. in Proceedings of the Workshop on MultiDimensional Separation of Concerns in Software Engineering (held in conjunction with the ACM 22nd International Conference on Software Engineering). 2000. Limerick, Ireland. 108. Warmer, J., Discussion Report on EMWDA Working Group on ‘MDA is the Wrong Answer?, from Second European Workshop on Model Driven Architecture (MDA), September 7th-8th 2004. 2004, University of Kent: Canterbury, England. 109. DeWin, B., W. Joosen, and F. Piessens. AOSD & Security: a practical assessment. in Workshop on Software Engineering Properties of languages for Aspect Technologies (SPLAT03). 2003. Boston, Massachusetts, USA. 110. Simonyi, C., Aspect Oriented Programming: Asymptotic Fun? Workshop on New Visions for Software Design and Productivity, 2001: p. 7. 111. Colyer, A. Towards Widespread Adoption of AOSD. in Presentation to 1st International Workshop on the Commercialization of AOSD. 2003. Boston MA. 112. Tourwe, T., J. Brichau, and K. Gybels. On the Existence of the AOSD-Evolution Paradox. in AOSD 2003 Workshop on Software-engineering Properties of Languages for Aspect Technologies. 2003. Boston, Massachusetts, USA. 113. Bruce, D. and N. Exon. Alternatives to Aspect-Oriented Programming? in Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns. 2001. Lancaster, UK. 114. Groher, I. and S. Schulze, Generating Aspect Code from UML Models. Submission for Workshop on Aspect-Oriented Modelling with UML, AOSD 2003, 2003. 115. Katara, M. and S. Katz, Architectural Views of Aspects. Proceedings of AOSD 2003, 2003: p. 1 - 10. 116. Kienzle, J., Y. Yu, and J. Xiong, On Composition and Reuse of Aspects. FOAL 2003 Proceedings, Foundations of Aspect-Oriented Languages Workshop at AOSD 2003, 2003. 117. Tilley, S.R., H.A. Muller, and M. Orgun, Documenting Software Systems with Views. Proceedings of SIGDOC '92, 1992: p. 211 - 219. 118. Consens, M. and A. Mendelzon, Hy+: a Hygraph-based query and visualization system. Proceedings of the 1993 ACM SIGMOD international conference on Management of data, 1993: p. 511 - 516. 119. Issarny, V., T. Saridakis, and A. Zarras, Multi-View Description of Software Architectures. In Proceedings of the 3rd ACM SIGSOFT International Software Architecture Workshop, 1998. 120. Fowler, M., UMLAsSketch. 2004, http://www.martinfowler.com/bliki/UmlAsSketch.html. 121. Tourwe, T., J. Brichau, A. Kellens, and K. Gybels, Induced Intentional Software Views. Special Edition of Elsevier's Computer Languages, Systems & Structures Journal, 2004. 30(1-2): p. 35 - 47. 122. Gybels, K. and J. Brichau, Arranging Language Features for More Robust Pattern- based Crosscuts. Proceedings of AOSD 2003, 2003: p. 60 - 69. 123. Crew, R.F., ASTLOG: A language for examining abstract syntax trees. In Proceedings of the USENIX Conference on Domain-Specific Languages, 1997: p. 229 - 242.

103 124. Janzen, D. and K. De Volder, Navigating and querying code without getting lost. Proceedings of the 2nd international conference on Aspect-oriented software development, 2003: p. 178 - 187. 125. Eichberg, M., M. Mezini, and K. Ostermann, Pointcuts as Functional Queries. In The Second ASIAN Symposium on Programming Languages and Systems (APLAS 2004), 2004. 126. Collard, S., J. Maletic, and A. Marcus, Supporting Document and Data Views of Source Code. Proceedings of DocEng '02, 2002: p. 34 - 41. 127. Corney, D., PERWAPI. 2005, Queensland University of Technology: Brisbane http://www.plas.fit.qut.edu.au/perwapi/Default.aspx, last accessed July 17th 2006. 128. Peterson, M.D., D. Demsak, K. Cagle, R. Miles, T. Jordan, C. Bayes, R. Humphris, and M. Dunn, Saxon.Net. 2005 http://sourceforge.net/projects/saxondotnet/, last accessed July 17th 2005. 129. Google, Google Desktop Search. 2005 http://desktop.google.com/, last accessed July 17th 2006. 130. MSN, MSN Desktop Search. 2005 http://www.imagine- msn.com/search/tour/desktop.aspx, last accessed July 17th 2006. 131. Yes Software, CodeCharge Studio. 2005 http://www.yessoftware.com/products/product_detail.php?product_id=1, last accessed July 17th 2006. 132. ARTech, DeKlarit. 2005 http://www.deklarit.com, last accessed July 17th 2006. 133. Eeles, P., Layering Strategies. The Rational Edge, 2001. October 2001.

104 Appendix 1 – Project Source Code

The full source code for the Concern Maps system along with supporting materials can be downloaded from http://www.patrickcooney.com/concernmaps.

105