Unifying Abstractions and Code with Concern...

i

Unifying Abstractions and Code

with Concern Maps

by

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

© Patrick Cooney 2006

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

ii

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

iii

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.

iv

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

v

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

vi

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

vii

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.4. Scenario 3 – Design Pattern Implementation ................................................. 69

viii

4.4.1. Scenario overview................................................................................... 69

4.4.2. Example .................................................................................................. 69

4.4.3. Applying Concern Maps ......................................................................... 70



4.5. Scenario 4 – Architecture and Code ............................................................... 73

4.5.1. Scenario Overview.................................................................................. 73

4.5.2. Example .................................................................................................. 74




4.6. Scenario 5 – Documents and Code ................................................................. 78


4.6.2. Example .................................................................................................. 79




4.7. Scenario 6 – Tests and Code........................................................................... 85


4.7.2. Example .................................................................................................. 86




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

1

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

2

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

3

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.

4

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.

5

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

implementation

A design pattern, which can be considered a

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].

6

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

implementation

The observer pattern implemented across basic

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

7

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

8

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.

9

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:

10

• 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

Code scattering

Design patterns

Relating code and tests

Aspect orientation

Code visualisation

Model-driven development

Between design and Disconnected models Model-driven development

11

source code Reverse-engineering models

Requirements and code

and design

Traceability between

stages

Traceability tools

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.

12

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

13

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.

14

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.

15

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

16

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].

17

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

18

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,

19

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

20

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

21

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

22

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

23

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

24

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

25

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

26

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,

27

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]

28

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]

29

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

30

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.


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.


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.


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.


31

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.


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.


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

32

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

33

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".

34

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

35

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

36

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:

37

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.

38

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

39

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.

40

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.

41

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

42

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.

43

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.

44

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:

45

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

Output Handlers

Provides advanced editing capabilities for Selectors

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

Languages

Evaluates Selector expressions

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

46

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.

47

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]

48

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

49

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.

50

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.

51

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.

52

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

53

• 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.

54

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

55

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 File Mechanism Control

& Variation Mechanism.cmp

Concern Map file mechanism.cmp.

File Core Persistence

Functionality CorePersistence.cmp

Concern Map file

corepersistence.cmp.

File Data Collection

Variation Collection_variation.cmp

Concern Map file

collection_variation.cmp.

File Persisting Data

Transaction.cmp

Concern Map file transaction.cmp.

File Transaction Control

Persisting.cmp

Concern Map file persisting.cmp.

Table 7 Selectors for persistence Concern Map

Core Persistence Functionality

56

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 XPath Persistence

Mechanism //interface[@name='IPersistenceMechanism']

Interface IPersistenceMechanism

TypeNamed Persistence

Mechanism DatabasePersistenceMechanism

Class DatabasePersistenceMechanism

TypeNamed Data Collections

PersistentComplaintData

Class PersistentComplaintData

TypeNamed Data Collections

VolatileComplaintData

Class 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'.

57

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 XPath Configuration

//class[@name='HealthWatcherFacade']

//method[@name='GetAndInitialisePersistence']

Method GetAndInitialisePersistence

in class HealthWatcherFacade.

CallsMethod Configuration

GetAndInitialisePersistence

All calls to method

GetAndInitialisePersistence, in this

case matching three methods within

the façade: AddComplaint,

UpdateComplaint, DeleteComplaint.

XQuery Error handling

cleanup for $m in

//class[@name='HealthWatcherFacade']//method

where $m//methodCall[@name='Cleanup']

[@type='IPersistenceMechanism']

return $m

Within class HealthWatcherFacade,

any method that calls the method

Cleanup on the type

IPersistenceMechanism, in this case

the three methods listed in the

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.

58

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.

59

Concept Node Selector Type & Expression Selects XQuery Start Transaction

for $m in


where

$m//methodCall[@name='StartTransaction']

[@type='IPersistenceMechanism'] return $m

Any methods in class

HealthWatcherFacade that call into

StartTransaction on type

IPersistenceMechanism. In this case,

matching three methods

AddComplaint, UpdateComplaint

and DeleteComplaint.

XQuery Commit

Transaction for $m in


where

$m//methodCall[@name='CommitTransaction']


As per the previous section, but

matching calls to

CommitTransaction.

XQuery Rollback

Transaction for $m in


where

$m//methodCall[@name='RollbackTransaction']


As per the previous section, but

matching calls to

RollbackTransaction.

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.

60

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 XQuery Add

for $m in //method where

$m//methodCall[@name='Add']

[@type='IBusinessData']

return $m

Any method that calls the method

Add on the type IBusinessData. In

this case, matches method Add in

class ComplaintRecord

XQuery Update

for $m in //method where

$m//methodCall[@name='Update']

[@type='IBusinessData']

return $m

Any method that calls the method

Update on the type IBusinessData.

In this case, matches method Update

in class ComplaintRecord

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.

61

Figure 16 Data Collection Variation Point concern

Concept Node Selector Type & Expression Selects XQuery Data Collection

Variation Point for $m in //method

for $tname in

$m//methodCall[@name='.ctor']/@type

for $c in //class[@name=$tname]

where $c[implements='IBusinessData']

return $m

Any method that calls a constructor

(.ctor) on a type that implements the

interface IBusinessData. In this

example matches the method

GetBusinessData in class

HealthWatcherFacade.

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

62

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.

63

4.3. Scenario 2 – Feature De-Localisation


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

64

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.


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.


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.

65

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.

66

Concept

Node Selector Type & Expression Selects

File Order

..\..\Order.aspx

The file Order.aspx stored in the web site

project directory.

XPath Order

//class[@name='Facade']

//method[contains(@name,'Order')]

Any method in the class Façade containing

the phrase 'Order'. In this case, matches the

three methods AddOrder, UpdateOrder and

SearchForOrder.

TypeNamed Order

Operations.Order

Class named Operations.Order.

TypeNamed Order

DatabaseOps.OrderDB

Class named DatabaseOps.OrderDB

File Order

..\Database\Queries\AddOrder.sql

..\Database\Queries\SearchOrder.sql

..\Database\Queries\UpdateOrder.sql

The files AddOrder.sql, SearchOrder.sql

and UpdateOrder.sql in the Queries

directory of the Database project.

File Product

..\..\Product.aspx

The file Product.aspx stored in the web site

project directory.

XPath Product


//method[contains(@name,'Product')]


the phrase 'Product'. In this case, matches

the three methods AddProduct,

UpdateProduct and SearchForProduct.

TypeNamed Product

Operations.Product

Class named Operations.Product.

67

Concept

Node Selector Type & Expression Selects

TypeNamed Product

DatabaseOps.ProductDB

Class named DatabaseOps.ProductDB

File Product

..\Database\Queries\AddProduct.sql

..\Database\Queries\SearchProduct.sql

..\Database\Queries\UpdateProduct.sql

The files AddProduct.sql, SearchProduct.sql

and UpdateProduct.sql in the Queries


File Customer

..\..\Customer.aspx

The file Customer.aspx stored in the web

site project directory.

XPath Customer


//method[contains(@name,'Customer')]


the phrase 'Customer'. In this case, matches

the three methods AddCustomer,

UpdateCustomer and SearchForCustomer.

TypeNamed Customer

Operations.Customer

Class named Operations.Customer.

TypeNamed Customer

DatabaseOps.CustomerDB

Class named DatabaseOps.CustomerDB

Customer File

..\Database\Queries\AddCustomer.sql

..\Database\Queries\SearchCustomer.sql

..\Database\Queries\UpdateCustomer.sql

The files AddCustomer.sql,

SearchCustomer.sql and

UpdateCustomer.sql in the Queries


Table 13 Selectors for order, product and customer Concern Map


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].

68

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.


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.

69

4.4. Scenario 3 – Design Pattern Implementation


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.

70


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.


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.

71

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.

72

Concept Node Selector Type & Expression Selects TypeNamed Abstract Subject

Subject

The type named Subject.

ExtendsType Concrete Subjects

Subject

Any class that inherits from Subject,

in this case the Point and Line

classes.

CallsMethod Notifications

Notify

Any method calling into the method

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.

ImplementsInterface Observer

IObserver

Any class implementing the

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.


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.

73


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.

74

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.

75

Figure 20 UML Deployment diagram


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.


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

various artefacts:

76

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 File Deployment Model

..\..\Deployment.vsd

The deployment.vsd file.

File Package Model

..\..\Package.vsd

The package.vsd file.

File Implementation

Layers.cmp

The layers.cmp file.

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:

77

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 InNamespace Presentation Logic

Presentation

Any class within the namespace

Presentation, in this case the classes

CustomerView, OrderView and

ProductView.

InNamespace Business Logic

Business


Business, in this case the classes

Customer, Order and Product.

InNamespace Data Access Logic

DataAccess


DataAccess, in this case the classes

CustomerData, OrderData and

ProductData.

File Implementation

..\Database\Queries\AddCustomer.sql

..\Database\Queries\UpdateCustomer.sql

..\Database\Queries\AddOrdersql

..\Database\Queries\UpdateOrder.sql

..\Database\Queries\AddProduct.sql

..\Database\Queries\UpdateProduct.sql

Stored procedure files.

Table 16 Selectors for layers Concern Map

78


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.


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


Some concerns involve information in specification documents and implementation in

source code. This scattering of information makes it more difficult to understand the

79

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).

80

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.

81

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.


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.


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.

82

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.

83

Concept Node Selector Type & Expression Selects XPath Implementation

//method[@name='Cost']

The Cost method within the Order

class.

Regular Expression Requirements

>>>Pricing<<<

The Word document 'Order

Management Functional

Requirements.doc' which contains

the matching metadata tag.

Regular Expression Test Scenarios

>>>PricingTests<<<

The Excel document Tests.xls

containing the matching metadata

tag.

XPath Test

Implementation //class[@namespace='Tests']

/method[//methodCall/@name='Cost']

Any method in the namespace

'Tests' that calls into the method

'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.

84

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 ExtendsType Implementation

Business.Discount

Any class that extends the class

Business.Discount. In this case,

matches the classes AmountOff and

PercentageOff.

Regular Expression Requirements

>>>DiscountTypes<<<

The Word documents 'Order

Management Functional

Requirements.doc' and 'Business

Rule Requirements.doc' which

contain the matching metadata tag.

File Data Setup

..\Database\Create Scripts\SetupDiscounts.sql

The SQL file used to set up discount

data in the database.

Table 18 Selectors for discounts Concern Map

85


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.


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


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.

86

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.


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.

87


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.

88

Concept Node Selector Type & Expression Selects XPath Equality

//class[@name='Money']/method[@name='Equals']

The Equals method within the

Money class.

XPath Equality

//method

[attribute/@type='NUnit.Framework.TestAttribute']

[body/methodCall/@name='Equals']

Any NUnit test (as indicated by

the custom NUnit attribute) that

calls into a method Equals, in this

case the method TestEquality in

the tests class.

XPath Addition

//class[@name='Money']/method[@name='Add']

The Add method within the

Money class.

XPath Addition

//method

[attribute/@type='NUnit.Framework.TestAttribute']

[body/methodCall/@name='Add']

Any NUnit test (as indicated by

the custom NUnit attribute) that

calls into a method Add, in this

case the method TestAddition in

the tests class.

Table 19 Selectors for equality and addition Concern Map


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.

89

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.


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

90

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.


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.

91

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.


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.


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

92

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

all six examples.


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.


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.


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

93

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

94

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.

95

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

96

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.

97

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.

98

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).

99

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.

100

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.

101

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.

102

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.

103

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.

104

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.

105

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.

Date post:	07-Aug-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times