Aspect-Oriented Requirements Engineering

A Systematic Mapping

Paulo Afonso Parreira Júnior

1,2

and Rosângela Aparecida Dellosso Penteado

Departament of Computer Science, Federal University of São Carlos, São Carlos, Brazil

Computer Science Course, Federal University of Goiás/Campus Jataí, Jataí, Brazil

Keywords: Systematic Mapping, Concern Identification and Classification, Aspect-Oriented Requirements

Engineering, Crosscutting Concerns.

Abstract: Background: Aspect-Oriented Requirements Engineering (AORE) is a research field that provides the most

appropriate strategies for identification, modularization and composition of crosscutting concerns. Several

AORE approaches have been developed recently, although with different features, strengths and limitations.

Goals: the aim of this paper is threefold: i) cataloguing existing AORE approaches based on the activities

encompassed by them; ii) describing what types of techniques have been used for concern identification and

classification – a bottleneck activity; and iii) identifying which are the most used means of publication of

AORE-based studies and how it has been the progress of these studies over the years. Results: we have

selected and analyzed 60 papers and among them, we identified 38 AORE distinct approaches. Some

interesting obtained results were: i) few approaches lead to Conflict Identification and Resolution, an

activity responsible for discovering and treating the mutual influence between different concerns existing in

a software; ii) the most of 60 studies consist of presenting new AORE approaches or extensions of previous

approaches - therefore, there is a lack of evaluation studies about already existing approaches; iii) few

studies have been published in journals, what can be a consequence of the item (ii).

1 INTRODUCTION

The Requirements Engineering (RE) encompasses

activities related to the elicitation and analysis of

information about the software: its requirements.

Each sub-activity (or task) performed during

requirements elicitation will result in a document

with the textual description of all the software

requirements. This document is then analyzed and

requirements are structured in individual units, such

as viewpoints, goals, use cases, scenarios. This is

done in order to promote the separation of Concerns

- SoC (Dijkstra, 1976), i. e., the identification and

modularization of pieces of the software that are

relevant for a particular purpose.

In the context of RE, a “concern” can be

understood as a set of one or more software

requirements for a given purpose. For example, a

security concern can encompass several

requirements related to the following goal:

“guarantying that software is secure”.

In an ideal scenario of software development,

each concern should be allocated in a specific

module, which achieves its goals. When it occurs,

the software is called well-modularized, because all

their concerns are clearly separated (Sampaio et al.,

2007). However, there are some types of concerns,

for which, this allocation is not possible, only using

traditional software engineering abstractions, such as

viewpoints, goals, use cases, scenarios, among

others. These concerns are called “crosscutting

concerns” or “early aspects” and are defined as

software requirements that are spread and tangled

within other requirements. Some examples of

common crosscutting concerns include: Persistence,

Security, Caching, and Synchronization. The

existence of crosscutting concerns can lead to lack

of modularization and make harder the software

maintenance and evolution activities.

Aspect-Oriented Requirements Engineering

(AORE) is a research field that provides the most

appropriate strategies for identification,

modularization and composition of crosscutting

concerns.

A concern, in the context of AORE, encapsulates

one or more requirements specified by stakeholders,

Afonso Parreira Junior P. and Aparecida Dellosso Penteado R..

Aspect-Oriented Requirements Engineering - A Systematic Mapping.

DOI: 10.5220/0004899200830095

In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 83-95

ISBN: 978-989-758-028-4

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

and a crosscutting concern is a concern whose

requirements cut across requirements of other

software concerns. For example, a security concern

may contain a requirement related to encryption and

another one related to checking access permissions.

In addition, this set of security requirements can

affect other software requirements, such as the

requirement of sending registration information to a

customer, which is related to another software

concern. Thus, the security concern is called

“crosscutting concern”.

Several AORE approaches have been developed

recently, although with different features, strengths

and limitations. However, there are few studies in

the literature that describe: i) the amount of material

produced about this subject; ii) the location of this

material and in what time it was produced; and iii)

which are the main AORE activities explored by

researchers, etc.

This paper shows the planning and execution of a

Systematic Mapping (SM) (Kai et al., 2008;

Kitchenham and Charters, 2007), conducted with a

focus on AORE, aiming to catalogue, identify and

classify approaches related to this subject. A SM can

be understood as a wider review of primary studies

available in the literature, in order to identify the

amount and types of studies about a particular

subject. It also may indicate the evolution of the

published studies about this subject over the years

(Kai et al., 2008).

In this SM, we have selected and analyzed 60

papers and among them, we identified 38 AORE

distinct approaches. Some interesting obtained

results were: i) few approaches lead to Conflict

Identification and Resolution, an activity responsible

for discovering and treating the mutual influence

between different concerns existing in a software; ii)

the most of 60 studies consist of presenting new

AORE approaches or extensions of previous

approaches - therefore, there is a lack of evaluation

studies about already existing approaches; iii) few

studies have been published in journals, what can be

a consequence of the item (ii); among others.

The obtained results in this SM can help other

researchers to conduct further studies from this

work, proposing new methods/techniques/tools for

AORE as well as comparing their proposals with the

catalogued present in this paper. The remainder of

this paper is organized as follows: Section 2 presents

an overview about Aspect-Oriented Requirements

Engineering; Section 3 illustrates the planning of the

Systematic Mapping, along with the research

questions for which we have found answers in this

work. In Section 4, the answers to the research

questions are given and discussed. In Section 5,

some threats to validity are discussed and, finally,

Section 6 presents the final remarks and proposals

for future works.

2 BACKGROUND

The SoC principle is based on the identification and

modularization of pieces of the software relating to a

particular concept, goal or purpose (Dijkstra, 1976).

Several traditional approaches for software

development, such as Object-Orientation (OO), were

created based on this principle; however, some

broad scope concerns (e. g., security,

synchronization, and logging) are not easy to be

modularized and maintained separately during the

development of software. When these concerns are

not appropriately modularized, the software can

contain tangled and scattered representations,

making its understanding and evolution harder.

An effective approach for RE must take into

account the SoC principle and the need to satisfy

broad scope concerns (Moreira et al., 2005). AORE

emerges as an attempt to encompass this goal

through the usage of specific strategies to

modularize concerns that are difficult to be isolated

in individual modules (crosscutting concerns). The

concern identification on requirements level allows

software engineers to think about them in an

isolation way from the beginning of software

development, thus facilitating the creation/usage of

strategies to modularization.

Figure 1 shows a generic process for AORE,

proposed by Chitchyan et al. (2006), which was

developed based on other approaches available in

the literature (Moreira et al., 2005; Baniassad and

Clarke, 2004; Rashid et al., 2002; Yijun et al.,

2004). The rounded-corner rectangles represent the

process activities.

Figure 1: A Generic Process for AORE (Chitchyan et al.,

2006).

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

From an initial available set of requirements, the

activity “Concern Identification” identifies and

classifies software concerns as basis or crosscutting

ones. The software engineer knows the influences

and constraints imposed by crosscutting concerns on

other software concerns, through the activity

“Concern Relationship Identification”. The activity

“Concern Screening Out” aid software engineers to

identify if there is repetition in the list of identified

concerns and decide which of these concerns are

relevant to the software. The activity “Concern

Refinement” happens when there is a need to change

the set of already identified concern and

relationships.

During the activity “Concern Representation”,

the concerns are then represented in a particular

template. This template can vary according to the

used AORE approach, e. g., it can be a text, a use

case model, viewpoints, among others. For example,

the approach developed by Rashid et al. (2003;

2002) represents base concerns using viewpoints; in

the Baniassad and Clarke’s approach (Clarke and

Baniassad, 2005; Baniassad and Clarke, 2004) it is

defined themes as a new concept for representation

of base and crosscutting concerns. Still in the

“Concern Representation” activity, the software

engineer can identify the need for refinement, for

example, for addition/removal concerns and/or

relationships. Therefore, he/she can return to the

previous activities (Figure 1). Finally, the base and

crosscutting concerns represented in a specific

template must be composed and then analysed to

identify conflicts between them. These tasks are

performed in the “Concern Composition” and

“Conflict Identification and Resolution” activities.

Then, identified conflicts are solved by the software

engineers with the help of stakeholders.

In general, the activities described in the process

presented in Figure 1 are aggregated into four major

activities, namely: “Concern Identification and

Classification”, “Concern Representation”,

“Concern Composition” and “Conflict Identification

and Resolution”. These activities are used as a basis

for cataloguing the AORE approaches (Section 4).

3 SYSTEMATIC MAPPING

PLANNING

Kitchenham et al. (2010) argue that a systematic

review should be carried out following the steps of

planning, execution and documentation of the

review and these steps can be used in the context of

a Systematic Mapping (SM). This section shows the

planning and strategy of execution of the SM

performed in this work, according to the model of

Kitchenham et al. Further, a discussion about the

results of this SM is presented in Section 4.

3.1 Research Questions

The SM conducted aims to answer the questions

presented in Table 1. The first column shows the

code of the research question, which will be

referenced throughout this text, and the second one,

shows its description.

The goal of the question Q1 is discovering the

AORE approaches existing in the literature and what

activities they encompass. This question is important

for at least two reasons, it allows to: i) catalogue

existing approaches based on the activities

encompassed by them; and ii) indicate the

approaches that deal with concern identification and

classification - which will facilitate obtaining data to

answer the question Q3.

Table 1: Research Questions for the SM.

# Description

What are the AORE approaches available in the

literature and which activities they cover?

What are the types of studies (Validation Study,

Evaluation Study, Original Solution, Adapted

Solution, Philosophical Study, Opinion Papers and

Experience Papers) that have been proposed

regarding the approaches identified in Question Q1?

What are the types of techniques that have been

used by the approaches listed in Question Q1 for

concern identification and classification?

Which are the events (conferences, workshops,

among others), journals, book chapters, among

others, where the approaches listed in Question Q1

have been published and when this happened?

The question Q2 classifies the studies analysed

in the SM based on the type of study conducted by

the authors: Validation Study, Evaluation Study,

Original Solution, Adapted Solution, Philosophical

Study, Opinion Papers and Experience Papers. This

classification was initially defined by Wieringa et al.

(2006) and is used to guide the development of SMs

proposed by Kai et al. (2008). An adaptation of the

original classification is presented in Table 2.

It is important to highlight few points regarding

the classification presented in Table 2:

 This work adapts the classification proposed by

Wieringa et al. in the following way: the

category “proposed solution” (Wieringa et al.,

2006) was subdivided into “original solution”

and “adapted solution”. This adaptation let we

Aspect-OrientedRequirementsEngineering-ASystematicMapping

know which approaches are new and which

ones are extensions of existing approaches;

Table 2: Classification of the Types of Studies (adapted

from Wieringa et al., 2006 apud Kai et al., 2008).

Classification Description

Validation

Study

It presents an evaluation of a proposed

approach in simulated environments

(laboratories), through controlled

experiments, case studies or proof of

concept.

Evaluation

Study

It presents a practical evaluation of a

proposed approach, through experiments

on real industrial environment. This type

of study, in general, is conducted on more

mature approaches, whose strengths have

been evaluated by means of “validation

studies”.

Original

Solution

It presents the description of an original

solution to a given problem. The potential

benefits and applicability of the proposed

solution are presented by small examples

and good arguments by the authors of the

study.

Adapted

Solution

It presents a description of a solution to a

given problem, but it is an adaptation of

an existing solution. An adaptation may

be considered as a supplementary solution

or a solution that minimize certain

limitations of the original approach.

Similarly, the type of study “original

solution”, the potential benefits and

applicability of the proposed solution are

shown by small examples and good

argumentation from the authors of the

study.

Philosophical

Study

It delineates a new way to look at existing

approaches and structures them in the

form of a taxonomy, conceptual

framework or catalogue.

Opinion

Papers

This type of study expresses the personal

opinion of a (some) researcher(s) about

the benefits and/or limitations of a

particular approach or how the approach

should be used.

Experience

Papers

It consists in testimonials expressed by

professionals/researches about how the

approaches can be used in practice. It is

the personal experience of the author(s)

from the usage of a particular approach.

 In the context of this paper, a study is classified

as an “adapted solution” when it comes to an

extension of an existing AORE approach. For

example, a study that describes the development

of a computational support for an approach

proposed in another study. However, studies

that show solutions non-based on AORE

approaches are considered original solutions,

because the extensions made in the original

approach, generally, are more significant. For

example, a study that presents an approach for

concern identification and classification based

on use cases, which is a traditional approach for

software development, is classified as “original

solution”; and

 A study can be classified in more than one class

described in Table 2. For example, a study may

provide an original solution to a problem while

presenting a description of a controlled

experiment for evaluating this approach

(“validation study”).

Question Q3: some studies (Herrera et al., 2012;

Sampaio et al., 2007) describe that concern

identification and classification activity is a

bottleneck in the AORE process. While this activity

serves as a basis for execution of the other activities,

it is important to know: i) what types of techniques

have been used for concern identification and

classification; ii) what are the strengths and

limitations of these techniques; and iii) which of

them has been more used.

The question Q4 was proposed in order to know

which are the most used means of publication of

AORE-based studies and how it has been the

progress of these studies over the years.

To answer these questions, it is necessary to

conduct an investigation in the literature aiming to

recovery primary studies, as full papers, experience

reports, among others. Kitchenham et al. (2010)

describe certain criteria to lead to an appropriate

selection of primary studies, they are: population,

intervention and outcomes.

The population refers to the group of studies that

will be observed. In this work, the population

consists of publications (full papers published in

conference proceedings, journals, among others)

with a focus on Aspect-Oriented Requirements

Engineering. The intervention refers to what will be

observed in SM. In this case, all type of AORE

approaches, techniques, methods and tools was

observed. The outcomes refer to the expected results

at the end of the SM. In this case, the expected

results are: i) a catalogue of AORE approaches

available in the literature; ii) the classification of the

main AORE activities encompassed by the identified

approaches; iii) a catalogue of the main techniques

used for concerns identification and classification;

and iv) the presentation of the evolution of the

publications related to AORE over the years, as well

as vehicles in which they have been published.

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

3.2 Keywords

The keywords used in the search string to obtain the

primary studies of this MS are: “requirements

engineering”, “approach”, “aspect-oriented”, “aspect

orientation”, “tool”, “method” and “technique”.

Based on this set of keywords, the search string was

generated: ((approach OR approaches OR technique

OR techniques OR tool OR tools OR method OR

methods) AND (“aspect-orientation” OR “aspect-

oriented”) AND (“requirements engineering”)).

Some studies that were not retrieved by the

search engines used in this SM were manually added

to the repository of the studies. These works were

mainly obtained from references found in

publications considered relevant for this work.

3.3 Criteria for Inclusion of the

Sources and Method for the Search

of Primary Studies

The IEEE Xplorer and Scopus search sources of

primary studies were select based on the following

criteria: i) the source must index publications in the

field of Computer Science; ii) the source should

allow searches to studies published in conference

proceedings and journals via web; and iii) the source

must provide advanced search engines, using the

keywords and filters. The method used to search for

primary studies was the search engines available for

these sources. Beside, a manual review of the

references from studies returned by these sources

was performed to obtain publications that were not

retrieved by the search engines and that are relevant

for this SM.

3.4 Criteria for Inclusion of Primary

Studies, Quality Criteria and

Methods for Evaluation of Primary

Studies

The inclusion criteria for primary studies are

presented in Table 3. The exclusion criteria were

created based on the negative form of the inclusion

criteria.

Quality Criteria: as a way to assess the quality

of selected primary studies, we have considered only

publications that present a complete and detailed

description of the proposed approach. Thus, short

papers up to two pages were not considered.

The evaluation method consists in selecting

primary studies according to the inclusion criteria

described in Table 3 and the quality criteria, as

Table 3: Criteria for Inclusion or Exclusion of the Primary

Studies.

Inclusion Criteria

[I1] The text of the study must be written in English.

[I2] The complete version of the text of the study must be

available on web.

[I3] The study must contain some keywords cited in

Section 3.2 in their title, abstract or set of keywords.

[I4] The study must treat to the usage, adaptation, and/or

creation of AORE approaches.

previously comment. This protocol was applied for

each study obtained from the research method

described in Section 3.3 and the selected papers

were stored for later analysis.

3.5 Extraction of Data from the

Selected Primary Studies

The data extraction from the selected primary

studies for this SM was performed in four steps.

Step 1. One of the researchers has applied the

research method to identify potential primary

studies. Based on the preliminary identified studies,

a researcher read the title, the abstract and the

keywords of the publication, applying the criteria

described in Table 3. It was recovered 217 studies:

162 coming from the source Scopus and 55 from the

IEEE Xplorer; 112 of these studies were accepted

and then, completely analyzed in the second step of

this SM.

The other ones were considered duplicated (48)

or rejected (57). Duplicated studies are those ones

that consist of exactly the same publication, without

any extension. This occurs because the source

Scopus can also index publications available in other

sources, such as IEEE, among others. Fifty-seven

studies were rejected mainly due to the exclusion

criteria E4 (the study does not treat to the usage,

adaptation, and/or creation of AORE approaches.).

Examples of rejected studies are those that propose

the usage of aspect orientation to create tools for

requirements management. In this case, the meaning

of keyword “requirements engineering” was not

directly related to AORE.

Step 2. In this step, the same researcher who has

completed Step 1 also has read the full text of the

112 accepted studies. The criteria described in Table

3 were reapplied, as well as the quality criteria

(Section 3.4). Several studies were rejected because

they were short papers without enough information

for answering the research questions of this work.

The classification of the primary studies after

finishing Step 2 can be seen in Figure 2. It can be

noticed that some duplicated studies were identified

Aspect-OrientedRequirementsEngineering-ASystematicMapping

yet. This occurred because the researcher has not

detected this situation, while performing Step 1. The

obtained results reinforces that Systematic Mapping

must be done at stages, as well as by more than one

researcher (Kitchenham et al., 2010; Kai et al.,

2008).

Figure 2: Classification of the studies after Step 2.

Due to the manual insertion of some relevant studies

referenced in the selected papers of the Step 1

(performed by researcher), the amount of studies has

increased in 14. It is important to mention these

studies also were submitted to the same set of

inclusion and quality criteria already discussed in the

paper.

Step 3. The results of the Step 2 were reviewed

by another researcher involved in this study, so that

any disagreements were discussed and resolved.

There was not need to change the previously

selected set of studies, but the interaction between

the researchers was important for the next step (Step

4), as it will be explained below.

Step 4. Finally, the resulting set of primary

studies was used to extract the information required

to answer the questions listed at the beginning of this

study (Table 1). In this step, the collaboration

between the researches was important to reduce the

interpretation errors about some data extracted to the

studies. The results of this step are presented in

detail in Section 4.

4 THE SYSTEMATIC MAPPING

RESULTS

In this section, answers to the research questions for

this SM (Table 1) are presented. The data needed to

answer the question Q1 are in Table 4; there are 38

approaches identified and analyzed in this SM. The

columns 1 and 2 show the code of the approach,

used to identify it in other parts of this paper, the

name of the approach and the reference of the

study(ies) that present(s) it, respectively.

If there is not a specific name for an approach,

we have used the title of the study in which this

approach was presented. Then, the reader can find,

at any time, what are the AORE approaches

analysed in this SM and which studies are related to

them. Columns 3, 4, 5 and 6 of Table 4 describe

which AORE activities, as discussed in Section 2,

are encompassed by the identified approaches.

It is possible to notice that many approaches

include the concern identification and classification,

representation and composition activities. However,

there is a lack of approaches related to the conflict

identification and resolution. Other interesting points

are that only 16% of the analysed approaches (7, 8,

13, 15, 18 and 23) are complete, i. e., include all

activities related to AORE and 55% of them

encompass just one or two activities. This provides

indications that conducting studies on a specific

AORE activity or a small subset of activities can be

an interesting strategy of research instead of trying

to develop approaches that deal with all activities.

A final point to be emphasized with respect to

Table 4 is that not every 60 studies analyzed in this

SM are referenced in this table. This occurs because

some studies are related to the usage and/or

comparison of some AORE approaches, i. e., they

did not develop or extend any approach.

In order to answer the question Q2, Figure 3

presents the classification of primary studies

analysed in this SM according to the classes

described in Table 2.

Figure 3: Classification of Primary Studies.

Seventy nine percent of the studies were classified

as an “Original Solution” or an “Adapted Solution”

and there were few validation studies and none

evaluation studies. This fact calls our attention,

because many approaches are being used/adapted

without having been submitted to evaluation studies.

In addition, new approaches are being proposed

without knowing the real accuracy of the existing

approaches.

Another evidence about the previously

affirmation is presented in Table 5, that presents: i)

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

Table 4: AORE Approaches.

# Approach

AORE Activities

CIC CR CC CIR

An approach for crosscutting concern identification at requirements level using NLP:

Ali and Kasirun, 2011; Ali and Kasirun, 2008a; Ali and Kasirun, 2008b.

2 ACE - Aspect Clustering Engine: Duan and Cleland-Huang, 2007. X

3 AWC - Aspect Weaving Connector: Lau et al., 2007. X X

4 RDL - Requirements Description Language: Weston et al., 2008; Chitchyan et al., 2009. X

5 ASSD - Aspects Specification for the Space Domain: Agostinho et al., 2008. X X

A semi-automatic strategy to identify crosscutting concerns in PL-AOVgraph requirement

models: Medeiros et al., 2013.

7 EA-Miner: Sampaio et al., 2005; Chitchyan et al., 2006. X X X X

8 NFR/AUC: Zheng et al., 2010; Liu et al., 2009. X X X X

9 DERAF - Distributed Embedded Realtime Aspects Framework: Wehrmeister et al., 2007. X X

10 An evolutionary model of requirements correctness with early aspects: Araújo et al., 2007. X X X

11 AORE/XML: Soeiro et al., 2006. X X X

12 Theme: Clarke and Baniassad, 2005; Clarke and Baniassad, 2004. X X X

13 AspOrAs: Ribeiro and Araújo, 2008; Araújo and Ribeiro, 2005. X X X X

14 EA-Analyzer: Sardinha et al., 2009. X

15 AORE with Arcade: Rashid et al., 2002; Rashid et al., 2003. X X X X

16 PROBE: Katz and Rashid, 2004. X

17 MAST - Modeling Aspectual Scenarios with Theme: Penim and Araújo, 2010. X X X

18 Integrating Problem Frames with Aspects: Marques et al., 2009. X X X X

19 Interaction Analysis in Aspect-Oriented Models: Mehner et al., 2006. X

20 Isolating and relating concerns in requirements using latent semantic analysis: Kit et al., 2006. X

21 ADORA – An Object-Oriented Requirements and Architecture Language: Meier et al., 2007. X

22 Multi-Dimensional Composition by Objectives (Multi-ComBO): Marques et al., 2008. X X

23 Multi-Dimensional Separation of Concerns in Requirements Engineering: Moreira et al., 2005. X X X X

24 Concern Interaction Graph (CIG): Mussbacher and Amyot, 2009; Mussbacher et al., 2009. X

25 On the discovery of candidate aspects in software requirements: Hamza et al., 2009. X

Promoting the software evolution in AOSD with early aspects: Architecture-oriented model-

based pointcuts: Pinto et al., 2009.

X X

27 RCT - Requirements Composition Table: Chernak, 2012. X X X

AOZCL - Revisiting a Formal Framework for Modeling Aspects in the Design Phase: De Paula

and Batista, 2007.

29 Scenario Modeling with Aspects: Whittle and Araújo, 2004. X X X

30 VisualAORE: Oliveira et al., 2010. X

31 Aspectual i* Model: Alencar et al., 2010. X X

32 AO-ADL - Aspect-Oriented Architecture Description Language: Pinto et al., 2007. X

33 AoUCM-to-RAM: Mussbacher et al., 2011; Mussbacher et al., 2007. X X

Using tagging to identify and organize concerns during pre-requirements analysis: Ossher et al.,

2009.

VGraph - From Goals to Aspects: Discovering Aspects from Requirements Goal Models: Yijun et

al., 2004.

X X X

36 AORA - Aspect-Oriented Requirements Analysis: Brito and Moreira, 2003. X X X

37 AoURN - Aspect-oriented User Requirements Notation: Mussbacher et al., 2010. X X X

38 RAM - Reusable Aspect Models: Kienzle et al., 2009. X X

Amount of Approaches for each AORE Activity 22 26 22 12

Subtitle: CIC – Concern Identification and Classification; CR – Concern Representation; CC – Concern Composition; CDR– Conflict

Identification and Resolution.

the code of the AORE approach; ii) the year of the

first publication of this approach;

iii) the years of publication corresponding to

adaptations of this approach; iv) the references of

the approaches used as basis for development of this

approach; and v) the references of the studies that

evaluate this approach.

Approximately 74% of the approaches (28 of 38)

were not evaluated through case studies, controlled

experiments, among others, performed in a

laboratory or an industrial environment.In addition,

many approaches (55%: 2, 3, 5, 6, 9, 10, 14, 16, 17,

18, 19, 21, 22, 23, 24, 25, 26, 28, 31, 32 and 34)

have been proposed and then they have not been

adapted, evaluated or used as a basis for other

approaches anymore. In other hand, some

approaches that have been evaluated, adapted and/or

used as a basis for other approaches are: 4, 7, 11, 12,

15, 20, 23, 27, 29, 30, 35, 36, 37 and 38. The

approaches 15 (Rashid et al., 2002; Rashid et al.,

2003) and 35 (Yijun et al., 2004) have been

evaluated in more than one experimental study.

Aspect-OrientedRequirementsEngineering-ASystematicMapping

Table 5: Evolution of the AORE approaches.

# Proposal Evolutions Based on

Performed

Evaluations

# Proposal Evolutions Based on

Performed

Evaluations

1 2008 2011 12 - 20 2006 - 12 -

2 2007 - 20 - 21 2007 - - -

3 2007 - - - 22 2008 - 36 -

4 2007 2008 -

Chitchyan et

al., 2009.

23 2005 - -

Sampaio et al.,

2007.

5 2008 - 36 - 24 2009 - 29 -

6 2013 - 35 - 25 2009 - - -

7 2005 2006 -

Herrera et al.,

2012.

26 2009 - - -

8 2009 2010 - -

27 2012 - -

Chitchyan et al.,

2009.

9 2007 - - - 28 2007 - - -

10 2007 - - - 29 2004 - - -

11 2006 - -

Sampaio et

al., 2007.

30 2010 - -

Oliveira et al.,

2010.

12 2004 2005 -

Herrera et al.,

2012.

31 2010 - - -

13 2005 2008 - - 32 2007 - - -

14 2009 - - - 33 2007 2011 37; 38 -

15 2002 2003 -

Sampaio et

al., 2007;

Chitchyan et

al., 2009.

34 2009 - - -

16 2004 - - -

35 2004 - -

Sampaio et al.,

2007; Chitchyan

et al., 2009.

17 2010 - 12; 29 - 36 2003 - - -

18 2009 - - -

37 2010 - -

Mussbacher et

al., 2010.

19 2006 - - - 38 2009 - - -

The approaches 12 (Clarke and Baniassad, 2005;

Clarke and Baniassad, 2004) and 29 (Whittle and

Araújo, 2004) were used as basis for, at least, two

other approaches. With regard to the question Q3,

Table 6 presents the name and description of five

concern identification and classification techniques

and the approaches that use them.

Some experimental studies (Herrera et al., 2012;

Sampaio et al., 2007) describe that concern

identification and classification activity is a

bottleneck in the AORE process.

Then, knowing the techniques used in this

activity can help professionals and researchers to

obtain better strategies to perform this activity.

As can be seen the most used technique in

different approaches is “Manual Analysis of the

Requirements Document by the Software Engineers

with the Aid of Guidelines”. Despite being limited to

large scale software, this technique has promising

benefits, such as minimizing the dependence of

users’ experience during the application of the

approach.

This is an indication that this technique has

significant benefits for the concern identification and

classification and should be studied more carefully.

Another important point to notice is that few

approaches (7, 23 and 27) use more than one

technique for concern identification and

classification. This fact can be an interest research

field, because the usage of combined techniques can

lead to higher accuracy of AORE approaches.

Finally, to answer the question Q4, two bubble

charts were built and they are presented,

respectively, in Figures 4 and 5. Regarding to these

figures, it is important to comment that:

i) the distribution of the published studies on

conference proceedings is in Y-axis of the graph

of the Figure 4;

ii) the distribution of the published studies on

journals, books and other vehicles of scientific

publication is in Y-axis of the graph of the

Figure 5. Aiming to simplify the visualization of

these graphs, only the initials of the

events/journals was used to identify them; and

iii) the amount of publications per event, journal or

book and the year in which they occurred are

presented in X-axis of the graphs of Figures 4

and 5.

It may be notice that most publications (eleven)

comes from the Workshop in Aspect-Oriented

Requirements Engineering and Architecture Design

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

Table 6: Techniques for concern identification and classification.

Concern Identification and

Classification Technique

Description

Natural Language Processing

(NLP)

It is based on NLP techniques such as part-of-speech, lemmatization (approach 7), among others to

find keywords of the text of requirements document that are related to with some kind of concern.

According to the analyzed studies, this technique was not good for identification of implicit

concerns, i. e., concern that are not explicitly described in the text of the requirements document.

Approaches that use this technique: 1, 7 and 23.

Probabilistic Models and

Clustering

It is based on statistical models, such as (Latent Semantic Analysis - approach 20) and clustering

techniques such as the use of tags (approach 34) to find concern candidates. As this is a technique

based on statistical analysis, it does not usually bring good results when the requirements document

is small, i. e., when the sample is small.

Approaches that use this technique: 2, 20, 25 and 34.

Manual Analysis of Requirements

Document by Software Engineers

In this type of technique, the software engineer performs a manual inspection in the requirements

document trying to discover the software concern. As limitations, we have: i) the results obtained

with this technique are strongly dependent on the experience of those who apply it; and ii) this

technique is error-prone, difficult to replicate its application and has high cost of execution when

requirements documents of large software are used.

Approaches that use this technique: 10, 13, 15 and 17.

Manual Analysis of Requirements

Document by Software Engineers

with the Aid of Guidelines

It is similar to the technique of manual analysis, but differs by the fact that users of this technique

have guidelines that can assist them during the process of concern identification. One type of

guidelines quite common is non-functional requirements catalogs, such as proposed by Chung and

Leite (2000). This type of technique can minimizing the dependence of the user experience that

applies it, however, it remains costly to be performed on large software. In addition, it takes a

certain user experience to understand and follow the guidelines.

Approaches that use this technique: 5, 7, 8, 11, 23, 27, 29, 31, 36 and 37.

Software Visualization

It is based on visualization techniques to help the user identify the software concerns. A type of

well-known visualization if "Action Views", proposed by Baniassad and Clarke (approach - 12). A

limitation of this technique is that for building the visualizations, usually, the user must perform a

manual inspection from the requirements document, i. e., it suffer the same problems of technical

based on manual analysis of requirements document, cited above.

Approaches that use this technique: 6, 18, 12 and 27.

(EA). This makes sense, because this is an event

dedicated to publishing works related to AORE.

Another event that has a relevant amount of

publications related to AORE (eight) is the

International Requirements Engineering (RE), a

good and well-known conference in the RE field.

Another important point to be observed in

Figures 4 and 5 is the evolution of AORE

publications over the years. It is possible to notice

that there was a great amount of publications

between 2007 and 2009. In this period, the scientific

community have published 52% of all studies

published from 2002 to 2013. Finally, we also can

observe that most of studies have been published in

conference proceedings and only eight studies (13%)

were published in journals.

This indication is consistent to what we have

said about the lack of evaluation studies on the

existing approaches. Since the approaches are not

mature enough, i. e., the evidences of the robustness

and accuracy of such approaches are fragile,

publishing them in good journals may be a hard task.

5 THREATS TO VALIDITY

Primary Studies Selection. Aiming at ensuring an

unbiased selection process, we defined research

questions and devised inclusion and exclusion

criteria we believe are detailed enough to provide an

assessment of how the final set of primary studies

was obtained. However, we cannot rule out threats

from a quality assessment perspective, we simply

selected studies without assigning any scores. In

addition, we wanted to be as inclusive as possible,

thus no limits were placed on date of publication and

we avoided imposing many restrictions on primary

study selection since we wanted a broad overview of

the research area.

Missing Important Primary Studies. The

search for primary studies was conducted in two

well-known search engines (Scopus and IEEE

Xplorer), even though it is rather possible we have

missed some relevant primary studies. Nevertheless,

this threat was mitigated by selecting search engines

which have been regarded as the most relevant

scientific sources (Dyba et al., 2007) and therefore

prone to contain the majority of the important

studies.

Aspect-OrientedRequirementsEngineering-ASystematicMapping

Figure 4: Distribution of the published studies on

conference proceedings.

Figure 5: Distribution of the published studies on journals

and books.

Reviewers’ Reliability. All the reviewers of this

study are researchers in the software engineering,

focused on the aspect-oriented development,

requirements engineering and aspect mining.

Therefore, we are not aware of any bias we may

have introduced during the analyses.

Data extraction. Another threat for this review

refers to how the data were extracted from the digital

libraries, since not all the information was obvious

to answer the questions and some data had to be

interpreted. Therefore, in order to ensure the

validity, multiple sources of data were analyzed, i.e.

papers, technical reports, white papers. Furthermore,

in the event of a disagreement between the two

primary reviewers, a third reviewer acted as an

arbitrator to ensure full agreement was reached.

6 FINAL REMARKS

In this paper, we presented a SM of Aspect-Oriented

Requirements Engineering (AORE), based on the

process described by Kitchenham et al., 2010.

The SM presented was conducted as the planning

described in Section 3. Through an examination of

60 primary studies related to AORE approaches, this

review has presented 38 different approaches. The

steps outlined in this plan were sufficient to obtain

relevant primary studies, which generated the data

needed to answer the research questions (Table 1).

Summarizing the results observed from this SM:

1. We have identified 38 (thirty-eight) distinct

AORE approaches;

2. The most of identified approaches are related

to concern identification and classification,

representation and composition activities; we have

notice there is a lack of studies based on conflicts

detection and resolution;

3. The most studies analyzed in this SM consist

of presenting either new AORE approaches or

adaptation of existing approaches; this indicates that

more evaluation studies, based on these existing

approaches, need to be performed to verify the real

accuracy of them;

4. We have identified five different types of

techniques for concern identification and

classification, which are used by the AORE

approaches: “Natural Language Processing (NLP)”,

“Probabilistic Models and Clustering”, “Manual

Analysis of Requirements Document by Software

Engineers”, “Manual Analysis of Requirements

Document by Software Engineers with the Aid of

Guidelines” and “Software Visualization”. The most

used technique is the “Manual Analysis of

Requirements Document by Software Engineers

with the Aid of Guidelines”. Despite being limited to

large software, it has promising benefits, such as

minimizing the dependence users' experience during

the application of the approach; and

5. Finally, it was notice that most of the studies

has been published in conference proceedings,

which reinforces the idea that many approaches have

been proposed, but few of them are mature enough

to be published in journals.

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

Researchers can use this SM as a base for

advancing the field, while practitioners can use it to

identify approaches that are well-suited to their

needs.

With the results obtained through this SM, it

was possible to develop a set of comparison criteria

for AORE approaches, based on common features

and variability of the approaches analyzed in this

SM (Parreira Júnior and Penteado, 2013). Such

criteria were then applied on six of the main AORE

approaches: 7, 11, 12, 15, 23 and 29. The results can

serve as a guide so that users can choose the

approach that best meets their needs, and to facilitate

the conduct of research in AORE. The main future

directions that emerged from this mapping are the

need for empirical, comparative evaluations and the

opportunity for developing combined AORE

approaches.

REFERENCES

Agostinho, S. et al. A Metadata-driven approach for

aspect-oriented requirements analysis. In: 10th Inter-

national Conference on Enterprise Information Sys-

tems. Proceedings Barcelona, Spain, p.129-136, 2008.

Alencar, F. et al. Towards modular i* models. In: ACM

Symposium on Applied Computing, p. 292-297, 2010.

Ali, B. S.; Kasirun, Z. M. D. An approach for crosscutting

concern identification at requirements level using

NLP. Int. Journal of Physical Sciences, v. 6 (11), p.

2718-2730, 2011.

Ali, B. S.; Kasirun, Z. M. 3CI: A Tool for Crosscutting

Concern Identification. In: Int. Conf. on

Computational Intelligence for Modeling Control and

Automation. Proceedings. Vienna, Austria, p. 351-

355, 2008a.

Ali, B. S.; Kasirun, Z.M. Developing tool for crosscutting

concern identification using NLP. In: Int. Symposium

on Information Technology. Proceedings. Kuala

Lumpur, Malaysia, 2008b.

Araújo, J.; Zowghi, D.; Moreira, A. An evolutionary

model of requirements correctness with early aspects.

In: 9th Int. Workshop on Principles of Software

Evolution. Proceedings. Dubrovnik, Croatia, p. 67-70,

2007.

Araújo, J.; Ribeiro, J.C., Towards an aspect-oriented agile

requirements approach. In: Int. Workshop on

Principles of Software Evolution. Proceedings.

Lisbon, Portugal, p. 140-143, 2005.

Baniassad, E.; Clarke, S. Theme: An approach for aspect-

oriented analysis and design. In 26th Int. Conf. on

Software Engineering (ICSE’04). 2004.

Brito, I.; Moreira A. Towards a Composition Process for

Aspect-Oriented Requirements. Early Aspects

Workshop at AOSD. Proceedings. Massachusetts,

USA, 2003.

Chernak, Y. Requirements Composition Table Explained.

In: 20th IEEE Int. Req. Eng. Conference. Proceedings.

Chicago, Illinois, USA, pp. 273-278, 2012.

Chitchyan, R.; et al. Semantic vs. syntactic compositions

in aspect-oriented requirements engineering: An

empirical study. In: 8th Int. Conf. on AOSD.

Proceedings. Virginia, USA, p. 149-160, 2009.

Chitchyan, R.; Sampaio, A.; Rashid, A.; Rayson, P. A tool

suite for aspect-oriented requirements engineering. In

Int. Workshop on Early Aspects. ACM, p. 19-26,

2006.

Chung, L.; Leite, J. S. P. Non-Functional Requirements in

Software Engineering. Springer, 441 p., 2000.

Clarke, S.; Baniassad, E. Aspect-Oriented Analysis and

Design: The Theme Approach: Addison-Wesley, 2005.

De Paula, V.; Batista, T. Revisiting a formal framework

for modeling aspects in the design phase. In: Int. Conf.

on Soft. Eng. Proceedings. Minneapolis, MN, 2007.

Dijkstra, E. W. A Discipline of Programming. Pearson

Prentice Hall, 217 p., ISBN: 978-0132158718, 1976.

Duan, C.; Cleland-Huang, J. A clustering technique for

early detection of dominant and recessive crosscutting

concerns. In: International Conference on Software

Engineering, Proceedings. Minneapolis, MN, 2007.

Dyba T.; Dingsoyr T.; Hanssen G. K. Applying systematic

reviews to diverse study types. In: Int. Symposium on

Empirical Software Engineering and Measurement.

Proceedings. Washington, DC, USA, 2007.

Hamza, H. S.; Darwish, D. On the discovery of candidate

aspects in software requirements. In: 6th Int.

Conference on Information Technology: New

Generations. Proceedings. Las Vegas, USA, p. 819-

824, 2009.

Herrera, J. et al. Revealing Crosscutting Concerns in

Textual Requirements Documents: An Exploratory

Study with Industry Systems. In 26th Brazilian

Symposium on Software Engineering. p. 111-120,

2012.

Kai P.; Robert F.; Shadid M.; Michael M. Systematic

mapping studies in software engineering. In: 12th Int.

Conference on Evaluation and Assessment in Soft.

Eng. Proceedings. Swinton, UK, p. 68-77, 2008.

Katz, S.; Rashid, A. From aspectual requirements to proof

obligations for aspect-oriented systems. In: IEEE

International Conference on Requirements

Engineering. Proceedings. Kyoto, Japan, p. 48-57,

2004.

Kienzle, J.; Abed W. A.; Klein, J. Aspect-oriented multi-

view modeling. In: 8th Int. Conf. on AOSD.

Proceedings. New York, USA, p. 87-98. 2009.

Kit, L. K.; Man, C. K.; Baniassad, E. Isolating and relating

concerns in requirements using latent semantic

analysis. In: ACM SIGPLAN Notices, v. 41(10), p.

383-396, 2006.

Kitchenham, B.; et al. Systematic literature reviews in

software engineering – A tertiary study. In:

Information and Software Technology, v. 52, p. 792–

805, 2010.

Kitchenham, B.; Charters, S. Guidelines for performing

systematic literature reviews in software engineering.

Aspect-OrientedRequirementsEngineering-ASystematicMapping

Technical Report. Keele University and Durham

University, 2007.

Lau, Y.; Zhao, W.; Peng, X.; Tang, S. A connector-centric

approach to aspect-oriented software evolution. In: Int.

Computer Software and Applications Conference.

Proceedings. Beijing, China, p. 391-396, 2007.

Liu, X.; Liu, S.; Zheng, X. Adapting the NFR framework

to aspectual use-case driven approach, Proceedings.

7th International Conference on Software Engineering

Research, Management and Applications.

Proceedings. Hainan Island, China, p. 209-214, 2009.

Marques, G.; Araújo, J.; Lencastre, M. Integrating

problem frames with aspects. In: 23rd Brazilian

Symposium on Software Engineering. Proceedings.

Fortaleza/CE, p. 196-206, 2009.

Marques, A.; Moreira, A.; Araújo, J. Multi-dimensional

composition by objective. In: International

Conference on Software Engineering. Proceedings.

Leipzig, Germany, p. 19-25, 2008.

Medeiros, M.; Silva, L.; Medeiros, A. L. A semi-

automatic strategy to identify crosscutting concerns in

PL-AOVgraph requirement models. In: Workshop on

Requirements Engineering. Proceedings. Rio de

Janeiro, Rio de Janeiro, p. 46-59, 2013.

Meier, S.; Reinhard, T.; Stoiber, R.; Glinz, M. Modeling

and evolving crosscutting concerns in ADORA. In:

International Conference on Software Engineering.

Proceedings. Minneapolis, MN, 2007.

Mehner, K.; Monga, M.; Taentzer, G. Interaction Analysis

in Aspect-Oriented Models. In: 14th IEEE

International Conference Requirements Engineering.

Proceedings. Minnesota, USA, p. 69-78, 2006.

Moreira, A.; Rashid, A.; Araújo, J. Multi-Dimensional

Separation of Concerns in Requirements Engineering.

13th International Conference on Requirements

Engineering (RE). Proceedings. p. 285-296, 2005.

Mussbacher, G.; Kienzle, J.; Amyot, D. Transformation of

aspect-oriented requirements specifications for

reactive systems into aspect-oriented design

specifications. In: Model-Driven Requirements

Engineering Workshop. Proceedings. Trento, Italy, p.

39-47, 2011.

Mussbacher, G.; Amyot, D.; Araújo, J.; Moreira, A.

Requirements modeling with the aspect-oriented user

requirements notation (AoURN): A case study. In:

transactions on aspect-oriented software development.

Springer-Verlag, Berlin, Heidelberg, p. 23-68, 2010.

Mussbacher, G.; Amyot, D. On modeling interactions of

early aspects with goals. In: Workshop on Aspect-

Oriented Requirements Engineering and Architecture

Design. Proceedings. Charlottesville, VA, USA, p. 14-

19, 2009.

Mussbacher, G.; Whittle, J.; Amyot, D. Semantic-based

interaction detection in aspect-oriented scenarios. In:

IEEE Int. Conference on Requirements Engineering.

Proceedings. Georgia, USA, p. 203-212, 2009.

Mussbacher, G.; Amyot, D.; Weiss, M. Visualizing

aspect-oriented requirements scenarios with use case

maps. In: First International Workshop on

Visualization in Requirements Engineering.

Proceedings. 2007.

Oliveira, A.R.; Araújo, J.; Amaral, V. The VisualAORE

DSL. In: 5th Int.

Workshop on Req. Eng.

Visualization. Proceedings. Sydney, Australia, p. 11-

19, 2010.

Ossher, H.; et al., C. Using tagging to identify and

organize concerns during pre-requirements analysis.

In: Aspect-Oriented Req. Eng. and Architecture

Design. Proceedings. Charlottesville, VA, USA, p. 25-

30, 2009.

Parreira Júnior, P. A.; Penteado, R. A. D. Criteria for

Comparison of Aspect-Oriented Requirements

Engineering Approaches. In: Brazilian Symposium on

Software Eng. Brasília/DF, Brazil, 2013 (in

Portuguese).

Penim, A. S.; Araújo, J. Identifying and modeling

aspectual scenarios with theme and MATA. In: ACM

Symposium on Applied Computing. Proceedings.

Switzerland, p. 287-291, 2010.

Pinto, M.; Fuentes, L.; Valenzuela, J. A.; Pires, P. F.;

Delicato, F. C. Promoting the software evolution in

AOSD with early aspects: Architecture-oriented

model-based pointcuts. In: Workshop on Aspect-

Oriented Requirements Engineering and Architecture

Design. Proceedings. Charlottesville, VA, USA, p. 31-

37, 2009.

Pinto, M.; Gamez, N.; Fuentes, L. Towards the

Architectural Definition of the Health Watcher System

with AO-ADL. In: Workshop in Aspect-Oriented Req.

Eng. and Architecture Design. Proceedings.

Minneapolis, 2007.

Rashid, A.; Moreira, A.; Araújo, J. Modularisation and

composition of aspectual requirements. In 2nd

International Conference on Aspect-Oriented Software

Development (AOSD’03). ACM, 2003.

Rashid, A.; Sawyer, P.; Moreira, A.; Araújo, J. Early

Aspects: a Model for Aspect-Oriented Requirements

Engineering. In Int. Conference on Requirements Eng.

(RE). 2002.

Ribeiro, J. C.; Araújo, J. AspOrAS: A requirements agile

approach based on scenarios and aspects. In: 2

Int.

Conf. on Research Challenges in Information Science.

Proceedings. Marrakech, Morocco, p. 313-323, 2008.

Sampaio, A.; Greenwood P.; Garcia, A. F.; Rashid, A. A

Comparative Study of Aspect-Oriented Requirements

Engineering Approaches. In 1st Int. Symposium on

Empirical Soft. Eng. and Measurement p 166-175,

2007.

Sampaio, A.; Chitchyan, R.; Rashid, A.; Rayson, P. EA-

Miner: a Tool for Automating Aspect-Oriented

Requirements Identification. In: Int. Conf. Automated

Soft. Eng. Proceedings. California, USA, p. 353-355,

2005.

Sardinha, A.; Chitchyan, R.; Weston, N.; Greenwood, P.;

Rashid, A., 2009. EA-Analyzer: Automating conflict

detection in aspect-oriented requirements. In: 24th Int.

Conference on Automated Soft. Eng. Proceedings.

Auckland, New Zealand, p. 530-534, 2009.

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

Soeiro E.; Brito, I. S; Moreira, A. An XML-Based

Language for Specification and Composition of

Aspectual Concerns. In: 8th Int. Conf. on Enterprise

Information Systems. Proceedings. Paphos, Cyprus,

2006.

Yijun Y.; Leite, J. C. S. P.; Mylopoulos, J. From Goals to

Aspects: Discovering Aspects from Requirements

Goal Models. In: Int. Conf. on Req. Engineering (RE).

2004.

Wehrmeister, M. A.; Freitas, E. P.; Pereira, C. E.; Wagner,

F.R. An aspect-oriented approach for dealing with

non-functional requirements in a model-driven

development of distributed embedded real-time

systems. In: 10th Int. Symposium on Object and

Component-Oriented Real-Time Distributed

Computing. Proceedings. Orlando, Florida, USA, p.

428-432, 2008.

Weston, N.; Chitchyan, R.; Rashid, A. A formal approach

to semantic composition of aspect-oriented

requirements. In: 16th IEEE Int. Requirements

Engineering Conference. Proceedings. Catalunya,

Spain, p. 173-182, 2008.

Wieringa, R.; Maiden, N. A. M.; Mead, N. R.; Rolland, C.

Requirements engineering paper classification and

evaluation criteria: a proposal and a discussion. In:

Requirements Engineering v. 11(1), p. 102–107, 2006.

Whittle J.; Araújo, J. Scenario Modeling with Aspects. In:

IEEE Software, v. 151(4), p. 157-172, 2004.

Zheng, X.; Liu, X.; Liu, S. Use case and non-functional

scenario template-based approach to identify aspects.

2nd International Conference on Computer

Engineering and Applications. Proceedings. Bali

Island, Indonesia, p. 89-93, 2010.

Aspect-OrientedRequirementsEngineering-ASystematicMapping