Chapter 4 Aspect-Oriented Requirements Analysis

Isabel Sofia Sousa Brito
Aspect-Oriented Requirements Analysis
Dissertação apresentada para obtenção do
Grau de Doutor em Informática pela
Universidade Nova de Lisboa, Faculdade de
Ciência e Tecnologia.
Lisboa
2008

Aspect-Oriented Requirements Analysis
Post-Graduation student: Isabel Sofia Sousa Brito
Post-Graduation Supervisor: PhD Professor Ana Maria Dinis Moreira
Lisboa
2008
III

Acknowledgments
I would like to express my appreciation to my supervisor, Ana Moreira, whose expertise,
understanding, friendship and, more important, patience, added considerably to my knowledge. She
provided me with direction, technical support and became more of a mentor and friend, than a
supervisor. I would like to thank her son, Tomi, and her husband, José Braz, who have given up some
time of his mother and his wife, respectively.
A special word of appreciation goes to João Araújo for helpful discussions on previous versions of this
PhD thesis and, more important, for his friendship.
I must also thanks João Paulo Barros and Luís Domingues for help me in preparation of this thesis
proposing greats reviews. Also, I would like to thank the reviewers of my publications for their very
thorough comments and useful links that helped me improve this work.
I wish to thank André Marques, Elisabete Soeiro, Filipe Vieira, José Magno, Marco Brasil, Marcos
Larsen, Marta Tabares, Miguel Goulão, Nuno Ferreira, Rita Ribeiro and Sérgio Agostinho for
contributing on the validation of some of the techniques proposed here. These contributions have been
partially supported by Fundação para a Ciência e a Tecnologia (project SOFTAS
POSC/EIA/60189/2004). Thanks to Fundação para a Ciência e a Tecnologia for this opportunity.
Very special thanks goes to João Paulo Barros, João Paulo Trindade, Maria Basilio and Miguel
Tavares for our “philosophical” debates, exchanges of knowledge, and, some times, supporting my
frustration during our work in Conselho Directivo at ESTIG. Also, to my colleagues Elsa Rodrigues,
Luís Garcia, Luís Bruno, Sofia Soares, Roberto Espenica, Carlos Pimental and Ludovina Pereira for
supporting my “discussions” and “crazy” ideas. You have an extraordinary level of professionalism!
I would also like to thank my oldest friends, Alcobia family and Ruizinho, Milú, Rosario, Ana and
Sebastião family, Fatinha and family, who suffered with my absence on "farras".
I must also acknowledge my dogs, Fofinho, Luna and Inis that, with “abanadelas de rabo” and
“lambidelas”, had always comforted me.
Finally, and most important, I wish to thank my family because they are “responsible” for what I am
now: my father Ezequiel and his girl-friend Mariela; my uncles, Dina and Toino, Lita and Oliveira,
Lisete and Valdemar, Vital and Felisberto; cousins Manú, Erica and Lourenço, Valentina and sons,
Jorge and Cristina; Luís; my grand-grandparents Mami and Papi; my grandparents Joaquim and
V

Lucília. I wish to thank Adriana, Carlos and Filipe that are part of this family a long time a go. I would
also like to thank my boy-friend Luís for the support and understanding he provided me during these
three years of common life. I must thank my mother, Odilia, for the encouragement and support she
provided me through my entire life.
Muitos beijinhos e obrigada a todos!
VI

Abstract
Aspect-Oriented Software Development (AOSD) aims at providing means to identify, modularise,
specify and compose crosscutting concerns. Crosscutting concerns are responsible for producing
scattered and tangled representations that are difficult to maintain and evolve. AOSD was introduced
first at programming level, with Aspect-Oriented Programming, where crosscutting concerns, known
as aspects, are handled in code. Aspect-oriented concepts have been propagated up the software
development lifecycle, to software design, software architecture and requirements engineering. The
primary aim of this PhD thesis was to address crosscutting concerns at the requirements level. The end
result is the Aspect-Oriented Requirements Analysis (AORA) approach. AORA, with associated
process model, techniques and tool, supports separation, specification, conflict resolution and
composition of crosscutting and non-crosscutting concerns at the requirements level.
The AORA process model is composed of three plans, each one divided in tasks. The first two plans
contribute to identify crosscutting concerns in requirements documents and to minimize the tyranny of
dominant decomposition. This is achieved by handling all concerns in the same fashion using a unique
template. This template supports a complete and consistent set of descriptions and representations of
concerns, be them crosscutting or non-crosscutting. The third and final plan contributes with the
ability to compose crosscutting and non-crosscutting concerns to clearly understand the system
requirements and to identify and analyse critical trade-offs between concerns.
The AORA conflict management technique is applied during the composition activity. The Analytical
Hierarchical Process and Weighted Average multi-criteria analysis methods are used to find, given a
set of alternatives and a set of decision criteria, the best alternative for a given problem. It is important
to understand well each concern, study the level of impact that each one may have on others and
decide on their relative importance before any solution decision is made.
A set of guidelines are proposed to support concern horizontal forward traceability. Tool’s
functionalities are developed to support horizontal backward traceability as well as vertical
traceability. Thanks to these guidelines and the tool, our approach promotes better understanding of
concerns, and supports validation of specifications and compositions of concerns for the stakeholders
through functionalities that guarantees consistency of the concerns’ specification and their
composition rules.
AORA has been assessed through independent case studies and users, as well as empirical
comparisons with respect to other Aspect-Oriented Requirements Engineering approaches.
VII

VIII

Sumário
O desenvolvimento de software orientado pelos aspectos propõe meios para identificar, modularizar,
especificar e compor assuntos transversais. Estes assuntos são responsáveis por produzir
representações dispersas e emaranhadas. O resultado são representações difíceis de compreender,
manter e fazer evoluir. Os aspectos surgiram primeiro com a programação orientada pelos aspectos,
onde os assuntos transversais, ou “aspectos”, são tratados ao nível do código. Os conceitos da
programação orientada pelos aspectos foram depois sendo propagados para as fases anteriores do
processo de desenvolvimento, por exemplo, desenho e engenharia de requisitos.
O objectivo desta tese de doutoramento foi criar uma abordagem para tratar assuntos transversais e não
transversais para a engenharia de requisitos. No final, os conceitos sobre orientação pelos aspectos,
requisitos não-funcionais e engenharia de requisitos foram articuladas numa abordagem denominada
Aspect-Oriented Requirements Analysis (AORA). O AORA, através do seu modelo do processo,
técnicas e ferramenta, suporta separação, especificação, gestão de conflitos e composição dos assuntos
transversais e não transversais.
O processo é composto por três planos principais, cada um composto por actividades. Os dois
primeiros planos contribuem para identificar e especificar assuntos transversais e ainda para minimizar
a tirania da decomposição dominante. Isto é conseguido através da definição de uma tabela onde cada
assunto é especificado de forma completa, consistente e uniforme, independentemente da sua natureza
transversal. O terceiro plano contribui para a composição de assuntos transversais e não transversais,
facilitando, por um lado, a compreensão de todo o sistema e, por outro, a identificação e análise de
situações de conflito.
A gestão de conflitos do AORA realiza-se durante a composição de assuntos. Métodos multi-critério,
como o Analytical Hierarchical Process ou o Weighted Average usam-se para encontrar, dado um
conjunto de alternativas e critérios de decisão, a melhor opção para um dado problema. Torna-se assim
importante compreender cada assunto, estudar o impacto de cada um nos restantes e decidir acerca da
sua importância relativa antes de se avançar para uma solução.
Um conjunto de directrizes ajuda a gerir as relações entre assuntos e artefactos do desenho de software
para a garantir forward traceability. A ferramenta do AORA possui funcionalidades que permitem
garantir backward e vertical traceability. Estas directrizes e a ferramenta garantem a validação e a
consistência das especificações e composições dos assuntos.
IX

O AORA foi avaliado com casos de estudo, por vários utilizadores e, ainda, através de comparações
empíricas com outras abordagens da área de engenharia de requisitos orientadas pelos aspectos.
X

Acronyms
This section contains a list of acronyms used in the thesis.
ACRONYM EXPANSION
AHP Analytical Hierarchical Process
AORA Aspect-Oriented Requirements Analysis
AORE Aspect-Oriented Requirements Engineering
AOSD Aspect-Oriented Software Development
ARCaDE Aspectual Requirements Composition and Decision Support
ASSD Aspects Specification for the Space Domain
CORE Concern Oriented Requirements Engineering
MCDM Multiple Criteria Decision Making
MDD Model-Driven Development
MDSOC Multi-Dimensional Separation of Concerns
MRAT Multi-Dimensional Requirements Analysis Tool
NFR Non-Functional Requirements
OMG Object Management Group
PREView Process and Requirements Engineering Viewpoints
RDL Requirements Description Language
SIG Softgoal Interdependency Graph
SOFTAS Software Development with Aspects
TAO Testbed for Aspect-Oriented Software Development project
UML Unified Modelling Language
XML Extensible Markup Language
XI

XII

List of Contents
Chapter 1 Introduction .............................................................................................................................1
1.1 Motivation...............................................................................................................................2
1.2 Objectives of this PhD thesis..................................................................................................4
1.3 Validation of the results..........................................................................................................5
1.4 Contribution of the thesis........................................................................................................6
1.5 Structure of the thesis ...........................................................................................................10
Chapter 2 Requirements Engineering ....................................................................................................13
2.1 What is a requirement? .........................................................................................................14
2.2 What is requirements engineering?.......................................................................................15
2.3 An overview of requirements engineering approaches.........................................................19
2.3.1 The use case approach..................................................................................................19
2.3.2 Goal-oriented approaches.............................................................................................22
2.3.3 Viewpoint-oriented approaches ...................................................................................26
2.4 Summary...............................................................................................................................30
Chapter 3 Aspect-Oriented Software Development...............................................................................31
3.1 Separation of concerns..........................................................................................................32
3.2 What is a concern?................................................................................................................32
3.3 A new step towards improved separation of concerns..........................................................33
3.4 A brief introduction to aspect-orientation.............................................................................34
3.4.1 Symmetric versus asymmetric approaches ..................................................................35
3.4.2 Aspect-Oriented Programming ....................................................................................36
3.5 Aspect-oriented requirements engineering approaches ........................................................38
3.5.1 Aspect-oriented component requirements engineering................................................39
3.5.2 Aspect-oriented software development with use cases................................................40
3.5.3 Cosmos.........................................................................................................................42
3.5.4 Aspect-oriented requirements engineering with ARCaDE ..........................................44
3.5.5 Concern oriented requirements engineering ................................................................46
3.5.6 Aspect-oriented scenario modelling.............................................................................47
3.5.7 Theme...........................................................................................................................48
3.5.8 Requirements description language .............................................................................50
3.5.9 AOV-Graph..................................................................................................................51
3.6 Conclusions...........................................................................................................................52
Chapter 4 Aspect-Oriented Requirements Analysis...............................................................................55
4.1 The AORA approach ............................................................................................................56
4.1.1 Identify concerns..........................................................................................................58
4.1.2 Specify concerns ..........................................................................................................63
4.1.3 Compose concerns .......................................................................................................65
4.2 The AORA metamodel .........................................................................................................69
4.3 Illustrating AORA with an example .....................................................................................74
4.3.1 Identify concerns..........................................................................................................75
4.3.2 Specify concerns ..........................................................................................................77
4.3.3 Compose concerns .......................................................................................................80
4.4 Conclusions...........................................................................................................................83
Chapter 5 AORA Traceability and Tool Support...................................................................................85
5.1 Traceability support ..............................................................................................................86
5.1.1 Horizontal traceability..................................................................................................87
5.1.2 Vertical traceability......................................................................................................96
5.2 The AORA tool support........................................................................................................96
5.2.1 The tool architecture ....................................................................................................97
5.2.2 The tool specification features ...................................................................................105
5.2.3 The tool generic management features.......................................................................108
XIII

5.2.4 Related work.............................................................................................................. 110
5.3 Conclusions........................................................................................................................ 111
Chapter 6 Handling Conflicts in AORA.............................................................................................. 113
6.1 Multi-Criteria Decision Making: an overview................................................................... 114
6.2 An introduction to the AHP method .................................................................................. 117
6.3 Applying AHP to the AORA approach.............................................................................. 120
6.3.1 Exploring the use of AHP.......................................................................................... 120
6.3.2 Applying the AHP method ........................................................................................ 121
6.3.3 Discussion of the results............................................................................................ 126
6.3.4 A summary of our initial experiments with AHP...................................................... 127
6.4 AHP versus Weighted Average ......................................................................................... 128
6.5 Related work ...................................................................................................................... 130
6.6 Summary ............................................................................................................................ 134
Chapter 7 Evaluation of the AORA Approach.................................................................................... 135
7.1 A Testbed for Aspect-Oriented Software Development Project........................................ 136
7.2 A quantitative analysis of AORE....................................................................................... 137
7.2.1 Applying AORE metrics to the TAO requirements documents ................................ 139
7.2.2 Conclusions ............................................................................................................... 148
7.3 A qualitative analysis of AORE......................................................................................... 149
7.3.1 Traceability................................................................................................................ 151
7.3.2 Modularization of crosscutting requirements............................................................ 152
7.3.3 Identification of crosscutting requirements ............................................................... 153
7.3.4 Composition of crosscutting requirements................................................................ 153
7.3.5 Conflict management ................................................................................................ 154
7.3.6 Tool support .............................................................................................................. 155
7.3.7 Validation .................................................................................................................. 155
7.3.8 Mapping crosscutting requirements to later development stages.............................. 156
7.3.9 Maturity..................................................................................................................... 156
7.3.10 Summary ................................................................................................................... 157
7.4 AORA Tested in Projects................................................................................................... 158
7.4.1 The role of AORA in the SOFTAS Project............................................................... 158
7.4.2 The role of AORA in ASSD Project ......................................................................... 163
7.5 Conclusions........................................................................................................................ 165
Chapter 8 The AORA Refinement for MDD ...................................................................................... 167
8.1 An introduction to Model-Driven Development................................................................ 169
8.2 AORA refinement with MDD............................................................................................ 170
8.3 AORA refinement example................................................................................................ 176
8.4 Problems and limitations.................................................................................................... 177
8.5 Conclusions and future work ............................................................................................. 177
Chapter 9 The AORA Design Rationale ............................................................................................. 181
9.1 AORA first version ............................................................................................................ 182
9.2 AORA second version........................................................................................................ 185
9.3 AORA third version........................................................................................................... 189
9.3.1 The XML schema for concern specification ............................................................. 191
9.3.2 The XML Schema for Composition Specifications .................................................. 192
9.4 Major problems and their resolution.................................................................................. 194
9.5 Conclusions........................................................................................................................ 197
Chapter 10 Conclusions and Future Work .......................................................................................... 199
10.1 Summarising the goals of the thesis................................................................................... 199
10.2 Results of the thesis............................................................................................................ 200
10.3 Future work on AORA....................................................................................................... 202
10.4 Final remarks...................................................................................................................... 203
References ........................................................................................................................................... 205
XIV

List of Figures
Figure 2.1 The requirements engineering process..................................................................................16
Figure 2.2 An use case model for HMS.................................................................................................21
Figure 2.3 Representations for the three types of softgoals ...................................................................24
Figure 2.4 Representations for softgoal contributions ...........................................................................24
Figure 2.5 NFR framework process .......................................................................................................25
Figure 2.6 Decomposing security softgoal.............................................................................................26
Figure 2.7 Preview process ....................................................................................................................29
Figure 3.1 Separation of crosscutting concerns......................................................................................34
Figure 3.2 Aspect weaver.......................................................................................................................37
Figure 3.3 Use case slice........................................................................................................................41
Figure 3.4 UML elements for each use case slice..................................................................................41
Figure 3.5 Logical concerns from GPS cache........................................................................................43
Figure 3.6 Logical concerns from GPS cache........................................................................................43
Figure 3.7 AORE with ARCaDe............................................................................................................44
Figure 3.8 Concern oriented requirements engineering process ............................................................46
Figure 3.9 Scenario modelling with aspects...........................................................................................48
Figure 3.10 Theme/Doc Views ..............................................................................................................49
Figure 4.1 AORA model ........................................................................................................................57
Figure 4.2 AORA main tasks process described using an activity diagram ..........................................58
Figure 4.3 Identify concerns process......................................................................................................59
Figure 4.4 Specify concern process........................................................................................................63
Figure 4.5 Compose concerns process ...................................................................................................65
Figure 4.6 Composition rules between concerns....................................................................................68
Figure 4.7 A four-layered architecture...................................................................................................70
Figure 4.8 AORA metamodel packages.................................................................................................70
Figure 4.9 ConcernSpecification of the AORA metamodel...................................................................71
Figure 4.10 Concern composition of the AORA metamodel.................................................................72
Figure 4.11 AORA UML profile............................................................................................................74
Figure 4.12 Security SIG applied to enter subway.................................................................................76
Figure 5.1 The traceability schema ........................................................................................................86
Figure 5.2 Use case diagram for Enter Subway .....................................................................................90
Figure 5.3 Sequence diagram for EnterSubway.....................................................................................91
Figure 5.4 Resulting composition of Enter Subway sequence diagram (Figure 5.3) with its required
concerns on MPES ..........................................................................................................................93
Figure 5.5 Database_API architecture....................................................................................................97
Figure 5.6 Packages of the tool architecture ..........................................................................................98
Figure 5.7 Composition rule validation architecture..............................................................................99
Figure 5.8 Overall AORA architecture ................................................................................................100
Figure 5.9 Project XML tag.................................................................................................................101
Figure 5.10 Stakeholders XML tag......................................................................................................101
Figure 5.11 Concern XML tag.............................................................................................................103
Figure 5.12 Matchpoint XML tag ........................................................................................................104
Figure 5.13 History XML tag...............................................................................................................104
Figure 5.14 Operators XML tag ..........................................................................................................105
Figure 5.15 Tool three main views (left) and concern specification window (right)...........................106
Figure 5.16 MatchPoints window ........................................................................................................107
Figure 5.17 "Composition rule editor” window...................................................................................107
Figure 5.18 History window.................................................................................................................109
Figure 5.19 Decomposition and Contribution graph............................................................................109
XV

Figure 6.1 AHP hierarchical tree......................................................................................................... 117
Figure 6.2 Graphical representation of the enter subway match point ................................................ 122
Figure 7.1 Number of Concern Diffusion over Artefacts per approach .............................................. 141
Figure 7.2 Number of Concern Diffusion over Operations per approach ........................................... 142
Figure 7.3 Number of Concern Diffusion over LOC per approach..................................................... 144
Figure 7.4 Number of Coupling Between Artefacts per approach ...................................................... 145
Figure 7.5 Number of Lack of Cohesion in Operations per approach................................................. 146
Figure 7.6 Number of Artefacts per approach..................................................................................... 146
Figure 7.7 Number of Vocabulary Size per approach ......................................................................... 147
Figure 7.8 Number of Weighted Operations per Artefact per approach ............................................. 148
Figure 8.1 MDD transformation.......................................................................................................... 170
Figure 8.2 AORA refinement metamodel packages............................................................................ 171
Figure 8.3 Responsibility specification package of the AORA refinement metamodel...................... 172
Figure 8.4 Responsibility composition of the AORA refinement metamodel .................................... 174
Figure 8.5 AORA refinement UML profile......................................................................................... 175
Figure 8.6 Responsibility composition rule for responsibility match point of EnterSubway concern 176
Figure 9.1 A requirements model for quality attributes ...................................................................... 184
Figure 9.2 A model for advanced separation of concern..................................................................... 186
Figure 9.3 XML Schema of the definition of a concern...................................................................... 191
Figure 9.4 XML schema for composition in a match point................................................................. 192
XVI

List of Tables
Table 2.1 Reserve room use case specification......................................................................................21
Table 4.1 A template to specify concerns ..............................................................................................62
Table 4.2 Match point identification......................................................................................................66
Table 4.3 Relating stakeholders with match points................................................................................66
Table 4.4 Contributions for non-functional concerns ............................................................................77
Table 4.5 Template for Enter Subway concern......................................................................................78
Table 4.6 Template for Response Time concern....................................................................................79
Table 4.7 Template for Validate Card concern ......................................................................................80
Table 4.8 Match points identification ....................................................................................................81
Table 4.9 Match points table in a stakeholder point of view..................................................................82
Table 5.1 A guideline to derive a use case model from a set of concern templates...............................89
Table 5.2 A guideline to derive an activity diagram from a use case ....................................................90
Table 5.3 A guideline to derive a sequence diagram from a use case....................................................91
Table 5.4 Possible mapping of composition operators to sequence diagram fragments........................92
Table 5.5 Traceability matrix between concern and use cases and SIG ................................................94
Table 5.6 Traceability matrix between stakeholders and actors from use-cases diagrams ....................94
Table 5.7 Traceability matrix between concerns and their responsibility and sequence diagrams and
their messages................................................................................................................................95
Table 5.8 Traceability matrix between composition rules and sequence diagrams ...............................95
Table 6.1 Decision matrix ....................................................................................................................116
Table 6.2 Example of AHP pairwise classification of alternatives for a criterion ...............................118
Table 6.3 Example of AHP pairwise assignment of weights (importance) between two criteria........118
Table 6.4 Pairwise comparison matrix for criterion Contribution (4th level of tree)...........................122
Table 6.5 Pairwise comparison matrix for importance of stakeholder Passenger (4th level of tree)...123
Table 6.6 Pairwise comparison matrix for importance of stakeholder System Owner (4th level).......123
Table 6.7 Pairwise comparison matrix for importance of stakeholder Developer (4th level)..............123
Table 6.8 Pairwise comparison matrix for Stakeholders Importance criterion (3rd level of tree) and
respective Priority Vector (calculated)........................................................................................123
Table 6.9 Paiwise comparison of criteria weights (2nd level of tree) and respective Priority Vector
(calculated) ..................................................................................................................................124
Table 6.10 Priority matrix for level 3 plus final Vector.......................................................................125
Table 6.11 Final Ranking (synthesis)...................................................................................................125
Table 6.12 Final consistency ratio for all pairwise matrices................................................................126
Table 6.13 Criteria weights ..................................................................................................................128
Table 6.14 Alternatives classification, final priorities and ranking for Enter Subway match point.....129
Table 7.1 A set of AOSD metrics ........................................................................................................138
Table 7.2 A set of AORE metrics ........................................................................................................139
Table 7.3 Mapping of AORE metrics notions into AORE approaches elements.................................140
Table 7.4 The metrics results for AORE approaches...........................................................................141
Table 7.5 A summary of approaches that support backward traceability ............................................151
Table 7.6 A summary of approaches that support forward traceability ...............................................151
Table 7.7 A summary of approaches that support vertical traceability................................................152
Table 7.8 A summary of approaches that support modularization of crosscutting requirements ........152
Table 7.9 A summary of approaches that support identification of crosscutting requirements ...........153
Table 7.10 A summary of approaches that support composition of crosscutting requirements...........154
Table 7.11 A summary of approaches that support conflict management ...........................................154
Table 7.12 A summary of approaches that have tool support..............................................................155
Table 7.13 A summary of approaches that support requirements validation.......................................155
Table 7.14 A summary of how each of the selected approaches supports crosscutting requirements
mapping .......................................................................................................................................156
XVII

Table 7.15 A summary of the projects in which AORE approaches were used.................................. 156
Table 7.16 Short summary of AORE approaches and the features that their support......................... 157
Table 7.17 Retrieval concern template................................................................................................ 161
Table 7.18 Match point identification ................................................................................................. 161
Table 7.19 Contributions between concerns........................................................................................ 162
Table 8.1 A guideline to refine a responsibility .................................................................................. 172
Table 9.1 Template for quality attributes ............................................................................................ 184
Table 9.2 Template to describe concern.............................................................................................. 186
Table 9.3 A template to specify concerns............................................................................................ 190
XVIII

1
Chapter 1
Introduction
The general focus of the work developed for this PhD thesis is separation of concerns. In his book “A
Discipline of Programming”, Dijkstra introduces the term “separation of concerns” to refer the ability
of identifying, encapsulating and manipulating parts of software that are crucial to a particular goal or
purpose (Dijkstra, 1976). Separation of concerns helps managing software complexity, enhancing
understandability and traceability throughout the development process. It minimizes the impact of
change by proposing encapsulation of different concerns in separate modules. Existing approaches to
software development, such as those based on structured and object-oriented paradigms, were
proposed with this principle in mind. However, these approaches are unable to modularize properties
that cut across several other properties that compose the system. The code that implements each of
these properties cannot be encapsulated in a single module, a class for example, and is typically spread
along several modules. These properties, known as crosscutting concerns, are responsible for
producing scattered code, where the implementation of a given property is not localized in a single
module, and tangled code, where each module contains information about several distinct properties.
Therefore, the final implementation is more difficult to understand, maintain and evolve.
Aspect-Oriented Software Development (ACM, 2001) is another step towards achieving improved
modularity during software development. Aspect-Oriented Software Development focuses on
crosscutting concerns by providing means for their systematic identification, separation, representation
and composition (Rashid, 2003). Crosscutting concerns are encapsulated in separate modules, known

as aspects, and composition mechanisms are later used to weave them back with other core modules,
at loading time, compilation time, or run-time (Baniassad, 2006).
Historically, most new software development approaches are introduced at the programming level and
their concepts later move up the software lifecycle to be applied at the earlier phases, such as
requirements engineering, architecture design and modelling. We have seen this evolution tendency, in
the 70’s, with structured techniques and, in the late 80’s and early 90’s, with object-oriented
techniques. Similarly to previous software development approaches, Aspect-Oriented Software
Development was introduced first at programming level, with Aspect-Oriented Programming, where
aspects are handled in code. A number of Aspect-Oriented Programming approaches have been
proposed. These range from language mechanisms (AspectJ Project, 2007) to filter-based techniques
(Bergmans, 2000) through traversal-oriented (Lieberherr, 2001) and multi-dimensional approaches
(Tarr, 1999). Work has also been carried out to incorporate aspects, and hence separation of
crosscutting concerns, at the design level mainly through extensions to the UML metamodel e.g.
(Suzuki, 1999; Clarke, 2001; France, 2004; Clarke, 2005). However, crosscutting concerns are often
present before the solution domain, such as in Requirements Engineering (Moreira, 2002; Sutton Jr,
2002c; Rashid, 2003; Brito, 2003b; 2004; Clarke, 2005; Moreira, 2005a).
The purpose of this PhD work is to create an approach, with associated process, techniques and
supporting tools, to handle crosscutting and non-crosscutting concerns at the requirements level.
The remaining of this chapter presents the motivation for our work, our main objectives, the validation
of the results strategy, the contributions that resulted from our research and, finally, the structure of
this document.
1.1 Motivation
Software development is a discipline in constant evolution. Its main focus has always been on
improving the “separation of concerns” (Dijkstra, 1976) principle, by promoting abstraction,
modularisation and composition techniques. In the past decades several software development
paradigms, such as structured and object-oriented, have been proposed with this principle in mind.
While these paradigms represent a large step towards improved abstraction, modularization and
composition, there are still some concerns that do not align well with their decomposition criteria, and
are therefore difficult to modularise. The final result is that the specification and implementation of
those concerns are typically scattered along several core (base) modules, producing tangled
representations that are difficult to maintain, reuse and evolve. Such concerns are known as
2

crosscutting concerns, of which, logging, tracing, security and persistence are classical examples
(Kiczales, 1997).
Aspect-Oriented Software Development (AOSD) (ACM, 2001) aims at providing improved
modularisation and composition mechanisms to handle crosscutting concerns. Crosscutting concerns
are encapsulated in separate modules, known as aspects, and composition, or weaving, mechanisms
are later used to weave them back to the base modules in compilation, loading or execution time
(Baniassad, 2006).
An interesting phenomenon in software development is that the concepts are usually experimented in
the implementation phase and later tend to be abstracted and propagated to the earlier phases of the
software lifecycle. We witnessed this evolution tendency before with structured programming and
object-orientation, for example. A similar trend has been also happening to aspect-orientation. Aspect-
oriented concepts have been propagated up the software development lifecycle, to Software Design
(Herrero, 2000; Stein, 2002; France, 2004; Jacobson, 2004; Clarke, 2005), Software Architecture
(Pinto, 2003; Barais, 2004) and Requirements Engineering (Moreira, 2002; Sutton Jr, 2002a; Rashid,
2003; Baniassad, 2004; Brito, 2004; Baniassad, 2004a; Moreira, 2005a).
The focus of our work is exactly on handling crosscutting concerns during Requirements Engineering.
Aspect-Oriented Requirements Engineering (AORE) seeks to improve the modular representation of
crosscutting concerns at requirements level. AORE should describe crosscutting concerns in separate
modules and special composition rules are defined to support their influence on each other. In fact,
early composition expresses projections among different concerns, allowing the identification of
possible conflicting situations whenever a concern contributes negatively to others (Brito, 2004;
Moreira, 2005a). This offers the opportunity to establish critical trade-offs even before the architecture
design is derived, supporting the necessary negotiations among stakeholders (Rashid, 2003).
Composition can also be used to allow developers to grasp the full picture of a broader part of the
system.
Existing techniques to Requirements Engineering provide good support for identification and
treatment of requirements. However, these requirements approaches do not explicitly support, in an
integrated fashion, all kinds of requirements, particularly crosscutting concerns. Moreover, these
approaches suffer from the “tyranny of the dominant decomposition” (Tarr, 1999), as separation and
representation of requirements is achieved through a single decomposition criterion, such as use case
(Jacobson, 1992; Schneider, 1998), viewpoints (Finkelstein, 1996) and goals (Mylopoulos, 1992;
Chung, 2000). Aspects allow the modularization of crosscutting concerns that cannot be encapsulated
using those typical requirements artefacts, and are typically spread across several of them. Common
3

examples of crosscutting concerns are some non-functional requirements such as distribution,
synchronization and security. However, functional concerns can also be crosscutting as demonstrated
and discussed in (Baniassad, 2006) and (Rashid, 2006b). Therefore, if crosscutting functional or non-
functional requirements are hard to isolate within individual modules, and not effectively modularised,
it is not possible to reason about their effect on the system or on each other. Yet, neither the non-
crosscutting requirements approaches reflect the separation of the crosscutting requirements, nor do
they present mechanisms to compose such requirements in a successful manner without losing
abstraction.
According to Rashid et al., “an effective Requirements Engineering approach should reconcile the
need to integrate functional and non-functional concerns with the need to modularize those that are
crosscutting” (Rashid, 2003). Thus, effective Requirements Engineering approaches also remove any
distinction about whether a concern is functional or non-functional hence facilitating uniform
modelling of concerns and their crosscutting influences. Therefore, the difficulty in requirements
engineering classical approaches is, on the one side, the modularization of certain types of concerns
and, on the other side, composition mechanisms to reason about the impact crosscutting concerns have
on others.
The discussion above illustrates the need for Aspect-Oriented Requirements Engineering (AORE)
approaches. Aspect-Oriented Requirements Engineering fills the gap left by the traditional
Requirements Engineering approaches by providing systematic means for the identification,
modularization, representation and composition of crosscutting requirements, both functional and non-
functional. Aspect-Oriented Requirements Analysis (AORA) is the approach we developed during the
course of our research to handle crosscutting and non-crosscutting concerns at the requirements level.
1.2 Objectives of this PhD thesis
The objective of this PhD work is to create an approach, with associated process, techniques and
supporting tools, to handle crosscutting and non-crosscutting concerns at the requirements level. To
achieve this goal, we have created the Aspect-Oriented Requirements Analysis (AORA) approach.
Thus, AORA:
• Supports the identification and modularization of crosscutting concerns.
• Offers a technique to specify crosscutting and non-crosscutting concerns.
• Offers a systematic method to identify and resolve conflicts.
4

• Offers mechanisms for specifying concern compositions, crosscutting and non-
crosscutting, to reason about the impact any of them can have on others.
• Prevents the tyranny of the dominant decomposition symptoms.
• Proposes a list of mappings to transform concerns, crosscutting and non-crosscutting, into
artefacts at later development stages.
• Explores mechanisms for forward and backward traceability.
• Implements tool support for specification and composition of concerns.
1.3 Validation of the results
The ideal validation strategy we had in mind in the beginning required the AORA assessment in a real
setting, performed by independent users. During the period in which this PhD work was developed,
many other researchers started to investigate in “our” topic. The increased importance of the topic,
even if worrying at times, since this PhD author worked as a full time lecturer during the whole period
under evaluation, ended up contributing for an alternative, more interesting, validation strategy. So,
the validation we adopted required the AORA assessment according to four perspectives:
• Have different users applying the approach. AORA has been submitted to the
assessment of five postgraduate students: one PhD student, José Magno; four master
students, André Marques, Elisabete Soeiro, Filipe Vieira and Sérgio Agostinho; and three
undergraduate students, Marcos Brasil, Marcus Larsen and Nuno Ferreira. In spite of their
different backgrounds and maturity, they were able to apply the approach to different case
studies and use AORA for different purposes.
• Test the method and tools in different, if possible, independent, projects. AORA was
applied in two real case studies: the space domain ground segment software in the context
of the Aspect Specification for the Space Domain (ASSD) project funded by the European
Space Agency (ESA) (Agostinho, 2006) and the Flight Plan Tower Interface system in the
context of the Software Development with Aspects (SOFTAS) project funded by the
Fundação para a Ciência e a Tecnologia (SOFTAS, 2007).
• Identify comparison criteria to evaluate AORA against other recent methods. A set
of criteria was selected to compare several aspect-oriented requirements approaches,
including AORA. The comparison criteria chosen were inspired by those proposed in the
AOSD-Europe network (AOSD-European Network of Excellence, 2007).
5

• Define a set of metrics for producing an empirical validation. Metrics for measuring
some quality attributes in aspect-oriented software development (Sant’Anna, 2003;
Garcia, 2005) were adapted to help us performing a quantitative evaluation of AORA. The
adapted metrics were used to measure the results obtained by a selected set of aspect-
oriented requirements engineering methods in the context of a Testbed for Aspect
Oriented Software Development (TAO Project, 2007).
1.4 Contribution of the thesis
This PhD work contributes to a seamless approach for aspect-orientation, supporting separation,
specification, conflict resolution and composition of crosscutting and non-crosscutting concerns at the
requirements level. The resulting artefacts are:
• A model to identify, specify and compose crosscutting and non-crosscutting concerns.
• A metamodel to define the involved concepts and their relationships rigorously.
• A rigorous technique to identify and resolve conflicts.
• A set of guidelines to support forward traceability and tool functionalities to support
backward traceability.
• A tool to support the approach.
• A first step towards exploring the use of AORA in the Model-Driven Development
paradigm.
The Aspect-Oriented Requirements Analysis model is composed of plans and, each one, in tasks.
Each plan is related to the approach goals, i.e., identify, specify and compose concerns. The first two
plans (Identify and Specify concerns) contribute to offer effective means to identify crosscutting
concerns in requirements documents and to minimize the tyranny of dominant decomposition. This is
achieved by handling all concerns in the same fashion using a unique template. This template supports
a complete and consistent set of descriptions and representations of concerns, be them crosscutting or
non-crosscutting. The third and final plan (Compose concerns) contributes with the ability to compose
crosscutting and non-crosscutting concerns to clearly understand the system requirements and to
identify and analyse critical trade-offs between concerns.
6

A metamodel defines the main AORA concepts as an extension of the Unified Modelling Language
metamodel, allowing a language designer or methodologist to better capture, analyze and understand
our approach.
The AORA rigorous conflict management technique uses Multi-Criteria Decision Making methods,
in particular the Weighted Average (Dong, 1987) and the Analytical Hierarchical Process (Saaty,
1980), to rank conflicting concerns. Conflict identification and resolution is handled during
composition. It is important to understand well each concern, study the level of impact that each one
may have on others and decide on their relative importance before any solution decision is made.
A set of guidelines to support traceability is also offered. These guidelines offer a seamless transition
of concerns to concrete UML artefacts (UML, 2004). A set of functionalities of AORA tool supports
backward horizontal and vertical traceability. These mechanisms promote better understanding of
concerns and supports stakeholders’ validation of specifications and compositions.
Tool support was developed to facilitate the specification of concerns, the identification of
crosscutting concerns and the composition of concerns. The tool guarantees consistency of the
concerns’ specifications and their compositions, minimizing error occurrence and requirements
omissions.
Model-Driven Development was used to refine AORA. The definition of a metamodel that
describes the refinement of the approach is the first step towards exploring the use of AORA in the
Model-Driven Development paradigm. This is a modest contribute towards obtaining the first model
from where successive transformations can then be applied to evolve the requirements models into
architecture design models, for example (Sanchez, 2006).
We started working officially in aspect-oriented requirements engineering in 2002. We may securely
say that ours was the very first work in the area back then. Since then, we contributed to the Early
Aspects community (http://www.early-aspects.net/) by submitting the results of our investigation. We
have published only in events with peer-review. These range from international workshops, to
conferences and to journals. Our current list of publications in this area is:
International Journals:
• I. Brito, F. Vieira, A. Moreira and R. Ribeiro, Handling Conflicts in Aspectual
Requirements Compositions, Transaction on Aspect-Oriented Software Development
Journal, Special Issue on Early Aspects, LNCS, Springer, pp. 144-166, 4620, November
2007.
7

International Conferences:
• I. Brito, A. Moreira, J. Araújo, “Tool Support for Aspect-Oriented Requirements”, 10th
International Conference on Software Engineering and Applications (SEA’06), Texas,
USA. November 13-15, 2006.
• I. Brito, A. Moreira, “Towards an Integrated Approach for Aspectual Requirements”, 14th
IEEE International Requirements Engineering Conference (RE’06), IEEE Computer
Society, pp. 341-342, Minneapolis, USA. September 11-15, 2006.
• E. Soeiro, I. Brito, A. Moreira, “A XML-Based Language for Specification and
Composition of Aspectual Concerns”, 8th International Conference on Enterprise
Information Systems (ICEIS’06), pp. 410-419, Paphos, Cyprus. May 23-27, 2006.
• I. Brito, A. Moreira, “Advanced Separation of Concerns for Requirements Engineering”,
VIII Jornadas de Ingenieria del Software y Bases de Datos (JISBD’03), pp. 47-56,
Alicante, Spain. November 12-14, 2003.
• I. Brito, A. Moreira, “Aspect-Oriented Software Development: an Overview”, 5th
International Conference on Enterprise Information Systems (ICEIS’03), pp. 531-534,
Angers, France. April 23-26, 2003.
• A. Moreira, J. Araújo, I. Brito, “Crosscutting Quality Attributes for Requirements
Engineering”, 14th International Conference on Software Engineering And Knowledge
Engineering (SEKE’02), ACM, pp. 167-174, Ischia, Italy. July 15-19, 2002.
Workshops (one national):
• P. Greenwood, A. Garcia, A. Rashid, E. Figueiredo, C. Sant’Anna, N. Cacho, A. Sampaio,
S. Soares, P. Borba, M. Dosea, R. Ramos, U. Kulesza, L. Fernandes, T. Bartolomei, M.
Pinto, L. Fuentes, N. Gamez, A. Moreira, J. Araujo, T. Batista, A. Medeiros, F. Dantas, A.
Medeiros, J. Wloka, C. Chavez, R. France, I. Brito, “On the Contributions of an End-to-
End AOSD Testbed”, Early Aspects Workshop in Aspect-Oriented Requirements
Engineering and Architecture Design, 29th International Conference on Software
Engineering (ICSE’07), Minnesota, USA. May 20-26, 2007.
• F. Vieira, I. Brito, A. Moreira, “Using Multi-criteria Analysis to Handle Conflicts During
Composition”, Early Aspects Workshop in Traceability of Aspects in the Early Life
Cycle, 5th International Conference on Aspect-Oriented Software Development
(AOSD’06), Bonn, Germany. March 20, 2006.
8

• I. Brito, “A Framework for Aspect-Oriented Requirements Engineering”, Student
Extravaganza, 4th International Conference on Aspect-Oriented Software Development
(AOSD’05), Chicago, USA. March 14-18, 2005.
• I. Brito, “Aspect-Oriented Requirements Engineering”, Doctoral Symposium, 7th
Conference on Unified Modeling Language (UML’04), Lisboa, Portugal. October 10,
2004.
• I. Brito, “Engenharia de Requisitos Orientada pelos Aspectos”, Simpósio para Estudantes
de Doutoramento em Engenharia de Software (SEDES’2004), Coimbra, Portugal. April 6,
2004.
• I. Brito, A. Moreira, “Integrating the NFR Framework in a RE Model”, Early Aspects
Workshop in Aspect-Oriented Requirements Engineering and Architecture Design, 3rd
International Conference on Aspect-Oriented Software Development, Lancaster, UK.
March 22-26, 2004.
• I. Brito, A. Moreira, “Towards a Composition Process for Aspect-Oriented
Requirements”, Early Aspects Workshop in Aspect-Oriented Requirements Engineering
and Architecture Design, 2nd International Conference on Aspect-Oriented Software
Development (AOSD’03), Boston, USA. March 17-21, 2003.
• J. Araújo, A. Moreira, I. Brito, A. Rashid, “Aspect-Oriented Requirements with UML”,
2nd International Workshop on Aspect-Oriented Modeling with UML, 5th Conference on
Unified Modeling Language (UML’02), Dresden, Germany. September 30 to October 4,
2002.
• I. Brito, A. Moreira e J. Araújo, “A Requirements Model to Quality Attributes”, Early
Aspects Workshop in Aspect-Oriented Requirements Engineering and Architecture
Design, 1st International Conference on Aspect-Oriented Software Development
(AOSD’02), Enschede, The Netherlands. April 22 – 26, 2002.
International Technical Report:
• R. Chitchyan, A. Rashid, R. Waters, I. Brito, A. Moreira, J. Araújo, “Requirements-Level
Aspectual Trade-Off Analysis Approach”, AOSD-Europe-ULANC-28 Technical Report,
February 2007. http://www.aosd-europe.net/deliverables/d74.pdf .
9

1.5 Structure of the thesis
This thesis has ten chapters and three appendices. Chapter 1 is this introduction. The other nine
chapters and appendices are briefly presented below.
Chapter 2. Requirements Engineering. This chapter gives a background on Requirements Engineering,
contributing to help the reader understand some core key terms. The chapter starts with requirements
definitions and then follows with a brief introduction to the requirements engineering process. It
finishes with an overview of some relevant requirements engineering approaches.
Chapter 3. Aspect-Oriented Software Development. This chapter introduces a set of software
development notions and problems that motivate the need for aspect-oriented software development. It
starts with the notion of separation of concerns and why this principle is not successfully supported by
existing software development paradigms, such as object-orientation. It introduces the notion of
crosscutting concerns, explaining the need for improved modularization and composition mechanisms.
It follows by discussing Aspect-Oriented Requirements Engineering, introducing the context of this
thesis. The chapter finishes with an overview of some relevant Aspect-Oriented Requirements
Engineering approaches that were developed in parallel with later versions of AORA.
Chapter 4. The Aspect-Oriented Requirements Analysis Approach. This chapter explains AORA,
discussing the adopted development model. The core part of this chapter describes each AORA plan
with its major tasks. Each plan is closely related to the Aspect-Oriented Requirements Analysis goals,
i.e., identification, specification and composition of concerns. The main AORA concepts are defined
as an extension of the Unified Modelling Language metamodel, allowing a language designer or
methodologist to better capture, analyze and understand our approach. The chapter finishes with an
illustration of the approach by means of a case study.
Chapter 5. AORA Traceability and Tool Support. This chapter describes the AORA support for
traceability needed to help tracing between concerns, and between concerns and other artefacts of the
software lifecycle. It starts with the description of a set of guidelines proposed to explore horizontal
forward traceability and follows by describing the AORA tool, its architecture and main features. This
tool helps tracing concerns from requirements to the specification and composition rules through the
History feature and the Source attribute, as well, as tracing concern relationships. The various topics
and guidelines discussed in this chapter are illustrated with an example case study.
Chapter 6. Handling Conflicts in AORA. This chapter describes a rigorous technique to support
conflict management, as adopted by AORA. It describes two Multi-Criteria Decision Making
methods, the Weighted Average and the Analytical Hierarchical Process, which AORA uses to resolve
10

conflicts between concerns. The application of both methods is exemplified in the context of AORA
and the obtained results are discussed. The chapter finishes with a related work section and summary
conclusions.
Chapter 7. Evaluation of the AORA Approach. This chapter presents an AORA evaluation according to
two dimensions: qualitative and quantitative. AORA has been applied to several examples in the
context of our work and also to some case studies undergone outside this author’s control. In
particular, AORA has been used by several PhD, MSc and undergraduate students. It has also been
used in three research projects: SOFTAS 1 , funded by the Portuguese Fundação para a Ciência e a
Tecnologia, ASSD 2 , funded by the European Space Agency, and finally TAO 3 , a Testbed for Aspect-
Oriented Software Development. TAO made available a case study and invited several authors of
aspect-oriented methods, including us, to contribute with the results of applying their own method to
that case study. The various aspect-oriented requirements specifications available on the project
website were used for a quantitative evaluation of AORA using a set of metrics. A qualitative
evaluation was also performed comparing several aspect-oriented requirements engineering
approaches, including AORA. The chapter finishes with a discussion of AORA strengths and
weakness.
Chapter 8. The AORA Refinement for MDD. This chapter explores Model-Driven Development
technologies to refine AORA concern specifications and compositions. It starts with a brief
introduction to the Model-Driven Development and follows by using the source and target models
based on a UML metamodel, to refine AORA. This refinement has been validated by deriving
instantiations of AORA models using a case study.
Chapter 9. The AORA Design Rationale. This chapter gives an historical overview of the AORA
evolution. It discusses the problems we found and the solutions tried during the AORA development,
justifying the solutions we adopted and discussing the reasons why we discarded some of the
intermediate solutions.
Chapter 10. Conclusions and Future Work. This chapter states the conclusions of this work and
suggests directions for future work. It recalls the initial goals of this work and discusses how these
goals were pursued and achieved. It finishes with a final remarks section.
1 (SOFTAS, 2007), where this author participated
2 (ASSD, 2006), without this author participation
3 (TAO Project, 2007), where this author contributed with the results of applying AORA to the Health Watcher System
11

Appendix A. The Subway System Specification. This appendix presents the report specification
generated by the AORA tool of the case study Subway system.
Appendix B. The Health Watcher System Specification. This appendix presents the Health watcher
system case study used in the context of the TAO project, as well as the report specification generated
by the AORA tool.
Appendix C. SOFTAS Report. This appendix presents the report specification of the case study Flight
Plan Tower Interface.
12

13
Chapter 2
Requirements Engineering
Lack of user input, incomplete requirements, and changing requirements are the major reasons why so
many software development projects fail to deliver what the clients need on time and within the
budget (Sommerville, 1997b; Nuseibeh, 2000; Dusire, 2002). Requirements Engineering appeared to
overcome this situation. Requirements Engineering is a discipline composed of a set of activities that
support the description of what to develop and why it should be developed. This process contributes to
the solution of some real world problem. Once described, one needs to manage changes in these
descriptions and ensure a complete, consistent and correct set of requirements. The goal of
Requirements Engineering is to handle requirements that are good enough to allow the requirements
engineer to proceed with design and implementation of the software and deliver what the clients needs
(Sommerville, 1997b; Wiegers, 2003).
This chapter sets the context and the background for the work developed for this PhD work,
contributing to help understand some core key terms. It is organized into four sections. The first one
illustrates requirements definitions, the second explains the requirements engineering process, the
third summarizes some relevant existing approaches and, finally, the fourth concludes the chapter.

2.1 What is a requirement?
The literature provides many requirements’ definitions. For example, IEEE 610.12 standard defines a
requirement as (IEEE 610.12, 1990):
“A condition or capability needed by a user to solve a problem or achieve an objective.”
“A condition or capability that must be met or possessed by a system or system component to satisfy a
contract, standard, specification, or other formally imposed documents.”
“A documented representation of a condition or capability as in (1) or (2)”.
These definitions encompass both users and developers’ view, which in the perspective of this PhD
work are the stakeholders’ view. Stakeholders represent all the people that have a direct or indirect
influence on the project. They may be users, clients, owners, managers, developers, etc.
Another requirement definition proposed by Sommerville states that:
Requirements for the system are “The descriptions of the services and constraints …”. The same
author, this time with Sawyer, defines requirements as “… a specification of what should be
implemented. They are descriptions of how the system should behave, or they are a system property or
attribute. They may be constraints on the development process of the system” (Sommerville, 1997b).
Clearly, there is no universal definition of what a requirement is. There are, however, different kinds
of requirements. For example, Wiegers classifies requirements into five types (Wiegers, 2003):
• Business requirements: describe high-level goals of the organization or client who requests the
software.
• User requirements: describe required activities needed to achieve the users’ goals.
• System requirements: describe the top-level product requirements that can include software
and hardware.
• Functional requirements: describe the software functionality from the developer’s perspective.
• Non-functional requirements: describe global properties that affect affect the whole, or a large
part of, the system; they are quality characteristics such as performance, usability and
efficiency.
14

Sommerville proposes a clearly separation between different levels of description by using two terms:
(i) user requirements (high-level of requirements) and (ii) system requirements (detailed description of
the behaviour of the system) (Sommerville, 2004). Furthermore, Sommerville proposes that system
requirements are classified as functional or non-functional or domain requirements. They are defined
as follows:
• “Functional requirements are statements of services the system should provide, how the
system should react to particular inputs and how the system should behave in particular
situations.”
• “Non-functional requirements are constraints on the services or functions offered by the
system. They include timing constraints, constraints on the development process, standards,
etc.”
• “Domain requirements come from the application domain of the system and that reflect
characteristics of that domain. They may be functional or non-functional.”
In the last few years, the requirements engineer community has been dedicating some attention to non-
functional requirements that are defined as global requirements (Chung, 2000). To this community,
non-functional requirements are also quality attributes and constraints, and play a critical role during
software development, since they are very difficult to test and they are usually evaluated subjectively.
Chung proposes a framework to treat non-functional requirements based on a process-oriented
approach and on qualitative techniques. The goal is to build techniques for justifying design decisions
during the developments process, adopting ideas from qualitative reasoning.
Based on the classifications given above, we can synthesise by suggesting that there is a consensus
around the existence of two large classes of requirements, non-functional and functional requirements.
2.2 What is requirements engineering?
There is not a consensual definition of Requirements Engineering. We have analysed the existing
relevant definitions, looking for a definition that establishes exactly what is Requirements
Engineering.
Considerer Zave’s definition (Zave, 1997):
15

“Requirements engineering is the branch of software engineering concerned with the real-world goals
for, function of, and constraint on software systems. It is also concerned with the relationship of these
factors to precise specifications of software behaviour, and their evolution over time and cross
software families.”
While Zave’s definition considerer Requirements Engineering as part of the software development
process, the Sommerville definition is concerned with the activities to establish exactly what the
system should do (Sommerville, 2004):
“The descriptions of the services and constraints are the requirements for the system and the process of
finding out, analysing, documenting and checking these services and constraint is called requirements
engineering”.
At the end of the requirements engineering process, we obtain the system requirement documentation.
This documentation consists of requirements models, specifications and traceability policies.
Sommerville proposes four generic activities, as depicted in Figure 2.1, to build such documents
specification (Sommerville, 2004).
Figure 2.1 The requirements engineering process, taken from (Sommerville, 2004)
But there are many other definitions. For example, Wiegers says that (Wiegers, 2003): “Requirements
engineering is a discipline based on requirements development and requirements management.
Requirements development is related to elicitation, analysis, specification and validation. The goals of
these activities are gathering, evaluating and documenting the requirements for the software.
16

Requirements management goal is establish and maintaining an agreement with the customer on the
requirements for the software.”
And Pressman, a very respected author in software engineering states that (Pressman, 2005):
“Requirements engineering helps software engineers to better understand the problem they will work
to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of
the software will be, what the customer wants, and how end-users will interact with the software.
Requirements engineering begins with inception – a task that defines the scope and the nature of the
problem to be solved. It moves onward to elicitation – a task that helps the customer to define what is
required, and then elaboration – where basic requirements are refined and modified. As the customer
defines the problem, negotiation occurs – what are the priorities, what is essential? Finally, the
problem is specified and reviewed or validated to ensure that the customers’ and your understanding
of the problem coincide.” At the same time, requirements management activities are needed to
guarantee trace and changes of requirements.
These above presented definitions reveal requirements engineering process activities that are required
to allow before proceeding to the software design and its implementation. Inspired on these
definitions, the activities that are tackled in this PhD thesis are requirements elicitation and analysis,
specification, validation, and requirements management planning.
The requirements elicitation activity offers means for the identification and analysis of all
requirements. The requirements engineer might use information-gathering techniques to obtain and
analyze the requirements, to capture derived requirements that are a logical consequence of what the
users and clients requested (Nuseibeh, 2000). While some techniques emphasize the main functions
that the future system should implement (e.g. use cases proposed by (Jacobson, 1992)), others
emphasize constraints and certain properties that affect the whole system, for example the Quality
Attribute Workshop (Nord, 2004). The Quality Attribute Workshop provides a way to identify
important quality attributes and the scenarios associated with them as well as to clarify system
requirements before the software architecture has been created. The Quality Attribute Workshop
elicits, collects, and organizes software quality attribute requirements in the form of scenarios. The
results of the Workshop are intended to be followed by an analysis and planning activity to determine
further steps, such as applying the Attribute-Driven Design method (Nord, 2004). This information has
to be specified and validated.
The specification activity goal is to obtain the descriptions and representations of all gathered
requirements. The requirements engineer might use standard templates, such as proposed by
(Jacobson, 1992), (Sommerville, 1997a) and (Volere Requirements Resources, 2007), graphical
17

models, such as proposed by (Jacobson, 1992) and (VanLamsweerde, 2001), mathematical equations
and prototypes (Jacobson, 1992; VanLamsweerde, 2001).
The requirements validation activity is to ensure that the “requirements and models elicited provide an
accurate account of stakeholder requirements” (Nuseibeh, 2000). This activity can be accomplished by
checking if the requirements in the document do not diverge (contributing to ensure consistency) and
if the documents include all the stakeholders planned requirements (helping completeness). To achieve
this, the requirements engineer can use review techniques, such as program inspections (Gilb, 1993).
Conflict management, including identification and resolution of conflicts between requirements or
stakeholders’, can be included in the requirements validation activity (Karlsson, 1997; Boehm, 1998;
VanLamsweerde, 1998; Alves, 2003).
The requirements management activity facilitates communication among different stakeholders
supporting the sometimes difficult task of negotiation to obtain “agreement” in difficult, conflicting
situations. This agreement, in which requirements are documented, plays an important role in ensuring
that the requirements can be read, analysed, (re-)written, and validated (Nuseibeh, 2000). During the
requirements management activity we need to define the relationships between requirements and
between requirements and the architectural/design artefacts, to support traceability.
According to Nuseibeh, requirements traceability “lies at the heart of requirements management
practice in that it can provide a rationale for requirements and is the basis for tools that analyse the
consequences and impact of change” (Nuseibeh, 2000). Providing support for requirements
traceability is a way to achieve integrity and completeness of the end product. It is Gotel and
Finkelstein’s definition of traceability that is the one commonly used in Requirements Engineering
(Gotel, 1994). They define requirements traceability as the ability to describe and follow the life of a
requirement in both a forward and backward direction. Forward traceability assists with tracking the
artefact conversion from one representation and lifecycle stage to another. Backward traceability helps
to understand where an artefact or a change comes from. Pleeger and Bohner propose the definition of
horizontal and vertical traceability (Pleeger, 1990). Horizontal traceability is the possibility to trace a
requirement throughout the work products, i.e. from requirements throughout the design to its
implementation in the code. Vertical traceability, on the other hand, is the possibility to trace
dependencies within a work-product. Vertical traceability applied on requirements expresses the
relations between requirements on different levels.
Also, the requirements management task needs tool to storage and maintains large amounts of
requirements information to achieve its goals.
18

Many requirements engineering approaches have been created to handle all kinds of requirements. The
next section describes requirements approaches that are relevant in the context of this work.
2.3 An overview of requirements engineering approaches
This section presents some of the better known requirements engineering approaches in the literature,
in particular, uses cases (Jacobson, 1992), goals (Mylopoulos, 1992) and viewpoints (Finkelstein,
1996).
2.3.1 The use case approach
The use case approach, first proposed by Jacobson, has emerged as the most popular means of eliciting
system stakeholders or actors’ needs and capture requirements in industry (Jacobson, 1992). An actor
is an external entity, a person, another system or anything that interacts with the system under study. A
use case defines a set of interactions between an actor and the system to accomplish a goal. Each use
case focuses on describing how an actor achieves a goal or task.
In summary, the benefits of the use case approach are:
• Use case is generally regarded as an excellent technique for capturing the functional
requirements of a system.
• Use case alternative paths capture additional behaviour that can improve system robustness.
• Use cases have proved to be easily understood by business users and are excellent bridges
between software developers and end users.
• Use cases help stakeholders to understand the nature and scope of the business area or the
system under development.
• Use cases can be recorded using UML and maintained within widely available computer-aided
software engineering tools.
Use cases have, nonetheless, several limitations:
• Use cases are not well suited to capture non-functional requirements.
19

• Use cases do not handle conflicts.
• Use cases do not offer a means to reflect commonality/variability across products in a product
line or family.
The use case eliciting process starts by identifying the actors who will be using the system. This can
be done, for instance, by interviewing the relevant stakeholders of the project. Then, for each actor, we
collect the set of required functionalities for the system. Each major functionality is mapped onto one
use case which is triggered by the actor that requires that functionality. The set of use cases form the
use case model. The following step is to describe each use case. There are several techniques that can
be sued to achieve this, from free text to some formal technique. Scenarios are, perhaps, the most
common and simpler technique. Each use case is usually composed of one primary scenario that
describes the normal or basic flow of interactions and several alternative or secondary scenarios, each
one describing an error or unusual execution.
In addition, use cases can be related through include, generalization and extend relationships and
actors can be related through inherits relationships.
The include relationship allows us to “factor out” common behaviours between use cases. So, instead
of describing such behaviours repeatedly, we only need to define them once. The generalization
relationship between use cases has a similar meaning as that between classes, and is used when the
sequence of actions of one concrete use case (the child) is similar to but refines those of the other
abstract use case (the parent). The extend relationship allows us to add behaviour to a base use case at
a set of extension points without changing the base use case. The added behaviour is specified in the
extending use case which will be inserted into the base use case.
The set of use cases, actors and relationships among them composes the use case model.
This approach becomes a fundamental element of the Unified Modelling Language (UML) notation
(Jacobson, 1998). UML is a general-purpose modeling language that includes a graphical notation
used to create an abstract model of a system that drive the software development process and was
proposed by Object Management Group (OMG). In UML, actors are represented as stick figures and
use cases are represented by ellipses. Lines indicate which actors are involved in which use cases.
Figure 2.2 illustrates the notation used for use case models, as proposed by the UML language. The
example is based on the Hotel Management System (HMS) taken from (Jacobson, 2004).
20

Hotel Counter
Staff
Check- In Customer
Check-OutCustomer
21
Reserve Room
Customer
Figure 2.2 An use case model for HMS, taken from (Jacobson, 2004)
It is a common practice to document a use case fully through a template, where primary and
alternative scenarios are added as fundamental pieces of the document. There are a number of
schemes, however, but typical sections are:
• Name that provides a unique identifier for the use case and should be written in a verb-noun
format.
• Description is used to capture the essence of the use case.
• Preconditions are used to convey any conditions that must be true when a user initiates a use
case.
• Primary scenario is the description of the basic flow.
• Alternative scenarios are variations of the primary scenario.
• Post-conditions summarize the state of affairs after the scenario is complete.
Table 2.1 shows an example of use case specification for the Reserve room use case illustrated in
Figure 2.2.
Brief Description
Table 2.1 Reserve room use case specification, taken from (Jacobson, 2004)
This use case describes how the customer reserves the room.
Basic Flows
B1. Reserve Room
The use case begins when a customer wants to reserve a room(s).
The customer selects to reserve a room.
The system displays the types of rooms the hotel has and their rates.
The customer Check Room Cost.

The customer makes the reservation for the chosen rooms.
The system deducts the number of rooms available for reservation for the specified room type.
The system creates a new reservation with the given details.
The system displays the reservation confirmation number and check in instructions.
The use case terminates.
Sub Flows
S1. Check Room Cost
The customer selects his desired room type, indicates his period of stay.
The system computes the cost for the specified period.
Pre-Conditions
The customer has logged in the system.
Post Conditions
Upon successful reservation, a new reservation record is created and the number of rooms available for
the specified dates is decreased. If reservation is unsuccessful, there is no change in the database.
Special Requirements
The system must handle 5 concurrent reservations. Each reservation should not take more than 20
seconds.
Finally, the description of each use case is reviewed against the descriptions of the other use cases.
Further processing of the use case approach, related to use case realisations is considered during the
architecture and design stages of software development lifecycle.
2.3.2 Goal-oriented approaches
Goals have long been recognized to be essential components in requirements engineering. A goal is
defined as an objective the system under consideration should achieve (VanLamsweerde, 2001). Goals
must be specified precisely to support requirements elaboration, verification/validation, conflict
management, negotiation, explanation and evolution.
The benefits of the goal-oriented approaches are (VanLamsweerde, 2001):
• Goals provide a precise criterion for sufficient completeness of a requirements specification.
So, the specification is complete with respect to a set of goals if all the goals can be proved to
be achieved from the specification and the properties known about the domain considered.
• Goals provide the rationale for requirements change, so a requirement appears because of
some underlying goal which provides a base for it. This is motivated by the more dynamic
22

usiness and organizational environments, where systems are increasingly used to
fundamentally change business processes.
• Goals refinement provide a natural mechanism for structuring complex requirements
documents for increased readability and provide traceability links from high-level strategic
objectives to low-level requirements.
• Goals provide techniques to manage conflicts among multiple viewpoints. Goals have been
recognized to provide the roots for detecting conflicts among requirements and for resolving
them eventually.
• Goals are a substantial promise in supporting the requirements elicitation and elaboration.
Goals drive the identification of requirements to support them.
The Non-Functional Requirements Framework, NFR, proposed by (Chung, 2000), i* framework,
proposed by (Yu, 1997), and Knowledge Acquisition in Automated Specification, KAOS, proposed by
(Dardenne, 1993) are representative and complementary goal-based approaches. The KAOS
methodology uses goals as the central concept in requirements acquisition and as the main guiding
concept in developing formal specifications that integrate goals and goals refinements in requirements
models. The NFR framework provides knowledge structures about the non-functional goals based on a
qualitative framework for integrating goals and goal refinements in requirements models. The i*
framework is an agent-oriented knowledge approach for explicit modelling and analysis of multiple
actor relationships, introducing social analysis into the requirement analysis and facilitating the
dialogue with stakeholders during requirement elicitation. Beyond the importance that each of them
has in the context of the requirements engineering, the NFR framework is described in more detail
next to introduce some central concepts used for this PhD work.
The NFR Framework is first used to represent and analyse non-functional requirements and later uses
non-functional requirements, such as performance and security, to drive the overall design process
(Chung, 2000). This framework uses the central concept softgoal, which represents a non-functional
requirement. There are three types of softgoals: NFR softgoals, operationalizing softgoals, and claim
softgoals. The NFR softgoals act as overall constraints on the system. They are satisfied through
operationalizing softgoals that represent the design alternatives available for the given non-functional
requirement solution. Claim softgoals provide the rationale for design and development decisions.
Through claims certain characteristics can be reflected in the decision making process, some choices
explained, support for prioritising certain softgoals over others provided, etc. Figure 2.3 shows the
23

notation for the three types of softgoals, where operationalizing softgoals are represented by dark
clouds and claim softgoals are represented by dashed clouds.
Figure 2.3 Representations for the three types of softgoals, taken from (Chung, 2000)
These softgoals are systematically decomposed into more specific softgoals or sub-goals. When all the
sub-goals are needed together to meet the (parent) goal, an AND link is represented. A situation where
not all the sub-goals are necessary to achieve the goal is represented through and OR link. Figure 2.4
shows the notation for softgoal decompositions. When all sub-goals of a given goal are needed to
achieve that goal, an AND relationship is defined with an arc connecting the lines. A situation where
not all the sub-goals are necessary to achieve the goal, an OR relationship, is defined with two arcs
linking the decomposition lines.
Figure 2.4 Representations for softgoal contributions, taken from (Chung, 2000)
The framework provides others refinement methods: (i) operationalization methods assist in
operationalizing a softgoal, and (ii) augmentation methods help to represent additional information
about a softgoal.
When the softgoals are sufficiently refined, development techniques (i.e., operationalizations) for
achieve the softgoal are identified. When softgoals are refined, offspring softgoals are created to
represent the contribution to their parents either partially positive or surely positive or partially
negative or surely negative that are represented by ‘+’, ‘++’, ‘—‘ and ‘— —‘ respectively (see Figure
2.4). In the case of a positive contribution, satisfying the offspring leads to satisfaction of the parent
too, while in the case of negative contribution it leads to dissatisfying the parent. In order to focus on
what is important, priority softgoals are identified. All these elements are used to support design
decisions and to record a design rationale through a claim softgoal. This allows us to select
operationalizations based on design rationale.
24

The NFR framework provides an iterative process that is composed of the six major steps, as depicted
in Figure 2.5.
The framework process starts by acquiring domain knowledge and identifying non-functional
requirements that are treated as softgoals.
Decompose non -functional
requirements
Identify operationalizations
ActivityInitial
Identify non -functional
requirements
Select operationalizations
based on design rationale
Evaluate the impact of the
decisions
25
Identify priorities and
define tradeoffs
Figure 2.5 NFR framework process, adapted from (Chung, 1995; 2000)
All the above information is collected and represented in a Softgoal Interdependency Graph (SIG).
Nodes of a SIG are non-functional requirements, and are represented by clouds, and the lines represent
decompositions. Figure 2.6 shows an example of a SIG for the security softgoal where parent goals are
connected to their sub-softgoals, or sub-goals, with AND relationships.

Figure 2.6 Decomposing security softgoal, taken from (Chung, 2000)
The security softgoal is decomposed into Integrity, Confidentiality and Availability through an AND
relationship. The softgoals also have a subject matter or topics, in the case illustrate by Figure 2.6 is
[Account].
The evaluation procedure is applied to the SIG to determine the degree to which the initial NFR
softgoal is satisfied with the given set of decisions. After NFR requirements have been decomposed,
operationalised and evaluated, the NFR SIG is related to the appropriate functional requirement via
design decision links and the operationalisations are related to the specifications (design decisions) via
operationalisation links. Thus, when turning to the design stage, the functional requirements have clear
links to their related non-functional ones.
In the NFR framework, the identified softgoals need to be catalogued and arranged into types, and
hierarchies of IsA relationships that refine the initial softgoal. These catalogues are intended for future
reuse and to guard against omitting important concerns.
The approach does not clarify how exactly the non-functional requirements are identified, only
suggesting that they should be obtained by gathering knowledge about the domain for which a system
will be built. The NFR focuses on clarifying the meaning of non-functional requirements and
providing alternatives for satisfying them to the highest possible level, considering the conflicts
between them, their interrelationships (assisted by correlation catalogues), as well as the developers’
preferences.
2.3.3 Viewpoint-oriented approaches
According to Sommerville, the viewpoint-oriented requirements engineering approaches aim at
improving (i) the requirements engineering process and (ii) the organisation and presentation of the
26

specification itself (Sommerville, 1997a). The requirements engineer collects and analyses the
requirements for a system from different perspectives or viewpoints. Viewpoints are entities which
may be used to structure the process of requirements elicitation and to structure the requirements
specification.
The main arguments in favour of a viewpoint-oriented approach to requirements engineering are:
• Viewpoints organise system requirements from different types of users and stakeholders.
• Viewpoints are used to collect and classify different types of information, for example,
information about the application domain, information about the system’s environment and
engineering information about the system’s development.
• Viewpoints may be used as a means for structuring the process of requirements elicitation.
• Viewpoints may be used to identify conflicts between different requirements.
PREView (Process and Requirements Engineering Viewpoints) is a viewpoint-oriented approach that
improves the processes of requirements discovery, analysis and negotiation of the requirements
process (Sommerville, 1997a).
PREView uses concerns as drivers in requirement discovery and these concerns reflect the critical
non-functional characteristics of the system. While using viewpoints for actual requirements
discovery, the concerns (that are identified at the very start of the Requirements Engineering process
and are decomposed into questions, constraints, or requirements) should be addressed by the
viewpoints. Thus, the concerns may cut across all viewpoints and the questions associated with
concerns must be linked to all viewpoints and posed to viewpoint sources as part of the analysis
process.
PREView provides templates for concerns and viewpoints. The viewpoint template includes the
following information:
• The viewpoint name. This is used to identify and refer to the viewpoint; it should normally be
chosen to reflect the focus of the viewpoint. The name may reflect a role in the organisation or
a part of the system or process to which the analysis is restricted.
• The viewpoint focus. A viewpoint's focus defines the scope of the viewpoint. It is expressed as
a statement of the perspective adopted by that viewpoint.
27

• The viewpoint concerns. The viewpoint concerns reflect the organisational goals, business
objectives and constraints which drive the analysis process.
• The viewpoint sources. Viewpoint sources are explicit identifications of the sources of the
information associated with the viewpoint.
• The viewpoint requirements. This is the set of requirements arising from analysis of the
system from the viewpoint's focus. The requirements may be expressed in terms of system
functionality, user needs or constraints arising from application domain or organisational
considerations.
• The viewpoint history. This records changes to the viewpoint as an aid to traceability. It
includes changes to the focus, the sources and the requirements encapsulated in the viewpoint.
Each concern is also defined via a template, which includes the following information:
• The concern’s name and description.
• The external requirements contain references to requirements that represent the concern
elaborations that exert a direct influence on the requirements process.
The PREView process is composed of four main steps: (i) requirements discovery; (ii) requirements
analysis; (iii) requirements negotiation and (iv) requirements definition Figure 2.7 illustrates the whole
process.
The requirements discovery step starts with founding and describing concerns that are the base for
identify viewpoints and requirements. This step is broken down into four activities namely:
• Identify concerns.
• Elaborate concerns as external requirements and questions.
• Identify viewpoints.
• Discovery of the requirements for each viewpoint.
28

Figure 2.7 Preview process, taken from (Sommerville, 1997a)
The purpose of the requirements analysis step is to identify those requirements which are inconsistent
with concern questions, external requirements, or other viewpoints’ requirements. The objective is to
discover internal viewpoint conflicts and external inconsistencies where requirements from different
viewpoints are in conflict. To accomplish this, PREView uses decision tables, based on Quality
Function Deployment proposed by Zultner, to cross-check requirements against overlapping,
conflicting, or being independent of external requirements (Zultner, 1992). The result of this activity is
the input to the requirements negotiation activity where the inconsistencies should be resolved. So, the
inputs to the requirements negotiation step are the sets of conflicting and overlapping requirements.
PREView does not prescribe how conflicts are resolved or how overlapping requirements are
rationalised as this will necessitate trade-offs and negotiation.
Some of the outstanding problems in PREView are:
• Only a small number of concerns can be effectively addressed in each project. A larger
number of concerns make the amount of generated information unmanageable.
• Similarly, only a small number of viewpoints should be used.
• Lack of clear guidelines for concern decomposition.
29

• Lack of a mechanism for inconsistency management, trade-off analysis and decision support.
• Lack of relationships between viewpoints.
PREView is a well-know viewpoint-oriented approach, but there are others such as the Viewpoint-
Oriented Requirements Definition (VORD) proposed in (Kotonya, 1999).
2.4 Summary
While contemporary requirements engineering approaches, e.g., viewpoints, use cases, and goals
provide good support for identification and treatment of most kinds of requirements, they do not
explicitly support all kinds of requirements (Jacobson, 1992; Sommerville, 1997a; VanLamsweerde,
2001).
For example, use cases and viewpoint-oriented provide subjective perspectives on a system, but they
do not treat non-functional requirements, in a systematic, integrated way. While use cases simple
ignores them, viewpoints addresses them transversally to the whole set of viewpoint without further
refinement or relationships among them. That is, these approaches do not clearly capture how non-
functional requirements constrain or influence certain viewpoints or uses cases. In other words, they
do not specify the compositional relationships between broadly-scoped, non-functional properties and
the stakeholder requirements affected by them.
Goal-oriented approaches, on the other hand, drive the requirements engineering process from the
perspective of systemic goals, which are often non-functional in nature. Consequently, they do not
effectively capture the influence of highly functional properties on other requirements in the system. If
goal concepts indeed have such fundamental significance in Requirements Engineering, then it would
be desirable to seek some coherent view of the various notions of goal within the field.
30

31
Chapter 3
Aspect-Oriented Software
Development
The goal of this chapter is to introduce a set of notions and problems that motivates the need for the
Aspect-Oriented Requirement Analysis approach proposed in this document. The origin of Aspect-
Oriented Software Development is explained by remembering the notion of separation of concerns.
Separation of concerns aims at identifying and modularizing those parts of software that are relevant to
a particular concept, goal or purpose.
Existing approaches do not consider the crosscutting nature of some of functional and non-functional
requirements. The result is that the implementation of these crosscutting concerns are spread among
several modules, producing tangled representations that are invasive to implement, and therefore
difficult to understand, maintain and evolve.
Since these crosscutting concerns are often present in requirements, this chapter follows by describing
a set of selected Aspect-Oriented Requirements Engineering approaches, presenting their main steps
and characteristics. These approaches, together with AORA, will then be compared in the evaluation
chapter (Chapter 7). This chapter finishes with a summary of the main open issues that need to be
addressed by the Aspect-Oriented Requirements approaches.

3.1 Separation of concerns
The term separation of concerns was first discussed by Dijkstra in his classic book A Discipline of
Programming (Dijkstra, 1976). The following exert from page 211, clearly explains the concept
(Dijkstra, 1976):
“To my taste the main characteristic of intelligent thinking is that one is willing and able to study in
depth an aspect of one's subject matter in isolation, for the sake of its own consistency, all the time
knowing that one is occupying oneself with only one of the aspects. The others aspects have to wait
their turn, because our heads are so small that we cannot deal with them simultaneously without
getting confused. This is what I mean by "focussing one's attention upon a certain aspect"; it does not
mean completely ignoring the other ones, but temporarily forgetting them to the extent that they are
irrelevant for the current topic. Such separation, even if not perfectly possible, is yet the only available
technique for effective ordering of one’s thoughts that I know of. I usually refer to it as “a separation
of concerns”, because one tries to deal with the difficulties, the obligations, the desires and the
constraints one by one. When this can be achieved successfully, we have more or less partitioned the
reasoning that had to be done – and this partitioning may find its reflection in the resulting partitioning
of the program into “modules” – but I would like to point out that this partitioning of the reasoning to
be done is only the result, and not the purpose”.
According to this, separation of concerns means that a large problem is easier to manage if it can be
broken down into pieces, i.e., modules, particularly if the solutions to the sub-problems can be
combined to form a solution to the large problem. So, separation of concerns aims at identifying and
modularizing parts of software which are relevant to a particular concept, goal or purpose. This is a
fundamental principle in software engineering as it reduces software development complexity and
increases understandability and helps supporting traceability throughout the development process. It
minimizes the impact of change, by proposing encapsulation of different concerns in separate
modules.
3.2 What is a concern?
The software literature provides many definitions of concerns, many of them focusing on code. For
example, the Wikipedia defines a concern as “any particular piece of interest or focus in a program”.
However, the concept can be used across all the software development phases.
32

The Oxford English Reference Dictionary defines concern as “a matter of interest or importance to
one”. Another general definition given by Filman, a well-known author in aspect-orientation, states
that “a concern is any matter of interest in a software system” (Filman, 2005). Such definitions are,
however, too general to be useful, since almost everything can be seen as a concern. A more specific
definition is given in the IEEE standard for architecture: “a concern is those interests which pertain to
the system’s development, its operation or any other characteristics that are critical or otherwise
important to one or more stakeholders” (IEEE 1471, 2000).
In the context of this thesis, a concern will refer to a property which addresses a certain problem that is
of interest to one or more stakeholders and which can be defined by a set of coherent requirements.
Therefore, each concern defines a property that the future system must provide.
3.3 A new step towards improved separation of concerns
Once software systems reach a certain complexity, the good old principles of Software Engineering, as
defined by Ross et al., become more and more relevant, in particular, modularization, abstraction and
encapsulation (Ross, 1975). These principles play a fundamental role in achieving separation of
concerns. Traditional Software Engineering methods, such as structured and object-oriented ones,
have been developed with those principles in mind. Nonetheless, the modularization techniques they
provided cannot separate all interrelated complex concerns. Certain broadly-scoped properties, such as
response time, accuracy, security, persistence and several other functional requirements are very
difficult to modularize and its implementation is typically spread along several different modules. This
is because existing approaches generally follow a dominant decomposition criterion that is not suitable
to capture and represent all kinds of concerns that can be found in a software application (Kiczales,
1997). This problem is identified by Tarr et al. as the tyranny of the dominant decomposition and is the
source of deficient modularization: the system can be modularized in only one way at a time and as a
consequence the many concerns that do not align with that decomposition criteria end up scattered
across many modules and even tangled with modules that addresses other concerns (Tarr, 1999).
These two symptoms, known as scattering and tangling, are responsible for producing systems that are
hard to understand and very difficult to evolve. Such crosscutting concerns span traditional module
boundaries (for example, classes in an object-oriented decomposition), hindering understandability,
maintainability and evolution.
Figure 3.1 illustrates that Security, Logging and Persistence concerns are scattered along several
implementation modules, obliging each module to address more than one property, or concern.
33

Aspect
Module
34
Aspects
Modules
Figure 3.1 Separation of crosscutting concerns, taken from (Laddad, 2002)
Aspect-orientation is a new software development approach that addresses the above mentioned
limitations inherent in other approaches, including object-oriented programming. It aims to create
techniques, methods and tools to address crosscutting concerns.
3.4 A brief introduction to aspect-orientation
“Software Engineering is a continuously evolving discipline, searching for better and more efficient
techniques, methods and tools to determine the way we modularise and compose software systems. An
interesting characteristic of this continuously evolving discipline is the reverse introduction of the
techniques” (Rashid, 2004). Historically, most new development techniques are introduced at the
programming level and their concepts subsequently travel up the development lifecycle to be applied
at the earlier stages, for example, design, analysis and requirements engineering. We have seen this
evolution tendency, in the 70’s, with structured techniques and, in the late 80’s and early 90’s, with
object-oriented techniques. For example, object-oriented concepts were initially introduced by the
programming language SIMULA-67 and are now applied throughout the software lifecycle with
standard notations, such as the Unified Modelling Language, available for modelling, analysis and
design (Jacobson, 1998).
Aspect-Oriented Software Development (AOSD) is another step towards achieving improved
modularity during software development to assist developers in the separation of concerns, or the
breaking down of the system into distinct parts that overlap in functionality as little as possible (ACM,
2001). AOSD aims at addressing crosscutting concerns by providing means for their systematic
identification, separation, representation and composition (Rashid, 2003). In particular, AOSD focuses
on the modularization and encapsulation of crosscutting concerns. The term crosscutting concerns

efers to properties of software that cannot be effectively modularized using traditional software
development techniques, such as object-oriented methods. Notice that “crosscutting” is a relationship
between concerns. When we say that a concern is crosscutting we are implicitly acknowledging some
dominant decomposition that offers the base over which the crosscutting concern cuts across. This
relationship highly depends on the representation chosen to model, specify, or implement concerns.
This means that what is crosscutting in requirements may not be crosscutting in design, for example,
or what is crosscutting in an object-oriented representation may not be crosscutting in a functional
representation, and vice versa (Berg, 2005). Typical examples of crosscutting concerns are non-
functional requirements, such as security, fault tolerance, persistency. However, crosscutting concerns
can also be functional requirements, such as auditing, or validation (Moreira, 2002; Rashid, 2006b).
Crosscutting concerns are encapsulated in separate modules, known as aspects, and composition
mechanisms are later used to weave them back with other core modules, at loading time, compilation
time, or run-time (Baniassad, 2006).
Similarly to what happened to previous software development approaches, Aspect-oriented software
development, was introduced first at the programming level, with Aspect-Oriented Programming,
where aspects are identified and captured mainly in code (Kiczales, 1997; Bergmans, 2000),
(Lieberherr, 2001) and (Tarr, 1999). Several Aspect-Oriented Programming languages exist, but
AspectJ has played a key role in its early adoption by researchers and practitioners (AspectJ Project,
2007). The notion of aspect-orientation is based on earlier work on Composition Filters (Composition
Filters Project, 2007) and Adaptive Programming (Lieberherr, 2001). The concepts have been moving
beyond programming and are now being applied at earlier development stages. For example, work has
been carried out to incorporate aspects at the design (Suzuki, 1999; Herrero, 2000; Clarke, 2001) and
architecture levels (Pinto, 2003; Tekinerdogan, 2004) and requirements engineering (Moreira, 2002;
Sutton Jr, 2002c; Rashid, 2003; Brito, 2003b; 2004; Sutton Jr, 2004; Clarke, 2005; Moreira, 2005a;
Rashid, 2006a).
3.4.1 Symmetric versus asymmetric approaches
There are two levels of separation of concerns supported by existing aspect-oriented approaches,
symmetric and asymmetric (Harrison, 2002). In general, the distinction relates to whether an approach
includes a means to separate all kinds of concerns, both crosscutting and non-crosscutting (symmetric)
or includes a means to just separate crosscutting concerns from the rest of the system (asymmetric).
Some of the existing aspect-oriented requirements engineering approaches are asymmetric, where
functional requirements, or the dominant level, serve as the base decomposition and the crosscutting
35

equirements, or early aspects, that cross cut the base (Rashid, 2002). These asymmetric approaches
suffer from the tyranny of dominant decomposition. A symmetric Requirements Engineering approach
that eliminates the dominant decomposition through uniform treatment of the various types of
concerns in a system is proposed in Moreira et al. where the requirements are partitioned in a uniform
fashion, so there is one type of concern (Moreira, 2005b). In this work, a multi-dimensional view is
proposed to handle all concerns in an effective fashion.
3.4.2 Aspect-Oriented Programming
Aspect-Oriented Programming is a recent programming methodology that increases separation of
concerns by introducing a new modular unit, called aspect, for the modularization of crosscutting
concerns. Aspect-Oriented Programming enhances code abstraction, understandability and
adaptability. It minimizes the impact of change, by proposing encapsulation of different concerns in
separate modules.
This process is normally denominated aspectual decomposition, which identifies core functionality
and crosscutting concerns (or aspects). Afterwards, a composition process is needed to weave the
aspects back later on, at loading time, compilation time, or run-time (Baniassad, 2006). Aspect-
Oriented Programming allows the description of the relationships that exist between the different
concerns of a system and the mechanisms to compose them together into a coherent program. This
action is normally denominated as weaving, which expresses how the system intertwines the execution
of the base code and aspects. Figure 3.2 illustrates how the DisplayUpdating aspect (top left in the
figure) is weaved is the setX(), setY() and moveBy() elements from Point and Line class.
Although Aspect-Oriented Programming is a recent paradigm, numerous aspect-oriented programming
approaches have already been proposed such as AspectJ (AspectJ Project, 2007) , Adaptive
Programming (Lieberherr, 2001), Composition Filters (Composition Filters Project, 2007), JBoss AOP
(JBoss Project, 2007), JAsCo (JAsCo Project, 2007), HyperJ (HyperJ, 2007), Caesar (CAESAR,
2007), among others. Aspect-Oriented Programming extensions to other languages have also been
developed, for example, AspectC (AspectC Project, 2007), and AspectC++ (Spinczyk, 2005) are
aspect-oriented extensions to C and C++, respectively.
36

after(): call(void
FigureElement+.set*(..))
|| call(void
FigureElement.moveBy(int, int))
{
Display.update();
}
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int,int)
draw()
FigureElement
moveBy(int,int)
refresh()
2
Line
Weaver
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int,int)
draw()
37
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
draw()
DisplayUpdating
FigureElement
moveBy(int, int)
refresh()
Figure 3.2 Aspect weaver, taken from (Kiczales, 2003)
2
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
draw()
AspectJ is probably the most mature, and therefore reliable, Aspect-Oriented Programming language.
AspectJ is a general purpose programming language and is an extension to java to support the concept
of aspect at the implementation level. To achieve this, AspectJ offers a special constructs called
aspect. Aspects can contain several entities unavailable to standard classes such as pointcuts,
joinpoints and advices. Join points are points in a program where additional behavior can be usefully
joined. An advice is a program element that defines additional code to run at a join point, and can run
before, after, and around join points. A pointcut is a program element that identifies join points.
An aspect can alter the behaviour of the base code (the non-aspect part of a program) by applying
advice (additional behaviour) at various join points (points in a program) specified in a quantification
or query called a pointcut (that detects whether a given join point matches).
These new concepts are needed to weave aspects with the base application. Traditionally, weaving
takes place at compile time, which means that the advices are inserted into the target application at the
source or byte-code level. However, more flexible approaches allow weaving to occur at runtime, such
as Jasco (JAsCo Project, 2007).
AspectJ includes a compiler (ajc), a debugger (ajdb), a documentation generator (ajdoc), a program
structure browser (ajbrowser); it is integrated with Eclipse, Sun-ONE/Netbeans, GNU
Emacs/XEmacs, JBuilder, and Ant (AspectJ Project, 2007).

A radically different programming language is Hyper/J (Tarr, 1999; MDSoC, 2007). Hyper/J supports
“multi-dimensional” separation and integration of concerns in Java. The goal is to avoid the tyranny of
the dominant decomposition. This is achieved using hyperslices to encapsulate concerns in
dimensions. The HyperJ tool manages the interactions across different decompositions and provides a
powerful composition capability, which can be used to integrate separated concerns into a component.
3.5 Aspect-oriented requirements engineering approaches
As described in Chapter 2, contemporary requirements engineering approaches, such as viewpoints
(Sommerville, 1997b), use cases (Jacobson, 1992), and goals (VanLamsweerde, 2001) provide good
support for identification and treatment of some kinds of requirements. However, these requirements
approaches do not explicitly support well broadly-scoped requirements, such as crosscutting concerns,
and do not explicitly support their composition. Moreover, they all suffer from the “tyranny of the
dominant decomposition”.
The dominant decomposition for requirements is the organization of the requirements document into
elements on the basis of stakeholders’ perspectives, for example, use cases, viewpoints, and goal
descriptions. So, aspects allow the modularization of crosscutting concerns that cannot be
encapsulated using use cases or viewpoints, for example, and are typically spread across several of
them (Jacobson, 1992; Finkelstein, 1996). Composition, on the other hand, apart from allowing the
developers to picture a broader part of the system, allows them to identify conflicting situations
whenever a concern contributes negatively to others. This offers the opportunity to establish critical
trade-offs before the architecture design is derived, supporting the necessary negotiations among the
stakeholders (Rashid, 2003).
In summary, if crosscutting requirements, functional or non-functional, are hard to isolate within
individual modules and not effectively modularised, it is not possible to reason about their effect on
the system or on each other. Yet, neither the non-crosscutting requirements approaches reflect the
separation of the crosscutting requirements, nor do they present mechanisms to compose such
requirements in a successful manner without losing abstraction. This fact motivates the work on
Aspect-Oriented Requirements Engineering (AORE).
The AORE approaches fill the gap left by the traditional requirements engineering approaches, by
providing systematic means for the identification, modularization, representation and composition of
crosscutting requirements.
38

AORE approaches, similarly to other requirements approaches, consist of elicitation, analysis and
specification, validation, conflict resolution and management of requirements. The fundamental
difference between AORE and classic requirements engineering approaches is that AORE handles all
kinds of requirements, including crosscutting requirements. To achieve this, AORE requires:
• The existence of effective means to identify aspectual requirements in requirements
documents.
• The ability to modularize aspectual requirements.
• The facilities to obtain a complete and consistent set of descriptions and representations of all
requirements.
• The ability to compose aspectual and non-aspectual requirements to clearly understand the
system and to identify and analyse critical trade-offs between requirements.
• The procedure to identify and resolve conflicts between requirements or stakeholders.
• The facilities to trace aspectual requirements to latter development stages or to their source.
• A set of tools to facilitate aspectual requirements management.
From the large list of AORE approaches that currently exist, we have chosen the better-know ones;
some of these are extensions of well-established requirements engineering techniques and the others
are newly created to support AORE.
3.5.1 Aspect-oriented component requirements engineering
The Aspect-Oriented Component Requirements Engineering approach was one of the first to be
proposed. This approach is an extension of component based software development, offering a
characterization of diverse aspects of a system that each component provides to end users or other
components (Grundy, 1999). When building an application, a developer needs to identify all the
components, using “functional decomposition”, and use the term “aspects” in to ways: (i) to describe
features that crosscutting many different components and (ii) to provide “multiple perspectives” on
software components using aspect information of the component specification and design (Filman,
2005).
39

The Aspect-Oriented Component Requirements Engineering approach is complementary to design and
implementation component-based approaches. It extends components and their interactions to support
overlapping aspects between components. Also, promoting the isolation of aspects into reusable
components is another important issue of the approach. According to this, Aspect-Oriented
Component Requirements Engineering is an asymmetric approach since it includes means to just
separate aspects that crosscut the components.
This approach is too specific for component development, not showing evidence of its use in software
development in general. Besides, the identification of aspects for each component is not clearly
defined and lacks tool support.
3.5.2 Aspect-oriented software development with use cases
The Aspect-Oriented Software Development with Use Cases approach model crosscutting concerns
with use cases (Jacobson, 2004). According to the author, one should design use cases in terms of
overlays on top of classes – overlays refer to use cases slices and use case modules. Later, aspect
technology is used to compose use cases slices/modules to form the complete system. More
specifically, Aspect-Oriented Software Development with Use Cases proposes a technique to identify
and keep crosscutting concerns separate and a composition mechanism to compose these concerns to
form the desired system. This is achieved with the concepts of a use-case slice and a use-case module.
Use-case slices employ aspects to compose the different parts of a model together. A use-case module
contains the specifics of a use case over all models of the system. Another important concept used in
this approach is the extension use case. This is a special kind of use case that allows us to keep
additional functionality separate from an existing use case. The realization of extension use cases
requires additional behaviour to be defined into existing operations and the use-case slices keep these
operation extensions separate from the existing operations. They are subsequently executed at
designated points specified by pointcuts during compilation or execution.
A system is built use case by use case. First, we must identify the use cases that form the system.
Secondly, we specify each use case, to analyze it, to design and implement it. As each use case
progresses through the various models, the corresponding use case slice is updated in the respective
models. These slices are shown shaded in Figure 3.3.
40

Specify
Use Case
updates
use case model
Analyze
Use Case
updates
analysis model
41
Design and Implement
Use Case
design model
updates
implementation
model
Figure 3.3 Use case slice, taken from (Jacobson, 2004)
Figure 3.4 shows an example of use case progress through the UML models. For example, Withdraw
Cash use case has Interface, Cash Withdrawal and Cash components in the Use Case design model
and Component design & implementation model. Furthermore, the Interface and Cash from the
Component design & implementation model are also components of Transfer Funds and Deposit
Funds use cases.
Use case
Specification
Withdraw Cash
Transfer Funds
Deposit Funds
Interface Cash
Withdrawal
Interface
Use case
design
Transfer
Funds
Interface Deposit
Funds
Cash
Cash
Component design &
implementation
Interface
Cash
Withdrawal
Transfer
Funds
Deposit
Funds
Figure 3.4 UML elements for each use case slice, taken from (Jacobson, 2004)
Aspect-Oriented Software Development with Use Cases approach is based on the original Uses Case
approach from the same author and adapts the concept of use cases to support crosscutting concerns.
Also, it introduces new concepts, such as use-case slices and pointcuts to handle composition. These
notions are strongly influenced by the AspectJ-style linguistic constructs (e.g., pointcut) and HyperJ-
type decomposition modules (e.g., slice).
Aspect-Oriented Software Development with Use Cases is an approach strongly related to UML;
currently, it does not support conflicts management. At requirements level, this approach handles all
Cash

concerns in a uniform fashion using use cases, use case slices and use case modules, so it is a
symmetric approach.
3.5.3 Cosmos
Cosmos is a general purpose schema for modelling multidimensional concern-spaces (Sutton Jr,
2002c; MDSoC, 2007). A concern-space is an organised representation of concerns and their
relationships and predicates. The relationships and predicates are also classified as concerns to
guarantee completeness and consistency with a multi-dimensional perspective. The authors use the
term “Multi-Dimensional Separation of Concerns” (MDSoC) to refer to flexible and incremental
separation, modularization, and integration of software artefacts based on any number of concerns. Its
mechanisms allow clean separation of multiple, potentially overlapping and interacting concerns
simultaneously, with support for on-demand remodularization to encapsulate new concerns at any
time. Considering this multi-dimensional perspective, Cosmos handles all concerns in a uniform
fashion, so it is a symmetric approach.
Based on this schema it is possible to modularize concerns but not to identify them. Using mapping
association and physical implementation relationships’ elements it is possible to map concerns into
artefacts of the next development process stages. Also, using the interpretative contribution
relationship element, it is possible to identify conflicts between concerns, but not to solve them.
Finally, the schema does not have enough information about how concerns can be composed.
To illustrate this approach, a general-purpose software cache example is used in (Filman, 2005). “It
supports the usual functionality associated with a cache and it has some less common features such
object dependencies, logging, and statistics collection. It is also highly configurable, both statically
and dynamically.” In particular, a cache has to be specified in terms of a particular set of desired
concerns, and then to enable a cache that addressed those concerns to be composed from reusable,
concern specific fragments of Java code. Examples of high-level concerns in the implementation of the
GPS cache are illustrated in Figure 3.5 and Figure 3.6. In these figures the concerns are organized as
classes of logical concerns or other categories of logical concerns. The logical concerns classes is
composed of implementation object classes, functionality, behaviour, state, properties, and Java units.
42

Figure 3.5 Logical concerns from GPS cache, taken from (Filman, 2005)
The logical concerns other categories is composed of instances, properties, and topics.
Figure 3.6 Logical concerns from GPS cache, taken from (Filman, 2005)
The authors of this approach affirm that Cosmos supports the modelling of multidimensional concern
spaces, and concerns in the cache can indeed be described multidimensional, i.e., many elements in the
cache can be assigned to concerns in multiple classifications.
43

3.5.4 Aspect-oriented requirements engineering with ARCaDE
The aspect-oriented requirements engineering with ARCaDE (Aspectual Requirements Composition
and Decision Support) approach proposes a model that supports separation of aspects at the
requirements level based on treating PREView concerns as aspects (Rashid, 2002). Due to the
broadly-scoped characteristic of PREView concerns, as they refer to non-functional requirements, they
basically crosscut the requirements emerging from viewpoints (Rashid, 2002; 2003). This approach
proposes techniques to:
• Identify and specify concerns and candidate aspects.
• Compose candidate aspects with the viewpoints that they cut across.
• Handle conflicts.
Figure 3.7, taken from Rashid et al., shows the process for ARCaDE process model (Rashid, 2003).
Identify and
specify concerns
Identify coarse-grained
concern/stakeholders’
requirements relationships
Identify candidate
aspects
Compose
Define composition
rules
Compose aspects
and stakeholders’
requirements
Identify & Specify
Identify and specify
stakeholders’ requirements
Build
contribution
table
Handle conflicts
Attribute weights
to conflicting
aspects
44
Revise
requirements
specification
Resolve
conflicts
Figure 3.7 AORE with ARCaDe, taken from (Rashid, 2003)
Specify aspect
dimensions
The model starts by identifying and specifying both concerns and stakeholders’ requirements. Using a
matrix, the concerns that crosscut the viewpoints are identified and qualified as candidate aspects.
Once the coarse-grained relationships between concerns and stakeholders’ requirements have been
established and the candidate aspects identified, the next step is to compose candidate aspects with
viewpoints. Composition rules between aspectual requirements and viewpoint requirements are then
defined using composition operators. A set of composition rules is defined for each candidate aspect.

The rules are written at the requirements’ aspect and viewpoint granularity level, showing the effect of
the aspect on the base requirements. After the composition step, conflicts are identified and handled.
First, due to the ability to compose aspectual and non-aspectual requirements at fine granularity level,
the need for analysing possible conflicts is eliminated when different concerns affect different
requirements within the same viewpoint. Secondly, a mechanism for conflict assessment and
resolution is provided when concerns do affect the same requirement. In this case, the model proposes
three steps:
• Built a contribution matrix with only negative contributions presenting a real problem.
• Allocate weights to conflicting aspects based on fuzzy intervals to prioritise the conflicting
requirements.
• If the weights are assigned to conflicting requirements are equal, initiate a negotiation between
stakeholders.
The process concludes by identifying candidate aspects’ mapping and influence on later development
stages. A candidate aspect might map onto a system feature/function, decision, design and aspect. A
concern might influence different points in a development cycle, e.g., availability influences the
system architecture while mobility influences specification, architecture, design and implementation.
The approach supports separation and specification of aspectual and non-aspectual requirements in
modules representing coherent abstractions, and described using XML. The XML composition rules
use a list of constraint actions and operators, with well-defined semantics. They are used to specify
how aspectual requirements affect or advise the behaviour of a set of non-aspectual requirements. The
approach is supported by a tool called ARCaDe. This tool supports the validation of composition
relationships and the identification of conflicts. Once detected, this approach supports conflicts
resolution using fuzzy value assignment.
Aspect-Oriented Requirements Engineering is an extension of PREView requirements engineering
approach, proposing means to separate candidate aspects from view points, so according to this, the
approach is asymmetric. Also, it does not present a systematic technique to identify concerns and the
composition rules are defined based on the candidate aspect, i.e., the approach only proposes
composition rules that define how an identified crosscutting concern is composed with viewpoints. So,
the composition of the viewpoints themselves is not specified.
45

3.5.5 Concern oriented requirements engineering
Moreira et al. propose a multi-dimensional approach to separation of concerns in requirements
engineering as well as trade-off analysis of the requirements specification from such a multi-
dimensional perspective (Moreira, 2005a; 2005b). The basic ideas are: (i) to address the so-called
tyranny of dominant decomposition, promoting a uniform treatment of the various types of concerns;
(ii) to take advantage of the observation that concerns in a system are, in fact, a subset, and concrete
realisations, of abstract concerns in a meta concern space; and (iii) to provide a rigorous analysis of
requirements-level trade-offs as well as important insights into architectural choices.
Figure 3.8 shows the Concern-Oriented requirements Engineering (CORE) process model, taken from
(Moreira, 2005b).
Figure 3.8 Concern oriented requirements engineering process, taken from (Moreira, 2005b)
The process starts by identifying concerns using existing requirements elicitation mechanisms. The
identified concerns are specified using well-defined templates. The second step is to identify coarse-
grained relationships among concerns by relating concerns to each other through a matrix. The third
step is to specify the possible projections of each concern on other concerns using composition rules.
These rules operate at fine granularity, i.e., at individual requirements level and not just at concerns
level. After specifying the various projections with the aid of composition rules, identification and
resolution of conflicts among the concerns is carried out. This is accomplished by:
• Building a contribution matrix where each concern may contribute negatively (-) or positively
(+) to the others (empty cells represent “don’t care” contributions).
• Providing a folded table to “reflected projections”.
46

• Allocating priorities, i.e. weights in the interval [0…1], to those concerns or requirements that
contribute negatively to each other in relation to a particular concern.
• Solving the conflicts with the stakeholders, using the above prioritisation approach to help
negotiation and decision-making.
Conflict resolution might lead to a revision of the requirements specification, which is repeated until
all conflicts have been resolved through effective negotiations. The last activity in the model is
identification of the dimensions of a concern using two notions: mapping and influence, as in Aspect-
oriented requirements with ARCaDE (Rashid, 2003).
The discussion above demonstrates that this approach supports multi-dimensional separation of
concerns at the requirements level, eliminating the dominant decomposition through uniform treatment
of the various types of requirements in the system, so it is symmetric. This multi-dimensionality is
achieved through a uniform treatment of both functional and non-functional properties that enhance
the support of crosscutting functional properties. The multi-dimensional approach provides an
effective support for establishing early trade-offs and negotiations among stakeholders. A
Multidimensional Requirements Analysis Tool (MRAT) is the tool that supports this approach
(Chitchyan, 2007a).
3.5.6 Aspect-oriented scenario modelling
Whittle et al. and Araújo et al. present an aspect-oriented scenario modelling approach to be used at
the requirements level (Araújo, 2004; Whittle, 2004). The motivation for this approach is to eliminate
the need to repeatedly deal with the same crosscutting, i.e. aspectual scenarios (e.g., failures,
exceptions, etc.), which occur along with many scenarios. The non-aspectual and aspectual scenarios
are modelled separately from each other then merged as required, producing the complete scenarios.
Aspectual scenarios are modelled using Interaction Pattern Specifications described in France et al.
and composed with non-aspectual scenarios (France, 2004). The process model presented also
includes the generation of state machines from composed scenarios (represented by sequence
diagrams), to be used to create prototypes for stakeholder’s requirements validation, as implemented
by Whittle (Whittle, 2004). Figure 3.9, shows the main steps of the Scenario Modelling with Aspects
approach.
47

Figure 3.9 Scenario modelling with aspects, taken from (Whittle, 2004)
The process starts with requirements identification and definition using use cases to identify functional
requirements and templates for non-functional ones. This is followed by use case refinement and
scenario identification. The non-functional requirements are likely to result in aspectual scenarios, and
other aspectual scenarios may be identified for some functional requirements. Thereafter, the non-
aspectual scenarios are modelled as UML sequence and state machines diagrams. As mentioned
before, aspectual scenarios are modelled as Interaction Pattern Specifications, which are then
translated into State Machine Pattern Specifications using a state machine synthesis algorithm. These
aspectual state machines are composed with non-aspectual ones using State Machine Binding
Specification, which provides a correspondence between relevant states of each of the state machine.
Finally, the composed state machine can be simulated using existing simulation tool.
The approach does not propose a systematic technique to aspectual scenario identification, merely
stating that scenarios that represent use cases which affect other use cases are aspectual. The approach
also suggests that the non-functional requirements will result in aspectual scenarios. Nevertheless,
once identified, the non-aspectual and aspectual scenarios are specified and compose using UML
models. Also, aspectual scenarios is an asymmetric approach, since it proposes means to define and
modularize functional, non functional and crosscutting requirements through different elements, such
as use cases, templates and aspectual scenarios.
3.5.7 Theme
The Theme approach provides a model and tool support for identification of aspects in requirements
specifications (Theme/Doc), design level modelling of aspects and their composition, at design level
only (Theme/UML) and, checking design decisions in the context of the requirements (Baniassad,
2004; Baniassad, 2004a; Clarke, 2005). This is accomplishing by Theme/Doc and Theme/UML. At
the requirements level, Theme/Doc provides four views for requirements engineering to identity
aspects in requirements and map them to design. Figure 3.10, taken from Chitchyan et al., shows these
views: (i) action; (ii) clipped; (iii) theme and (iv) augment the theme (Chitchyan, 2005). Theme/Doc
allows the developer to first identify a set of actions in the requirements documentation, i.e. views, and
secondly, to refine and link views of the requirements to reveal which functionality in the system is
48

crosscutting, and where in the system it crosscuts. The requirements engineer checks-up the links, re-
groups the words and requirements and clips the links between action words and requirements. This
process, the clipped view, leads to grouping of requirements around main (base) and secondary
(aspectual) functionalities called themes. A theme is a collection of structures and behaviours that
represent one feature. According to this, Theme is a symmetric approach since any concern, whether
crosscutting or not, may be encapsulated in a theme.
The themes are then organised in accordance with the order of composition that is reflected by the
levels of themes in clipped view. The augment view is used to verify design decisions with
requirements.
Figure 3.10 Theme/Doc Views, taken from (Chitchyan, 2005)
At the design level, Theme/UML allows a developer to model features and aspects of a system, and
specifies how they should be combined (Clarke, 2005).
The Theme approach provides support to:
• Identify aspects by examining shared requirements at action view.
• Verify design decisions with requirements at augmented view.
• Traceability from requirements to design since requirements map directly to Theme/Doc
views, which map directly to Theme/UML models.
A tool is provided to create graphs of the relationships between concerns and the requirements that
mentioned those concerns.
Theme/Doc is useful to aspect-oriented analysis at requirements engineering, but does not propose any
technique to aspectual specification and composition in a systematic fashion. Also, Theme/Doc does
49

not provide enough support for requirements of large scale systems. Nevertheless, in Baniassad et al.
initial research is discussed about using several latent clues in requirements documentation to help
scale document concern-views (Baniassad, 2004a). In Theme/Doc, composition is delayed until design
with Theme/UML.
3.5.8 Requirements description language
Requirements Description Language (RDL) modularises the requirements in terms of concerns and
describes the relationships and constraints upon these concerns in terms of their requirements
semantics (Chitchyan, 2006; 2007a). RDL is a symmetric AORE approach, i.e., all concerns (whether
functional or non-functional, crosscutting or non-crosscutting) are represented using the same
abstraction. The requirements specified using RDL are annotated natural language sentences. Each
sentence may contain one or several clauses that contain sub-elements for subject, relationship and
optionally for object(s). A subject is the entity that undertakes actions described within the
requirement clause; same as the grammatical subject in the clause. An object is the entity which is
affected by the actions of the subject of that clause, or in respect with which the actions are
undertaken. Object in RDL also corresponds to the grammatical object of the clause. Relationship
depicts the action performed by the subject on or with regards to its object(s). Thus, the RDL, in
essence, is a language designed to capture the meaning of natural language requirements via the
elements that realize certain grammatical functions (i.e., subject, verb phrase, and object) and relate to
certain semantic categories (e.g., verb classes). This language allows description of requirements
interrelationships (via compositions) based on their semantics.
RDL provides mechanisms for composition specification based on natural language grammar and
semantics (using mainly Natural Language Processing techniques) as well as some notions of AOSD,
such as joinpoints and pointcuts. RDL joinpoint is any point/element of the annotated text where
interaction may occur, and pointcuts are query expressions that select sets of joinpoints.
RDL composition is a process of requirements analysis and aggregation into a coherent set of
elements. Through composition we are able to expose the influences of concerns, detect conflicts and
inconsistencies between them, and solve these conflicts and inconsistencies. The composition in RDL
contains three elements: Constraint, Base and Outcome. Each of these elements has an operator
attribute (defines the way in which the pointcut integrates with the other composition elements) and a
semantic query expression, i.e., a pointcut expression.
50

RDL is based on XML constructs to define all its elements. Since the RDL is XML-based, it makes
sense to use the XML-supporting technologies, such as XPath and XQuery for the pointcut definition.
Multi-Dimensional Requirements Analysis Tool (MRAT) can also be used by RDL to support analysis
of crosscutting requirements. MRAT is an ECLIPSE plug-in that supports composition specification
and conflict identification and resolution of some of the temporal conflicts by ordering the
compositions based on the composition operator semantics (Chitchyan, 2007a). To accomplish this, an
analysis algorithm was developed to compose concerns and finds temporal problems, revealing the
cause and resolution for temporal conflicts.
This approach claims that current Aspect-Oriented Requirements Engineering composition
mechanisms are still undeveloped because they do not handle efficiently the complexity of large
systems. So, using description of requirements compositions based on their semantics, RDL handles
efficiently this complexity. However, the approach requires a good and complete requirements
document, which we cannot expect to have unless some work on requirements elicitation and analysis
has already been done. Also, more work pertaining to requirement refinement as well as conflict and
trade-off resolution with this approach is required to make it more useful.
3.5.9 AOV-Graph
AOV-graph is an extension to V-graph models to avoid the tangling and scattering of crosscutting
concerns in requirements models (Fernandes, 2005). This approach uses goal models and the concepts
defined in aspect-oriented languages to provide separation, composition and visualization of
crosscutting concerns to facilitate their modelling. AOV-Graph goals are used to model sets of
requirements separately and to offer a way to model the relationships between them. According to this,
AOV-Graph is a symmetric approach since any concern, whether crosscutting or not, may be
encapsulated in a goal. Furthermore, AOV-Graph offers different views originating from the
composite model.
AOV-graph consists of:
• Goals, which represent concrete objectives to be achieved for the system.
• Softgoals, which represent abstract objectives, frequently associated to non-functional
requirements.
51

• Tasks, which represent actions (or functional requirements) to be performed to achieve
goals/softgoals.
The AOV-graph model also contains the following relationships:
• Correlations, which are used to make explicit the negative and positive influences between
goals and softgoals, or softgoals and softgoals.
• Contributions are used to show how goals/softgoals can be operationalized by tasks,
goals/softgoals.
• Crosscutting relationships are used to register how softgoals/goals are scattered and tangled
through their operationalizations.
This approach does not explicitly support the identification of crosscutting concerns. According to
Fernandes, identifying crosscutting concerns is not AOV-Graph focus because they naturally appear
during modelling (Fernandes, 2005). However, crosscutting relationships are identified, either because
a requirement impacts on many points, or because it is important to keep one requirement separate
from the others. Based on the crosscutting relationships, the compositions are specified using pointcuts
and operators, advices and intertype declarations. Using correlations relationships, conflicting
situations are identified. However, AOV-Graph does not support their resolution.
3.6 Conclusions
Crosscutting concerns are responsible for producing scattered and tangled representations (e.g.,
specifications and code) that are invasive to implement and difficult to understand and to evolve.
AOSD aims at providing means for their systematic identification, separation, representation and
composition, throughout the software lifecycle. AOSD emerges to address the crosscutting concerns,
or to properties of software that cannot be effectively modularized using traditional software
development techniques, such as object-oriented methods.
Similarly to what happened to previous software development approaches, AOSD was introduced first
at the programming level, with Aspect-Oriented Programming, where aspects are handled in code. The
AOSD concepts have been moving beyond programming and are now being applied at earlier
development stages, i.e., at the design, architectural and requirements level.
52

The AORE approaches fill the gap left by the traditional requirements engineering approaches, in
particular offering a uniform and integrated treatment of crosscutting concerns, as well as improved
composition techniques. As mentioned before, several methods have been proposed for AORE, each
one addressing specific issues of AORE (Rashid, 2003; Sutton Jr, 2004; Clarke, 2005; Moreira, 2005a;
Chitchyan, 2007a). In general AORE approaches propose techniques for elicitation, analysis and
specification, validation, conflict resolution and management of all types of requirements, including
crosscutting requirements. At the end of these activities, a complete and consistent set of requirements
specification, models and composition rules is obtained.
These approaches are too young and are still being validated to demonstrate that they can be
successfully applied to real case studies, when compared with more traditional Requirements
Engineering approaches. In particular, most AORE approaches still need to:
• Improve the ability to identify crosscutting functional concerns.
• Enhance the support for composition at a finer level of granularity.
• Improve the link between composed requirements and architectural units.
• Avoid the tyranny of dominant decomposition. Some of the AORE approaches are extensions
of existing Requirements Engineering approaches, consequently they “suffer” the symptoms
of this situation (scattering and tangling).
• Develop systematic techniques to identify and solve all kinds of conflicts that could emerge at
Requirements Engineering level.
• Propose facilities to trace aspectual requirements.
• Improve a tool to manage aspectual requirements.
53

55
Chapter 4
Aspect-Oriented Requirements
Analysis
This chapter describes the Aspect-Oriented Requirements Analysis (AORA) approach for analyzing
concerns, focusing specially on crosscutting concerns, or aspects, during requirements engineering.
Similarly to the approaches described in Chapter 3, AORA proposes techniques for elicitation,
analysis, specification and composition of all types of concerns, crosscutting and non-crosscutting
concerns. In particular, AORA focuses on:
• Support for identification of crosscutting concerns, functional or non-functional.
• Support for modularization and encapsulation of crosscutting concerns to avoid the tyranny of
the dominant decomposition symptoms. This is achieved by handling all concerns in the same
fashion.
• Support for composition of crosscutting and non-crosscutting concerns.
• Support for conflict identification and resolution that could emerge at Requirements
Engineering level.

The AORA concepts and relationships are defined more rigorously in a metamodel. So, this
metamodel, which is an extension of the UML metamodel (UML, 2004), defines concerns and their
elements, and composition rules and their operators.
This chapter consists of four sections. The first section presents the Aspect-Oriented Requirements
Analysis approach. It is composed of three main tasks: identify concerns, specify concerns, and
compose concerns. Identification of concerns is accomplished by undertaking a complete and
exhaustive analysis of the problem under study documentation, existing reusable catalogues and any
other information provided by the stakeholders. All the identified concerns are specified using an
unique template that describes all types of concerns, be crosscutting and non-crosscutting concerns.
For the composition of concerns, the match point and composition rule, including composition
operators, concepts are proposed. Apart from allowing the developers to picture a broader part of the
system, this activity allows them to identify conflicting situations whenever concerns contribute
negatively among them. The following section, Section 4.2, presents the AORA metamodel and an
AORA Profile. The AORA metamodel is organized in two parts: specification and composition.
Section 4.3 illustrates AORA by means of an example case study. The chapter finishes with some
conclusions.
4.1 The AORA approach
A general model for the AORA approach is shown in Figure 4.1. The figure uses the graphical
notation from Hierarchical Task Analysis (HTA) in which activities are represented in hierarchical
order (Annett, 2004). Each numbered box represents an activity that can be refined using a plan. Each
plan represents a flow diagram describing the activities’ sequence.
The AORA model is refined using Plan 0 that describes the three main tasks of the model: identify,
specify and compose concerns. Each of these tasks is refined using Plan 1, 2 and 3 to identify, specify
and compose concerns respectively. In Plan 1, Identify Concerns is refined into six subtasks (1.1)
Identify stakeholders, (1.2) Identify sources, (1.3) Elicit concerns, (1.4) Reuse of catalogues (1.5)
Decompose concerns and (1.6) Classify concerns. In Plan 2, Specify Concerns is refined into (2.1)
Identify responsibilities, (2.2) Identify contributions, (2.3) Identify required concerns and (2.4) Identify
stakeholders priorities. In Plan 3, Compose Concern is refined into (3.1) Identify match points, (3.2)
Identify crosscutting concerns, (3.3) Handle conflicts and (3.4) Define composition rules.
56

Plan 0:
Identify
Concerns
Plan 1:
Identify
stakeholders
(0.1) (0.2)
(0.3)
Plan 2:
AORA Model
Specify
Concerns
Identify
responsibilities
(1.1) Identify (1.2)
sources
Plan 3:
Compose
Concerns
Identify
match points
Identify
contributions
Elicit
concerns
(3.1) (3.2) (3.3) (3.4)
57
Identify
crosscutting
concerns
Reuse of
catalogues
Identify
required
concerns
Handle
conflicts
(2.1) (2.2) (2.3)
(2.4)
(1.4)
(1.5)
(1.3) Decompose
Figure 4.1 The AORA model
concerns
Identify
stakeholders
priorities
Define
composition
rules
(1.6)
Classify
concerns
The AORA process can be described in more detail using several techniques. Here, and for simplicity,
we decided to use UML activity diagrams. Figure 4.2 shows the activity diagram corresponding to the
tasks listed in Plan 0. Each task is modelled as an activity state and more important decision points are
marked using choices. Whenever a new concern is identified, the process restarts at the identify
concerns task. Plan 0 is finished when all the concerns have a template and the match points have a
composition rule as well as a list of their ranked concerns. The diagram also uses the note element to
make explicit the major deliverables between tasks: concern templates, match points, crosscutting
concerns, composition rules and ranked concerns.

Plan 0
Identify Concerns
Specify Concerns
other concerns?
Compose Concerns
other concerns?
End
[yes]
[yes]
58
Output :
Concern Templates
Output :
Concern Templates
Output :
Concern Templates
Composition rules
Ranked concerns
Crosscutting concerns
Match points
Figure 4.2 Plan 0: AORA main tasks described using an activity diagram
The following subsections present the remaining plans (1-3) with their respective subtasks.
4.1.1 Identify concerns
Intensive and deep concern identification is, per se, out of the scope of this work. It is not our aim to
propose new elicitation techniques and methods. Many techniques already exist in the literature and
we explored its use (Nuseibeh, 2000). Nonetheless, aspect-orientation brings an interesting new
dimension to the early requirements techniques and some authors are focusing on this. Currently, they
are exploring the use of Natural Language Processing techniques and tools to help mining aspects in
requirements documents (Sampaio, 2005).
For our work, and being one of the first in the field, we felt the need to divide our effort between the
three activities we still believe are fundamental in AOSD: identification, specification and
composition. In particular, specification and composition were the activities that, back to five years
ago, we believed were the fundamental tasks to help us understand the impact of aspects in the early
activities of the development lifecycle.
For the identification technique we have explored existing traditional elicitation techniques. Our main
contribution in this regard was to explore the relationships between work on non-functional
requirements, such as the NFR Framework described in (Chung, 2000).

This task consists of identifying all the concerns of a system. As described in Section 3.2 a concern
refers to a property which addresses a certain problem that is of interest to one or more stakeholders
and which can be defined as a set of coherent requirements. Each concern defines a property that the
future system must provide.
This task is divided into six subtasks: (i) identify stakeholders, (ii) identify sources, (iii) elicit
concerns, (iv) reuse the information available in existing catalogues, (v) decompose concerns and (vi)
classify the concerns. Figure 4.3 suggests a process that can be used to accomplish these subtasks.
Plan 1
Identify Stakeholders Identify Sources
Elicit Concerns
more concerns?
Reuse of
Catalogues
Classify Concerns
End
[no]
59
Decompose
concerns
Output :
Concern Templates
Figure 4.3 Plan 1: identify concerns process
As we can see in the Figure 4.3, the subtasks can be accomplished iteratively, incrementally and some
of them in parallel. At the end of this task we have concern templates partially filled for all the
identified concerns.
Identify Stakeholders. Because the requirements engineering process focuses on the stakeholders’
needs, our goal here is to identify all the persons, organizations and other systems that have a direct or
indirect interest on the system under study. Therefore, stakeholders are persons, including customers
or clients (that pay for the system), developers (those that design, construct and maintain the system),
and users (those that interact with the system to get their work done), other systems or organisations
(that need to collaborate with our system). To identify stakeholders, we should look for persons or
organizations who (Glinz, 2007):

• Must manage, introduce, operate, or maintain the system after its deployment.
• Are involved in developing the system as an architect, developer, tester, quality engineer, or
project manager.
• Are responsible for the business or process that the system supports.
• Have a financial interest, for example, they paid for it or are responsible for its sale.
• Constrain the system as regulators, for example, law.
• Can be affected by the system.
From the list of stakeholders identified, we must select representative individuals or groups with
whom we can elicit requirements, solve conflicts and validate concerns.
Identify Sources. The goal of this task is to collect all of existing documentation such as
organisational charts, process models or standards, catalogues and user or other manuals of existing
systems that helps the identification and maintenance of (raw) requirements and concerns.
Elicit Concerns. “The choice of elicitation technique depends on the time and resources available to
the requirements engineer, and of course, the kind of information that needs to be elicited” (Nuseibeh,
2000). Nuseibeh presents a number of classes of elicitation technique:
• Traditional techniques to data collect that include the use of questionnaires and surveys,
interviews, and analysis of existing documentation such as organisational charts, process
models or standards, and user or other manuals of existing systems.
• Group elicitation techniques to obtain stakeholder needs and include brainstorming as well as
workshops based on different techniques.
• Prototyping techniques to deal with uncertainty about the requirements, or where early
feedback from stakeholders is needed.
• Model driven techniques that provide a specific model of the type of information to be
gathered, and use this model to drive the elicitation process, for example, NFR framework or
Use Cases approaches.
• Cognitive techniques that include a series of techniques originally developed for knowledge
acquisition for knowledge-based systems.
60

• Ethnographic techniques aimed to ethnomethodogy.
In order to elicit concerns, we start by analysing the documents collected during the task Identify
Sources, including stakeholders’ interview transcripts, to understand the system domain. To
accomplish this, we look for verbs and nouns in the documents that express properties or tasks that the
system must provide. Further interviews with the stakeholders might be required (these general ideas
are common used by the object-oriented community, for example). Other techniques such as
ethnographic studies described in (Dusire, 2002), concern mining described in (Sampaio, 2005), model
oriented described in (Jacobson, 1992) may be required to obtain a more complete set of concerns.
Reuse of Catalogues. To lighten the concern identification task we propose to use existing catalogues,
such as those developed by Chung (Chung, 2000) and Wiegers (Wiegers, 2003). These catalogues are
a source of interesting information about concepts and terminology of non-functional requirements,
and at the same time promote reusability. For each entry in the catalogue, we must decide, taking also
into consideration the stakeholders’ opinion, whether each concept (from a non-functional requirement
to an operationalization of it) would be useful in our system, or not.
These “non-functional concerns” are described using Softgoal Interdependency Graphs (SIGs). A SIG
is a hierarchy graph that shows the interdependencies between softgoals (or concerns).
Decompose Concerns. Concern decomposition is not a mandatory task and is achieved based on the
interdependencies of SIG. Many different types of interdependencies have been introduced in the
literature to relate softgoals, for example, (a) where goals positively (+) or negatively (-) support other
goals and (b) AND/OR refinement links relate a goal to a set of subgoals.
AND-refinement links mean that satisfying all subgoals in the refinement is sufficient for satisfying
the parent goal. OR-refinement links mean that satisfying one of the refinements is sufficient for
satisfying the parent goal. On the basis of these links, we identify concerns that can be decomposed
into simpler ones. It should be noted that, besides the concern decomposition, SIGs illustrate a
possible design solution to satisfy the concern. This is known as operationalization and is to guarantee
attainment of the final goals in the decomposition process.
Here, as well as in the Reuse Catalogues task, for each concern identified, we must decide whether it
would be useful in our system, and therefore keep it, or discard it.
Classify Concerns. AORA proposes that all types of concerns are important and should be treated in
equal terms. Nonetheless, the concerns classification is important since it can provide some help in the
selection of the most appropriated approach to specify concerns.
61

Requirements classifications have been proposed in the software engineering literature, for example,
the one proposed by (Sommerville, 2004). Inspired on this classification, our approach defines two
types of concerns: functional and non-functional. Functional concerns underline services that the
system is expected to deliver and are, therefore, related to satisfying stakeholders’ requests, whereas
non-functional concerns refer to expected system qualities such as security, safety, performance,
usability, flexibility, customizability, interoperability, and in a general way identified using catalogues
(see reuse catalogues subtask).
We have developed a template, depicted in Table 4.1, where relevant information about each concern
should be registered.
Table 4.1 A template to specify concerns
Template Element Definition
Name Concern designation.
Sources Source of information, e.g. stakeholders, documents, system’s information, catalogues
and business process.
Stakeholders Entities (persons, other systems or organizations) that have an interest in a particular
decision. This includes people who influence a decision, or can influence it, as well as
those affected by it.
Description Short description of the intended behaviour of the concern.
Decomposition Concerns can be decomposed into simpler ones based on AND and OR relationships.
When all (sub) concerns are needed to achieve the concern, we have an AND
relationship. If not all the sub concerns are necessary to achieve the concern, we have
an OR relationship.
Classification For example: functional, non-functional. Helps the selection of the most appropriate
approach to specify the concern.
List of Responsibilities
Responsibility # List of what the concern must perform, or the knowledge that the concern must
maintain and offer.
List of Contributions
Contribution # List of concerns that contribute or affect this concern. This contribution can be positive
(+) or negative (-).
List of Priorities
Stakeholder
Priorities#
List of Required Concerns
Expresses the importance of the concern for a given stakeholder. It can take the values:
Very Important, Important, Medium, Low, Very Low and Don’t Care.
Required Concerns# List of concerns needed or requested by the concern being described.
One template for each concern will be filled iteratively, and incrementally, using the process proposed
in Figure 4.3. Based on the tasks described above, we fulfil the rows Name, Sources, Stakeholders,
Description, Decomposition and Classification of the template for each identified concern. The
remaining rows are filled during the task Specify Concerns.
62

4.1.2 Specify concerns
This task is divided into four subtasks: (i) identify responsibilities; (ii) identify contributions between
concerns; (iii) identify required concerns and (iv) identify stakeholders’ priorities. These subtasks can
be applied in parallel for each identified concern (see Figure 4.4). This task finishes when all the
concerns have a complete template.
Plan 2
Identify
Responsibilities
Identify Contributions
Identify Required
Concerns
Identify Stakeholders
Priorities
63
[no]
end?
Output :
Concern
Templates
Figure 4.4 Plan 2: specify concern process
Identify Responsibilities. This provides the list of the responsibilities that the concern must perform.
According to Wirfs-Brock, “a responsibility is an obligation to perform a task, or know certain
information” (Wirfs-Brock, 1999). Because a concern can be defined as a set of coherent
requirements, these requirements are considered as responsibilities. A concern without responsibilities
is an indication that something is missing or that the concern does not make sense, so we need to
restart the process at the Identification Concern task, precisely at Elicit Concern subtask. This
information is added to the Responsibility row in Table 4.1.
Identify Contributions. A contribution relationship between two concerns defines the way in which
one concern affects the other. This contribution can be collaborative (or positive, helping the affected
concern) and is represented by a “+” sign, or damage (or negative, obstructing the affected concern)
and is represented by a “-” sign. These relationships are unidirectional, meaning that if a concern A has
a positive contribution to concern B, the inverse is no mandatory, as we can observe in contribution
table presented in (Wiegers, 2003). For example, increasing testability has a positive effect on
usability because if we increase the number of tests, we can improve the usability of the system.
However, increasing usability has a negative effect on testability because if we want to guarantee more
usability we need more and complex tests.
End

While contribution relationships between some concerns can be found in catalogues such as those in
Chung et al. and Wiegers, others might be difficult to identify and require experts in several domains,
such as security and real time systems (Chung, 2000; Wiegers, 2003). The process of reusing domain
knowledge and catalogues in the production of new software is the key concept of domain
engineering. “Domain engineering addresses the systematic creation of domain models and
architectures for building reusable components. The emphasis is on reuse and product lines” (SEI,
2007).
These relationships are added to the Contribution row of the concern template in Table 4.1. If this
concern is not affected by other concerns, the keyword is used.
Identify Required Concerns. This gives the list of concerns that the concern under study needs to
accomplish its own responsibilities. This step identifies concern relations for all concerns, including
functional and non-functional, crosscutting and non-crosscutting. For example, the Update concern
needs the ValidateInformation concern to accomplish its responsibilities. If this concern does not
require any other concern, the keyword is used. This list is recorded in the row Required
Concerns in Table 4.1. Notice that the Required Concerns relation is different from the Decomposition
relation, where the concern is decomposed into simpler ones (see decomposition task).
Identify Stakeholders Priorities. Not all concerns are equally important, so we must prioritize them.
A priority gives the degree of importance of a concern for a given stakeholder. The priority of a
concern is context dependent, i.e., the same stakeholder can classify the same concern differently for
different business domains.
In requirements engineering, prioritization methods group requirements into different categories. For
example, Brackett proposes dividing the requirements into three groups: mandatory, desirable, and
inessential (Brackett, 1990). According to Karlsson’s method, participants assign each requirement a
number on a scale from 1 to 5 to indicate the importance of those requirements, where 1: does not
matter (the customer does not need it) , 2: not important (the customer would accept its absence) , 3:
rather important (the customer would appreciate it) , 4: very important (the customer does not want to
be without it) and 5: mandatory (the customer cannot do without it) (Karlsson, 1995).
Inspired on these approaches, we use a qualitative scale Very Important (the stakeholder cannot do
without it), Important (the stakeholder does not want to be without it), Medium (the stakeholder would
appreciate it), Low (the stakeholder would accept its absence), Very Low (the stakeholder accepts its
absence) and Don’t Care (the stakeholder does not need it). So, this information defines the priority of
64

the concern for a given stakeholder in the scope of the system. This information is added to the row
Stakeholder Priorities in Table 4.1, one for each stakeholder that revealed interest for the concern.
4.1.3 Compose concerns
The goal of this task is to compose the concerns to give the developer a view of the whole system and
to identify and manage conflicts between concerns that might result from the context-dependent
compositions. To guide the composition, we propose four subtasks: (i) identify match points; (ii)
identify crosscutting concerns; (iii) handle conflicts and (iv) define composition rules for each match
point. Similarly to what we have done in the previous tasks, Figure 4.5 illustrates a process to apply
these subtasks, which, once more, can be applied incrementally and iteratively. Moreover, we support
incremental composition, independently of the concern nature. This means that we can potentially
compose crosscutting with crosscutting concerns, in addition to crosscutting with non-crosscutting
concerns. This task finishes when all the match points have a composition rule. At the end of this task
we have a complete set of concern templates, match points, crosscutting concerns, ranked concerns
and composition rules.
Identify Crosscutting
Concerns
Output :
Concern Templates
Match points
Crosscutting concerns
Ranked concerns
Composition rules
Plan 3
Identify Match Points
Handle Conflicts Define Composition
Rules
end?
End
65
[no]
Figure 4.5 Plan 3: compose concerns process
Identify Match Points. Based on the Required Concerns row in Table 4.1, we identify the points
where compositions will take place. We call those special places match points. A match point is a
point in which one or more required concerns may need to be composed together. It is composed of a
set of concerns that need to be collected together. One of the concerns plays the role of the base

concern on which the behaviour of the remaining concerns needs to be weaved in. This can be better
demonstrated with a bi-dimensional table of “Concerns X Required Concerns” as illustrated in Table
4.2.
Table 4.2 Match point identification
Required Concerns (Ci , i=1,…,n)
Concerns (Ci,i=1,…,n) C1 C2 C3 … Cn
66
Match Points (MPi, i=1,…,n)
C1 √ √ MPC1
C2 √ MPC2
… … …
Cn √ MPCn
A cell is filled with a “√” if a given concern at the column “Required Concerns” is required by the
concern at the row “Concerns”. So, the match point for concern C1 (MPC1) lists the set of concerns
that must be composed with C1. For example, MPC1= {C1, C2, C3}.
Since composition rules are defined for each match point, identifying stakeholders with an interest on
the concerns that compose each match point is useful to help solving conflicts. Table 4.3 relates
stakeholders with match points, where each cell lists the concerns of interest for a given stakeholder
and match point.
Table 4.3 Relating stakeholders with match points
MatchPoints (MPCi,i=1,…,n)
Stakeholders (Si,i=1,…,m) MPC1 MPC2 … MPCm
S1 C2, C3 C2, C4
S2 C2
… … …
Sm C3, Ck C3, C4
Identify Crosscutting Concerns. A crosscutting concern is a concern, which cannot be modularly
represented within the selected decomposition.
In AORA, a concern is crosscutting if it is required by two or more other concerns. Note that a
concern that is required by one other concern can be a crosscutting concern at the responsibility level
if it is required by two or more concern’s responsibilities. This kind of crosscutting is not treated in
this activity. Identify crosscutting concerns task is accomplished by taking into account the
information in the column “Required Concerns” Table 4.2, i.e., if more than one cell is filled with a

“√” in a given concern at the column “Required Concerns”, it is a crosscutting concern. For example,
C2 is a crosscutting concern because it is required by C1 and Cn.
Handle Conflicts. This subtask supports the identification and resolution of conflicting situations
between concerns. Conflicting situations are identified by the developer and may emerge in a given
match point. A match point identifies specific locations in the concerns where other concerns’
behaviour (crosscutting or non-crosscutting) should be satisfied. In this context, a conflict occurs any
time two or more concerns that contribute negatively to each other (see Contribution row in Table
4.1.), and have the same priority, need to be composed in the same match point. For example, consider
the case where a given module, that was conceived to model or implement a given functionality of a
system, needs to be secure and to react in a very short period of time. It is well-known that security
and response time contribute negatively to each other, i.e. the more secure we want our module to be,
the less fast it will become, and vice-versa. This means that the system may not be able to satisfy both
with the same degree of importance. Therefore, we need to look to the Stakeholder Priorities row in
Table 4.1. If the priority allocated to each concern is different, the problem is not too difficult to solve.
However, if at least two concerns have the same priority, a trade-off must be negotiated with the
stakeholder. It is now when Table 4.3, where each cell lists the concerns of interest for a given
stakeholder and match point may be of help.
At the beginning of the AORA approach, we propose the identification of the concern with higher
priority between them all, i.e., the dominant concern. Next we need to identify the second concern
among the remaining concerns, and so forth until we have a dependency hierarchy between all the
concerns. Because this process has limitations, for example, a conflict handling is based on one
criterion, the priority, Chapter 6 proposes the use of multi-criteria decision methods to aid decision
makers to solve conflicting situations. This process finds, given a set of alternatives and a set of
decision criteria, the best alternative for a given problem, i.e., the ranking of the concerns in a given
match point.
Define Composition Rules. A composition rule defines the order and how in which concerns will be
applied in a particular match point. Composition rules need to be handled from two different
perspectives: the order in which required concerns will be composed with the (base) concern that
defines the match point and, for each particular required concern, how its behaviour will be integrated
into the base concern.
Composition rules can be built from simpler composition rules and brackets, “(” and “)”, are used to
allocate priorities to the operators (see Figure 4.6).
67

(1) Composition � Term Operator Term
| (Composition)
(2) Term � Composition
| Concern
(3) Operator � ’||’
|’>>’
|’[>’
|’[]’
Figure 4.6 Composition rules between concerns
Figure 4.6 illustrates that a Term can be a concern or a sub-composition (which is another composition
rule) and the Operator represents the order of composition between terms, which will be defined using
a simple set of operators.
The operators we have chosen (enable, disable, parallel and choice), were inspired in the LOTOS
operators, where (Brinksma, 1988) 4 :
• Enable (denoted by T1>>T2): refers to a sequential composition and means that the behaviour
of T2 begins if and only if T1 terminates successfully.
• Disable (denoted by T1[>T2): means that T2 interrupts the behaviour of T1 when it starts its
own behaviour. In this paper it will be used to mean that the behaviour of T1 is substituted by
the behaviour of T2.
• Parallel (denoted by T1||T2): refers to the parallel operator and means that the behaviour of T1
must be synchronized with the behaviour of T2. It represents concurrent composition of
concerns.
• Choice (denoted by T1[]T2): refers to the choice operator and means that only one of the
concerns will be satisfied (T1 or T2).
These rules allow compositions to be performed at a higher abstraction level, where each concern is
simply represented by its name and related with other concerns by using the above composition rules.
Moreover, we support incremental composition, independently of the concern nature. This means that
4 The interested reader can find in Brinksma, E. (1988). Information Processing Systems -- Open Systems Interconnection --
LOTOS: A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour. ISO 8807. the
formal semantics of each of these operators.
68

we can potentially compose one crosscutting with other crosscutting concerns, in addition to
crosscutting with non-crosscutting concerns.
4.2 The AORA metamodel
“A metamodel is a precise definition of the constructs and rules needed for creating semantic models”
(UML, 2004). Metamodels can serve several purposes:
• To define a schema for semantic data that needs to be stored.
• To define a language that supports a particular methodology or process (which was the
original purpose of the UML metamodel).
• To define a language to express additional semantics on existing information.
• To allow a language designer or methodologist to better capture, analyze and understand new
approaches.
• To serve as a basis to define an automatic supporting tool.
OMG has defined four architecture layers (M0 – M3) as described in Figure 4.7 (Bézivin, 2005). M0,
the user object layer, is where the actual runtime objects reside. This layer is composed of the
information that we wish to describe. M1, the user model layer, is the layer where the UML models
live. This is the level at which modelling of problems, solutions, or systems occur. M2, the metamodel
layer, is the level where the UML metamodel is defined. The concepts used by a UML modeller, such
as Class, Attribute, Message, etc., are defined at this level. M3, the meta-metamodel layer, is the top
level and is an instance of itself. It consists of the basic elements on which the UML is based. It also
defines the language for specifying metamodels. This layer is called Meta-Object Facility (MOF) in
the OMG terminology. A model element on every layer is strictly an instance of a model element of
the layer above.
69

ar
«metamodel»
MOF Meta-metamodel
«instanceOf»
«metamodel»
UML Metamodel
User Model
«instanceOf»
«instanceOf» «instanceOf»
foo
70
M3 Layer
M2 Layer
M1 Layer
M0 Layer
Figure 4.7 A four-layered architecture, taken from (Bézivin, 2005)
The AORA metamodel is defined at the M2 layer and its package structure is shown in Figure 4.8. The
AORA metamodel is composed by the sub-packages ConcernSpecification and ConcernComposition.
The ConcernComposition package merges with the ConcernSpecification package to link the
composition rules elements to the specification elements.
ConcernSpecification
«merge»
ConcernComposition
Figure 4.8 AORA metamodel packages
The template concern elements described in Table 4.1 are defined in the ConcernSpecification
package of the AORA metamodel as illustrated in Figure 4.9.

Figure 4.9 ConcernSpecification of the AORA metamodel
The meta-class Concern is composed of: a Name, a Description, a Classification (of functional or non-
functional kind, defined by ClassificationKind enumeration), a Source list (with at least one Source)
and a Responsibility list (with at least one Responsibility).
A Concern can have a Contribution list (of “+” or “–“ kind, defined by ContributionKind
enumeration).
A Concern can have a Decomposition list (of “AND” or an “OR” operator, defined by
DecompositionKind enumeration). It can also have a Stakeholder list that gives one Priority (of kind
“veryImportant”, “important”, “medium”, “low”, “veryLow” or “dontCare”, defined by PriorityKind
enumeration) per Concern.
There is a special type of Concern designated by CrosscuttingConcern.
A Concern can have a RequiredBy list. A MatchPoint joins one or more required concerns. Based on
the MatchPoint and the required concern the CompositionRule is build. The AORA composition rule
elements are defined in the ConcernComposition package metamodel as illustrated in Figure 4.10.
71

Figure 4.10 Concern composition of the AORA metamodel
A MatchPoint is defined by a CompositionRule. The CompositionRule is composed into two
operands. A CompositionRule can be an Operand of other CompositionRule. An Operand also can be
an ElementarOperand, and a Concern can be an ElementarOperand. Finally, the composition rule has
an operator defined by CompositionOperator enumeration (disable, enable, choice and parallel
operators).
To provide all the AORA relevant characteristics, we propose the following well-formedness rules:
• A minimum of one Concern and one Stakeholder are needed to accomplish all the tasks of the
approach.
• A minimum of one Responsibility per Concern is needed to accomplish all the tasks of the
approach.
• A Decomposition has a non repeated subconcern (other than the decomposed concern).
• A Concern cannot be decomposed by itself.
• A Concern cannot be RequiredBy by itself.
• A RequiredBy has a non repeated required concern (other than the requester concern).
• A Concern cannot have a Contribution to itself.
• A Contribution has a non repeated contributed concern (other than the contributor concern).
72

• A CompositeRule can always be defined for a MatchPoint.
• A Composition Rule may be empty.
• Composition rules are acyclic, i.e. a composition resulting from a composition rule must not
trigger itself.
• A CrosscuttingConcern or a Concern cannot inherit from itself.
• A Concern might be prioritized more than one time but one per Stakeholder.
This metamodel helps the development of the tool. Based on Figure 4.7, we develop a model that is an
the metamodel and after that develop the objects that are the model. In our
case, the model elements are intuitively converted in Java objects (Java was the chosen programming
language). For example, and in a bottom-up perspective of Figure 4.7, the system has the objects that
are instances of Concern class in the model, and this class is an instance of Classifier element in the
UML metamodel.
As described before, UML is a standard modelling language with many tools available that facilitate
its use. Since the AORA instance models can be represented as class diagrams, the learning curve can
be decreased. Therefore, to represent the instance of the AORA metamodel in UML, a UML profile
needs to be defined (OMG, 2007). Figure 4.11 illustrates the UML profile of the AORA metamodel to
specify the AORA metamodel concepts (described by meta-classes and enumerations) in terms of
stereotype hierarchy extensions of UML meta-classes.
The AORA UML profile shows that the Classifier meta-class extensions are considered as first level
entities. The entities are defined by the following stereotypes: Concern and its derivate
CrosscuttingConcern, Stakeholder and CompositionRule (with an operator attribute of
CompositionOperator enumeration type).
The next entities of the AORA UML profile are the Association meta-class extensions defined by the
following stereotypes: Contribution (with the kind attribute of ContributionKind enumeration type),
Priority (with the kind attribute of PriorityKind enumeration type), Decompositon (with the kind
attribute of DecompositionOperator enumeration type), RequiredBy and finally the MatchPoint.
73

Figure 4.11 AORA UML profile
The other entities of the AORA UML profile are the StructuralFeatures metaclass extensions defined
by the following stereotypes: Classification (with the kind attribute of ClassificationKind enumeration
type), Description, Name, Responsibility and Source.
4.3 Illustrating AORA with an example
The example chosen to illustrate our approach is based on the Washington subway system. A briefly
description is as follows:
“To use the subway, a passenger has to own a card that must have been credited with some amount of
money. A card is bought and credited in special buying machines available in any subway station. Its
owner uses this card in an entering machine to initiate her/his trip. When s/he reaches the destination,
the card is inserted in an exit machine that debits it with an amount that depends on the distance
travelled. If the card has not enough credit the gates will not open. The passenger can ask for a refund
of the amount in the card by giving it back to a buying machine.”
74

4.3.1 Identify concerns
This task consists of identifying all the concerns of a system and is divided into six subtasks (please
see Plan 1 in Figure 4.1).
Identify stakeholders (Task 1.1). The idea is to identify stakeholders and select representative
individuals or groups with whom we can elicit requirements. For example, the passenger is the person
that can be affected by the system. The other stakeholders are the system owner and the developer.
Identify sources (Task 1.2). The identified sources are two catalogues proposed by Chung et al. and
Wiegers, requirements documents and knowledge of the system provided by the stakeholders (Chung,
2000; Wiegers, 2003).
Elicit requirements (Task 1.3). The idea is to collect the requirements we can find about the system,
adding to them those that the stakeholders may give. To accomplish this, we look for verbs and nouns
in the documents that express tasks/behaviour or properties that the system must provide. For example,
“A card is bought” the concern identified is BuyCard. Other concerns that we identified in the first
iteration from the description of the example were EnterSubway, ExitSubway, RefundCard and
CreditCard. Also, the text “special buying machines available in any subway station”, suggests that
Availability can be of interest.
In a second iteration, during a more refined analysis of the templates, we noticed that it would make
sense to factor out the common behaviour ValidateCard from EnterSubway, ExitSubway, CreditCard
and RefundCard.
Reuse of catalogues (Task 1.4). Other concerns can be identified based on the NFR catalogue, for
example (Chung, 2000). For each entry in the catalogue, we must decide whether it would be useful in
our system. For example, the system can be used by many passengers at the same time, then Multi-
access is an issue that the system needs to address. As a consequence, one can think that the system
needs to react in a short amount of time to avoid delaying passengers. This suggests the Response
Time concern. Other concerns identified based on this catalogue are: Accuracy; Security;
Compatibility and Fault Tolerance.
Decompose concerns (1.5). During the identification task, we felt that while some concerns described
very concrete issues, e.g. EnterSubway, others represent complex and coarse-grained issues, e.g.
security. Whenever possible, high-level concerns should be decomposed. Currently we adopt SIGs to
represent this decomposition. Some concern decompositions can be found in the literature and,
75

therefore, can be reused. For example, the NFR Framework offers a catalogue for security (see Figure
4.12).
Integrity
[Card Data]
Security
EnterSubway
Availability
[Entering Machine]
Figure 4.12 Security SIG applied to enter subway
The nodes of a SIG are non-functional concerns and are represented by clouds. The lines represent
decompositions (of a given concern into its sub-concerns). When all sub-concerns of a parent concern
are needed to achieve that concern, an AND relationship is defined with an arc connecting the lines. (If
not all the sub-concerns are necessary to achieve the parent concern an OR relationship is defined with
two arcs linking the decomposition lines.)
In this context, this means that Integrity and Availability are both needed to achieve Security, and
therefore an AND relationship is required. Each sub-element can be identified using the “.” notation,
for example Security.Integrity or Security.Availability 5 . Notice that a subject matter is added under the
concern name. A subject matter is the topic addressed by the non-functional concern. This means that
in Figure 4.12, Security is being handled for EnterSubway, Integrity must be guaranteed for card data
and Availability needs to be guaranteed for the entering machine.
Classify concerns (Task 1.6). Functional concerns underline services that the system is expected to
deliver and are, therefore, related to satisfying stakeholders’ requests, for example, EnterSubway,
ValidateCard, ExitSubway, CreditCard, BuyCard and RefundCard. Non-functional concerns refer to
expected system qualities such as Security, ResponseTime, Integrity, Availability, Accuracy,
Compatibility and Fault Tolerance.
The information identified is stored in the corresponding concern template.
5 For simplicity we will use Integrity and Availability instead of Security.Integrity and Security.Availability.
76

4.3.2 Specify concerns
To illustrate our approach we chose the concerns EnterSubway, ValidateCard and ResponseTime.
Note that the templates will only be completed at the end of this task.
Identify responsibilities (Task 2.1). List the services or knowledge of each concern (and fill in the
Responsibilities row). These are taken from the requirements collected in Task 1.1. For each identified
concern, at least one responsibility needs to be collected. For example, to achieve the EnterSubway
objective the system needs to, for example, check the card data and register an entrance.
Identify contributions (Task 2.2). A contribution relationship between two concerns defines the way
in which one concern affects the other. As described in Section 4.1.2 this contribution can be
collaborative or damage. For each concern we must identify its contribution to other concerns and fill
the Contribution row in the template. Identifying contributions may be a difficult task; it requires
expertise in specific domain areas that may not always exist in a project team. For certain cases,
existing catalogues are a good source of information, but there are still many situations where
catalogues are not available. Chung et al. and Wiegers propose catalogues for some non-functional
concerns (Chung, 2000; Wiegers, 2003).
Contributions among concerns should be studied at the sub-concern level, as it may happen that sub-
concerns of a given parent concern contribute differently to another concern. For example, while
Response Time contributes positively (+) to Availability, it contributes negatively (-) to Integrity. The
contribution table for our example is illustrated in Table 4.4, where empty cells represent don’t care
contributions.
NF Concerns
NF Concerns
Table 4.4 Contributions for non-functional concerns
Accuracy Compatibility
Response-
Time
77
Fault-
Tolerance
Availabi-
lity
Integrity
Accuracy + – – +
Compatibility + – +
ResponseTime – + – –
FaultTolerance – +
Availability +
Integrity
MultiAccess
Multi-
Access

Identify required concerns (Task 2.3). This expresses if one concern requires other(s) concern(s) to
accomplish its own behaviour, or if one concern is restricted by any other concern. This information is
added to the Required Concerns row in the template. For example, EnterSubway concern requires the
Response Time concern, because the system needs to react in-time when a passenger enters the
subway.
Identify stakeholders priorities (Task 2.4). In this task we identify the importance of each concern
in the system for each stakeholder and fill in the Stakeholder Priorities row. For example, the
EnterSubway concern is very important to the system owner stakeholder.
At the end of this task a template for each concern is complete. Table 4.5 shows the template for
EnterSubway concern.
Table 4.5 Template for Enter Subway concern
Name EnterSubway
Sources Stakeholders, set of initial requirements, knowledge of the system
Stakeholders Passenger, System owner, Developer
Description It is responsible for handling the beginning of a trip
Decomposition
Classification Functional
List of Responsibilities
1. Checks the card data
2. Registers an entrance
3. Returns the card to the passenger
List of Contributions
List of Priorities
1. Passenger: Very Important
2. System owner: Very Important
3. Developer: Important
List of Required Concerns
1. ResponseTime
2. Accuracy
3. Integrity
4. Availability
5. ValidateCard
6. Multi-access
7. Fault Tolerance
Table 4.6 shows the template for ResponseTime concern. Note that the contribution relationships
between ResponseTime concern and other concerns are found in catalogues (Chung, 2000; Wiegers,
78

2003). For example, the Accuracy concern affects negatively to ResponseTime concern. This
information is added to the List of Contributions row.
Name ResponseTime
Table 4.6 Template for Response Time concern
Sources Stakeholders, initial requirements, NFR catalogue, knowledge of the system
Stakeholders System Owner, Passenger, Developer
Description The machine has to react in time when passengers use the system with a
Decomposition
Classification Non-functional
List of Responsibilities
card in entering, exiting and buying machines
1. Reacts in-time (

Name ValidateCard
Table 4.7 Template for Validate Card concern
Source Stakeholders, set of initial requirements, knowledge of the system
Stakeholders System Owner, Developer
Description The card needs to be authenticating to allow the passenger to use the system
Decomposition
Classification Functional
List of Responsibilities
1. Reads the card data
2. Checks credits of the card
3. Checks card expiry date
List of Contributions
List of Priorities
1. System Owner: Very Important
2. Developer: Important
List of Required Concerns
1. Accuracy
4.3.3 Compose concerns
The goal of this task is twofold: to obtain a broader picture of the system and to handle possible
conflicting situations. The early identification of conflicts helps both stakeholder negotiations and the
establishment of trade-offs before the architecture design is derived.
Identify match points (Task 3.1). This is accomplished by building the match points table, as
explained earlier in Section 4.1.3. This table is automatically generated by our AORA tool (more
information on the tool can be found in Chapter 5). Table 4.8 illustrates the resulting table for our case
study.
80

Required Concerns
Concerns ValidateCard
Table 4.8 Match points identification
Integrity
Availability
BuyCard √ √ √ √ √ √ MPBC
EnterSubway √ √ √ √ √ √ √ MPES
ExitSubway √ √ √ √ √ √ √ MPExS
RefundCard √ √ √ √ √ √ MPRC
CreditCard √ √ √ √ √ √ √ MPCC
ValidateCard √ MPValC
Identify crosscutting concerns (Task 3.2). As described in Section 4.1.3, crosscutting concerns are
those that are required by two or more other concerns. According to Table 4.8 all the required
concerns with exception of Compatibility are crosscutting. Note that Validate Card is a functional
concern that is crosscutting since it is required by ExitSubway, EnterSubway, RefundCard and
CreditCard.
Handle conflicts (Task 3.3). For each row (match point) in Table 4.8 we must identify contributions
between the concerns that compose it. In our example, most match points have more than one concern.
The match point MPES, for example, needs to handle seven crosscutting concerns. A graph showing
the contribution on this match point is given in by the tool (see Chapter 5).
Let’s simplify this situation and consider that only Response Time and Integrity were applied in this
match point. These two crosscutting concerns contribute negatively to each other. Depending on the
priority, we may have identified a conflicting situation. To help on the identification of the match
points with conflicting concerns, we build Table 4.9. The stakeholders listed for each match point are
those that can help us resolving the conflict.
For our example, since Response Time and Integrity have the same priority to the passenger,
developer and system owner stakeholders, a negotiation is required so that the concerns can be ranked.
This negotiation is accomplished using Multi-Criteria Decision Making approaches to obtain match
point ranking. The use of these methods to solve conflicts is illustrated in Chapter 6.
81
ResponseTime
Accuracy
Compatibility
FaultTolerance
Multi-Access
Match Points

Table 4.9 Match points table in a stakeholder point of view (Acc: Accuracy; Comp: Compatibility; RT:
ResponseTime; FT: Fault Tolerance; Avail: Availability; Int: Integrity; MA: Multiaccess; VCard= ValidateCard)
MatchPoints
Stakeholder
Passenger
System Owner
Developer
MPBC MPES MPExS MPRC MPCC MPVal
Int, Avail,
RT, Acc,
Comp, FT
Int, Avail,
RT, Acc,
Comp, FT
Int, Avail,
RT, MA, FT
VCard, Int,
Avail, RT,
Acc, MA, FT
VCard, Int,
Avail, RT,
Acc, MA, FT
Int, Avail,
RT, MA, FT
VCard, Int,
Avail, RT,
Acc, MA, FT
VCard, Int,
Avail, RT,
Acc, MA, FT
82
VCard, Int,
Avail, RT,
Acc, FT
VCard, Int,
Avail, RT,
Acc, FT
Int, Avail,
RT, MA, FT
VCard, Int,
Avail, RT,
Acc, MA, FT
VCard, Int,
Avail, RT,
Acc, MA, FT
Supposing that all the stakeholders agree to decrease the priority of Response Time, Integrity becomes
the dominant concern in MPES and the conflict is potentially solved. This means that we can now
choose an architecture solution that primarily satisfies the dominant concern. Notice however, that this
does not mean to discard the less important concern.
Define composition rules (Task 3.4). Using the information obtained on the three previous steps, a
composition rule for each match point can be defined. For example, the composition rule for MPES,
which composes together Enter Subway with all its required concerns, is as follows:
( (Availability || Multi-access)
>> ( (ValidateCard >> EnterSubway)
||
||
ResponseTime
Accuracy
) >> Integrity
) [>Fault Tolerance
This composition rule expresses the order in which each concern must be satisfied. After the
successfully satisfaction of Availability and Multi-access, ResponseTime, EnterSubway and Accuracy
are satisfied in parallel, and only after their successful satisfaction will Integrity be satisfied. Notice
however, that EnterSubway can only be satisfied after the successful satisfaction of ValidateCard. If
something goes wrong with any of the above concerns, the Fault Tolerance concern takes care of the
situation by starting its own behaviour.
Acc
Acc

4.4 Conclusions
This chapter discusses the Aspect-Oriented Requirements Analysis (AORA) approach to handle
separation, modularization, representation and composition of concerns, specially crosscutting
concerns. To accomplish this, each plan of the AORA model has a set of tasks. Identify and specify
concerns plans support the identification and modularization of concerns. The identification of
concerns are supported by a set of activities that allows the identification of all concern and collect
information that is important to validate the concerns, for example, the identification of stakeholders
and the sources. All the identified concerns, crosscutting and non-crosscutting, are specified using a
unique template that describes concerns in a consistency and completeness way. Moreover, the
template has information about the concern that is very important to support the compose concern task
(required concerns), to handle conflicts (contributions and priorities) and to guarantee track changes
(source), which is explained in more detail at Chapter 5.
The compose concerns plan supports the identification of crosscutting concerns and then the
composition of crosscutting and non-crosscutting concerns. This plan also supports the identification
and resolution of conflicts, which is explained in more detail at Chapter 6.
The main concepts AORA were defined as an extension of the UML metamodel, allowing a language
designer or methodologist to better capture, analyze and understand our approach. To facilitate the use
of the AORA concepts, a UML profile for AORA was also defined.
The Subway system was used to illustrate the AORA approach.
83

85
Chapter 5
AORA Traceability and Tool
Support
This chapter describes the AORA traceability and tool support that are needed to track the changes of
concerns, concerns traceability between the artefacts of the software lifecycle and establish an
agreement with the stakeholders on the software’s concerns.
Traceability between the artefacts of the software lifecycle is an important quality required for
understandable and maintainable software. The complexity of a software system demands a
requirements traceability mechanism to guarantee the completeness and consistency of the software
artefacts throughout the development process. Moreover, existing research has been concerned with
the study and definition of different types of traceability relations and support for generating and
maintaining these relations in software and requirements engineering tools. So to guarantee
traceability, during the AORA process, three types of traceability relationships are defined:
• Between concerns and other elements of the approach and their source of origin.
• Between concerns and other concerns.
• Between concerns and other elements of the approach and their architectural/design artefacts.
The AORA approach facilitates communication among different stakeholders supporting the
sometimes difficult task of negotiation to obtain “agreement” in difficult and conflicting situations.

This agreement, in which requirements are documented, plays an important role in ensuring that the
requirements can be read, analysed, (re-)written, and validated (Nuseibeh, 2000). To achieve these
goals, an AORA tool was developed to storage and maintains large amounts of information. Three
undergraduate students, Marcos Brasil, Marcus Larsen and Nelson Ferreira, were supervised under
this PhD work and they refined the implementation of some AORA functionalities.
This chapter is organized in three sections. Section one presents the AORA traceability support to
facilitate a smooth transition between aspect-oriented requirement engineering and design and to help
stakeholders understand where a concern, including its suffered changes, comes from. Section two
describes the AORA tool, its features and architecture. Finally, a conclusion of the chapter is shown in
Section three.
5.1 Traceability support
According to the definitions of traceability at requirements engineering level described in Chapter 2,
we propose an AORA traceability schema as depicted Figure 5.1.
Figure 5.1 The traceability schema
86

This schema illustrates two dimensions: horizontal traceability and vertical traceability. The horizontal
traceability is also defined in backward and forward: (i) backward describes the relationship between
the concerns and their origin or source, e.g. stakeholder, business rule, or documentation; (ii) forward
which relates the concern to the design artefacts, e.g., sequence diagrams.
The following sections illustrate how AORA supports these two types of dimensions.
5.1.1 Horizontal traceability
As described before (see Chapter 2), horizontal traceability can be defined as backward and forward
traceability. Horizontal backward traceability is achieved by keeping track of concern specification
and composition from its origins by recording:
• The information in Source and Stakeholder Priorities rows of the concern template (as
decribed in Chapter 4). These rows are an explicit record of where the information associated
to the concern comes from.
• All the actions performed by the stakeholders that provide information changes is registered,
as well as their rationale. This is accomplished through the History functionality supported by
the tool (see Section 5.2.3). With this functionality, we follow the lifecycle of a concern
specification from the date that it was first created, throughout all its changes, including
rationale and decision information on its changes. This is accomplished by recording: (i) the
action (update, delete or insertion) that affects the concern specification, (ii) the information
that is affected by the action, (iii) the date when the action occurs and (iv) the stakeholders
who perform the action as well as the reason they do it.
Through the tool and the rows of the template (Source and Stakeholders Priorities), our approach
promotes better understanding of the concerns manipulated by stakeholders, as well as supporting
validation of specifications and compositions of concerns given by the stakeholders. Furthermore, all
this information and the tool (together with the resulting completeness of concern specification and
composition) guarantee the consistency of the information handled by the approach.
Horizontal forward traceability is achieved by relating the concern specifications and the composition
rules to design artefacts. The design models are built using specific guidelines that map requirements-
level artefacts into design-level artefacts. This information is kept in traceability matrices. Each
element of concern template is mapped on one or more elements of UML diagrams. UML diagrams
are used due to five main reasons:
87

• It is a standard and a general-purpose language.
• It offers extension mechanisms that allow the representation of new concepts that are not part
of the core of UML, in this case to support all kinds of concerns and compositions.
• It supports sequence diagrams that help us in expressing concerns responsibilities and
composition rules in order to provide a more rigorous level of refinement.
• It offers a seamless transition of concerns to the next level of the development process.
• It promotes reuse of behaviour by offering interaction occurrences.
Therefore, the concerns and their relationships will be represented using UML models (such as use
cases, sequence diagrams). While these techniques emphasize the main functions that the future
system should implement, others emphasize constraints and certain properties that affect the whole
system. In order to specify these constraints and properties, we propose the use of Softgoal
Interdependency Graph (SIG) from NFR framework. The graph records the developer’s consideration
of softgoals, which are concerns as we said before in task Decompose concerns (see Chapter 4).
Based on the information of the templates, we can build an extended use case and sequence diagrams.
Based on sequence diagrams, class diagrams are then derived. To build each UML diagram, we can
offer a set of simple rules, which help the requirements engineer to derive the necessary models.
For example, a use case diagram can be derived from a set of templates by using the guidelines given
in Table 5.1. Before applying these rules, however, we need to refine the RequiredBy relationship (row
Required Concerns in the template) to make it reflect some kind of relationships between use cases.
Therefore, some of these relationships will be mapped into relationships while others
into relationships. The include relationship is inspired in use cases dependencies and
denotes the inclusion of the behaviour described by another concern. The best way to think of an
include relationship is that it is the invocation of a concern by another one. Also, the extend
relationship is inspired in use cases dependencies. An extending concern is an alternate course of the
extended use case. In fact, a good rule of thumb is to introduce an extending concern whenever the
logic for an alternate course of action is at a complexity level similar to that of your extended course of
action. The relationships reflecting an association between non-functional and functional concerns is
better represented through a new stereotype .
88

For each concern C
Table 5.1 A guideline to derive a use case model from a set of concern templates
AORA Templates Use Case Model
If C is functional, create a new use case corresponding to C.
If C is non-functional, create a new use case corresponding to C by prefixing its name by
If a Required Concern
relationship R exists
between C and C’,
If C is decomposed into
other concerns C1..Ci,
For each stakeholder S
that triggers the newly
created use case,
“Handle”.
create a relationship between the use cases corresponding to C and C’.
R is mapped into a , or
relationship.
create a relationship between the use case corresponding to C
and those corresponding to C1..Ci.
create an actor corresponding to S and an association between it and the
new use case.
The use case diagram that results from the application of these simple guidelines may be too large to
handle. Therefore we suggest that instead of creating a unique use case model illustrating the whole
system, we create different use case models views, where each use case model represents a “view” of
the system from the perspective of a given concern.
For example, using the example in Chapter 4 and the guidelines in Table 5.1, Figure 5.2 shows a use
case model view for EnterSubway concern with all the other concerns that are directly related to it (see
EnterSubway template in Section 4.3). The Passenger actor corresponds to Passenger stakeholder. The
EnterSubway functional concern corresponds to a use case. A non-functional concern corresponds to a
use case with a prefix, for example, the Security concern corresponds to the HandleSecurity use case.
The required concern relationship between EnterSubway and Security concerns corresponds to a
relationship between EnterSubway and HandleSecurity use cases. The required
concern relationship between EnterSubway and ValidateCard concerns corresponds to a
relationship between EnterSubway and ValidateCard use cases. The decomposition relationship
between Security and Integrity concerns corresponds to a relationship between
HandleSecurity and HandleIntegrity use cases.
89

Handle Accuracy
Handle Multiaccess
ValidateCard
Handle ResponseTime
EnterSubway
Handle Security
Passenger
90
Handle Integrity
Handle Availability
Handle FaultTolerance
Figure 5.2 Use case diagram for Enter Subway
Use cases can be described using several techniques, such as scenarios and activity diagrams. We use
scenarios, where each step corresponds to a responsibility or a set of responsibilities already identified
in the concern template. The complete set of use case scenarios can be easily put together in an activity
diagram. The advantage of the activity diagram is that a single description can illustrate the whole
behaviour of a use case. Table 5.2 gives a set of guidelines to derive such activity diagrams; there were
inspired in (Moreira, 2006).
Table 5.2 A guideline to derive an activity diagram from a use case
Use Case and its Scenarios Activity Diagram
For a use case U and its primary create a new activity diagram.
scenario S1,
For each step in the primary scenario create an activity in the activity diagram.
S1 corresponding to a responsibility
in C,
create appropriate transition to connect each activity in the activity
diagram.
For each secondary scenario create a new activity diagram.
S2 … Sn,
From either these scenarios or these activity diagrams, we can then build sequence diagrams, one per
use case, according to the guideline in Table 5.3. A sequence diagram expresses the responsibilities as
messages or message’s parameters exchanged between objects that compose the problem domain. The
message that is being sent to the receiving object represents an operation/method that the receiving
object's class implements.

Table 5.3 A guideline to derive a sequence diagram from a use case
Use Case and its Scenarios Sequence Diagram
For a use case U and its primary create a new sequence diagram.
scenario S1,
identify interface, control and entity objects for the life lines of the
sequence diagram.
For each step in the primary create a message or a message’s parameters in the sequence diagram.
scenario S1 corresponding to a
responsibility in C,
each message is originated by a sender object and is received by a receiver
object. These objects must be identified.
For each secondary scenario
S2 … Sn,
use alt, opt and loop frames if needed to add new messages to the existing
ones.
create an alt or opt frame in the sequence diagram.
identify the messages in the sequence diagram affected.
By using the example in Chapter 4, Figure 5.3 illustrates the sequence diagram for EnterSubway,
according to the guideline in Table 5.3. The responsibility register an entrance (see Section 4.3)
corresponds to addJourney(idCard,idEntrance) message. This message is originated by a sender
object (:CtrEnterSubway) and is received by a receiver object (:Journey)
sd EnterSubway
Passenger :EnterMachine :CtrEnterSubway :Card :Journey
ejectCard
openGate
91
addJourney(idCard, idEntrance)
Figure 5.3 Sequence diagram for EnterSubway
While some concerns are easily described as a sequence diagram, for example ValidateCard, others
may not be easy to describe, for example HandleAvailability. The Availability could map onto a
decision for an architectural choice, for example, backup servers or/and high stability network
connections. At the same time, it will also refine into concrete solution domain aspects realising
replication, session management, etc.
For the difficult cases, one could follow a decomposition approach similar to that of Chung et al. and
define sequence diagrams for the operationalizations (Chung, 2000). However, we prefer to leave the
sequence diagrams at a very high level of abstraction and leave operationalizations until the solution
domain is tackled.
The new elements introduced for the construction of sequence diagrams in UML 2.0 help constructing
behavioural models in a more systematic and incremental fashion (UML, 2004). In particular, the

interaction occurrences will be used for incremental development while notation elements will be of
major help during composition to help us mapping our composition operators into UML.
These composition operators can be mapped into UML 2.0 sequence diagrams fragments, as shown in
Table 5.4 (UML, 2004). So, the composition rule is mapped into UML 2.0 using the sequence diagram
of the base concern and the sequence diagrams fragments of the required concern with the notation
elements. Note that as described in Section 4.1.3 a Term is a concern.
Table 5.4 Possible mapping of composition operators to sequence diagram fragments
Operator Map Example Representation
||
>>
[ ]
[>
Par
Sequence
Alt
Break
Term1||Term2
Term1>>Term2
Term1[]Term2
Term1[>Term2
92
par
ref
ref
Term 1
Term 2
alt
Term 1
Term 2
Term 1
Term 2
ref Term 1
break Term2
This is achieved using the “frame”, “ref”, “alt” “break” and “par” notation elements of UML 2.0
sequence diagrams (Bell, 2004; UML, 2004). The “frame” element is used to identify the boundaries
for the diagram. The “ref” notation element is an “interaction occurrence” that allow us to compose
primitive sequence diagrams into complex interactions. This is very important since it allows the reuse
of existing sequence diagrams. The “alt” notation element allows the representation of alternative
interactions based on a choice. The “break” element can be used to represent situations where a
sequence of events needs to be interrupted. This element is used to represent the “disable” operator
and is commonly used to model exceptions. The “par” element is used to show parallelism in a
sequence diagram and is used here to represent the “full synchronization” operator.

By using the example in Chapter 4, Figure 5.4 shows the composed sequence diagram for match point
EnterSubway MPES. This figure illustrates, for example, that HandleAvailability and
HandleMultiAccess interactions occurrences are composed in parallel.
break
par
par
Passenger
[incorrectUse]
:EnterMachine
ref Handle Availability
ref Handle MultiAccess
ref
ref
ref
ref
ejectCard ()
openGate ()
:CtrlEnterSubway :Card :Journey
ValidateCard
Handle ResponseTime
Handle Accuracy
Handle Integrity
ref Handle FaultTolerance
93
addJourney(idCard, idEntrance)
Figure 5.4 Resulting composition of Enter Subway sequence diagram (Figure 5.3) with its required concerns on
MPES
During the application of the guidelines, the traceability links between AORA elements and the design
artefacts are recorded. To accomplish this, four traceability matrices are used:
• Traceability matrix between concerns and use cases and SIG.
• Traceability matrix between stakeholders and actors from use-cases diagrams.
• Traceability matrix between concerns and their responsibility and sequence diagrams and their
messages.
• Traceability matrix between composition rules and sequence diagrams.
Table 5.5 shows a traceability matrix between concerns and use-cases and SIG (softgoal) artefacts. A
cell is filled with a “√” if a given concern at the row “Concerns” is mapped into Use Case and/or SIG
at the column “Use Cases and SIG diagrams”. Notice that some concerns can be mapped into use case
and SIG. For example, C1 (concern) is mapped into UC1 (use case diagram) and SIG2 (Softgoal graph).

Table 5.5 Traceability matrix between concern and use cases and SIG
Concerns (Ck,
k=1,..,N)
Use Cases (UCi, i=1,..,M) and SIG diagrams
(SIGj, j=1,..,2)
UC1 UC2 … SIG1 SIG2
C1 √ √
C2 √
…
CN √
Table 5.6 shows traceability matrix between stakeholders and actors from use-cases diagrams. A cell
is filled with a “√” if a given stakeholder at the row “Stakeholders” is mapped into actor at the column
“Use Cases Actors”. For example, S1 (stakeholder) is mapped into A1 (actor).
Table 5.6 Traceability matrix between stakeholders and actors from use-cases diagrams
Stakeholders
(Sj, j=1,..,N)
S1 √
Use Cases Actors (Ai, i=1,..,M)
A1 A2 …. AM
S2 √
…
SN √
Table 5.7 shows a traceability matrix between concerns and their responsibility and sequence diagrams
and their messages or parameters. A cell is filled with a “√” if a given responsibility at the row
“Concern’s responsibilities” is mapped into a message or a parameter of a sequence diagram at the
column “Messages or message’s parameters of sequence diagrams”. Note that some responsibilities
could be mapped into more than one message of the sequence diagrams, because the responsibility
needs more than one message in order to achieve its goal. For example, C1.R1 (responsibility of
concern) is mapped into SD1.M1 and SD1.M2 (messages of the same sequence diagram) and SD1.M1.P1
(parameter of message of sequence diagram).
As we said before, some concerns and their responsibilities can’t be mapped onto a sequence diagram
because they influence architectural and detailed design of the system (Rashid, 2003). For this reason
a concern might map onto a design decision (e.g. an architectural choice) and this information needs to
be recorded for the designer.
94

Table 5.7 Traceability matrix between concerns and their responsibility and sequence diagrams and their
messages
Concerns’
responsibilities
(Ci.Rj, i=1,..,N;
j=1,…M)
Messages (SDi.Mj, i=1,..,P; j=1,…N) or message’s parameters
of sequence diagrams Messages (SDi.Mj.Pk, k=1,.., Z)
SD1.M1 SD1.M2 SD2.M1 … SD1.M1.P1 SD3.M1
C1.R1 √ √ √
C1.R2 √
…
CN.Rj √
Table 5.8 shows traceability matrix between composition rules and sequence diagrams. A cell is filled
with a “√” if given composition rule at the row “Composition Rules” is mapped into sequence
diagrams at the column “Sequence Diagrams”. For example, the composition rule CR1 is mapped into
the sequence diagram SD1.
Table 5.8 Traceability matrix between composition rules and sequence diagrams
Composition
Rules (CRj,
j=1,..N)
CR1 √
Sequence Diagrams (SDi, i=1,..,M)
SD1 SD2 …. SDM
CR2 √
…
CRN √
Recording mapping information between AORA elements and UML diagrams using these matrices
promotes the consistency and completeness of mapping information and has the following benefits:
• The relationship between specification and composition concern elements and UML elements
is described explicitly.
• The effect of concern specification and composition change on UML diagrams can be
identified by examining the recorded relationships.
• Because a concern might also be mapped into a design decision, the justification for choosing
alternatives can be reviewed to ensure they are the most appropriate in the context of the
change.
95

The artefacts produced by the application of the forward traceability guidelines can be created by any
tool that supports UML, such as MagicDraw 6 or RationalRose 7 .
5.1.2 Vertical traceability
Vertical traceability is supported by the tool (see Section 5.2.3). This is accomplished by the
identification of concern specification or composition that could be affected by a concern specification
or composition change. For example, if a composition rule is based on the Required Concern
associations (row of the template) and these associations were changed, the tool would send a message
with all the steps required to maintain the consistency of the composition rule and the associations.
Thanks to these guidelines and the traceability matrices, our approach promotes better understanding
of concerns, as well as supporting validation of specifications and compositions of concerns for the
stakeholders.
5.2 The AORA tool support
The AORA tool handles each concern as defined by the specification template, helps identifying
match points, generates the list of crosscutting concerns, locates possible conflicting situations and
supports the definition of composition rules.
The tool was developed in Java and the information is stored in eXist, an open source native XML
database featuring efficient, index-based XQuery processing, XUpdate support and tight integration
with existing XML development tools (eXist, 2005; Sun, 2005). Figure 5.5 illustrates how these
technologies interact with each other.
6 http://www.magicdraw.com/
7 http://www-306.ibm.com/software/awdtools/developer/rose/index.html
96

Database_Handler
XQuery
XUpdate
eXist_API JDOM_API
Database
Figure 5.5 Database_API architecture
The Database_Handler is the interface between all the features of the tool and the data. It is
responsible for managing eXist and dealing with the insert, remove, update and query operations.
XQuery provides the means to extract and manipulate data from XML documents and XUpdate is a
simple XML update language and can be used to modify XML content by simply declaring what
changes should be made in XML syntax. To accomplish their goals, XQuery and XUpdate access to
the data through eXist_API. For accessing, manipulating, and outputting XML data from Java code is
JDOM API is used (Hunter, 2005). All these functionalities are part of Database_API package of the
tool (see Section 5.2.1).
5.2.1 The tool architecture
The AORA tool architecture is mainly composed of ten packages, illustrated in Figure 5.6, which
support four views (see Section 5.2.2 for details). Concerns, History, Matchpoints, Projects,
Stakeholders, Visualizer, Composition Rule and Administrator packages depended on Core package.
The Core package depends on Database API package.
97

Concerns
+ CertifyConcern
+ GetRepositoryConcern
+ NewConcern
+ RemoveConcern
+ UpdateConcern
(from Packages)
Visualizer
+ CompositionRuleGraph
History
+ ConcernsContributionsGraph
+ form_view_history
(from Packages)
+ ConcernsDependenciesNDecompositionsGraph
+ EventHandler
+ form_change_port
+ Graph
+ Node
+ Port
+ ViewController
+ Visualize
+ VisualizeCompositionRule
+ VisualizeConcernsContributions
+ VisualizeConcernsDependenciesNDecompositions
(from Packages)
AORE
Matchpoints
+ form_concerns_matchpoints
+ MatchpointTable
Core
+ AORE
(from Packages)
(from Packages)
+ concern
+ history
+ matchpoint
+ operator
+ Project
+ stakeholder
(from Packages)
Database_API
+ APIs
+ Database_Handler
(from Packages)
98
Proj ects
+ CloseProject
+ ImportExportReportProject
+ NewProject
+ OpenProject
+ RemoveProject
(from Packages)
Figure 5.6 Packages of the tool architecture
Composition Rule
Stakeholders
+ NewStakeholder
+ RemoveStakeholder
+ UpdateStakeholder
(from Packages)
+ EditCompositionRuleFrame
+ Interpreter
+ Parser
Administration
(from Packages)
+ form_administration
+ form_login
(from Packages)
The Concerns package manages the concern specifications, being composed of the classes that
accomplish the Concern View features (see more about Views in Section 5.2.2) including Certify
Concern and GetRepository Concern from Repository. The History package supports the History
feature and offers its own interface. The MatchPoints package supports the MatchPoint View and has
two interface classes. The Projects package deals with the project elements as we described in Handle
Project, Import and Export Project features (see Section 5.2.3 for details). The Stakeholders package
supports the Stakeholder View features. The Composition Rule package supports the Composition
View including the Validation rule feature that is supported by the Interpreter, the Parser, the
EditCompositionRule interface, the Grammar and the information in the database. This is illustrated in
Figure 5.7.

Figure 5.7 Composition rule validation architecture
The composition rule is edited using EditCompositionRule interface. An Interpreter is developed to
“clean” the composition rule from non-useful characters, for example extra “/r”, “/n” “/t”. Then, a
Parser is used to receive and validate the composition rule according to the composition grammar
(GrammarAORE) described in Section 4.1.3. In summary, the Composition Rule package interacts
with the composition rule validation elements to authenticate the composition rule according to the
grammar.
The Administration package is responsible for maintaining the information in the database. For
example, it updates the composition rule operators. The Visualizer package supports the Visualize
graphics representation feature (see Section 5.2.3 for details).
The Database_API package interacts with database handler elements to access the data in the
database. The DataBase_API package has functionalities to handle the data to and from the database
and the APIs, as described in Section 5.2.
Figure 5.8 illustrates how AORA packages (Figure 5.6), composition validation (Figure 5.7) and
database handler (Figure 5.5) elements interact with each other.
99

AORA
Packages
Database
Handler
Concerns History
Matchpoints Projects
Stakeholders Visualizer
Administration
Core
Database_API
XQuery XUpdate
eXist_API JDOM_API
Database
Figure 5.8 Overall AORA architecture
100
CompositionRule
EditCompositionRule
Interpreter
Parser
Grammar
Composition
Validation
The AORA concepts are defined in XML and an open source, native XML database: eXist. According
to this the AORA template for concern representation will be mapped into a XML Schema, creating a
standard representation. The resulting XML Schema is compliant with the information present in the
AORA template. Other elements are defined to support all the features of the tool, for example, project
and history.
The construction of the XML Schema has been done in a modular way, factoring out common
definitions for better understanding. Figure 5.9 illustrates the XML schema of the tool. Project is the
core element of the database and is needed to relate all the elements to a particular system that are
developed. It is composed of: name, stakeholders, concerns, matchpoints, history and operators. An id
attribute identifies the project element.

Figure 5.9 Project XML tag
The stakeholders element defines all stakeholders that participated in the development process (see
Figure 5.10). This element is described by name, role, description and responsibilities elements and an
id attribute that identify the stakeholder element.
Figure 5.10 Stakeholders XML tag
101

The concern element defines all concerns identified (see Figure 5.11). This element is described by
name, description, classification, sources, responsibilities, stakeholders_priorities,
concerns_contribution, required_concerns and decomposition elements; and id attribute that
characterize the concern element according with the template. The concern has one description and
classification, and a list of (i) source, (ii) responsibility, (iii) stakeholder_priority, (iv)
concern_contribution, (v) required_concern and (vi) child. The stakeholder_priority element is also
composed into the stakeholder_id and the priority attributes to aggregate one stakeholder together
with his/her priority for the concern. The priority attribute can take the values “Very Important”,
“Important”, “Medium”, “Low” “Very Low” and “Don’t Care” (PriorityType). The
concern_contribution element is also composed into the concern_id and contribution to define the
contribution relationship between the concern under study and other concerns. The contribution
attribute can be positive (+) or negative (-) (ContributionType). The required_concern element has a
concern_id attribute to define the concerns from which the current concern depends upon, i.e. the
concerns required by the concern under study. The child element is composed into the concern_id and
type to define the decomposition relationship between the concern under study and its children. The
type attribute can be “And” or “Or” (DecompositionType).
102

Figure 5.11 Concern XML tag
The matchpoint element has the composition rules for a given match point (see Figure 5.12). This
element is composed into name, owner, rule, associated_concerns elements, and id attribute. The
owner element defines the base concern of the match point, the rule defines the composition rule of
103

the match point and the associated_concerns defines the list of concern, with at least one concern, and
their rank that are required in the match point.
Figure 5.12 Matchpoint XML tag
The history element is needed to manage the update information of a concern (see Figure 5.13). This
element is composed into date, concern_id, action, stakeholder_reasons and before. These elements
are required to save the information about an update or delete actions realized to the concern
information in a given date. The stakeholders’ reasons can be recorded. The before element has the
concern information before the action was performed.
Figure 5.13 History XML tag
104

The operators element describes the composition rule operators (see Figure 5.14). This element is
composed into a name, symbol and commutative attribute. The symbol attribute can be “||”, “>>”, “[>”
“[]”, as described in Chapter 4.
5.2.2 The tool specification features
Figure 5.14 Operators XML tag
The AORA tool is composed of four views: Concern View, Stakeholder View, MatchPoint View and
Composition View. A snapshot of these views is illustrated in Figure 5.15. (The examples used to
illustrate the tool are part of a case study in Chapter 4).
The Concern View manages the information of the concerns being specified, and offers information
regarding the crosscutting nature of the concerns. This view allows the user to:
• Specify Concern. This requires the users to complete a form, based on the template (see
Chapter 4). Figure 5.15 illustrates part of the views (left hand-side) supported by the tool,
together with the concern specification template (right hand-side). In particular, the concern
view shows the list of concerns of the subway system. The icon offers this functionality.
• Update Concern. This allows the user to change the fields of a concern specification. The icon
offers this functionality.
• Remove Concern. This allows the user to remove a concern. The icon offers this
functionality.
• Crosscutting concerns. This information is visualized in the concern specification windows
(button “Crosscutting” at the concern specification window in Figure 5.15) and gives the list
of concerns that the concern cuts across.
105

Figure 5.15 Tool three main views (left) and concern specification window (right)
The Stakeholder View allows the definition of responsibilities and roles for each concern. More
precisely, this view allows the user to specify, update and remove a stakeholder (icons similar to those
used for the concern view are also available).
The MatchPoint View supports the definition of composition rules for each match point, being able to
generate a list of both match points and crosscutting concerns. This list is generated by clicking on the
button (see Figure 5.15). This view allows the user to update the list of concerns with Required
Concern associations in a given match point. To accomplish this, the user can check or uncheck the
buttons that represents the associations. Moreover, a concern is crosscutting if more than one check
button appear in the concern’s column. For example, by using the example described in Chapter 4, in
Figure 5.16, Fault Tolerance, Response Time, Availability, Validate Card, Multi Access, Accuracy
and Integrity are crosscutting concerns.
106

Figure 5.16 MatchPoints window
Finally, Composition View allows the user to create and modify existing composition rules. A
composition rule is defined for a match point and specifies how the concerns in that match point
interact. The upper area of the window in Figure 5.17 shows the list of possible concerns and tokens
(i.e., composition operators). A rule is built by either editing directly on the Composing Rule edition
box or by double clicking on an element of the lists Concerns and Tokens. The Validate button
validates whether the composition rule is well-formed, i.e. it is conformant with the composition
grammar (see Chapter 4).
Figure 5.17 "Composition rule editor” window
107

If the composition rule is correctly built, a message appears at the bottom area of the window and the
Save button becomes active to allow the composition rule to be saved in the database. If the
composition rule is not correctly built, an error message appears, highlighting the cause of the error.
Figure 5.17 illustrates the error “concerns are duplicated”, as a concern can occur only once in a
composition. Other possible errors are: concern does not exist; missing bracket; missing operator;
operator does not exist.
5.2.3 The tool generic management features
Besides the features described above, the tool provides other features, such as:
• Handle Project: to create, open and close projects. A project is created to relate all the AORA
elements to particular software that is developed.
• Consistency and logical integrity checking: to validate consistency and logical integrity of the
information. For example, if you have a composition rule based on the Required Concern
associations and these associations were changed, the tool would raise an error and not allow
the action, to maintain the consistency of the Required Concern associations.
• Generate reports: to provide reports in HTML and PDF format.
• Certify Concern: to save the concern specification in a repository making it available for reuse
in other projects. This action is triggered when the user chooses a concern and clicks on (see
Figure 5.15).
• Import Concern from Repository: to reuse a concern description from the repository. This
action is triggered when the user chooses a certified concern and clicks on (see Figure
5.15).
• History Entry: to log all the important actions (and corresponding states) that the concern has
gone through during its life. To each log is associated the stakeholder name, reason for
change, and date and time (see Figure 5.18).
108

Figure 5.18 History window
• Visualize graphics representation: offers four graphical representations: a match point
composition rule, concerns Required concern relationships, concerns contribution
relationships and concerns decomposition relationships (see Figure 5.19). This feature has the
following functionalities: save visible area to a .png file, zoom in, zoom out, show selected
concern and snap to grid. Also, crosscutting concerns are represented by red circles (Figure
5.19). For example, Integrity and Availability are crosscutting concerns. Security is
decomposed into Integrity and Availability with an and operator.
Figure 5.19 Decomposition and Contribution graph
109

• Export Project to XML: to export the project data (Concerns, Matchpoints, Rules, etc.) into
XML format. This action creates an XML file with the concern specification (Export) and is
accomplished by clicking on the button in Figure 5.15.
• Import Project from XML: to import the project data (Concerns, Rules, etc.) that is in XML
format to the tool database. This is accomplished by clicking on (Figure 5.15).
• The import and export features play an important role, since they offer the possibility to
integrate the models and documentation produced by our tool with other tools.
5.2.4 Related work
A metadata driven approach for the creation of a repository for aspects is discussed in (Ferreira, 2005).
A XML schema is used to represent this structure in order to guarantee information independent from
representation, traceability of aspects through the development phases and versioning control. Our
goal is not the creation of a general repository for aspects. Our repository only offers minimal support
to store sets of concerns. The concerns in a given project and in the repository are stored in eXist, a
XML native database.
The approach in Moreira et al. and Rashid et al. is based on separating the specification of aspectual
requirements, non-aspectual requirements and composition rules in modules representing coherent
abstractions and following well-defined templates (Moreira, 2003; Rashid, 2003). The approach is
supported by a tool called ARCaDe. Our approach differs from the above by offering a set of operators
that are simpler than those in (Rashid, 2003). Also, our tool has a composition rule editor and a parser
to validate its grammar. Moreover, our concern template offers a complete set of information that is
not offered by other existing AORE methods.
The Theme approach provides support for aspect-oriented development at analysis and design levels
(Clarke, 2005). At the analysis level, Theme/Doc is carried out by first identifying a set of actions in
the requirements list which are, in turn, used to identify crosscutting behaviours. The approach is
supported by a tool that creates graph relationships between concerns and the requirements that
mentioned those concerns. Theme does not offer a well-defined concern specification language neither
does it offer the possibility of composing themes together. Moreover, our tool has import and export
interfaces to XML to easily exchange concerns’ information with other applications.
EA-Miner is a web-based tool that uses natural language processing techniques to identify base
concerns, early aspects and crosscutting relationships between them at the requirements level
110

(Sampaio, 2005). EA-Miner supports the identification activity by helping the requirements engineer
to focus on the input documents. Therefore, EA-Miner gets the input files provided by the engineer
and sends them to WMATRIX that is a natural language processing tool, developed at Lancaster
University. WMATRIX then generates an XML file that consists of the input file with part-of-speech
and semantic annotations. EA-Miner uses this file to produce an internal representation of the file as
Java objects, which is created for a specific requirements engineering approach (e.g., viewpoint,
scenario based, etc.) selected previously by the user. In summary, EA-Miner provides automated
support for the identification of early aspects from various requirements’ documents and also helps to
structure the identified early aspects and other concepts such as viewpoints into a specific AORE
technique. This tool can be integrated with other AORE tools, for example, Multi-Dimensional
Requirements Analysis Tool.
Multi-Dimensional Requirements Analysis Tool (MRAT) is an ECLIPSE plug-in that supports
composition specification and conflict identification and resolution of some of the temporal conflicts
by ordering the compositions based on the composition operator semantics (Chitchyan, 2007b). To
accomplish this, an analysis algorithm was developed to compose concerns and finds temporal
problems, revealing the cause and resolution for temporal conflicts. Moreover, MRAT can be used by
RDL approach to support analysis of crosscutting requirements.
In general, our tool differs from the tools described above since it offers features that help tracing the
concerns from requirements to the specification, composition of concerns, management of changes of
concern specifications and compositions, and a concern repository within a project.
5.3 Conclusions
This chapter described the AORA tool. This tool facilitates the specification of concerns, identification
of crosscutting concerns, generation of the match point table and definition of composition rules. The
tool guarantees consistency of the concerns specifications and the composition rules in order to
minimize error occurrence and omissions in the systems’ requirements. It also offers import and
export interfaces to XML to exchange concerns’ data with other applications. Furthermore, the
multiple views facilitate the navigation within the approach.
A set of guidelines are proposed to support concern forward horizontal traceability. Forward
traceability is supported through requirements specifications for software design models and
architectural decisions. Our purpose is to be able to perform an impact analysis before the
implementation of a requested change. This is possible because the requirements impacted by the
111

change can be detected since the links between these requirements and design’s artefacts can be traced
using traceability matrices. Hence, software quality can be improved since we can check if all
stakeholders’ requirements are addressed by the system using vertical and horizontal backward
traceability mechanisms supported by the tool. The tool helps tracing concerns from requirements to
the specification and composition of concerns, through the History feature and Source attribute.
Thanks to the guidelines and the tool, our approach promotes better understanding of concerns, as well
as supporting validation of specifications and compositions of concerns.
For future work, we plan an extension of the AORA tool to incorporate a parser to integrate a
reference model to support forward traceability with the method.
112

113
Chapter 6
Handling Conflicts in AORA
Managing conflicts among multiple viewpoints or stakeholders is another Requirement Engineering
objective because their identification during implementation may become more expensive, since it is
during the requirements phase that a more direct contact is maintained with the stakeholders
(Nuseibeh, 2000). In the context of Aspect-Oriented Requirements Engineering, it is also important to
identify conflicting situations as early as possible to facilitate negotiation and decision-making among
stakeholders, as these situations might lead to a revision of the aspectual and non-aspectual
specifications, as well as the compositions.
In the AORA approach, the conflict management problem is handled during the composition activity,
where conflicting situations may emerge in a given match point. A match point identifies specific
locations in the base concerns where other concerns’ behaviour (crosscutting or non-crosscutting)
should be composed, or satisfied (see Chapter 4). In this context, a conflict occurs any time two or
more concerns that contribute negatively to each other, and have the same priority, need to be
composed in the same match point. For example, consider the case where a given module, that was
conceived to model or implement a given functionality of a system, needs to be secure and to react in a
very short period of time. It is well-known that security and response time contribute negatively to
each other, i.e., the more secure we want our module to be, the less fast it will become, and vice-versa.
This means that the system may not be able to satisfy both with the same degree of importance.
Therefore, this also means that each of these concerns lead to a number of architecture choices that
would serve their needs with varying levels of stakeholder satisfaction. A discussion about the side

effects of this problem can be found in (Moreira, 2005a). For this reason, it is important to understand
well each concern, study the level of impact that each one may have on others and decide on their
relative importance before any solution decision is made.
Considering that Multi-Criteria Decision Making (MCDM) techniques offer the possibility to find,
given a set of alternatives and a set of decision criteria, the best alternative, the contribution of this
chapter is, therefore, to propose the use of a MCDM method to support conflict management
resolution. Weighted average and Analytical Hierarchical Process (AHP) are MCDM methods widely
used (Saaty, 1980; Dong, 1987). The selected method was the AHP with a simpler aggregation process
(Williams, 2000). The main reason why this simplified AHP method was selected is that it is well
suited to handle the kind of problems in hand and it helps guarantee the logical consistency of many
human-based judgments, as well as synthesizing a wide-range of data in a single solution. The end
result is a list of concerns ranked according to a set of criteria. This list of ranked concerns will lead
the choice of the system’s architecture design, as previously mentioned. Direct scoring techniques are
widely used, particularly the weighted scoring method described in Dong et al. (also called weighted
average method), and this is the reason why we compare it with the approach selected for our work,
the AHP (Dong, 1987). During the development of the work contained in this chapter, the student,
Filipe Vieira, developed his MSc dissertation, therefore helping to validate the results achieved
(Vieira, 2007).
This chapter gives an overview on MCDM, describes the AHP technique and applies AHP to handle
conflicts in AORA, illustrates the main ideas with an example, compares AHP with Weighted average
technique and discusses the obtained results. Finally, a related work and a summary are presented.
6.1 Multi-Criteria Decision Making: an overview
Multi-Criteria Decision Making (MCDM) techniques aim at supporting decision makers to solve
conflicting situations (Triantaphyllou, 2000). It is one of the most well know branches of decision
making. The MCDM field is usually divided into Multi-Objective Decision Making and Multi-
Attribute Decision Making (Zimmerman, 1991; Chen, 1992). Multi-Objective Decision Making
analyses a subset of a continuous vector space, usually restricted by constraints, by locating all
efficient solutions, before determining the optimum dependent on the user's preferences. Therefore,
Multi-Objective Decision Making offers feasible methods for operational planning, e.g. goal
programming. For the comparison of several particular alternatives or in strategic planning, when a
certain number of recycling techniques are to be pre-selected for further investigation, the approaches
114

of Multi-Attribute Decision Making should be used, because Multi-Attribute Decision Making
investigates a finite set of alternatives. Basically, Multi-Attribute Decision Making comprises two
steps: (i) the aggregation of the judgements with regard to each criterion and each alternative, and (ii)
the ranking of the alternatives according to the aggregation rules (Geldermann, 2000).
In our work we focus on Multi-Attribute Decision Making, and we will use the more general notation
of criteria instead of attribute, i.e., MCDM. MCDM methods use mathematical techniques to help
decision makers in choosing among a discrete set of alternative decisions. These methods do not try to
compute an optimal solution, but they try to determine, via various ranking procedures, either a
ranking of the relevant actions (decision alternatives) that is “optimal” with respect to several criteria,
or the “optimal” actions amongst the existing solutions (decisions alternatives) (Triantaphyllou, 2000).
Triantaphyllou warns that there may never be a single MCDM method that guaranties that a solution
(derived ranking of alternatives) is the correct one because of the subjective assignment of alternative
classifications and weights for criteria. The problem of determining the best alternative is an ill
defined one by its own nature. It is hard to know the best solution even under perfect knowledge of the
input data of a MCDM problem.
Although MCDM methods may be widely diverse, many of then have certain notions in common,
such as:
• Alternatives represent the different choices of action available to the decision maker. In the
context of this thesis the set of alternatives is assumed to be finite, and they are the elements to
be ranked or prioritized.
• Criteria are also referred to as goals and represent the different dimensions from which the
alternatives can be viewed. In cases in which the number of criteria is large, criteria may be
arranged hierarchically.
• Weights of importance are assigned to the criteria. Usually, these weights are normalized.
Based on the definitions above, there are three parameters in a MCDM problem:
• The set of alternatives to be ranked.
• The set of criteria that will be used for classifying (rating) each alternative.
• The weights (importance) attributed to each criterion.
115

The weights represent the relative importance of that criterion in relation to others in a decision
scenario. The higher the weight, the higher the importance of the criteria is for the decision maker.
Usually, decision problems are represented in a decision matrix, as depicted in Table 6.1.
Table 6.1 Decision matrix
Weight 1 Weight 2 … Weight j
Criteria1 Criteria 2 … Criteria j
Alternative 1 x11 x12 … x1j
… … … … …
Alternative i xi1 xi2 ... xij
The normalized mathematical formulation of a MCDM problem is:
⎡ ⎤
D ( Ai
) = ⎢⊕(
xij
⊗ w j ) ⎥ / ∑ w j
(1)
⎣ j ⎦ j
j where w ij
is the relative importance of criteria, x is the rating of the alternative for the respective
criteria and ⊕, ⊗ are appropriate (to be selected) aggregation operators. When we are dealing with a
simple weighted average aggregation, the ⊗ is the operator multiplication and ⊕ is the summation.
The best alternative Ai is the one with the highest priority in the ranking.
To solve MCDM problems many aggregation methods have been proposed in Chen et al. direct
scoring and outranking methods, trade-off schemes, distance based methods, value and utility
functions, interactive methods (Chen, 1992). Direct scoring techniques are widely used, particularly
the weighted scoring method as described in Dong et al. (also called weighted average method), and
this is the reason why we compare it with the approach selected for our work, the AHP (Dong, 1987).
The AHP method was selected because it uses pairwise comparisons for its weighting process, which
allows a direct match for solving our problem, i.e. our conflicts are between each pair of concerns
(Saaty, 1980; Triantaphyllou, 2000).
There are three steps in utilizing any decision making technique involving direct scoring:
• Determine the relevant criteria and alternatives.
• Attach numerical measures to the weights importance of the criteria and to the impacts of the
alternatives on these criteria.
• Process the numerical values to determine a ranking of each alternative.
116

6.2 An introduction to the AHP method
AHP is a decision analysis method that ranks alternatives based on a number of criteria (Saaty, 1980).
This method provides a mathematically rigorous process for prioritization and decision-making, by
reducing complex decisions to a series of pairwise comparisons and then synthesizing the results,
decision-makers arrive at the best decision based on a clear rationale. Based on specific conflict
handling characteristics, the AHP is a valid option because:
• It offers an interpretation/analysis of the problem with low complexity.
• It uses deductible and systematic procedures for reducing complexity.
• It permits tradeoffs in conflicting situations.
• It provides a way to express preferences (pairwise) between all criteria and between all
alternatives.
• It calculates the judgements logical consistency.
• Its final result is based in the synthesis of the different judgements.
The AHP method can be described in five steps, each one described below.
Step 1: Problem definition. In this step we define the problem goal.
Step 2: Graphical representation of the problem. This step is divided into three sub-steps: state the
objective (according to goal encountered in step 1), define the criteria and choose the alternatives.
Figure 6.1 illustrates an example of a hierarchical tree.
Alternative 1
Objective
Criteria1 Criteria2 Criteriai
...
...
Alternative j
Figure 6.1 AHP hierarchical tree
117
Level 1: Overall goal
Level 2: Criteria
Level 3: Decision Alternatives

Step 3: Establish priorities. Pairwise comparisons are used to define the preferences for alternatives
over each criterion, as well as the weights of each criterion. To accomplish this, Satty uses the scale
[1..9] to rate the relative importance/preference of one criterion over another, and constructs a matrix
of the pairwise comparison ratings. The same process applies to the definition of the importance of
criteria. If a criterion is less important that other, then the inverse preference is rated in the scale 1, 1/2,
1/3, …, 1/9.
The reason for Satty´s scale is based in psychological theories and experiments that points to the use
of 9 unit scales as a reasonable set that allows humans to perform discrimination between preferences
for two items. Each value of the scale can be given a different interpretation allowing a numerical,
verbal or graphical interpretation of the values (Saaty, 1980). An example of pairwise priorities
assignment for a problem with three alternatives is depicted in Table 6.2. An example of pairwise
comparison to express the relative importance (weights) between two criteria is depicted in Table 6.3.
Table 6.2 Example of AHP pairwise classification of alternatives for a criterion
Criterion Alternative 1 Alternative 2 Alternative 3
Alternative 1 1 3 9
Alternative 2 1/3 1 5
Alternative 3 1/9 1/5 1
The comparative matrices are reciprocal, hence they have to satisfy the property: aji=1/aij.
Table 6.3 Example of AHP pairwise assignment of weights (importance) between two criteria
Weights Criterion 1 Criterion 2
Criterion 1 1 5
Criterion 2 1/5 1
The interpretation of the matrix in Table 6.2 is: Alternative 1 is weakly more important than
Alternative 2 and absolutely more important than Alternative 3; Alternative 2 is moderately more
important than Alternative 3. The interpretation for Table 6.3 is: the weight (importance) of Criterion
1 is moderately more important than Criterion 2. Note that the ratios on both matrices (Table 6.2 and
Table 6.3) represent the inverse of the mentioned interpretations, the diagonal is always 1 to express
neutrality between the same alternative or criterion, and the complete matrices are denoted as
reciprocal matrices (Saaty, 1980).
Step 4. Synthesis. In this step we calculate the priority of each alternative solutions and criteria being
compared. Several mathematical procedures can be used for synthesization, for example eigenvalues
and eigenvectors (Saaty, 1980). However, here, as mentioned before, we use a simple averaging
118

solution, which provides similar results and is much simpler to apply (Williams, 2000). The synthesis
is determined in 2 phases:
1. The process for synthesis follows a bottom-up approach. Hence, starting from the bottom of the
hierarchical tree and using the reciprocal matrices as shown in Table 6.2 they are normalized per
column and then we calculate the average per line to obtain a priority vector for each matrix
corresponding to each criterion. The same process is done for the pairwise matrices corresponding
to the criteria relative importance (Table 6.3).
2. Next, the vectors per criterion are combined into a single matrix and this new matrix is multiplied
by the priority vector obtained from the criteria importance matrix to obtain the overall objective
(i.e., ranking of alternatives).
This process is repeated as many times as needed until the tree root is reached.
Step 5. Consistency. The logical quality of the decisions is guaranteed through a measure of
consistency of pairwise comparison judgments by computing a consistency ratio (CR):
CR =
CI
RCI
where CI represents the consistency index and RCI gives the random consistency index. RCI is a pre-
defined average random index derived from a sample of size 500 of randomly generated reciprocal
matrices, and depends on the number of elements being compared (Triantaphyllou, 2000). CI is
calculated using:
CI = λ − n)
/( n −1)
( max
where n is the number of items being compared and λmax is calculated using:
AW = A * W
λ
max
n
= ( ∑ AW / W ) / n
i
i
i
where A is the pairwise reciprocal matrix, W is the weights vector, index i corresponds to each value
in the AW vector and n is again the number of elements.
CR is designed in such a way that values of the ratio exceeding 10% are indicative of inconsistent
judgement; in such cases, the decision maker should revise the original values in the respective
pairwise comparison matrix (Williams, 2000). It should be noted that this consistency ratio ensures
119
(2)
(3)
(4)

that the transitive property (if a> b and b>c then a>c) is guaranteed, which means the user pairwise
judgements, are logical.
In summary, we have chosen the AHP proposed in Saaty with the simplified aggregation method
proposed in Williams et al. because: it is a well-known and accepted method; it is appropriate for
handling conflicting concerns problems; it has the ability to quantify subjective judgements; it is
capable of comparing alternatives in relation to established criteria; it provides the means to establish
preferences (pairwise) between all criteria and between alternatives in relation to each criterion; and it
provides means to guarantee the logical consistency of the judgements (Saaty, 1980; Williams, 2000).
As stated in Zimmerman, choosing a perfect method is an elusive goal and such selection can be based
on criteria such as consistency, empirical adequacy, adaptability, numerical efficiency, the range of
membership degrees of the results, the aggregation behaviour or the required scale for the membership
functions (Zimmerman, 1991).
6.3 Applying AHP to the AORA approach
This section starts with a brief background on our preliminary attempts to use the AHP for conflict
resolution and then introduces an example to illustrate the proposed application of the AHP method to
the selected AORA approach (Brito, 2003b; 2004).
6.3.1 Exploring the use of AHP
For small problems, a simple approach for conflict resolution may be reasonable. However, for large
and complex problems, where the number of comparisons and possible alternatives are very high, a
correct intuitive evaluation might be too difficult to achieve. As a system grows, it is common to find
many concerns with the same priority resulting in more conflicts, each one dealing with more complex
situations.
In our first attempt to handle conflicts in the AORA approach using the AHP method, we tried to
handle all the concerns in the whole system (Vieira, 2006). However, we soon realised that we needed
to first resolve conflicts with respect to particular match points. The very first problem we had to solve
was to identify the set of alternatives (based on the problem under study) as well as the list of criteria
(from the template in Chapter 4) that could bring useful information to the conflict resolution process.
120

While the alternatives are the required concerns in a given match point, the criteria are a subset of the
fields in the template.
Initially, the fields selected were source, classification and priority (at that time, priority was
stakeholder independent). The required concern field has also been used indirectly through the type
alternative. The type criterion basically holds the information about the crosscutting nature of a
concern. These experiments, led us to change priority to be stakeholder dependent, because we were
unable to differentiate stakeholders’ interest on each alternative. Another decision that is worth noting
is that source has been identified as having no effect in the solutions obtained, which, by its nature,
should have been a reasonable expectation. During the refinement of the process we detected that the
contribution field was included in the process in a fashion that quantifies the negative contributions.
The chosen criteria are then used by the AHP method to rank the list of concerns in a given match
point. This ranking is therefore used as a means for solving conflicts and can also be used as a guide to
define the composition rule.
6.3.2 Applying the AHP method
As described above, the AHP method is composed of five main steps. The result is a list of concerns,
ordered by degree of importance in a match point. It should be noted that we developed the whole
application in excel, which shows how easy it is to implement this approach.
Step 1: Problem definition
The goal is to rank the concerns required in a given match point. In our case, as mentioned before, the
match point selected is “Enter subway”. The alternatives are the different concerns identified in the
Enter Subway match point:
A = {Accuracy, Response time, Availability, Integrity, Multi-Access, Validate Card, Fault Tolerance}
The criteria, also referred to as decision criteria, represent the different dimensions from which the
alternatives can be analysed. For our problem, we have two major criteria:
C = {Contribution, Stakeholders_Importance}
By dividing the Stakeholders_Importance criterion into sub-criteria it is possible to use individual
stakeholder judgments as part of the decision problem. The main reason for the division is that the
relation between concerns and its importance is dependent of the judgement of each stakeholder
121

egarding the variables that are influent in her/his perspective of the system. Therefore, the identified
Stakeholders_Importance sub-criteria are:
Cstakeholder_importance= {Passenger, System owner, Developer}
Step 2: Graphical representation of the problem
With the identified objective, criteria and alternatives we can now build the hierarchical tree for our
match point, as depicted in Figure 6.2.
Validate
card
Contribution
Step 3: Establish priorities
Enter Subway MatchPoint
Concerns ranking
Importance
Dev eloper
Availability Response
...
time
Stakeholder
Importance
Importance
System Owner
122
Importance
Passenger
Figure 6.2 Graphical representation of the enter subway match point
Objective
Criteria
Alternatives
As mentioned, AHP uses a pairwise comparison matrix to determine the ratings of judgements and
comparisons are quantified by using the AHP [1..9] scale. In our example, the pairwise matrices are
shown in Table 6.4 to Table 6.9.
Table 6.4 Pairwise comparison matrix for criterion Contribution (4th level of tree)
Response
Multi- Validate Fault
Contribution Accuracy Time Availability Integrity Access Card Tolerance
Accuracy 1.000 1.000 0.500 1.000 0.333 0.250 0.333
Response Time 1.000 1.000 0.500 0.333 0.333 0.250 0.333
Availability 2.000 2.000 1.000 0.500 0.500 0.333 0.500
Integrity 1.000 3.000 2.000 1.000 1.000 0.500 1.000
Multi-Access 3.000 3.000 2.000 1.000 1.000 0.500 1.000
Validate Card 4.000 4.000 3.000 2.000 2.000 1.000 2.000
Fault Tolerance 3.000 3.000 2.000 1.000 1.000 0.500 1.000
Table 6.4 to Table 6.7 show pairwise priority assignments for the alternatives based on Contribution,
Passenger Importance, System Owner Importance, and Developer Importance criteria, respectively.
The assigned values are subjective and based on the authors’ experience.

Table 6.5 Pairwise comparison matrix for importance of stakeholder Passenger (4th level of tree)
Passenger
Response
Multi- Validate Fault
Importance Accuracy Time Availability Integrity Access Card Tolerance
Accuracy 1.000 0.143 1.000 1.000 0.500 1.000 5.000
Response Time 7.000 1.000 6.000 6.000 6.000 6.000 7.000
Availability 1.000 0.167 1.000 1.000 2.000 2.000 3.000
Integrity 1.000 0.167 1.000 1.000 0.333 0.333 2.000
Multi-Access 2.000 0.167 0.500 3.000 1.000 2.000 3.000
Validate Card 1.000 0.167 0.500 3.000 0.500 1.000 2.000
Fault Tolerance 0.200 0.143 0.333 0.500 0.333 0.500 1.000
Table 6.6 Pairwise comparison matrix for importance of stakeholder System Owner (4 th level)
System Owner
Response
Multi- Validate Fault
Importance Accuracy Time Availability Integrity Access Card Tolerance
Accuracy 1.000 1.000 2.000 2.000 1.000 1.000 2.000
Response Time 1.000 1.000 2.000 2.000 1.000 2.000 2.000
Availability 0.500 0.500 1.000 2.000 0.500 2.000 3.000
Integrity 0.500 0.500 0.500 1.000 0.500 0.500 2.000
Multi-Access 1.000 1.000 2.000 2.000 1.000 1.000 2.000
Validate Card 1.000 0.500 0.500 2.000 1.000 1.000 2.000
Fault Tolerance 0.500 0.500 0.333 0.500 0.500 0.500 1.000
Table 6.7 Pairwise comparison matrix for importance of stakeholder Developer (4th level)
Developer
Response
Multi- Validate Fault
Importance Accuracy Time Availability Integrity Access Card Tolerance
Accuracy 1.000 1.000 1.000 1.000 1.000 1.000 2.000
Response Time 1.000 1.000 0.500 3.000 0.500 0.500 3.000
Availability 1.000 2.000 1.000 2.000 1.000 1.000 3.000
Integrity 1.000 0.333 0.500 1.000 1.000 1.000 1.000
Multi-Access 1.000 2.000 1.000 1.000 1.000 1.000 3.000
Validate Card 1.000 2.000 1.000 1.000 1.000 1.000 3.000
Fault Tolerance 0.500 0.333 0.333 1.000 0.333 0.333 1.000
Now, we need to establish the relative importance of each stakeholder (level 3 of the tree) as well as
the relative importance between the two criteria (level 2 of the tree). Table 6.8 and Table 6.9 show the
relative importance (preferences) of each criterion for both levels of the tree, again attributed by
experience.
Table 6.8 Pairwise comparison matrix for Stakeholders Importance criterion (3rd level of tree) and respective
Priority Vector (calculated)
Passenger System Owner Developer
Stakeholders Importance Importance Importance Importance Priority Vector
Passenger 1.000 0.333 0.500 0.163
System Owner 3.000 1.000 2.000 0.538
Developer 2.000 0.500 1.000 0.297
123

Table 6.9 Paiwise comparison of criteria weights (2nd level of tree) and respective Priority Vector (calculated)
Criteria Weights Contribution
Stakeholders
Importance Priority Vector
Contribution 1.000 0.500 0.333
Stakeholder Importance 2.000 1.000 0.667
It should be noted that for large problems the total number of required comparisons is quite time
consuming. Nevertheless, there are ways to avoid deriving priorities for alternatives by means of
pairwise comparisons, for example by deriving relative weights from different comparisons. This
would reduce the number of comparisons to n-1; however, if an error is introduced in this process, a
strong negative impact can be felt in the final result (Triantaphyllou, 2000). Fortunately, there are
commercial tools, such as Expert Choice, Rank Master and Descriptor, to support the AHP process,
facilitating its use and speeding up the calculations.
Step 4: Synthesis
After creating all pairwise comparisons it is now possible to calculate the priority of each alternative in
terms of each criterion. First we calculate the normalized pairwise comparison matrix by dividing each
element of the comparison matrix by the sum of each column. Then we find the estimated relative
priorities by calculating the average of each row of the normalized matrix. At the end of this step we
have the priority vectors for each pairwise matrix. Second, we collect the priority vectors for the third
level of matrix in one matrix and using the importance priority vector (Table 6.8) we calculate the
synthesized value for level 3. Table 6.9 shows the intermediate collected vectors and the final priority
vector for level 2.
Now, to calculate the final ranking, we need to combine, into a single matrix, the final priority vector
determined in Table 6.10 with the final vector resulting from Table 6.4, and then multiply it by the
criteria weights priority vector of level 2 (Table 6.9). The results are shown in Table 6.11.
Observe that, in our example, we only have two major criteria at level 2 and three sub-criteria at level
3 (Figure 6.2); hence, the final ranking was obtained by first synthesizing level 3 (Table 6.10) and then
synthesizing level 2 (Table 6.11). As mentioned before, the AHP works with a bottom-up approach.
124

Table 6.10 Priority matrix for level 3 plus final Vector
Passenger
Importance
System Owner
Importance
125
Developer
Importance Priority Vector
Accuracy 0.093 0.178 0.146 0.155
Response Time 0.478 0.196 0.146 0.227
Availability 0.114 0.149 0.186 0.154
Integrity 0.067 0.091 0.113 0.093
Multi-Access 0.123 0.178 0.172 0.167
Validate Card 0.088 0.138 0.172 0.1408
Fault Tolerance 0.038 0.071 0.065 0.064
Table 6.11 Final Ranking (synthesis)
Contribution
Stakeholders
Importance
Final
Priorities Ranking
Accuracy 0.071 0.155 0.127 5 th
Response Time 0.058 0.227 0.171 2 nd
Availability 0.097 0.154 0.135 4 th
Integrity 0.149 0.093 0.112 6 th
Multi-Access 0.168 0.167 0.168 3 rd
Validate Card 0.288 0.140 0.189 1 st
Fault Tolerance 0.168 0.064 0.099 7 th
Let us now interpret the final ranking in Table 6.11 in the context of our Enter Subway match point,
where negative contributions were found between several concerns (see templates in Chapter 4). The
system can only be used with a valid card, therefore, it is not a surprise that the concern Validate Card
appears raked first. Response Time come next in the ranking because we need to do our best to avoid
long queues. Third ranking is Multi-Access because it is important to guarantee the use of the system
by thousands of passengers at the same moment. Furthermore, Availability needs to be accomplished
first than Accuracy and Integrity 8 in order to guarantee that the system is accessible for the passengers
and helps Multi-Access and Response Time (this is possible because Availability has positive
contribution to Response Time and Multi-Access). Accuracy appears in fifth place because this
concern contributes negatively to Response Time and Availability, which have higher preferences for
the stakeholders, so Accuracy priority needs to be lower in order to help guaranteeing the stakeholders
preferences. Integrity is ranked sixth and Fault Tolerance comes later, in the seventh position. Fault
Tolerance contributes positively to Accuracy and Availability so its composition helps the others.
Notice that the resulting raking can also be used to guide an incremental development and even to
define the composition rule, but this issue in not the focus of this section.
8 As we said before, Security has been decomposed into Integrity and Availability.

Step 5: Consistency
The AHP method provides means to evaluate the consistency of the judgements that the decision
maker demonstrated during the pairwise comparisons. This reduces any possible error that might have
been introduced during the judgement process. Since our example was small we decided to check the
consistency for all pairwise matrices instead of just obtaining a final consistency ratio. The results
using equations (2), (3) and (4) of Section 6.2 are shown in Table 6.12.
Table 6.12 Final consistency ratio for all pairwise matrices
Pairwise matrices Consistency
Index (CR)
Table 6.1 (Contribution) 0.02
Table 6.2 (Passenger) 0.07
Table 6.3 (System Owner) 0.04
Table 6.4 (Developer) 0.05
Table 6.5 (Stakeholders Importance) 0.01
Table 6.6 (Criteria Weights) 0.00
The consistency indexes obtained are a good indication that logical consistent judgments were made
on all pairwise comparisons, because they are well below the required 10% threshold, as explained in
Section 6.2.
6.3.3 Discussion of the results
Based on the results obtained by applying the AHP method, it is possible to use ranking methods to
help solving conflicting situations that might occur in a match point. Having the concerns ranked by
order of importance, permits one to select the architectural design that will optimise the attainment of
various objectives by their order of importance. Based on the obtained rankings, decisions can be
taken to handle unresolved conflicts (see discussion in Step 4).
To ensure that the method is applied correctly we must guarantee that the questions below are
answered during the initial activities of the AORA approach: Have all the concerns been identified?
Were all the stakeholders considered? How correct is the stakeholder knowledge about the problem?
At what level of decomposition should AHP be applied?
In what concerns the AHP method we should remember that human judgements are not error free,
even if the consistency level is below 10%, judgements are always subjective. Consistency only tells
that the judgements are valid in a logical perspective. However, the reasoning used to achieve those
values is subjective and may not reflect the best alternatives.
126

As the reader can appreciate, the application of the method can be time consuming and certainly error
prone, if all the calculations are done by hand. This technique has been proved useful in all the case
studies we have solved so far. However, automatic tools should be used to reduce the overhead
introduced in the AORA approach.
We use the Expert Choice tool as a means to validate our final concern ranking. The comparison has
not been done in detail, since Expert Choice uses a combination of techniques to obtain the final
raking. However, we could already confirm that the final rakings do not present a significant variation
from those obtained using AHP.
6.3.4 A summary of our initial experiments with AHP
In our first attempt to use the AHP method to manage conflicts within the AORA approach, we tried
to handle all the concerns in the whole system at once (Brito, 2004; Vieira, 2006). However, we soon
realised that we needed to first resolve conflicts with respect to particular match points. The very first
problem we had to solve was to identify the set of alternatives (based on the problem under study) as
well as the list of criteria (from the template in Chapter 4) that could bring useful information to the
conflict resolution process. While the alternatives are the required concerns in a given match point, the
criteria are a subset of the fields in the template.
Initially, the fields selected were Sources, Type, Contribution, Classification and Importance (at that
time, Importance was stakeholder independent). These experiments led us to change the “Importance”
element to be stakeholder dependent, since different stakeholders may have different interests on each
concern. This allowed us to be able to differentiate stakeholders’ interest on each alternative. Another
decision that is worth noting is that Sources, Type and Classification have been identified as having no
effect in the solutions obtained. While Sources is a string and it is virtually impossible to associate a
degree of trust to it, Type and Classification ranges are crisp binary values and therefore there is no
indecision associated with them.
During the process refinement, we realised that the Contribution field, which initially also looked like
a binary crisp type, could have an impact on the results obtained. The explanation is that we could
“quantify” the strength of the negative contributions. For example, considering two concerns A and B,
contributing negatively to each other, we can associate a degree of strength to this relationship of the
kind “highly negative”, “negative”, “not too negative”, for example.
After several experiments, the criteria chosen were Importance (one value for each stakeholder) and
Contribution.
127

6.4 AHP versus Weighted Average
The AHP method proved to produce useful information and since it ensures logical consistency,
contributes to the developers trust on the results. Moreover, the AHP pairwise structure provides the
means to express, easily, preferences between criteria (e.g. passenger is less important than system
owner) and as well as between alternatives for each criterion (e.g. response time is much more
important than accuracy for passenger). Nevertheless, it is rather cumbersome in terms of requiring
pairwise comparisons for all levels of the decision tree and, within each level, to obtain weights for
criteria. This makes its application time consuming. In addition, AHP does not deal with the problem
of dependencies between more than two concerns because of its pairwise structure.
Hence, we decided to compare the AHP method with a widely known direct scoring method such as
the classical weighted average, using the same illustrative example. Obviously, with this method we
lose the possibility of using pairwise judgment and checking the logical consistency of the judgements
made, but we gain in terms of time spent. In addition, with the simple weighted average we can neither
compare the intermediate values nor use direct pairwise judgements to express our preferences
between each pair of concerns, since in the classical weighted average method the assigned
importance are direct (it is a direct scoring method).
In spite of the drawbacks of using a simple weighted average method for our type of problem, it is a
widely used method and a good candidate for comparison purposes. Furthermore, we will use a
classification scale within the interval [0, 1] to enable a direct comparison with the final results of the
AHP method. To allow some interpretation of the classification of alternatives we will use a discrete
set of values from the interval scale, such as: {Very important: 0.9, Important: 0.75, Medium: 0.5,
Low: 0.3, Very low: 0.1}. This classification is based on discrete fuzzy sets, as described in (Chen,
1992). Table 6.13 shows the weights (i.e., the relative importance of criteria).
Table 6.13 Criteria weights
Criteria Criteria Weights
Contribution 0.33
Developer Importance 0.35
Passenger Importance 0.50
System Owner Importance 0.75
Table 6.14 shows the classifications for each alternative per criterion, the final priority obtained with
equation (1) in Section 6.1, and the respective final ranking.
128

Table 6.14 Alternatives classification, final priorities and ranking for Enter Subway match point
EnterSubway
Developer Passenger
System
Owner Final
Match Point Contribution Importance Importance Importance Priorities Ranking
Accuracy 0.1 0.50 0.50 0.75 0.529 6 th
Response Time 0.9 0.75 0.75 0.30 0.601 3 rd
Availability 0.9 0.30 0.75 0.50 0.597 4 th
Integrity 0.9 0.50 0.50 0.50 0.570 5 th
Multi-Access 0.1 0.30 0.75 0.90 0.623 2 nd
Validate Card 0.0 0.90 0.50 0.90 0.635 1 st
Fault Tolerance 0.1 0.50 0.50 0.30 0.350 7 th
Comparing the results just obtained (depicted in Table 6.14) with those obtained by applying the AHP
ranking (in Table 6.11) we can observe that both methods agree in the first concern ranking, Validate
Card. The 2nd ranking for AHP is given to Response Time and third to Multi-Access, while classical
WA considers Multi-access the 2nd and Response Time the 3rd priority. The two concerns have a high
ranking but Response time seems more essential in a system that deals with the public. The 4th place
is the same for both approaches. There is an inversion regarding Accuracy and Integrity, respectively
5th and 6th for AHP, versus 6th and 5th for classical weighted average. Again the results of the AHP
seem more appropriate because we need to ensure Accuracy before being worried with Integrity. Fault
Tolerance occupies the last position in both methods.
Obviously, the classical weighted average method is much simpler and provides good enough results;
however, it does not allow: using sound logical pairwise comparisons (expressing different actors’
preferences); consistency checks; and an easy interpretable hierarchical representation with various
levels (Figure 6.2). Hence, the choice between using this method or the AHP requires a decision
between using a faster and simpler method (although with direct classifications) versus using AHP,
which ensures pairwise psychological robustness, logical consistency and interpretability.
To conclude, we should remember that since all MCDM problems are always ill-defined as described
in Triantaphyllou one should ensure that the classifications and weights of criteria reflect, as much as
possible, the users and developers opinions (Triantaphyllou, 2000). Another problem, common to all
MCDM methods, is that big changes in the assigned classifications (both, pairwise or direct) may
result in different rankings. Hence, the selection of a “good” MCDM method should be done having in
mind: the type of problem; the subjective nature of classifications and their dependencies; the need to
express preferences between criteria and alternatives; check trade-offs between the
advantages/disadvantages of each method for the problem at hand. In this thesis we compared two
well-known methods and discussed their results and respective advantages and drawbacks.
129

In summary, we can say that within subjective contexts, as is the case of resolving conflicts in AORA
in general, MCDM methods, despite their limitations, are a suitable approach. Moreover, it seems that
for resolving conflicts between concerns the AHP method provides more robust and logical sound
results, but with an overhead of being a more time consuming method.
6.5 Related work
Handling conflicts at Requirements Engineering level depends of what is a “conflict” at this level.
Therefore, this section presents some definitions and solutions proposals used in requirements
engineering field.
Chung et al. propose a reasoning schema to detect and solve conflicting situations between non-
functional requirements (Chung, 2000). A contribution link between two goals is introduced when the
satisfaction of one of them may prevent the other from being satisfied (Chung, 2000). According to
this, the identification of conflicts is based on positive and negative contributions. Our conflict
analysis takes inspiration from these notions of positive and negative contributions. However, this
process does not support means for a rigorous consistency checking neither does it offer a systematic
trade-off analysis technique.
Yen et al. present a formal framework that facilitates the identification and the trade-off analysis of
conflicting requirements (Yen, 1997). This framework describes a systematic approach for analyzing
the tradeoffs between conflicting requirements using techniques based on fuzzy sets. However, again,
there is no check of consistency of priorities in order to minimize the errors during the decision
process.
Goal-oriented approaches detect priorities as the base attribute to handle conflicting goals. Formal
techniques and heuristics are proposed for detecting conflicts and divergences from specifications of
goals/requirements and of domain properties (VanLamsweerde, 1998). In VanLamsweerde a
divergence is a weak form of conflict that occurs frequently in practice (VanLamsweerde, 1998). A
conflict is a divergence between goals when there is a feasible boundary condition that makes the
goals inconsistent. The major difference with respect to the proposal presented in this chapter is that
consistency of judgements is not guaranteed. In VanLamsweerde et al. goals have been recognized to
provide the roots for detecting conflicts among requirements and for resolving them eventually
(VanLamsweerde, 2001). The authors first review the main types of inconsistency that can arise
during requirements specification, defining them in an integrated framework and exploring their
interrelationships. They then concentrate on the specific case of conflicting formulations of goals and
130

equirements among different stakeholder viewpoints or within a single viewpoint. Secondly, they
propose formal techniques and heuristics for identifying conflicts from specifications of
goals/requirements and from known properties about the domain. Thirdly, they present formal
techniques and heuristics for conflict resolution by specification transformation. Special emphasis is
put on a weak form of conflict that has received no attention so far in the literature although frequently
encountered in practice. In this case, a divergence between goals or requirements corresponds to
situations where some particular combination of circumstances can be found that makes the
goals/requirements conflicting. Such a particular combination of circumstances will be called a
boundary condition.
Robinson et al. propose two definitions to describe a “conflict” (Robinson, 1999). First, requirement
inconsistency often refers to the technical nature of constructing a requirements document—“any
situation in which two parts of a requirements specification do not obey some relationship that should
hold between them”. Second, requirement conflict often refers to the stakeholders of a requirements
document— “a conflict requirements held by two or more stakeholders that cause an inconsistency”.
Based on these definitions, Robinson et al. present a reasoning about potential inconsistencies that
requires techniques for representing overlapping descriptions and inconsistency relationships
(Robinson, 2003). To accomplish these Robinson proposes two structures: goals and viewpoints. Goal
refinement links and binary conflict links have both been introduced in goal structures to capture
situations where the satisfaction of one goal may influence the satisfaction of another. Mechanisms
have also been proposed to record independent descriptions into modular structures called viewpoints
(Finkelstein, 1996). These structures are linked by consistency rules and associated with specific
stakeholders involved in the elicitation process.
Alves et al. propose a goal-oriented approach to manage conflicts in Commercial Off-The-Shelf based
development (Alves, 2003). Here the authors define two kinds of conflict: intra and inter. Intra
conflicts are originated between goals when there is a negative interaction between them. In this case,
decision- makers have to solve intra conflicts through negotiation. Inter conflicts are those found
between goals and product features. This type of conflict occurs in cases of mismatch of goals and
product features. According to these definitions, this work aims at developing a selection process of
how to identify and manage conflicting interests between costumers and vendors to support
Commercial Off-The-Shelf decision-making. This process demonstrated that conflicts may arise when
there is a mismatch between requirements and features. So, they have proposed a set of matching
patterns to support the evaluation of how features match requirements. This works differs from ours
because it proposes a set of alternative solutions at design level and we propose a ranking of
alternatives (concerns) at requirements level.
131

Conflict-Oriented Requirements Analysis (CORA) incorporates requirement ontology and strategies
for restructuring requirements transformations as a mean to reduce or remove conflicts (Robinson,
1999). This work deals with technical inconsistency and stakeholders conflicts, and ours deals with
technical conflicts.
In Karlsson et al., AHP is used to compare requirements pairwise according to relative value and cost
where stakeholders are considered as having equal relevance (Karlsson, 1997). In our case a ranking
process is used to establish stakeholders’ degree of importance using the AHP and then we compare
this method with the classical weighted average method.
Win-Win Spiral Model proposes an iterative 3-step process model for goal-based negotiation of
requirements in order to conflict resolution (Boehm, 1994; 1998). At each iteration of a spiral model
for requirements elaboration, (i) all stakeholders involved are identified together with their wished
goals (called win conditions); (ii) conflicts between these goals are captured together with their
associated risks and uncertainties; (iii) goals are reconciled through negotiation to reach a mutually
agreed set of goals, constraints, and alternatives for the next iteration, and the software process is
managed and measured to ensure that all the win conditions are satisfied, through negotiation among
the stakeholders.
The Quality Attribute Risk and Conflict Consultant (QARCC) is an exploratory knowledge-based tool
that identifies and analyses the quality attributes’ tradeoffs involved in software architecture (Boehm,
1996). This tool identifies potential quality attribute conflicts, flagging them for affected stakeholders
and suggesting options to resolve the conflicts. The Win Win system is used to help on the
identification and negotiation of the quality attributes conflicts. The QARCC tool operates on the win
conditions to diagnose potential quality conflicts and tradeoffs. For each win condition that identifies a
quality attribute, the QARCC tool uses a knowledge-base to identify software architecture and
strategies for achieving the quality attribute. Based on the strategies and the knowledge-base, it
identifies potential conflicts. Then, QARCC tool provides suggestions for resolve these potential
conflicts. QARCC diverges from ours, e.g.: (i) instead of a knowledge-based tools, we present a
mathematical technique; (ii) QARCC fails to provide a method to evaluate quality of stakeholders’
judgements. In our case, a consistency index is used to identify inconsistent judgement thus suggesting
to the decision maker judgement revision; (iii) QARCC is based on key stakeholders identification; we
use stakeholder ranking, for priority criteria, to identify different degrees of importance among them.
Fewer stakeholders may result in less overhead and inconsistencies but erratic judgements may have
more impact in the system.
132

In “Early Aspects: The current landscape”, a conflict captures the situation of semantical interference:
one aspect that works correct in isolation does not work correctly anymore when it is composed with
other aspects. Hence, an aspect influences the correct working of another aspect negatively, often
because different (sub-)concerns will have conflicting requirements (Araújo, 2005).
Several AORE approaches handle conflicts mostly based on intuitive and very simple reasoning
methods that are error prone and do not allow a rigorous engineering approach to the problem (Rashid,
2003; Brito, 2003b; 2004; Moreira, 2005a).
In Brito et al. conflict solving is based on the principle of iteratively identifying the dominant
candidate aspect (i.e. a crosscutting concern) (Brito, 2004). This is achieved by priority comparison,
which may involve trade-off negotiations with stakeholders. For example, suppose we have four
concerns with priority “Very Important” to all stakeholders; a negotiation is required so that the
concerns can be ranked. The process starts by analysing two concerns to identify the dominant one,
then take this and analyse it with a third concern and so forth until we have taken into consideration all
the concerns. The result is the concern with higher priority between them all. Next the process is
repeated to identify the second dominant concern among the remaining concerns, and so forth until we
have a dependency hierarchy between all the concerns. The major difference with respect to the
proposal presented in this chapter is that conflict resolution is based on more than one criterion.
Moreira et al. and Rashid et al. use a similar idea, by assign weights to those aspects that contribute
negatively to each other in relation to a set of stakeholders’ requirements (Rashid, 2003; Moreira,
2005a). Weighting allows them to describe the extent to which an aspect may constrain a base module.
The scales used are based on ideas from fuzzy logic. Again, concerns contributing negatively to each
other and with the same weight with respect to a given base module require explicit, but informal,
negotiation among stakeholders. The main limitations of these approaches are:
• Each concern must be allocated one single different importance using intuition.
• Conflict handling is based on one criterion, the importance, not considering other parameters
that may have an impact on the decision.
• Different stakeholders may have different interests on the same concern, and the relative
importance/power of each one might be different (so their relative position might have to be
taken into account).
• Trade-offs must be negotiated informally with the stakeholders without any rigorous and
systematic analysis technique or tool.
133

It was with these limitations in mind that we started exploring rigorous alternatives that could be used
effectively without having to rely so strongly on a single criterion (importance), taking into
consideration other possible useful information collected during the application of the methods.
6.6 Summary
It is worth pointing out that conflict management is a real problem, regardless of whether or not one
uses AOSD to handle it. The difference is that in traditional software development methods, such as
object-oriented methods, the base module would need to include security and response time
behaviours, while in AOSD, both security and response time behaviours are modularized and each one
implemented as a separate aspect.
A rigorous technique to support conflict management at the aspect-oriented requirements engineering
level has been presented. The technique uses a particular multi-criteria analysis method, the AHP, to
find, given a set of alternatives and a set of decision criteria, the best alternative for a given problem.
Such a technique is not only useful in the context we have described here, but it looks very promising
as a tool to support architectural choices during the software architecture design.
We also compared the AHP with a classical weighted average method and the results proved that
selecting the appropriate MCDM is always a question of trade-offs between advantages of each
method. In this work we noticed that AHP ensures more psychological robustness in classifying the
concerns, logical consistency and better interpretability at the expense of longer time to formulate and
calculate the results.
We plan to explore the use of the AORA template responsibilities given that most of the existing
aspect-oriented requirements engineering approaches use a similar concept. Finally, we also need to
study how the level of granularity and dependency of/between concerns can influence the decision
process.
134

135
Chapter 7
Evaluation of the AORA
Approach
This chapter evaluates the AORA approach in two different dimensions: quantitative and qualitative.
The quantitative evaluation is performed by applying a set of metrics to several aspect-oriented
requirements specifications obtained from several different AORE approaches, including AORA. The
results obtained for the chosen approaches are then compared. The requirements specifications that
serve as input for this study were obtained in the context of the Testbed for Aspect-Oriented Software
Development project (TAO), whose main goal was to define an infrastructure to test aspect-oriented
development techniques, from requirements to implementation (TAO Project, 2007). As part of the
project, various AORE approaches were applied to the same case study.
The qualitative evaluation is achieved by selecting a set of criteria to compare the AORE approaches
used in the quantitative evaluation. Furthermore, the evaluation is also performed by applying the
AORA approach to two real case studies: the space domain ground segment software in the context of
the Aspect Specification for the Space Domain (ASSD) project funded by the European Space Agency
and the Flight Plan Tower Interface system in the context of the Software Development with Aspects
(SOFTAS) project funded by the Fundação da Ciência e Tecnologia (FCT) (Agostinho, 2006;
SOFTAS, 2007).
This chapter consists of five sections. The first section presents the TAO project. Section two presents
a quantitative evaluation of AORE approaches used in the TAO project. Section three presents a

qualitative analysis of the same AORE approaches, based on a set of specific criteria. The approach
with its process and concepts is assessed by several developers, and used to develop projects in a real
setting. This information is shown in Section four and presents the maturity level of the approach.
Finally, Section five concludes the chapter.
7.1 A Testbed for Aspect-Oriented Software Development Project
The TAO 9 project, a Testbed for Aspect-Oriented Software Development, is a collaborative research
project among several researchers around the world that was set up at Lancaster University for the
assessment of AOSD (TAO Project, 2007). The main goal of this project is to assess and compare
AOSD techniques in terms of modularity, maintainability and reusability. The specific aims are (TAO
Project, 2007):
• “To design the testbed to identify assessment issues to be explored in the software
development phases, such as requirements engineering, architecture design, implementation,
and quality assurance.
• To perform an end-to-end realisation of a major case study, to form part of the testbed suite of
studies.
• To exploit the case study to identify candidate points of integration between AOSD
techniques.
• To evaluate the testbed using AOSD techniques developed at Lancaster and gathering of
empirical data based on the end-to-end case study. “
This chapter uses the resulting artefacts provided by the application of aspect-oriented requirements
approaches in the TAO context, to the same case study, the Health Watcher system (Soares, 2006).
The Health Watcher is a real-life web based system aimed at improving the quality of health care
services that manages health-related complaints. The system allows members of the public to register
complaints against restaurants or pets. These complaints can then be investigated by health care
personnel and appropriate action taken. The complaints are registered via a web-based front-end and
Remote Method Invocation is then used to allow the web-server to interact with the application server.
9 http://www.comp.lancs.ac.uk/research/projects/project.php?pid=215
136

An initial use-case document was created and offered as part of the specification of the Health
Watcher system behaviour. This document also identified some useful non-functional requirements.
The AORE approaches that have been involved in the study, through their authors, were AOV-Graph
(Fernandes, 2005), MultiDimensional Separation of Concern 10 (Moreira, 2005a), Viewpoint-based
AORE with EA-Miner 11 (Rashid, 2003; Sampaio, 2005) and our own approach, AORA (Brito, 2006a;
2006b). The resulting artefacts provided by the application of these AORE approaches were shared
among all the authors. This is, therefore, the source that we used to compare AORA with other AORE
approaches and to quantitatively measure the quality of the artefacts obtained. Appendix B shows the
Health Watcher document specification produced by AORA tool.
7.2 A quantitative analysis of AORE
This section presents a quantitative evaluation of AORE approaches in the TAO project. The metrics
used were originally proposed to RE for Object-Oriented approaches and then were adapted to AOSD.
The results are analysed to verify if the following software quality attributes are achieved successfully:
separation of concerns, coupling, cohesion and size. These attributes are the base for the definition of
metrics.
Metrics are used in Software Engineering to quantify software artefacts (the product), characteristics
of the software development (the process) and characteristics of resource project (personal skills)
(Ebert, 2005). Traditional RE metrics are used to quantify the product, such as the size of
requirements, requirements completeness and requirements volatility (Costello, 1995). Since AORE
introduces new abstractions to the software development process, for example new composition
techniques and new concepts to the product, such as, crosscutting relationships, some of the existing
RE metrics cannot be applied directly. Therefore, these metrics had to be extended for AORE and new
ones had to be created (Mehner, 2006).
A few AOSD metrics have been proposed, such as (Sant’Anna, 2003; Garcia, 2005; Mussbacher,
2007). Table 7.1 presents a brief definition of AOSD metrics taken from Garcia et al., and associates
them with the software quality attributes (Garcia, 2005). Coupling Between Components (CBC) and
Depth Inheritance Tree (DIT) metrics for coupling, Lack of Cohesion in Operations (LCOO) for
cohesion and Lines of Code (LOC), Number of Attributes (NOA) and Weighted Operations per
10 From now on this approach is referred simply as “Multi-Dimensional CORE”
11 From now on this approach is referred simply as “EA-Miner” for simplification
137

Component (WOC) for size are extensions of Object-Oriented metrics to support aspects. Concern
Diffusion over Components (CDC), Concern Diffusion over Operations (CDO) and Concern
Diffusions over LOC (CDLOC) metrics are defined to allow assessment of separation of concerns that
is an objective of AOSD.
Table 7.1 A set of AOSD metrics, taken from (Garcia, 2005)
Attributes Metrics Definition
Separation
of
Concerns
(SoC)
Concern Diffusion over
Components (CDC)
Concern Diffusion over
Operations (CDO)
Concern Diffusions over
LOC (CDLOC)
Counts the number of classes and aspects whose main purpose is to
contribute to the implementation of a concern and the number of
other classes and aspects that access them.
Counts the number of methods and advices whose main purpose is
to contribute to the implementation of a concern and the number of
other methods and advices that access them.
Counts the number of transition points for each concern through the
lines of code. Transition points are points in the code where there is
a “concern switch”.
Counts the number of other classes and aspects to which a class or
an aspect is coupled.
Counts how far down in the inheritance hierarchy a class or aspect
Coupling Coupling Between
Components (CBC)
Depth Inheritance Tree
(DIT)
is declared.
Cohesion Lack of Cohesion in Measures the lack of cohesion of a class or an aspect in terms of the
Operations (LCOO) amount of method and advice pairs that do not access the same
instance variable.
Size Lines of Code (LOC) Counts the lines of code.
Number of Attributes
(NOA)
Counts the number of attributes of each class or aspect.
Weighted Operations per Counts the number of methods and advices of each class or aspect
Component (WOC) and the number of its parameters.
These AOSD metrics are used as a base for the AORE metrics definition. The AOSD metrics inspire
the new AORE metrics because:
• They have already been used in different studies, for example in (Garcia, 2004).
• They are refinements of classical and object-oriented metrics.
• They encompass new metrics for measuring separation of concerns to be applied to AO
paradigm.
However, these metrics are much related to specific artefacts, for example classes, which cannot assess
accurately the AORE artefacts of the different approaches. So, the evaluation of the AORE approaches
in TAO project is carried out based on the metrics described in Table 7.2 that are a generalization of
AOSD metrics described in (Garcia, 2005; Mussbacher, 2007).
138

Table 7.2 A set of AORE metrics
Attributes Metrics Definition
SoC Concern Diffusion over Counts the number of artefacts (main decomposition structures)
Artefacts (CDA) whose main purpose is to contribute to the specification of a
concern.
Concern Diffusion over Counts the number of methods and operations whose main purpose
Operations (CDO) is to contribute to the specification of a concern.
Concern Diffusions over Counts the number of transition points for concern through the
LOC (CDLOC)
specification. Transition points are points in the specification where
there is a “concern switch”, i.e., when a concern switches to any
other concern.
Coupling Coupling Between
Artefacts (CBA)
Counts the number of other artefacts to which a concern is coupled.
Cohesion Lack of Cohesion in Counts the number of methods and operations of an artefact that do
Operations (LCOO) not contribute to the concern.
Size Artefacts (Artefacts) Counts the number of artefacts.
Vocabulary Size (VS) Counts the number of elements used to specify primary artefacts.
Weighted Operations per Calculates the average number of methods and operations of each
Artefact (WOA) artefact.
These AORE metrics evaluate requirements artefacts instead of classes and aspects like in AOSD
metrics. Moreover, Number Of Attributes and Line Of Code AOSD metrics are replaced by
Vocabulary Size and Artefacts metrics because the first ones (Number Of Attributes and Line Of
Code) are related to design and implementation phase and it was necessary to transform these metrics
to be applied to the requirements phase. Depth Inheritance Tree metric is removed for the same reason.
7.2.1 Applying AORE metrics to the TAO requirements documents
As stated in Section 7.1, the EA-Miner, AORA, AOV-Graph and Multi-Dimensional CORE
approaches were applied to a requirements document that contains the information of functional and
non-functional requirements of the Health Watcher medium-sized software system. Considering each
functional and non-functional requirement of the Health Watcher requirements document as a concern,
the list of concerns are: “query information”, “complaint specification”, “login”, “register table”,
“update complaint”, “register new employee”, “update employee”, “update health unit”, “change
logged employee”, “usability”, “availability”, “performance”, “security”, “standards”, “hardware and
software”, “distribution”, “storage medium” and “user interface”.
Since the AORE approaches used in TAO deal with different kinds of elements and structures, the
metrics are adapted by mapping some of the metrics notions into the elements of each AORE approach
as described in Table 7.3.
139

Table 7.3 Mapping of AORE metrics notions into AORE approaches elements
Metrics notions
AORE approaches
EA-Miner
Multi-Dimensional CORE
Artefact Method and operation Transition points
Viewpoint and early Requirement Crosscutting
aspect
relationships
Concern Requirement Composition rules
AORA Concern Responsibility Match points
AOV-Graph Goal and softgoal Task Pointcuts in crosscutting
relationships
The notion of “artefact” is mapped into: “concern” in the context of Multi-Dimensional CORE and
AORA; “goal” and “softgoal” in the context of AOV-Graph; and “viewpoint” and “early aspect” in the
context of EA-Miner. These mappings are defined based on the identification of primary artefacts for
each approach.
The notions of “method” and “operation” are mapped into: “responsibility” in the context of AORA;
“task” in the context of AOV-Graph; and “requirement” in the context of Multi-Dimensional CORE
and EA-Miner. These mappings are defined based on the identification of elements that contribute to
the specification of the primary artefact for each approach.
The notion of “transition points” or points in the specification where there is a concern switch to any
other concern (concern switch) is mapped into: “match points” in the AORA context; “composition
rules” in the context of Multi-Dimensional CORE; pointcuts in crosscutting relationships for AOV-
Graph and “crosscutting relationships” in the context of EA-Miner. These mappings are defined based
on the identification of “places” where a “concern switch” occurs.
Table 7.4 shows the results of the application of the metrics (listed in Table 7.2), considering the
mappings shown in Table 7.3 and the TAO AORE approaches requirements documents.
Analysing the results in Table 7.4 and considering the artefacts mapping in Table 7.3, the Concern
Diffusion over Artefacts row shows the highest number of artefacts whose main purpose is to
contribute to the specification of a concern.
140

Table 7.4 The metrics results for AORE approaches
Attributes Metrics AORA EA-Miner Multi- AOV-
Dimensional
CORE
Graph
SoC Concern Diffusion over Artefacts
(CDA)
1 3 1 2
Concern Diffusion over Operations
(CDO)
7 23 11 12
Concern Diffusions over LOC
(CDLOC)
9 11 14 10
Coupling Coupling Between Artefacts (CBA) 6 3 10 3
Cohesion Lack of Cohesion in Operations
(LCOO)
0 23 0 24
Size Artefacts (Artefacts) 22 15 18 22
Vocabulary Size (VS)
Weighted Operations per Artefact
9 3 2 6
(WOA)
Average: 3 Average: 6 Average:4.4 Average:8.3
The value for AORA and Multi-Dimensional CORE is one and they have the lowest value of Concern
Diffusion over Artefacts when compared with the other two approaches, as their primary artefacts are
concerns (see Figure 7.1).
3
2,5
2
1,5
1
0,5
0
1
Concern Diffusion over Artefacts
3
AORA EA-Miner Multi-
Dimensional
CORE
AOV-Graph
Figure 7.1 Number of Concern Diffusion over Artefacts per approach
The value for AOV-Graph is two since “Make [information on health service] available” and
“Authentication” goals contribute to the specification of “login” concern. In the case of EA-Miner, the
Concern Diffusion over Artefacts value is three since “Complaint”, “SSVS” and “Citizen” viewpoints
contribute to the specification of “complaint specification” concern as is illustrated by the underlined
text extracted from EA-Miner requirements document:
141
1
2

Viewpoint: Citizen
Requirements:
..
2. A citizen can interact with the system to query information and to
specify
(register) a complaint.
…
Viewpoint: Sanitary Surveillance (SSVS) System
Requirements:
…
1.2. Subsequently, when the SSVS has the Complaint Control module deployed,
Sanitary Surveillance complaints will be exchanged between the two systems.
…
Viewpoint: Complaint
Requirements:
…
3. Citizens can register a complaint while employees can register and update
them.
…
The Concern Diffusion over Operations row in Table 7.4 presents the highest number of operations
and methods whose main purpose is to contribute to the specification of a concern. Figure 7.2 shows
that AORA has the lowest value of Concern Diffusion over Operations (seven) when compared with
the other three approaches.
25
20
15
10
5
0
7
Concern Diffusion over Operations
23
11
AORA EA-Miner Multi-
Dimensional
CORE
142
12
AOV-Graph
Figure 7.2 Number of Concern Diffusion over Operations per approach
This value is given by “query information” concern’s responsibilities, taken from AORA requirements
document:

1. The system receives the type of query
2.1 In the case of a query on specialties grouped by health units, the citizen
selects the unit to be queried.
2.2 In the case of a query on health units grouped by specialties, the citizen
selects the specialty to be queried.
2.3 In the case of a query on complaints, the citizen provides the complaint
code.
2.4 In the case of a query on diseases, the citizen selects the disease to be
queried.
2.5 The system receives the data for the query
3. The system shows the query result.
The value of Concern Diffusion over Operations for AOV-Graph is given by the number of tasks in
“Manage [complaints] and [notifications]” goal that contribute to the “complaint specification”
concern specification, i.e., twelve. The Multi-Dimensional CORE value of Concern Diffusion over
Operations is eleven since “RegisterComplaint” concern requirements have the highest number of
methods that contribute to the “complaint specification” concern. EA-Miner has the highest value of
Concern Diffusion over Operations (twenty three), given by “SSVS”, “Complaint”, “Persistence” and
“Citizen” viewpoints requirements that contribute to “complaint specification” concern. Notice that
this value is very high when compared with the AORA, AOV-graph and Multi-Dimensional CORE
Concern Diffusion over Operations values (seven, twelve and eleven respectively), because the
“complaint specification” concern is spread over the requirements of four viewpoints.
The Concern Diffusion over LOC row presents the number of transition points where there is a
“concern switch”. The Concern Diffusion over LOC value for EA-Miner is eleven since this is the
number of crosscutting relationships as illustrates in Table 2.1 of Section 2.3 of EA-Miner
requirements document. In the case of Multi-Dimensional CORE, the Concern Diffusion over LOC
value is fourteen and is the number of composition rules. In the case of AORA the Concern Diffusion
over LOC value is nine since this is the number of match points. The AOV-Graph Concern Diffusion
over LOC value is ten since crosscutting relationships have ten pointcuts where a concern switches. As
shown in Figure 7.3, AORA has the lowest value of Concern Diffusion over LOC (nine) when
compared with the other three approaches.
143

14
12
10
8
6
4
2
0
9
Concern Diffusion over LOC
11
14
AORA EA-Miner Multi-
Dimensional
CORE
144
10
AOV-Graph
Figure 7.3 Number of Concern Diffusion over LOC per approach
The Coupling Between Artefacts row presents the highest number of artefacts to which a concern is
coupled. The Coupling Between Artefacts value for EA-Miner is three since it is the number of
viewpoints (Employee, Citizen and SSVS) that are coupled to the “security” concern, as illustrates in
Table 2.1 of Section 2.3 of EA-Miner requirements document. In the case of AOV-Graph, the
Coupling Between Artefacts metric is three since it is the number of goals (Persistence, Availability
and Authentications) that “error handling” concern is coupled. The EA-Miner and AOV-Graph
approaches have the lowest Coupling Between Artefacts values when compared with the other two
approaches since they have a lowest number of artefacts to which a concern is coupled, i.e., four
viewpoints to EA-Miner and twelve goals to AOV-Graph, while AORA has 22 concerns and Multi-
Dimensional CORE has eighteen concerns. In the case of AORA, Coupling Between Artefacts value is
six since the “integrity” concern is coupled to six other concerns (RegisterTables, UpdateComplaint,
RegisternewEmployee, UpdateEmployee, UpdateHealthUnit and ChangeLogged). The Coupling
Between Artefacts value for Multi-Dimensional CORE is ten since “storage medium” concern is
coupled to ten other concerns (Availability, Performance, Security, QueryInformation, RegisterTables,
UpdateComplaint, RegisterNewEmployee, UpdateEmployee, UpdateHealthUnit, RegisterComplaint).
This value for Multi-Dimensional CORE approach has the highest number of coupled concerns for a
specific concern, when compared with the other three approaches (see Figure 7.4) due the
multidimensional characteristic of the approach, i.e., the number of other concerns to which a concern
is coupled could be all the concerns minus one (itself).

10
9
8
7
6
5
4
3
2
1
0
6
Coupling Between Artefacts
3
145
10
AORA EA-Miner Multi-
Dimensional
CORE
3
AOV-Graph
Figure 7.4 Number of Coupling Between Artefacts per approach
The Lack of Cohesion in Operations row shows the highest number of operations in an artefact that
does not contribute to the concern. According to the mappings notions, in the case of EA-Miner the
value is 23 since employee viewpoint’s requirements has 23 requirements that do not contribute to the
“login” concern. AOV-Graph Lack of Cohesion in Operations value is 24 since “Make [information
on health service] available” goal has 24 tasks that do not contribute to “storage medium” concern.
These two approaches lack cohesion because their primary artefact aggregated more than one concern,
so some of the operations in an artefact do not contribute to a concern specification. The other two
approaches, AORA and Multi-Dimensional CORE, have zero value for this metric (see Figure 7.5).
This situation occurs because the primary artefact of these two approaches is a concern.

25
20
15
10
5
0
0
Lack of Cohesion in Operations
23
AORA EA-Miner Multi-
Dimensional
CORE
0
146
24
AOV-Graph
Figure 7.5 Number of Lack of Cohesion in Operations per approach
Artefacts row shows the number of artefacts. The value of this metric for EA-Miner is fifteen. This is
the lowest number of artefacts, as shown in Figure 7.6, because some concerns are encapsulated in a
viewpoint.
25
20
15
10
5
0
22
15
Artefacts
18
AORA EA-Miner Multi-
Dimensional
CORE
22
AOV-Graph
Figure 7.6 Number of Artefacts per approach
The value of Artefacts metric for AORA is 22 since it is the number of concerns, as shown in Figure
7.6. This value is highest when compared with the values of Multi-Dimensional CORE (eighteen) and
EA-Miner (fifteen) because AORA approach uses the NFR Framework to decompose concerns. For

example, Performance is decomposed of Throughput and Response Time concerns. In the case of
AOV-Graph, the Artefacts value is 22.
Vocabulary Size row value is nine for AORA and these elements are: name, description, concerns
contributions, required by and decompositions relationships, classification, sources, responsibilities,
stakeholders’ priorities. As shown in Figure 7.7, AORA has the highest value of Vocabulary Size
(nine) when compared with the other three approaches.
9
8
7
6
5
4
3
2
1
0
9
Vocabulary Size
AORA EA-Miner Multi-
Dimensional
CORE
3
147
2
6
AOV-Graph
Figure 7.7 Number of Vocabulary Size per approach
The value for Multi-Dimensional CORE is two and these elements are the concerns’ name and
requirements. The value for EA-Miner is three and these elements are the viewpoints’ name,
viewpoint’s requirements and early aspects elements. The Vocabulary Size value for AOV-Graph is
six and these elements are: softgoal, goal, task, contribution links, correlations links and crosscutting
relationships.
The Weighted Operations per Artefact row shows the highest number of the average of operations of
each artefact. The Weighted Operations per Artefact average value for AORA is three; this is the
lowest average (see Figure 7.8) when compared with the other three approaches because the operations
are placed based on artefacts that are concerns.

9
8
7
6
5
4
3
2
1
0
3
Weighted Operations per Artefact
6
4,4
AORA EA-Miner Multi-
Dimensional
CORE
148
8,3
AOV-Graph
Figure 7.8 Number of Weighted Operations per Artefact per approach
In the case of Multi-Dimensional CORE, the Weighted Operations per Artefact average value is 4,4
and for EA-Miner is six. AOV-Graph has the highest average 8,3 when compared with the other three
approaches. This situation occurs since the primary artefact, for example goals, aggregate a high
number of tasks.
7.2.2 Conclusions
EA-Miner, Multi-Dimensional CORE, AOV-Graph and AORA were applied to the Health Watcher
medium-sized requirements system specification document in the context of TAO project to produce
an AORE document specification for each approach. These documents were used to apply the AORE
metrics to evaluate if they are reusable, complete, traceable and maintainable AORE solutions.
Since AORE introduces new abstractions to the software development process, some of the existing
RE metrics had to be extended for AORE and new ones had to be created. Based on the metrics
results, AORA achieves separation of concerns better than the other three AORE approaches since it
has the lowest values for Concern Diffusion over Artefacts, Concern Diffusion over Operations and
Concern Diffusion over LOC metrics. Therefore, these results suggest that AORA decreases the
scattering problem and improves modularization.

Coupling Between Artefacts shows a slight advantage for AOV-Graph and EA-Miner approaches
since they have the lowest value. These values mean that the resulting document specification of these
approaches is easier to maintain and reuse than the other two (Multi-Dimensional CORE and AORA).
The Lack of Cohesion in Operations metric row presents better values for AORA and Multi-
Dimensional CORE than EA-Miner and AOV-Graph. So, AORA and Multi-Dimensional CORE may
be simpler to maintain.
The Artefacts and Vocabulary Size metrics for the size attribute show a disadvantage in the use of
AORA approach since the values are highest than the values of the other three approaches, 22 and 9,
respectively. However, these values claim that the AORA requirements document is more complete
than the others improving qualities like maintainability and traceability.
The Weighted Operations per Artefact metric presents better results (lowest average) for AORA
approach when compared with the other approaches avoiding tangled specifications that improve
reusability and maintainability qualities. The Weighted Operations per Artefact AOV-Graph value is
highest since the artefacts of this approach aggregate an elevated number of operations.
According with the information above, AORA is the best approach because it improves separation of
concerns, modularization and understandability, and consequently to promote maintainability. Also,
the AORA is the most complete approach considering the number of information in the AORA
requirements documentation. These characteristics promote traceability and improve
understandability.
7.3 A qualitative analysis of AORE
Based on the specific criteria for assessing requirements engineering approaches proposed in
Chitchyan et al., such as, homogeneity of requirements treatment, trade-off resolution and decision
support, verification and validation, identification and handling functional and non-functional
crosscutting requirements, mapping requirements to later stages, the following criteria for assessing
the aspect-oriented requirements engineering approaches are used (Chitchyan, 2005):
• Traceability. This criterion relates to the existence of facilities to trace aspectual requirements
to their source of origin and to map requirements to architectural design artefacts, i.e.,
horizontal backward traceability, vertical traceability and horizontal forward traceability,
149

espectively (see Chapter 2). Being able to trace artefacts along the software lifecycle is one of
the crucial qualities required for software evolution, understandability and maintainability.
• Modularization of crosscutting requirements. The ability to modularize crosscutting
requirements is related to define requirements artefacts that represent all types of crosscutting
requirements (functional and non-functional). This criterion is important to support
understandability and management of requirements change.
• Identification of crosscutting requirements. This criterion is related to the existence of
effective means to identify crosscutting requirements (be they functional or non-functional) in
requirements documents descriptions or/and any other means to identify the stakeholders
needs. This criterion guarantees completeness of the requirements documents and is the base
for the other activities of the requirements engineering process.
• Composition of crosscutting requirements. The ability to compose crosscutting and non-
crosscutting requirements and, consequently, to analyse their interrelationships and, if needed,
to obtain a more complete view of the requirements artefacts. This criterion is also desirable to
support the identification of conflicts very early in the development, even before the
architecture design is derived.
• Conflict management. Conflicts can arise because different stakeholders have incompatible
needs or because certain concerns impact negatively on others. Conflict identification is
important at this level of abstraction so that agreements between stakeholders are negotiated.
Such agreements cover the balancing of conflicting interests between stakeholders, deciding
on their relative importance before any solution decision is made. Therefore, this requires
trade-off decisions to be recorded and communicated to the other system developers.
• Tool support. This criterion is related to the existence of a tool to support the automation of
the aspect-oriented requirements process. This is desirable to manage large amounts of
requirements information produced by the approach.
• Validation. This criterion is concerned with showing that the identified and specified
requirements actually define what the stakeholder wants. This activity can be accomplished by
checking whether the requirements in the document do not diverge (consistency) and whether
the documents include all requirements planned by the stakeholders (completeness).
• Mapping crosscutting requirements to later development stages. Most current RE
approaches recognise that not all identified requirements will progress into formal
150

architectural or design artefacts: some will map onto decisions, trade-offs, or similar (Rashid,
2003). This criterion indicates that an AORE approach provides support for decisions on
mapping (especially for crosscutting concerns) that facilitate informed solution choices.
• Maturity. AORE approaches are very recent and are still being validated to demonstrate that
they can be successfully applied to real case studies. This criterion indicates if an AORE
approach was used to develop projects in a real setting, i.e., indicates the maturity level.
The AORE approaches chosen in the TAO project are used now for a comparison based on each
criterion described above.
7.3.1 Traceability
Backward traceability of crosscutting requirements is not supported by all the approaches. In fact, as
shown in Table 7.5, two of the AORE approaches do not support traceability of requirements back to
their sources of origin, Multi-Dimensional CORE and AOV-Graph. EA-Miner uses the information
given by the viewpoints. AORA differs from the others approaches by providing a concern template to
record all the valuable information found, such as the source of the requirements, stakeholder
information, information obtained from stakeholders regarding importance of the requirements, etc.
EA-Miner and AORA use their tool to record the change to their sources of origin.
Table 7.5 A summary of approaches that support backward traceability
Approach Traceability from requirements back to their sources of origin
EA-Miner Source row of the view points template
Multi-Dimensional
CORE
Not considered
AOV-Graph Not considered
AORA Source and stakeholder row of the concern template
Forward traceability of crosscutting requirements is not supported by all the approaches. In fact, as
shown in Table 7.6, two of the AORE approaches do not support traceability from requirements to
artefacts along the software development, Multi-Dimensional CORE and EA-Miner.
Table 7.6 A summary of approaches that support forward traceability
Approach Traceability from requirements to architecture or design artefacts
EA-Miner Not considered
Multi-Dimensional
CORE
Not considered
AOV-Graph Rules to transform AOV-graph information into scenarios, object-oriented
models and entity-relationship diagrams
AORA Guidelines to UML artefacts
151

AORA and AOV-Graph approaches support traceability to UML artefacts. These approaches use
UML because it is a well-known standard.
Vertical traceability of crosscutting requirements is supported by all the approaches. Support for this
dimension of traceability is summarized in Table 7.7.
Table 7.7 A summary of approaches that support vertical traceability
Approach Traceability within requirements
EA-Miner Crosscutting relationships
Multi-Dimensional Concern relationships
CORE
AOV-Graph Crosscutting and contributions relationships
AORA Required by relationships
EA-Miner approach support vertical traceability using “crosscutting relationships”. AOV-Graph
approach support vertical traceability using “crosscutting and contributions relationships”. AORA
approach supports this type of traceability using “required by” relationship and Multidimensional
CORE using “concern relationship”. Concern and required by relationships represent all kind of
relationships between the artefacts of Multidimensional CORE and AORA, respectively. In opposite,
the crosscutting relationship only represents one type of relationship between approaches’ artefacts,
i.e., the crosscutting relationship.
7.3.2 Modularization of crosscutting requirements
Modularization of crosscutting requirements is supported by most of the approaches. In fact, each
approach uses different concepts, such as goals, softgoals, early aspects and concerns. Table 7.8
summarizes how the AORE approaches under study support modularization.
Table 7.8 A summary of approaches that support modularization of crosscutting requirements
Approach Modularization of crosscutting requirement into artefacts
EA-miner Crosscutting concerns are represented as early aspects
Multi-Dimensional
CORE
No distinction between crosscutting and non-crosscutting, due to its
multidimensionality. The general term used is “concern”
AOV-Graph Crosscutting concerns are not represented. Goals, softgoals and tasks can have
crosscutting relationships
AORA Crosscutting concerns are represented as concerns’ templates, and so are the
non-crosscutting ones
AOV-Graph does not explicitly support the modularization of crosscutting concerns. Modularize
crosscutting concerns is not the AOV-Graph focus because they naturally appear during modelling.
The newly created approaches AORA and Multi-Dimensional CORE use new artefacts, such as
152

concern, to modularize crosscutting requirements. Notice that Multi-Dimensional CORE does not
make any distinction between crosscutting and non-crosscutting. The AORA approach uses the same
template to specify crosscutting and non-crosscutting concerns, however, information about the
concerns transversatility can be derived (and the AORA tool offers that functionality). AORA differs
from the others approaches by providing a complete concern template, offering more information that
will be useful to achieve successfully other criteria, such as conflict management, for example the
stakeholder priorities row. Also, since many concerns appear once and again in different applications,
it is important to collect, for each concern, all relevant information we may be able to find at this
stage.
7.3.3 Identification of crosscutting requirements
Identification of crosscutting requirements is supported by most of the approaches. In fact, and as
shown in Table 7.9, only Multi-Dimensional CORE approach does not offer support for identification
of crosscutting concerns, due to its multidimensionality.
Table 7.9 A summary of approaches that support identification of crosscutting requirements
Approach Identification of crosscutting requirements
EA-Miner EA-Miner tool uses NLP techniques for mining relevant concepts. A matrix is
built to mark which early aspect affects which viewpoints. If an early aspect
Multi-Dimensional
CORE
affects several viewpoints in the matrix it is considered a candidate aspect.
Not considered
AOV-Graph Through transversal or crosscutting relationships. If any goal, softgoal or task
affects several elements of the goals models it is considered a crosscutting
requirement
AORA AORA tool analysis information in the concerns’ templates, based mainly on the
“required by” relationship, to identify crosscutting concerns. A crosscutting
concern is required by more than one other concern.
The other approaches identify crosscutting requirements based on a special kind of relationship, i.e.,
crosscutting relationship for EA-Miner, AOV-Graph and required by relationship for AORA. EA-
Miner differs from the other approaches as it uses a NLP technique (Natural Language Processing) to
identify all kinds of artefacts in a requirements document.
7.3.4 Composition of crosscutting requirements
Composition of crosscutting requirements is supported by all the approaches, as Table 7.10 shows.
Generally speaking, all the approaches propose a technique based on the specification of crosscutting
relationships or projections using composition rules with operators.
153

Table 7.10 A summary of approaches that support composition of crosscutting requirements
Approach Composition of crosscutting requirements
EA-Miner Uses composition rules based on operators. A set of composition rules is
defined for each candidate aspect, i.e., the approach only proposes composition
rules that defines how an identified crosscutting concern is composed with
Multi-Dimensional
CORE
viewpoints
Concern projections specify the influence of a given concern on other
concerns. The materialisation of these projections is accomplished by defining
a set of composition rules (compositional intersections help reduce the number
of required compositions), one for each projection
AOV-Graph Crosscutting relationships are specified using pointcuts and operators, advices
and intertype declarations
AORA AORA uses the concept of match point to drive the composition. Compositions
are done in two different granularity levels: treating concerns as black boxes
and treating concerns as white boxes, using description elements of the
concerns. Composition rules are based on operators
AORA differs from the other approaches by offering a set of high-level composition operators that are
easy to understand and that give the order of satisfaction between concerns.
7.3.5 Conflict management
Support for conflict management is mentioned by all the approaches. While EA-miner and Multi-
Dimensional CORE support conflict identification and simple resolution, AOV-Graph only supports
conflict identification. AORA supports conflict identification and resolution using contribution
relationships and multi-criteria analysis, respectively, based on the information given in the concern
template. All this information and analysis is important to obtain a more accurate conflict
management. Table 7.11 presents a summary.
Table 7.11 A summary of approaches that support conflict management
Approach Conflict management
EA-Miner Detects conflicting situations emerging during composition based on negative
contributions. Then weight attribution based on fuzzy intervals is used to
Multi-Dimensional
CORE
prioritise the conflicting requirements based on stakeholders’ negotiations.
Detects conflicting situations emerging during composition, using contribution
tables, weights assignment, stakeholders negotiations and folded tables to study
composition intersection
AOV-Graph Identifies conflicts based on correlation relationships. Resolution is not
considered
AORA Detects conflicting situations emerging during composition and based on
negative contributions. Uses Multi Criteria Decision Making to solve the
conflicts based on pairwise matrices or weighted average and stakeholders’
priorities
154

7.3.6 Tool support
Tool support is needed to record and manage the approaches’ information. Because some approaches
are extensions of other existing approaches, they do not provide their own tool, for example, AOV-
Graph. This is not the case for Multi-Dimensional CORE that has no tool support. Table 7.12 shows a
summary of the AORE approaches with tool support.
Table 7.12 A summary of approaches that have tool support
Approach Crosscutting requirements management using a tool
EA-Miner EA-Miner tool supports the identification, specification and composition of
viewpoints and early aspects using XML. Identifies conflicting situations
Multi-Dimensional
CORE
emerging during composition
Not considered.
AOV-Graph Not considered. Although, there are a set of XSLTs to generate views. These are
not integrated and the transformation rules need to be improved
AORA AORA tool supports the specification and composition of concerns using XML
Schema. It identifies crosscutting concerns and conflicting situations emerging
during composition. Allows concerns reuse based on a concern repository and
records concerns’ changes
The tools provide mechanisms to specify and compose crosscutting requirements, but only EA-Miner
provides mechanisms to identify all kinds of requirements using text mining. Only two, AORA and
EA-Miner, provide mechanism to identify conflicts and use other tools to solve them. AORA tool
provides functionalities to manage changes; for example, it records all the concern specification
changes during time. It also provides simple concern graphics. Traceability support is a feature lacking
in all the tools.
7.3.7 Validation
Validation is not supported by any of the studied approaches, as shown in Table 7.13. Therefore, these
approaches need a review process to guarantee requirements consistency and completeness.
Table 7.13 A summary of approaches that support requirements validation
Approach Features that support requirements validation
EA-Miner Not considered
Multi-Dimensional
CORE
Not considered
AOV_Graph Not considered
AORA Not considered
155

7.3.8 Mapping crosscutting requirements to later development stages
Support for mapping is mentioned by all the approaches, as Table 7.14 illustrates. EA-Miner and
Multi-Dimensional CORE propose that a candidate aspect can be mapped to a function, decision or
aspect at the later stages. AOV-Graph proposes that a goal can be mapped into operationalisations.
AORA proposes that a concern can be mapped into different types of models or decisions at the later
stages.
Table 7.14 A summary of how each of the selected approaches supports crosscutting requirements mapping
Approach Crosscutting requirements mapping
EA-Miner The aspect should be mapped to a function, decision or aspect at the later
Multi-Dimensional
CORE
stages
Concerns have an impact on artefacts at later development stages that can be
described in terms of two dimensions: mapping and influence. A concern
might map onto a system feature/function, decision and design aspect. A
concern might influence different points in a development cycle.
AOV-Graph Goal decomposition relationships into operationalizations
AORA The concern should be mapped to UML and SIG models or decision at the
later stages
7.3.9 Maturity
Table 7.15 illustrates if an AORE approach was used to develop projects in a real setting, i.e., its
maturity level. All the approaches were applied at least to one project. However, AORA is the most
applied approach to development projects in a real setting (this is described in more detail in Section
7.4).
Table 7.15 A summary of the projects in which AORE approaches were used
Approach Projects in a real setting
EA-Miner Testbed for Aspect-Oriented Software Development (TAO Project, 2007),
AOSD-Europe, European Network of Excellence (AOSD-European Network
Multi-Dimensional
CORE
of Excellence, 2007)
Testbed for Aspect-Oriented Software Development (TAO Project, 2007)
AOV-Graph Testbed for Aspect-Oriented Software Development (TAO Project, 2007)
AORA Testbed for Aspect-Oriented Software Development (TAO Project, 2007),
Software Development with Aspects (SOFTAS, 2007) and Aspect
Specification for the Space Domain (ASSD, 2006)
156

7.3.10 Summary
Table 7.16 summarizes the discussion on qualitative comparison and reveals that existing aspect-
oriented approaches do not effectively address all the proposed criteria.
Table 7.16 Short summary of AORE approaches and the features that their support
(� completely satisfied; � no satisfied; � partially satisfied)
APPROACH
Backward traceability
Forward traceability
Modularization
157
Identification
CRITERIA
EA-Miner ���� ���� ���� ���� ���� ���� ���� ���� ���� ����
MultiDimensional CORE ���� ���� ���� ���� ���� ���� ���� ���� ���� ����
AOV-Graph ���� ���� ���� ���� ���� ���� ���� ���� ���� ����
AORA ���� ���� ���� ���� ���� ���� ���� ���� ���� ����
AORA supports more criteria than Multi-Dimensional CORE and AOV-Graph. This situation occurs
because Multi-Dimensional CORE approach is too young and needs to improve traceability and
validation techniques and develop a tool. It needs to be validated to demonstrate that it can be
successfully applied in real projects. AOV-Graph, on the other hand, being an extension of goal-
oriented approaches, it reuses some well-know features of goal-oriented approaches, such as forward
traceability. It still needs to improve on traceability, conflict management and tool support.
AORA and EA-Miner support almost the same number of criteria with exception the forward
traceability criterion. They emerged at the same time and evolved in parallel during the last few years.
EA-Miner is a viewpoint based approach so it suffers the symptoms of the tyranny of dominant
decomposition (Tarr, 1999). On the other hand, EA-Miner reuses some well-know features of
viewpoints, for example, backward traceability. EA-Miner needs to improve on traceability and
validation. AORA is an approach inspired in some features of different Requirements Engineering
approaches, which allows the reuse of activities and artefacts accepted by the Requirements
Engineering community, such as, requirements catalogues and UML diagrams.
All the evaluated approaches need to be applied to more real case studies to demonstrate that they can
be successfully applied in real, large, industrial projects. AORA was applied to two case studies in the
Composition
Conflicts
Tool
Validation
Mapping
Maturity

context of two real projects. Section 7.4 discusses the experiments. Although, AORA needs to
improve mapping and validation features, it is the most applied approach to development projects in a
real setting.
7.4 AORA Tested in Projects
The AORA approach with its process and concepts should be assessed by several developers, and
ideally used to develop projects in a real setting. The approach has been submitted to the assessment of
several users (one PhD student, four MSc students and three undergraduate students). In spite of their
different background and maturity, they were able to apply the approach to different case studies
(Soeiro, 2007; Vieira, 2007). The AORA approach was also used in Software Development with
Aspects and Aspect Specification for the Space Domain projects as is described in the next two
sections.
7.4.1 The role of AORA in the SOFTAS Project
The SOFTAS project 12 (Software Development with Aspects), funded by Fundação para a Ciência e a
Tecnologia, aims at creating a seamless aspect-oriented software development methodology, so that
crosscutting and non-crosscutting concerns can be traced during the lifecycle to produce efficient and
high-quality software applications (SOFTAS, 2007). The research results will be instantiated in
practice with real world examples from industry provided by Navegação Aérea de Portugal and
Soluções Integradas para Sistemas de Informação. In summary, the two main objectives of the project
are:
• To propose a modelling and architecture design framework, which includes methodological
and tool support, for the development of software applications that satisfy the principles of
aspect-orientation.
• To derive quantitative evidence on the improvement of the modularity of produced software
and other quality attributes.
12 http://aosd.di.fct.unl.pt/softas/
158

The main contribution of this project will be a new, innovative aspect-oriented framework for analysis,
architecture design and implementation of software. The proposed framework will include a
quantitative evaluation scheme for AOSD. More specifically the framework will provide:
• A language to model and specify requirements-level concerns and respective compositions.
• A set of mappings to derive an architecture design from the analysis model.
• A mechanism and guidelines to derive an implementation from the architecture design.
• A quantitative evaluation model for the resulting aspect-oriented software.
• A validation of the proposed methodology and tools by means of real case studies.
The goals of this project are accomplished by seven tasks. The Requirements Modelling with Aspects
is one of these tasks and the expected results are:
• A model to support the identification of concerns, facilitating the communication between
stakeholders.
• A language to specify concerns and define composition rules that allow the integration of all
concerns.
• A systematic method to handle conflicts that could emerge when two or more crosscutting
concerns affect one another.
The resulting methods and techniques produced by this task will be validated with case studies made
available by the industry partners.
The AORA approach is one of the methods used by Requirements Modelling with Aspects. It was
applied to “Flight Plan Tower Interface system” case study provided by Navegação Aérea de Portugal.
The Flight Plan Tower Interface is the system responsible for the air control operators interface with
Flight Data Processing System (FDPS). Flight Data Processing System is the system responsible for
the flight data processing in Lisbon airport towers (Lisbon, Porto, Faro and Funchal Towers) of
Navegação Aérea de Portugal Portugal’s aerodromes. This application implements the user friendly
system being used by the tower operators for managing the following tower related information: local
monitored aerodrome data and flight plan data relative to the arrival, departure and over- flights
involving the aerodrome.
159

A system requirement specification for the Flight Plan Tower Interface was elaborated in collaboration
with two master students (André Marques and Sérgio Agostinho), and was based on the AORA three
main tasks. The following concerns were identified using AORA identification task:
• Retrieval and Visualization: since the Flight Plan system is essentially an interface system the
Retrieval and Visualization are natural concerns.
• Update and Refresh: as the operator needs to edit and update data, the Update and Refresh
concerns are also required.
• Parameter Validation: as the data are essentially parameters, it is important that these are
valid.
• Flight Strip Printing: tower operators involved in the system use paper strips as a fail-safe
mechanism; therefore, there is a need for a Flight Strip Printing concern.
• Logging: as the Flight Strip Printings need to be reprinted under certain circumstances.
• Response Time, Error Handling and Fault-Tolerance: since the system is data-communication
and data-insertion sensitive, Response Time, Error Handling and Fault-Tolerance are required
concerns.
• Portability, Interoperability and Modularity: were also identified as concerns, since, and as
specified in the requirements and meetings hold with Navegação Aérea de Portugal experts,
the Flight Plan system must be Portable, Interoperability and Modular.
• Multi Access: in some situations, multiple operators may happen to be working on the same
set of data. Therefore, the system needs to support multi access.
• Correctness, Safety, Security: although not a critical system, it is an aid system that should
work as specified (Correctness), even with abnormal internal events (Safety) or external
events (Security).
The AORA specification task helps to describe fully, and in detail, each of the identified concerns. The
concern information found is collected in a concern template. Table 7.17 shows an example of such
templates for the “Retrieval” concern. Similar templates were constructed for the remaining concerns.
160

Table 7.17 Retrieval concern template
Name Retrieval
Description The operation of accessing data, either from memory or from a storage device
Classification Functional
FRS
Sources NAV
Retrieve aerodrome data from FDPS.
Retrieve arrival flight data from FDPS.
Retrieve data for the Flight Strip Printing from FDPS.
Retrieve departure flight data from FDPS.
Responsibilities Retrieve overflight data from FDPS.
NAV: Very Important
Stakeholders
Priorities Operator: Very Important
Concerns
Contributions None
Correctness
Required Concerns Security
The results of the AORA composition task are: (i) match points table to identify crosscutting concerns
(ii) match points table to support composition rules, and (iii) contribution table to identify conflict
situations.
Based on the “Required Concerns” row on the concern specification templates, the points where the
composition will take place, i.e. match points, are identified. The AORA tool collects the information
from all the concern templates and it together in a matrix, as depicted in Table 7.18.
Concerns vs.
Concerns Retrieval
Visualization
Update
Table 7.18 Match point identification
Refresh
Parameter Validity
Logging
Error Handling
Retrieval √ √ MPRetrieval
Visualization √ √ MPVisualization
Update √ √ √ √ √ √ √ √ √ MPUpdate
Refresh √ √ √ √ √ MPRefresh
Parameter Validity √ MPParamValid
Flight Strip Printing √ √ √ √ MPFlightStripPrint
ErrorHandling √ √ MPErrorHandling
For each identified match point a composition rule must be built. The composition rule for the
“retrieval” match point, MPRetrieval, is:
(Security || Correctness) >> Retrieval
161
Fault-Tolerance
Response Time
Multi Access
Security
Safety
Correctness
Match Points

This composition rule expresses the order in which each concern must be satisfied. Security and
Correctness must synchronize so that both concerns are satisfied in parallel, and only after their
successful satisfaction will Retrieval be satisfied.
Table 7.19 shows the contributions between concerns based on the concerns’ templates contribution
row.
Concerns vs.
Concerns
Table 7.19 Contributions between concerns
Error Handling
Fault-Tolerance
Error Handling +
Fault-Tolerance +
Response Time -
Portability -
Interoperability - +
Modularity - +
Multi Access +
Security -
Safety + -
Correctness + + - + +
The contribution table helps the identification of conflicting situations, based on the negative
contributions. To find possible conflicts, it is necessary to analyse the contributions between concerns
in the same match point. Two concerns with negative contribution that must be composed together in
the same match point may raise a possible conflict. Looking Table 7.18 and 7.19, the situations found
are: Response Time vs. Safety in MP Refresh, and Response Time vs. Security in MP Update.
Response Time, Safety and Security have the same priority according to stakeholder priorities row of
concerns template, so we identified a source of a potential conflict.
The complete system requirement specification document for Flight Plan tower interface system is
presented in Appendix C. The system requirement specification document is currently being validated
by Navegação Aérea de Portugal.
Analysing the results of the AORA application to Flight Plan Tower interface case study, it is possible
to conclude that the identification of crosscutting concerns is very important in this stage of the
development process since it can be used as the source for a concern impact analysis. This enables the
developer to be aware of the possible trade-offs required later and therefore to be prepared to
undertake better, informed decisions. Moreover, we realized that treating concerns as black boxes do
not allow us to identify new crosscutting relationships that could appear at a finer level of granularity,
Response Time
162
Portability
Security
Safety
Correctness

i.e., at responsibility level. Currently, some of the concerns are too coarse grained (e.g. availability,
response time) and it is possible that certain conflicting situations will disappear when handle at a
lower abstraction, thus the refinement of concerns will play a fundamental role in AORA approach
goals.
7.4.2 The role of AORA in ASSD Project
The ASSD project (Aspect Specification Space Domain), funded by the European Space Agency
(ESA), aims at assessing the applicability and usefulness of aspect-orientation in Space Domain
software development, as a way of reducing the complexity of software development, focusing on the
early stages of the development process (ASSD, 2006). The research results will be instantiated in
practice with real-world case studies that were provided by DEIMOS Space 13 and EADS Test &
Services 14 partners.
AORA has been used in this project, outside this author’s control. In summary, this project proposes
an approach that is a refinement of the AORA approach. So, in a similar way, the Aspect Specification
Space Domain approach addresses the identification, separation, representation and composition of
crosscutting concerns at the requirements level. To accomplish these, the Aspect Specification Space
Domain process model is composed by the following tasks: Identify Stakeholders and Requirements,
Elicit System Requirements, Identify Concerns, Specify Concerns, Analyze Match Points, and
Analyze Requirements Traceability. The resulting specification is stored in an XML-based Metadata
Repository (Ferreira, 2007). XML was chosen as the document format since it provides flexibility to
represent any kind of information.
An architecture and client tools were developed to provide a concretization of the Aspect Specification
Space Domain method and they are a refinement of previous work (Ferreira, 2005). The architecture
of the system relies on a Metadata Repository described in (Ferreira, 2005), for: (i) supporting the
approach definitions; (ii) automatically generate specific documentation; and (iii) provide the means
for creating reusable catalogues such as (Chung, 2000).
In terms of model Aspect Specification Space Domain differs on AORA regarding some extensions
and changes:
13 http://www.deimos-space.com/
14 http://www.ts.eads.net/
163

• Aspect Specification Space Domain added two new concepts to support requirements (System
Requirement and Stakeholder Requirement).
• Aspect Specification Space Domain added a new relationship (parent) to relate the new
concepts (Stakeholder, Concern, and System), allowing to form hierarchies.
• Aspect Specification Space Domain added a Review requirements step, in which is possible to
analyse the requirements traceability.
• In Aspect Specification Space Domain the concern contributions are unidirectional, instead of
bidirectional as in AORA.
• In Aspect Specification Space Domain the composition rule task was removed, so the
specification of the composition order was not specified and limited to some conflicts
identification, such as temporal conflicts.
A System Requirement refers to a technical requirement that allows an efficient mapping between a
possible non-technical Stakeholder Requirement to a requirement that is non-ambiguous in its
interpretation and can be understood by the development team. Depending on the elicited Stakeholder
Requirements, these may be collapsed in one, or expanded in multiple System Requirements. Both
concepts contain prioritization attributes that classify the requirement’s importance within the devised
System, an is similar to stakeholders priorities row in the AORA concern template
A Stakeholder describes an entity (e.g. person, company, university) responsible for defining the main
capabilities (Stakeholder Requirements) of a software application, usually during elicitation meetings.
The concept’s metadata is mainly descriptive regarding the contacts of the entity, e.g. address(es) and
email(s).
The Aspect Specification Space Domain approach was successfully applied to real-world case studies
that were provided by DEIMOS Space 15 and EADS Test & Services 16 partners. Analysing the results
of the ASSD application to the case studies, it is possible to conclude that the identification of
crosscutting concerns are very important in this stage of the development process since it helps to the
identification of impacts or contribution between concerns. This enables the analyst to foresee that
some trade-offs must be performed, in later steps of development. Also, the Aspect Specification
Space Domain approach allows some consistency check on the analysis by issuing warnings (e.g.
15 http://www.deimos-space.com/
16 http://www.ts.eads.net/
164

unused concerns or requirement mappings). Above all, the most important aspect about the approach
is that it makes the analyst think about concerns and their impact on among each other, in an early
stage of the development. However, since the case studies were nearly complete projects, it was not
possible to integrate the approach in their full development cycle; a task would allow further
validation of the approach. The use of a Metadata Repository solution for managing knowledge,
ensuring its validation, consistency and providing querying mechanisms, is a major advantage
comparing with traditional documentation supports.
7.5 Conclusions
Based on the quantitative and qualitative evaluation, AORA approach seems one of the most complete
AORE approaches, when compared with other three AORE approaches.
The analysis of the results of the applications of AORE metrics demonstrates that AORA achieves
better separation of concerns than the other three approaches. Size quality attribute for AORA presents
the worst results but, on other hand, these values indicate that AORA is a more complete approach,
since the AORA elements support many of the AORE features.
Besides the fact that Table 7.16 reveals that existing aspect-oriented approaches do not effectively
address all the proposed criteria, AORA addresses more of those criteria.
The application of AORA to real case studies using SOFTAS and ASSD projects, as presented in
Section 7.4, indicates that this approach is achieving a certain maturity status.
There are, however, some limitations that AORA needs to overcome. In particular, it would be nice to
be able to:
• Improve the ability to identify crosscutting functional concerns.
• Improve the link between composed requirements and architectural units.
• Propose features to validate crosscutting requirements.
165

166

167
Chapter 8
The AORA Refinement for MDD
During the AORA assessment, we confirmed that treating concerns as black boxes was not the best
option. Being able to compose using requirements elements at a finer granularity level would
contribute to balance concerns granularity.
Currently, some of the concerns are too coarse grained (e.g. availability, response time) and, apart
from the possibility of having different interpretations for different contexts, we believe that most of
the benefits of refining concerns will be found at later stages of the development, like architecture or
design level. This is so, because refinement is introducing another level of information that can help in
deriving architectural and design models, supporting design decisions to solve possible trade-offs.
Moreover, despite the crosscutting nature of certain concerns, this level of information shows that
these concerns might not be crosscutting at later stages of the development process.
It is our believe that the AORA refinement brings the following benefits:
• Improves modularisation, as complex responsibilities can be further decomposed into
finer-grained concerns, making the resulting concerns more balanced.
• Promotes the reuse of responsibilities because they are well-encapsulated in modules.
• May provide further support for conflict management in situations where the conflicting
concerns are, after all, applied to different fine-grained concerns, instead of their
originating coarse-grained one.

• Offers a step forward in taking us closer to the next development stage, therefore,
contributing to help identifying concern mappings onto functions, aspects, architectural or
design artefacts and decisions.
The strategy to refine AORA was to find a way to automate the refinement process, or at least to make
it as systematic and rigorous as possible. We are aware that even when a clear process is available, its
manual application can be a repetitive, laborious and error-prone task. So, the obvious choice was to
investigate how Model-Driven Development could support the automation of this process (France,
2007; Kovacevic, 2007). The resulting elements of the refinement process, such as responsibilities
composition rules, will benefit from the AOSD principles, since the AORA refinement supports
modularization, separation and composition of responsibility, crosscutting and non-crosscutting.
According to existing bibliography, the use of Model-Driven Development could bring the following
benefits to the AORA refinement:
• A raise in the level of abstraction at which developers create software, by formalising the
AORA approach concepts and tasks (Hailpern, 2006).
• The repetitive, laborious and error-prone tasks, required to create a model from another
model, can be automated.
• The refinement process is performed in a consistent manner, since it is automated.
• New model elements, such as responsibility and responsibility composition rule, can be
incorporated at the AORA model, and therefore defined in its metamodel, and consistently
and automatically propagated to the refined model.
This chapter describes the first step towards the AORA refinement with Model-Driven Development.
A fully fledged validation of the goals we believe to find in the future is still to be proved, and will be
part of the future work. Here, our intention was to offer a step forward in the AORA refinement.
For the time being, the main idea is to refine concerns’ responsibilities and define composition rules at
the responsibility level using the AORA metamodel and the AORA UML profile described in Chapter
4. This chapter starts introducing the main Model-Driven Development concepts. Section two
presents the AORA refinement with MDD. Section three illustrates the AORA refinement using a case
study. Section four shows the problems and limitations of this refinement process and, finally, Section
five draws some specific conclusions.
168

8.1 An introduction to Model-Driven Development
The OMG is promoting the use of models in the software development lifecycle to support automation
through model execution, model transformation and code generation techniques (OMG/MOF2.0,
2002). This goal is achieved with Model-Driven Development (MDD) (Selic, 2003; Stahl, 2006).
MDD is an approach that treats models as first-class primitives, with transformations as the primary
operation on models, used to map information from one model to another (Kovacevic, 2007).
According to this, MDD promotes (Hailpern, 2006):
• Abstraction by allowing us to ignore implementation details and focus on the concepts.
• Automation by automatically transform conceptual models into executable
implementations.
• Model portability to bridge a model between different metamodelling languages.
• Control over both modelling environment and transformation to implementation given by
modelling tools.
• (Semi) automatic transformations of models, until the running application is derived
(OMG, 2005).
Metamodels are at the core of the techniques, tools, and languages that support MDD of complex
software systems (OMG/MOF2.0, 2002). A metamodel is a precise definition of the constructs and
rules needed for creating semantic models that allows a language designer or methodologist to better
capture, analyze and understand their approaches (Metamodel.com, 2007). A model is an abstraction
of the characteristics of the real world, and a metamodel is another abstraction, highlighting properties
of the model itself, so a model is conformed to its metamodel.
MDD promotes the use of abstract models that are systematically transformed to execute technology-
specific implementations (Cornell, 2007). A transformation can define changes that are applied to a
source model to produce a target model. Often referred as a model-to-model transformation, the source
and target models can be based upon a metamodel like the UML, or else developer specific
metamodels. Figure 8.1 illustrates, in a nutshell, the MDD transformation concept.
169

Figure 8.1 MDD transformation, taken from (Kovacevic, 2007)
Systematic support for model transformations is considered to be critical to the success of the MDD.
To achieve this goal, OMG proposed a standard transformation language that supports rules between
two MOF-compliant models. This standard is called "MOF 2.0 Query/Views/Transformations" (QVT)
(OMG/MOF2.0, 2002). The main advantage of using a transformation language is that the
transformation logic can be expressed at a high level of abstraction thus enhancing maintainability and
understandability. To express a transformation in such a language, the user must specify mapping rules
that describe how model elements from the source model can be mapped to elements in the target
model.
We have used metamodelling to refine rigorously the AORA approach, from AORA source (described
in Chapter 4) to AORA target metamodel.
8.2 AORA refinement with MDD
As we said before, our aim is to refine AORA, preserving the information contained in the initial
AORA approach. This is achieved through the AORA source metamodel packages described in
Chapter 4 and applying to these packages a set of guidelines and grammar to obtain new metamodel
elements that support the AORA target metamodel. Therefore, these guidelines and grammar support
the source metamodel transformation to the target metamodel.
170

An extension of the AORA UML profile is proposed to instantiate the metamodels and obtains AORA
models that conform to AORA UML profile.
Figure 8.2 illustrates the AORA target packages metamodels which includes the AORA source
metamodel packages (ConcernSpecification and ConcernComposition), as well as the new
metamodels to support the refinement (ResponsibilitySpecification and ResponsibilityComposition).
As described before in Chapter 4, the package ConcernComposition merges with the package
ConcernSpecification to link the composition rule elements to specification elements. The
ResponsibilitySpecification merges with the package ConcernSpecification to link the concern and its
responsibility elements to responsibility specification elements. The ResponsibilityComposition
merges with both the package ConcernComposition to link the concern composition rule element to
responsibility composition rule element and the package ResponsibilitySpecification to link the
responsibility composition rule elements to responsibility specification elements.
ConcernSpecification
«merge»
171
ConcernComposition
«merge» «merge»
ResponsibilitySecification ResponsibilityComposition
Figure 8.2 AORA refinement metamodel packages
Let us start by refining ConcernSpecification package and then we will refine the
ConcernComposition package. The refinement of ConcernSpecification AORA source metamodel is
achieved through the ResponsibilitySpecification package. We use UML to represent our metamodel
packages and to express concerns responsibilities, for example using UML sequence diagram
elements. According to this, and inspired in Sanchez (Sanchez, 2006), we propose that each
responsibility can be described using the following elements:
• Entity, described by a name and a list of events associated with the entity.
• Message described by a name, a sent event and a received event.
• Event described by a name, a trigger time, an entity that handles the event and a message
associated with the event.
«merge»

• Time described by a name and an instantiation time.
These elements result from the responsibility refinement. The refinement is achieved by following a
set of simple guidelines to transform a responsibility into a consistent representation, as shown in
Table 8.1.
Table 8.1 A guideline to refine a responsibility
AORA responsibility AORA responsibility refinement
For each noun that expresses a property in the
responsibility,
create an Entity element
For each verb that expresses a task in the responsibility create a Message element
for each Message, create two Event elements
for each Event, create a Time element
The elements and the guidelines support the transformation of the responsibility into a more refined
level.
Figure 8.3 presents the ResponsibilitySpecification metamodel package.
Contribution
0..* +contributer
Responsibility
Concern
1..*
CrosscuttingResponsibility
Time
0..*
+contributor
1..*
2..*
ResponsibilityElement
Message Event Entity
2
172
+joins
ResponsibilityMatchPoint
Figure 8.3 Responsibility specification package of the AORA refinement metamodel
The ResponsibilitySpecification metamodel presents a special type of Responsibility designated by
CrosscuttingResponsibility. A CrosscuttingResponsibility is a Responsibility that is composed of two
or more ResponsibilityMatchPoint. A ResponsibilityMatchPoint element joins two or more
Responsibilities of a given Concern. A Responsibility can have a Contribution list (of “+” or “–“ kind,
defined by ContributionKind enumeration described in ConcernSpecification metamodel presented in
1..*

Chapter 4). The ResponsibilitySpecification package metamodel merges with the
ConcernSpecification package metamodel to link the Responsibility, Concerns and Contribution.
Using the Washington subway system case study described in Chapter 4, the responsibilities of the
EnterSubway concern are refined using the elements described before in Chapter 4. For example, The
“Checks the card data” responsibility is instantiated in terms of an Entity (Card data), a Message
(Checks) and two Events one received event and the other a send event (E1, E2).
During the refinement process investigation, we realized that some responsibilities cannot be naturally
refined because they are out of the requirements scope, and may refine into architectural or design
elements. For example, the Availability responsibilities “All the machines of the system need to be
accessible” has an adjective (accessible) that is difficult to define using any of the responsibility’s
elements presented before and it describes a very important quality of the system.
The refinement of the AORA source metamodel ConcernComposition package is achieved through the
ResponsibilityComposition package. Here, we propose a new “type” of composition rule
(ResponsibilityCompositionRule) that composes responsibilities of a given concern. According to this,
new elements need to be created, such as, Responsibility MatchPoint that is defined by a
Responsibility CompositionRule. Therefore, the Responsibility MatchPoint of a concern C will be
defined by a Responsibility CompositionRule. So, the Responsibility CompositionRule of a concern C
can be defined by the grammar:
:= (, )
:= , |
:= < Responsibility CompositionRule> | Responsibility
:= enable | disable | choice | parallel
This grammar supports the transformation of the composition task into a more refined level.
Figure 8.4 illustrates the ResponsibilityComposition metamodel package. As described by the
grammar above and the grammar for concern composition rule presented in Chapter 4, a composition
rule has similar elements for concern and responsibilities match points. These elements are the
CompositionOperator, CompositionRule and the Operand.
173

ElementarOperand
Responsibility
Operand
+operands
2...*
{ordered}
CompositionRule
ResponsibilityCompositionRule
definedBy
ResponsibilityMatchPoint
174
+operator
«enumeration»
CompositionOperator
disable
enable
choice
parallel
Figure 8.4 Responsibility composition of the AORA refinement metamodel
The Operand can be an ElementarOperand or a CompositionRule and they are ordered to express the
way in which responsibilities are arranged in relation to one another, for example, the responsibility
(R1) is needed before responsibility (R2), so R1 is the first operand and R2 is the second operand. The
ElementarOperand can be a Responsibility (and also a Concern from ConcernComposition package).
The CompositionRule can be a ResponsibilityCompositionRule that defines a
ResponsibilityMatchPoint and the CompositionRule has an operator defined by CompositionOperator
enumeration (the enumeration values are disable, enable, choice and parallel and represent the
operators supported in AORA composition).
The ResponsibilityComposition package metamodel merges with the ConcernComposition package
metamodel to link the Operand and CompositionRule elements from both metamodels. Moreover, the
ResponsibilityComposition package metamodel merges with the ResponsibilitySpecification package
metamodel to link the Responsibility elements from both metamodels.
As we described in Chapter 4, we defined a UML profile to represent an instance of the AORA
metamodel in UML. Figure 8.5 illustrates the UML profile of the AORA target metamodel to specify
its concepts (described by meta-classes and enumerations) in terms of stereotype hierarchy extensions
of UML meta-classes. This profile extends the AORA source metamodel UML profile.

«stereotype»
Responsibility
«stereotype»
Crosscutting
Responsibility
«stereotype»
ResponsibilityCompositionRule
operator: CompositionOperator
«stereotype»
Entity
175
«metaclass»
Classifier
«stereotype»
Event
«metaclass»
Association
«stereotype»
ResponsibilityMatchPoint
Figure 8.5 AORA refinement UML profile
«stereotype»
Message
«stereotype»
Time
In the AORA target UML profile, the Classifier meta-class extensions are considered as first class
entities. The entities are defined by the following stereotypes: Responsibility and its derivate
Crosscutting Responsibility, ResponsibilityCompositionRule (with an operator attribute of
CompositionOperator enumeration type) and Entity, Event, Message and Time. Note that to
accomplish the refinement process, the Responsibility element is defined as a Classifier. The last
entity of the AORA UML target profile is the Association meta-class extension defined by the
ResponsibilityMatchPoint.
To provide all the relevant aspects of AORA refinements, we propose the following well-formed
rules:
• A minimum of one ResponsibilityElement is needed to accomplish all the tasks of the
framework.
• A ResponsibilityCompositeRule can always be defined for a ResponsibilityMatchPoint.
• A ResponsibilityCompositeRule is acyclic, i.e., a composition resulting from a
composition rule must not trigger itself.
• A CrosscuttingResponsibility or a Responsibility cannot inherit from itself.

8.3 AORA refinement example
To illustrate the refinement let’s go back to the Washington subway system example and concentrate
on the ResponsibilityMatchPoint for EnterSubway concern. This ResponsibilityMatchPoint joins the
responsibilities: R1. Checks the card data, R2. Registers an entrance and R3. Returns the card to the
passenger. Moreover, this ResponsibilityMatchPoint is defined by a ResponsibilityCompositionRule
that is described as:
Responsibility CompositionRule:= enable(R1, R2, R3)
This responsibility composition rule for EnterSubway concern means that the all the responsibilities
are composed in sequence. Looking to the other responsibility composition rules, for example
ExitSubway, we observe that the responsibility R3 (“Returns the card to the passenger”) is involved in
at least two ResponsibilityMatchPoints, so it is defined as a crosscutting responsibility.
To better illustrate this example, Figure 8.6 shows the ResponsibilityCompositionRule instantiation of
the AORA ResponsibilityComposition package metamodel.
«Concern»
EnterSubway
+definedBy
+responsibilityMatchPoint
«ResponsibilityCompositionRule»
enable: CompositionOperator
+3operand
«Crosccutting Responsibility»
ReturnCard
176
«Responsibility»
ChecksCard
+1operand
+2operand
«Responsibility»
RegisterEntrance
Figure 8.6 Responsibility composition rule for responsibility match point of EnterSubway concern
Identifying contributions between two responsibilities may be a difficult task; it requires expertise in
specific domain areas that may not always exist in a project team. For certain cases, existing
catalogues are a good source of information but there are still many situations where catalogues are
not available. During the identification of conflicts between responsibilities, we realized that these

contributions can often only be detected when the composed system is analysed. So in AORA, we
need to compose all the responsibilities of the concerns required in a given concern match point.
Returning to the composition rule for EnterSubway match point (MPES) in Chapter 4 and the
responsibility composition rule described above, Response Time defines the time that a machine has to
react when passengers use the system with a card in entering, exiting and buying machines. If the
system supports mechanisms to support this time, such as, Redundant Arrays of Inexpensive Disks
(RAID) solutions, the Integrity, Accuracy and Multi-access concerns are improved. This means that
RAID's levels balance two key goals: increased data management and increased I/O (input/output)
actions. This proves that refining ResponseTime can help in deriving architecture, supporting design
decisions to solve possible trade-offs. Moreover, despite crosscutting nature of this concern, this
information shows that these concerns might not be a crosscutting concern at next stages of the
development process.
8.4 Problems and limitations
The difficulties in obtaining the first model from where transformations can then be applied to evolve
the models are well-acknowledged (Kovacevic, 2007). We believe we contributed with a modest step
forward towards helping solving this problem defining an AORA metamodel and an UML profile.
However, and to achieve our goals, there is still a lot of work to do:
• Although AORA refinement works with OMG standards, it does not have a modelling
tool to support the transformations, so the refinement process is not automatic.
• Identify a tool that checks the consistency of a model with respect to a UML profile.
• Define a rigours and systematic process to identify contributions between responsibilities
to support conflicts management at this level of granularity.
• Identify “false positive” conflicts between coarse-grained concerns that could potentially
disappear when concerns are dealt with at a finer-grained level.
8.5 Conclusions and future work
The main motivation for applying MDD to AORA is to improve the mechanisms for the separation
and composition of responsibilities, crosscutting and non-crosscutting, within each model. If all
177

esponsibilities can be modelled separately at a certain level, that level will become more manageable,
extensible and maintainable. Therefore, the concerns refinement improves modularisation and reuse of
responsibilities, since crosscutting responsibilities are well-encapsulated in modules. Besides this,
another benefit of refining concerns will be found at later stages of the development, since the
refinement shows that some crosscutting concerns might not be crosscutting at the architecture or
design stages, reducing the number of potential aspects in the final product.
This chapter presents an initial step in our research towards the automation of the AORA refinement
using MDD. From the AORA perspective only, the use of MDD brings value to our results, since:
• The AORA concepts and their relationships are described more rigorously.
• The approach is now prepared to be used in a seamless MDD development framework.
The proposal has been validated by deriving instantiations for AORA models using the case study
described in Chapter 4.
To accomplish the benefits described in this chapter, a set of new elements were defined:
• Responsibility is specified separately, so modularization and reuse can improve.
• Responsibility match point defines the responsibility composition rule that specifies how
and the order in which responsibilities will be applied in a particular match point.
• Crosscutting responsibilities are specified to identify those that are composed in more than
one responsibility match points.
• Concerns refinement show that some crosscutting concerns might not be crosscutting at
later stages of the development process.
We know that this is just a small step towards a more adequate model-driven development approach in
the context of AOSD. Therefore, there are still problems to be solved that constitute directions for
future work. For example, we would like to investigate the conflicts, dependencies and interactions
between responsibilities and between concerns and responsibilities and how to deal with
responsibilities that cannot be naturally refined. Also, we expect that some conflicts initially identified
between coarse-grained concerns are, in fact, false-positive conflicts, meaning that they could
potentially disappear when concerns were dealt with at a more fine-grained level. Moreover, a set of
rules are needed to transform instances of the AORA metamodel into instances of the refined AORA
metamodel. The set of rules would be encapsulated in a model transformation, taking a source model
and producing a target model. These transformations have not been tackled in this chapter and would
require further investigation. The current trend in transformation is to use rule-based languages such as
178

QVT to specify transformations between models to gradually obtain the system. QVT is chosen
because it defines a standard way to transform source models into target models.
179

180

181
Chapter 9
The AORA Design Rationale
It is always important to know the history of something, its development and evolution path. Apart
from giving the author the opportunity to remember his/her trials, failures and successes, it may help
the reader to understand some of the constraints and design rationale that led the author to opt for that
particular problem solution or take this or that decision. These are the two main reasons for this
chapter. We will, therefore, describe some of the earlier versions of the AORA approach, discussing
the main problems that led to the final version.
The first version of the AORA approach was published in 2002 (Moreira, 2002), and during the
following years it was influenced by several ideas and other approaches. Aspect-Oriented Software
Development was certainly not as well-developed as it is nowadays. In our opinion, the “Special Issue
on Aspect-Oriented Programming” was perhaps one of the first steps towards building the AOSD
community (ACM, 2001). In fact, the first edition of the respective conference took place in March
2002 and it addressed little more than Aspect-Oriented Programming. During the coming couple of
years, the only three groups working on Aspect-Oriented Requirements were our group at
Universidade Nova de Lisboa, a small group at Lancaster University and another one at IBM. The
work developed by Universidade Nova de Lisboa and Lancaster University teams, which in that year
joined researchers interested in software architecture (Paul Clements from SEI and Bedir
Tekinerdogan from University of Twente), culminated with the internationally well-known movement
on Early Aspects (www.early-aspects.net).

We can state that AORA was the very first AORE approach in AOSD. It evolved within the Early
Aspects context, with the initial primary goal of integrating the functional and non-functional
requirements. Since then, the approach has evolved in several ways that we will describe next. The
later version has been applied as a starting point in research projects, such as SOFTAS and ASSD, as
described in Chapter 7 (ASSD, 2006; SOFTAS, 2007).
During the AORA development, we had the following objectives:
• Identify and specify concerns, with particular emphasis on crosscutting concerns.
• Identify and solve conflicting situations that we suspected could arise during composition.
• Compose concerns, independently from their intrinsic nature (i.e., being functional or non-
functional).
• Development a tool to support the approach.
This chapter is organized as follows. The first three sections present the three main versions of the
AORA approach. Section four illustrates the most significant problems we had to solve during the
AORA approach development. Section five presents some conclusions.
9.1 AORA first version
The first period of the AORA approach saw its beginning in 2001 and lasted until the end of 2002. The
stepping stone for this first version published (Brito, 2002), which was later extended as a full paper in
(Moreira, 2002), consisted of a model to identify and specify quality attributes, which we thought as
strong crosscutting candidates. Back then we were not sure about which other types of crosscutting
requirements would exist, but we were very sure about the crosscutting nature of quality attributes, or
non-functional requirements. By then, the existing AOSD literature was not very rich in examples.
Security and tracing were perhaps the most typical and recurrent ones. Therefore, the work on the
NRF framework Chung et al. proposed by Mylopolous group from Toronto University seemed an
ideal starting point for our research, with benefits for both communities (Chung, 2000). On the one
hand, this would bring to AOSD several other examples of crosscutting concerns and, on the other
hand, the NFR framework, and in fact other existing work on non-functional requirements, could
benefit from a clear integration with functional requirements by using the AO composition
mechanisms. In other words, AOSD could help us achieving such an integration and explore further
crosscutting properties.
182

Therefore, the AORA approach first version initially tried to integrate in a single approach quality
attributes and functional requirements, which were handled separately in other existing approaches
(Kazman, 2000; Malan, 2002). Quality attributes, such as response time, accuracy, security, and
reliability, are properties that affect the system as a whole. Handling them separately from base
software components may add extra risk and complexity to the software development process,
impacting negatively on the quality of the final product. Traditionally, the integration is difficult to
achieve and is usually accomplished only at the later stages of the software development process.
Additionally, approaches of that time failed in addressing the crosscutting nature of some of those
attributes explicitly and, in particular, it was difficult to represent clearly how these attributes can
affect several requirements simultaneously. Since this was not supported from the requirements stage
to the implementation stage, some of the software engineering principles, such as abstraction,
localization, modularisation and reusability, could be compromised and, the resulting system would be
more difficult to maintain and evolve.
The above discussion highlights the need to include crosscutting quality attributes as fundamental
modelling primitives at the requirements level. The motivation for this was essentially to provide
improved support for separation of crosscutting quality attributes during requirements engineering,
hence offering a better means to identify and manage conflicts arising due to tangled representations.
Soon the main activities of the AORA first version approach were established as identify, specify and
integrate quality attributes with functional requirements. The resulting model was UML 1.4 compliant,
i.e., we used the UML standard and particular notations to specify functional requirements and
integrate them with the quality attributes. This model was composed of three main activities: identify,
specify and integrate requirements (see Figure 9.1).
The first activity consists of identifying all the requirements of a system and selecting from those, the
quality attributes relevant to the application domain and stakeholders. This was accomplished by
Identify actors and use cases and Identify quality attributes.
183

Identify
Specify
Integrate
Identify actors
and use cases
Build a use case
diagram
Specify use cases
Integrate crosscutting quality
attributes with functional
requirements
184
Identify quality
attributes
Specify quality
attributes using
templates
Identify crosscutting
quality attributes
Figure 9.1 A requirements model for quality attributes
The second activity was divided into two main parts: (i) specify functional requirements using a use
case based approach, accomplished by Build a use case diagram and Specify use case tasks; (ii)
describe quality attributes using special templates and identify those that cut across functional
requirements (i.e. crosscutting quality attributes), accomplished by Specify quality attributes using
templates and Identify crosscutting quality attributes tasks. The template we proposed to specify a
quality attribute is depicted in Table 9.1. The influence from the NRF framework (Chung, 2000) and
from the work described in (Malan, 2002) is noticeably in two respects: AND/OR decomposition
relationships and +/- contributions.
Table 9.1 Template for quality attributes
Name The name of the quality attribute
Description Executive description
Focus A quality attribute can affect the system (i.e. the end product) or the development process
Source Source of information (e.g. stakeholders, documents)
Decomposition Quality attributes can be decomposed into simpler ones. When all (sub) quality attributes
are needed to achieve the quality attribute, we have an AND relationship. If not all the sub
quality attributes are necessary to achieve the quality attribute, we have an OR relationship
Priority Expresses the importance of the quality attribute for the stakeholders. A priority can be
MAX, HIGH, LOW and MIN
Obligation Can be optional or mandatory
Influence Activities of the software process affected by the quality attribute
Where List of the actors influenced by the quality attribute and also a list of models (e.g. use cases
and sequence diagrams) requiring the quality attribute
Requirements Requirements describing the quality attribute
Contribution Represents how a quality attribute can be affected by the other quality attributes. This
contribution can be positive (+) or negative (-)

At the beginning we only considered quality attributes as crosscutting concerns because they can
affect large parts of a system and, therefore, potentially several requirements simultaneously. So, in
the second activity we identify quality attributes that cut across functional requirements.
The third activity proposes a set of UML models to represent the integration of crosscutting quality
attributes and functional requirements. Inspired on the concepts commonly used in various separation
of concerns approaches, we adopted the operators overlapping, overriding and wrapping to define the
integration part of the approach (ACM, 2001).
By analyzing the AORA first version, we can easily notice the two-dimensional perspective of the
approach, where functional and non-functional requirements were basically treated in parallel and
joined at the end using “composition” (which we called back then “integration”).
9.2 AORA second version
This second period lasted from 2003 to 2004, approximately. By 2002 we had the AORA first version,
but we were still unhappy with the integration activity and also the two separate parallel paths in the
approach to handle functional and non-functional concerns, which makes the process more complex.
This bi-dimensionality, even if consistent with many of the existing AOP languages, such as AspectJ,
felt uncomfortable at the level of abstraction we were working on. To move from this stage to a more
“muldimensional” or “symmetric” strategy was a simple step. AOSD claimed an improved Separation
of Concerns, as set out by our dear late Dijkstra. So, it made sense to think only in terms of concerns,
instead of kinds of requirements.
During 2003 we realised that composition was, most probably, the main contribution that AOSD gave
to the computer science community, since composition allows the developers to picture a broader part
of the system and to identify conflicting situations that offers the opportunity to minimize the impact
of these situations in later stages of the development process. From there, we decided to look more
carefully at our “Integration” task. This was still very much in line with one of our main objectives
“create a seamless approach to handle functional and non-functional requirements”. So, we dedicated
some time to investigate composition mechanisms as proposed by several aspect-oriented
programming languages. The stepping stone for a composition mechanisms was proposed in (Brito,
2003a), which was later published as a full paper in (Brito, 2003b). This paper introduces several new
notions to define composition rules: match point, dominant concern and LOTOS operators. In
addition, we recommend the use of existing catalogues to alleviate both the identification and the
specification tasks, as proposed in (Chung, 2000; Wiegers, 2003).
185

Figure 9.2 presents a generic model to handle advanced separation of concerns during requirements
engineering. It is composed of four main tasks: identify concerns, specify concerns, identify
crosscutting concerns, and compose concerns.
INPUT
���
�Task 1: Identify
concerns
CATALOGUES
� �
�Task 2: Specify
concerns
2.1: Using best
approach
2.2: Identify
contributions
2.3: Identify
priorities and
interrelationship
�Task 3: Identify
crosscutting concerns
186
OUTCOME
�Task 4: Compose
concerns
4.1: Identify
match points
4.2: Identify
conflicts
4.3: Identify
dominant
4.4: Define
composition
rules
� �
Templates Rules Visual models
Figure 9.2 A model for advanced separation of concern
This model uses any of the existing techniques, such as use cases (Jacobson, 1992) and catalogues
(Chung, 2000) to support concerns’ identification. Contrary to the AORA first version that proposes a
template to specify quality attributes, this AORA second version proposes a template to specify all
types of concerns. Table 9.2 illustrates the concern template.
Table 9.2 Template to describe concern
Name The name of the concern.
Source Source of information, e.g. stakeholders, documents, domain, catalogues and business
process.
Stakeholders Users that need the concern in order to accomplish their job.
Description Short description of the intended behaviour of the concern.
Classification Helps the selection of the most appropriate approach to specify the concern. For
example: functional, non-functional, goals.
Contribution Represents how a concern can be affected by other concern. This contribution can be
positive (+) or negative (-)
Priority Expresses the importance of the concern for the stakeholders. It can take the values:
Very Important, Important, Medium, Low and Very Low.
Interrelationships List of concerns needed by this concern.
The template was adapted to specify all types of concerns and differs from the Table 9.1 eliminating
Focus, Obligation, Decomposition and Influence rows and adding Stakeholders, Classification and
Interrelationships rows. The Stakeholders row registers the direct or indirect actors that have an

influence in the project and helps the identification of concerns, including concerns priorities. The
Classification row helps the selection of the most appropriate approach to specify the concern. The
Interrelationships row presents the list of concerns needed and allows the identification of crosscutting
concerns, as well as, the identification of places where the composition will take place. This
information is very important to accomplish the “Compose Concerns” task because they guide the
composition task.
The goal of the “Compose Concerns” task is to join together sets of concerns to obtain particular
views of the system, or of the whole system, as well as to help us express the way a crosscutting or
non-crosscutting concern affects the behaviour of other concerns. In the AORA second version, the
composition task composes crosscutting concerns with other crosscutting or non-crosscutting
concerns. To guide the composition, we proposed four subtasks:
• Identify match points.
• Identify conflicts.
• Identify the dominant concern.
• Define the composition rules.
The identification of match points was accomplished based on the row Interrelationships (in Table
9.2). A match point tells us which crosscutting concerns should be composed with a given concern, or
also called base concern.
The subtask “Identify conflicts” supports the identification of conflicting situations between concerns.
For a given match point we need to analyse if any of the involved crosscutting concerns affects or
contributes negatively to another concern (based on the Contribution row in Table 9.2). Concerns
contributing positively to other concerns raise no problems.
The subtask “Identify the dominant concern” was the strategy we found back then to help solving the
concern conflicts. It works based on the Priority row in Table 9.2 and its main goal is to obtain an
ordered ranking of the crosscutting concerns in a match point. Therefore, if the priority attributed to
each concern is different, the problem is not too difficult to solve, and the dominant concern is that
with higher priority. However, if at least two crosscutting concerns have the same priority, a trade-off
must be negotiated with the user. The identification of the dominant crosscutting concern for a given
match point was proposed to guide the negotiation among users. Therefore, if more than two
crosscutting concerns exist in a given match point, with negative contribution and the same priority,
we start by analysing two concerns first to identify the dominant, then take the dominant and analyse it
with a third concern and so forth until we have taken into consideration all the crosscutting concerns.
187

The result is the concern with higher priority between them all. Next we need to identify the second
dominant crosscutting concern among the remaining concerns, and so forth until we have a
dependency hierarchy between all the concerns.
The following subtask builds composition rules. One composition rule must be defined for each match
point. Therefore, the composition rule defines the order in which the concerns will be applied in a
particular match point. It takes the form: . Knowing the
importance of the composition task, we tried to define a rigorous composition language. Our goal was
to reuse and adapt concepts already explored in formal specification languages. We liked the process
part of LOTOS and ended up with the following subset of its main operators (Brinksma, 1988). In the
descriptions below Ci denotes Concerni:
• Enabling (denoted by C 1 >>C 2 ): This is a sequential composition and means that the
behaviour of C 2 begins if and only if C 1 terminates successfully.
• Disabling (denoted by C 1 [>C 2 ): This is the disabling composition and means that C 2
interrupts the behaviour of C 1 when it starts its own behaviour. This allows the
representation of interruptions.
• Pure interleaving (denoted by C 1 |||C 2 ): This is a parallel operator and means that C 1
evolves separately from C 2 . It represents concurrent composition without interaction.
• Full synchronization (denoted by C 1 ||C 2 ): This is another parallel operator and means
that the behaviour of C 1 must be synchronized with the behaviour of C 2 . It represents
concurrent composition with interaction.
A composition rule could then be defined based on simpler composition rules, separated by one of the
above operators. Brackets (“(“ and “)”) were used to attribute priorities to the operators. This task is
still very similar to the composition rule subtask of AORA final version.
Therefore, how does the second version compares with the first one? This is described as follows:
• The overlapping, overriding and wrapping operators were substituted with the LOTOS
operators enabling, disabling, pure interleaving and full synchronization.
• The concepts of composition rule and match point were introduced to systematize the
composition task.
• Conflict management was added. The first version approach does not propose any
technique to solve conflicts. The second version proposes a process technique to solve
conflicts using the dominant concern idea.
188

• A unique template is used o specify all kinds of concerns, crosscutting and non-
crosscutting, functional and non-functional.
In summary, the novelties introduced in second version were:
• A new composition process with the introduction of match points and composition rules
using LOTOS-like operators.
• A new conflict management support with the introduction of dominant crosscutting
concerns notion.
• A step towards a multidimensional or symmetric approach.
• The use of existing catalogues to support the identification and specification tasks.
9.3 AORA third version
Around middle-2005, we were implementing the AORA tool and still trying to ameliorate the
composition and specification techniques used. We were not after a formal specification and
composition language, but we wanted to add more rigour to the specification as a whole and the
composition in particular. We needed an infrastructure that could be easily integrated with the tool
support we were planning. With the help of a master student, we started to explore the advantages of
XML to be used to define the specification and composition languages. We have chosen XML because
it is a widely used standard that allows the description of any kind of data. XML Schema is another
standard that allows the definition of a full specification for a XML document, enabling the creation of
a set of rules to structure and form that XML document, as well as rules for data types and integrity.
Furthermore, XML provides a standard way to represent and manipulate source code, and represents
meta-information that can be manipulated by another program.
This work was performed in collaboration with an MSc student, Elisabete Soeiro (Soeiro, 2007). A
first version of an XML-based language for specification and composition of aspectual concerns is
proposed in (Soeiro, 2006), extending the work presented in (Brito, 2003b; 2004). This language
proposes new elements for specification and composition of concerns, as well as, a new composition
process.
Therefore, the AORA third version offers a rigorous means to support and extend the specification and
composition activities of the previous AORA approach versions. Our template for concern
specification is mapped into an XML Schema, creating a meta-template that functions as a standard
189

epresentation. Any instance that follows the meta-template must also be correctly validated with the
defined XML Schema. The resulting XML Schema is compliant with the logic present in the concern
specification template (see Table 9.3).
Table 9.3 A template to specify concerns
Concern Description
Name The name of the concern.
Description Short description of the intended behaviour of the concern.
Sources Source of information, e.g. stakeholders, documents, domain, catalogues and
business process.
Classification Helps the selection of the most appropriate approach to specify the concern. For
example: functional, non-functional, goals.
Stakeholders Users that need the concern in order to accomplish their job.
List of Responsibilities
Responsibility # List of what the concern must perform; knowledge or proprieties the concern must
offer.
List of Contributions
Contribution # List of concerns that contribute or affect this concern. This contribution can be
positive (+) or negative (-).
List of Priorities by Stakeholder
Stakeholder # Expresses the importance of the concern for a given stakeholder. It can take the
values: Very Important, Important, Medium, Low and Very Low.
List of Required concerns
Required Concern # List of concerns needed or requested by the concern being described.
The concern specification template depicted in Table 9.3 was adapted from Table 9.2. A Responsibility
row was added to the template to refine the concerns in terms of responsibilities, i.e., to be able to
describe the concern’s behaviour.
The ”Compose Concerns” task offers now the possibility to compose a set of concerns, incrementally,
until the whole system is obtained. Each composition takes place in a match point in the form of a
composition rule. As described in AORA second version, a match point tells us which crosscutting
concerns should be composed with a given (base) concern. A composition rule shows how a set of
concerns can be composed together by means of some pre-defined operators. Similarly, we defined a
XML Schema to represent the structure of a composition rule. To do that, we first need to study all the
possible logical forms that a composition rule can take.
This AORA version was supported by a tool developed in Java, where concerns and composition rules
can be handled as defined by the XML Schema. The modules encapsulating the various concerns and
composition rules were stored in eXist, a native XML database (eXist, 2005). The tool facilitates the
specification of concerns, identification of crosscutting concerns, generation of the match point table,
definition of composition rules and locates possible conflicting situations (on match points).
190

The following two subsections give an overview of the XML representations of concerns and of the
XML composition rules, respectively.
9.3.1 The XML schema for concern specification
The XML schema for concern specification is depicted in Figure 9.3.
Figure 9.3 XML Schema of the definition of a concern
The structure of the complex type Concern that defines one concern illustrated in Figure 9.3 is:
• Name defines a unique name for the concern. Since all names in our solution are seen as
keys, uniqueness is required.
• Description presents a summary description of the behaviour of concern.
• Classification indicates if a concern is functional or not functional.
• ListOfSources lists the information sources that contributed to the concern creation.
• ListOfPrioritiesByStakeholder groups the Stakeholders and Stakeholder Priorities from the
logic template. It is a list where each element aggregates one stakeholder together with
his/her priority for the concern.
• ListOfResponsibilities lists the information of what the concern must perform.
• ListOfContributions defines the contribution relationship between the concern under study
and other concerns.
191

• ListOfRequiredConcerns defines a list of other concerns from which the current concern
depends, i.e. the concerns required by the concern under study. This list can be empty,
meaning that the concern does not need other concerns to fulfil its objectives.
The system is represented as a list of all its concerns, together with a list of composition rules.
9.3.2 The XML Schema for Composition Specifications
The “composition rule” notion is similar to the notions defined in the AORA second version. To offer
the possibility to compose a set of concerns, incrementally, until the whole system is obtained, a
composition rule takes the form:
where a Term can be a concern or a sub-composition (which is another composition rule) and the
Operator represents the operator relating both terms. The operators are the same of the AORA second
version.
Similarly to what has been done to define the concern type, the XML schema was defined to represent
composition rules. A composition rule is defined for each match point by using the MP tag that
encapsulates all its simpler composition rules. The MP tag is composed of: Name, ListOfConcerns
and ListOfCompositionRules (see Figure 9.4).
Figure 9.4 XML schema for composition in a match point
192

• Name element defines a unique name for the match point. Again, since all names in our
solution are seen as keys, uniqueness is required.
• ListOfConcerns lists the concerns that compose a given match point.
• ListOfCompositionRules represents the set of all composition rules that take part in a
match point. It is composed of CompositionRule element.
The CompositionRule element is composed of:
• A Term that can be a simpler CompositionRule or a ConcernName.
• An Operator tag defining the operators.
• An OutCome tag expressing the result of constraining the concerns’ responsibilities by
means of the operators described before.
In summary, the novelties introduced in this third version were:
• It offers a rigorous means to support and extend the specification and composition
activities using an XML-based language.
• It offers a tool to support the AORA approach.
• It uses an XML Schema to guarantee information independency between representations,
promoting traceability of concerns through the software development phases.
Looking at the AORA third version, we still have several parts to refine, extend and test. The
following tasks needed to be done and were accomplished in the final version:
• Define composition rules at a finer level of granularity, i.e. compose crosscutting actions
or behaviour with the requirements it cuts across.
• Define a visual integrated notation, probably based on UML.
• Explore how fuzzy logic can be applied to help solving conflicts that can arise when
concerns contribute negatively to each other need to coexist in the same match point.
• Improve the tool to minimize error occurrence and omissions in the systems’
requirements.
• Define an AORA metamodel to add more rigour to the AORA basic notions.
193

9.4 Major problems and their resolution
During the AORA development it was important to keep in mind that we wanted to handle
crosscutting and non-crosscutting concerns at the requirements level. During our work, we identified
the following important issues for the approach:
• Identification of crosscutting concerns.
• Representation of crosscutting and non-crosscutting concerns.
• Composition of crosscutting and non-crosscutting concerns.
• Trade-off analysis technique to solve conflicts.
• Tool support.
This section summarizes the problems we faced during the development of the AORA approach to
find solutions for the above issues and for the tasks that remained to do after the third version.
Identify crosscutting and non-crosscutting concerns. In the AORA approach the identification of
concerns is accomplished by analysing the documents available, including existing stakeholders’
interview transcripts, to understand the system domain. Further interviews to the stakeholders might
be required. These are common general ideas used by the object-oriented community, and help the
identification of functional requirements. After the application of the AORA first version, we propose
the use of existing catalogues, such as the ones developed by (Wiegers, 2003) and (Chung, 2000) to
alleviate the onus of the identification of the broadly scoped requirements. These catalogues are a
source of interesting information about concepts and terminology on non-functional requirements,
promoting reusability and are used in the AORA final version (see Chapter 4).
Typical examples of crosscutting concerns are non-functional requirements or quality attributes, such
as security, fault tolerance and persistency, because they can affect several requirements
simultaneously. However, crosscutting concerns can also be functional requirements, such as auditing,
or validation, so we need a systematic process to identify crosscutting concern, functional or non-
functional. So, in the AORA final version the identification of crosscutting concerns is accomplished
by taking into account the information in the Required Concerns row of the AORA template (see
Chapter 4). A concern is crosscutting if it is required by two or more other concerns.
Specify concerns. Because existing techniques to specify requirements, such as use cases or
viewpoints, cannot encapsulate crosscutting concerns, a technique is needed to specify all types of
concerns (Jacobson, 1992; Finkelstein, 1996). At the beginning the AORA template was used only to
194

specify a quality attributes; the functional concerns were specified using UML diagrams, such as
sequence diagrams. However, a crosscutting concern can also be a functional one, so we needed an
uniform treatment of the various types of concerns in a system. According to this, we moved to a more
“multi-dimensional” strategy i.e., a unique template was proposed to treat all the concerns in a uniform
fashion, independently of their crosscutting nature, as described in Chapter 4. So, it made sense to
think in terms of concerns, instead of kinds of concerns and the information about each concern has
been collected in that a unique template.
At the beginning of the AORA approach, we could not write a valid expression to the concern’s
behaviour. To solve this problem a Responsibility row was added to the template of the AORA final
version to refine the concerns in terms of responsibilities, i.e., to be able to describe the concern’s
behaviour.
From the very beginning, we have chosen UML to model concerns. UML 2.0 was used in the AORA
final version (see Chapter 5) for five main reasons:
• It is a standard and a general-purpose language.
• It offers extension mechanisms that allow the representation of new concepts that are not
part of the core of UML.
• It supports sequence diagrams that help us expressing concerns responsibilities to provide
a more rigorous level of refinement.
• It offers a seamless transition of concerns to the next level of the development process.
• It promotes reuse of behaviour by offering interaction occurrences.
Moreover, an extension of the UML metamodel was used to define the main specification concepts of
the AORA final version, allowing a language designer or methodologist to better capture, analyze and
understand our approach (see Chapter 4).
Another modelling technique we adopted in the AORA final version is the Softgoal Interdependency
Graphs (SIG). A SIG can be used to specify non-functional requirements Chung et al., complementing
other the visual models (Chung, 2000). A SIG is a hierarchy graph that shows the interdependencies
between softgoals (or non-functional requirements). Based on these interdependencies, we identify
concerns that can be decomposed into simpler ones.
Compose concern. Composition, apart from allowing the stakeholders, including developers, to
picture the whole system, allows them to identify conflicting situations. This offers the opportunity to
establish critical trade-offs before the architecture design is derived, supporting the necessary
195

negotiations among the stakeholders. In the first version of the AORA approach, the composition is
accomplished by “weaving” the quality attributes with the functional requirements in three different
ways: overlapping, overriding and wrapping. We compose quality attributes with functional
requirements by using both standard diagrammatic representations (e.g. use case diagram, interaction
diagrams) and by new diagrams.
In the second version of the AORA approach we introduced the notions of match point and
composition rule to promote a more rigorous and systematic composition task. The identification of
match points was accomplished based on row Interrelationships and tells us which crosscutting
concerns should be composed with a given concern. This match point definition only allows the
composition of crosscutting concerns, so this notion was substituted by another in the last AORA
version: a match point tells us which concerns, non-crosscutting or crosscutting, should be composed.
During the second version of AORA approach, we substituted the overlapping, overriding and
wrapping concepts for the composition operators inspired on LOTOS: enabling, disabling, pure
interleaving and full synchronization. The LOTOS operators inspire the composition between
concerns used in AORA approach because they show the temporal order of the composition and
because they are simpler to understand (Brinksma, 1988). However, at the AORA third version we
cannot rigorously talk about a concern’s behaviour to be able to define composition rules at a finer
level of granularity. This granularity will help us study how the concerns are mapped onto functions,
aspects or a design decision.
As well as in the specification concern task, UML 2.0 was used to model concern composition because
it supports sequence diagrams that help us expressing composition rules to provide a more rigorous
level of refinement.
Trade-off analysis. These situations were initially handled based on intuitive and very simple
reasoning methods that are error prone and do not allow a rigorous engineering approach to the
problem. The main limitations of these reasoning methods are:
• Each concern must be allocated one single different importance using intuition.
• Conflict handling is based on one criterion, the importance, not considering other
parameters that may have an impact on the decision.
• Different stakeholders may have different interests on the same concern, and the relative
importance/power of each one might be different (so their relative position might have to
be taken into account).
196

• Trade-offs must be negotiated informally with the stakeholders without any rigorous and
systematic analysis technique or tool.
• It was with these limitations in mind that we started exploring rigorous alternatives that
could be used effectively without having to rely so strongly on a single criterion
(importance), taking into consideration other possible useful information collected during
the application of the methods.
Because these processes may lead to wrong decisions, the last version of the AORA approach
proposes Multiple Criteria Decision Making methods that help us deal with these type of problems as
we described in more detail in Chapter 6 (Triantaphyllou, 2000).
Tool support. The AORA tool described in Chapter 5 is an extension of the tool described in (Soeiro,
2006). This new tool guarantees consistency and completeness of the concerns specifications and the
composition rules to minimize error occurrence and omissions in the systems’ requirements. To
accomplish this, a new XML Schema was created (for more details see Chapter 5).
Moreover, this tool:
• Traces concerns from requirements to the specification and composition of concerns,
through the History feature and Source attribute.
• Offers import and export interfaces to XML to exchange concerns’ data with other
applications.
• Helps requirements engineering and stakeholders to store and manage concern
specifications and compositions.
• Facilitates navigation through multiple views.
9.5 Conclusions
This chapter focused on the previous versions of the AORA approach. It presented the three main
versions of the AORA since the beginning of this PhD. The chapter finishes by presenting the
problems and the solutions we found during the AORA development, justifying our approach.
197

198

199
Chapter 10
Conclusions and Future Work
This chapter reviews the goals of this PhD thesis, discusses how these goals were pursued and
achieved, and suggests possible future enhancements and developments.
10.1 Summarising the goals of the thesis
The purpose of this PhD thesis was to address crosscutting and non-crosscutting concerns at the
requirements engineering level. To this end, ideas from aspect-orientation, non-functional
requirements and requirements engineering were combined and the higher-level goal subdivided into
eight sub-goals:
• Identify crosscutting concerns, functional and non-functional, in requirements documents.
• Encapsulate crosscutting concerns in separate modules, so that modularization is
promoted.
• Avoid the tyranny of the dominant decomposition symptoms by treating concerns
uniformly, independently from their intrinsic nature.
• Compose crosscutting and non-crosscutting concerns to clearly understand the
relationships among them, supporting the identification analysis of critical trade-offs early
in the development.

• Identify and rigorously resolve conflicts between concerns.
• Offer minimal support for concerns traceability.
• Develop tool support to manage concern specifications and compositions.
• Assess the approach through independent case studies and users, as well as empirically
evaluate and compare AORA with respect to other Aspect-Oriented Requirements
Engineering approaches.
10.2 Results of the thesis
This PhD work contributes to a seamless approach for aspect-orientation, supporting separation,
specification, conflict resolution and composition of crosscutting and non-crosscutting concerns at the
requirements level. To accomplish these, the Aspect-Oriented Requirement Analysis (AORA)
approach proposed process model, metamodel, techniques, guidelines and tools.
The AORA process model is proposed to identify, specify and compose crosscutting and non-
crosscutting concerns. This model is composed of three main plans: identification, specification and
composition of concerns. The identification plan is supported by a set of tasks that allows the
identification of concerns and the collection of information that is important to validate them, for
example, the identification of stakeholders and the sources. This is accomplished by analysing the
available documents, including existing stakeholders’ interview transcripts, to understand the system
domain. Further interviews to the stakeholders might be required. We also propose the use of existing
catalogues, such as the ones developed by (Wiegers, 2003) and (Chung, 2000) to alleviate the onus of
the identification of the broadly scoped requirements. These catalogues are a source of interesting
information about concepts and terminology particularly on non-functional requirements, promoting
reusability.
The specification plan, describes the identified concerns, as they are discovered, using a unique
template to treat all the concerns in a uniform fashion, independently of their intrinsic nature. This
template collects relevant information to identify conflicts and help in their resolution, through the
contribution and priority rows. Moreover, the template supports some backward traceability by using
source and stakeholder rows information. It also helps identifying crosscutting concerns, through an
analysis of the Required Concerns row in the template.
The composition plan, apart from allowing the system stakeholders, including developers, to picture
the whole system, allows them to identify conflicting situations. This offers the opportunity to
200

establish critical trade-offs before the architecture design is derived, supporting the necessary
negotiations among the stakeholders. We introduced the notions of match point and composition rule
to promote a more rigorous and systematic composition activity. The composition operators used in
the composition rules were inspired on the LOTOS operators because they show the temporal order of
the composition and because they are simple to understand (Brinksma, 1988).
The main AORA concepts were defined as an extension of the UML metamodel in Chapter 4,
allowing a language designer or methodologist to better capture, analyze and understand our approach.
A UML profile was defined to represent an instance of the AORA metamodel.
A tool to support AORA was developed, facilitating the specification of concerns, the identification of
crosscutting concerns, the definition of composition rules and the generation of the match points table.
The tool guarantees consistency of the concerns’ specifications and the composition rules, minimizing
error occurrence and requirements omissions. It also offers import and export interfaces to XML to
exchange concerns’ data with other applications. Finally, the multiple views facilitate the navigation
within the approach.
A set of guidelines were proposed to support horizontal forward traceability. Horizontal forward
traceability is achieved by relating the concern specifications and the composition rules to design
artefacts using guidelines to build UML models and record this information in traceability matrices.
Each element of the concern template may be mapped onto one or more UML model elements. Tool
functionalities were proposed to support backward horizontal traceability as well as vertical
traceability. The tool helps tracing concerns from requirements to the specification and composition
rules through the History feature and the Source attribute, as well, as tracing concern relationships.
Thanks to these guidelines and the tool functionalities, our approach promotes better understanding of
concerns and supports stakeholders’ validation of specifications and compositions.
AORA conflict management is handled during composition, where conflicting situations may emerge
in a given match point. In this context, a conflict occurs any time two or more concerns that contribute
negatively to each other, and have the same priority, need to be composed in the same match point. It
is important to understand well each concern, study the level of impact that each one may have on
others and decide on their relative importance before any solution decision is made.
The AORA conflict management method explained in Chapter 6 uses a particular multi-criteria
analysis method, the Analytical Hierarchical Process proposed by Saaty, to find, given a set of
alternatives and a set of decision criteria, the best alternative for a given problem (Saaty, 1980). Such a
technique is not only useful in the context we have described here, but it looks very promising as a
201

tool to support architectural choices during the software architecture design. We also compared
Analytical Hierarchical Process with a classical weighted average method (Triantaphyllou, 2000) and
the results proved that selecting the appropriate Multi-Criteria Decision Making is always a question
of trade-offs between advantages of each method (Brito, 2007). In this work we noticed that the
Analytical Hierarchical Process method ensures more psychological robustness in classifying the
concerns, logical consistency and better interpretability at the expense of longer time to formulate and
calculate the results (Brito, 2007).
The evaluation strategy described in Chapter 7 highlights the strengths and weakness of AORA.
According to the results of the evaluation, AORA seems one of the most complete AORE approaches,
when compared with other four AORE approaches. The application of AORA approach to real case
studies in the context of the SOFTAS and ASSD projects indicates that this approach reaching some
maturity (ASSD, 2006; SOFTAS, 2007).
Model-Driven Development (MDD) technologies are explored to refine AORA, preparing it for an
integrated MDD development, in Chapter 8. The idea was to refine AORA according to the MDD
principles so that transformations can later be used to derive new models for the following
development stages. The difficulties in obtaining the first model from where transformations can then
be applied to evolve the models are well-acknowledged (Kovacevic, 2007). This proposal contributed
with a modest step forward towards helping solving this problem. From the AORA perspective only,
the use of MDD also brings added value to our results, since: (i) the AORA concepts and their
relationships are described more rigorously, and, finally (ii) the approach is now prepared to be used in
a seamless MDD development framework. The AORA refinement is accomplished via the concerns’
specification and composition source metamodel packages described in Chapter 4. A set of guidelines
are applied to these source metamodel packages to obtain new metamodel elements that support the
AORA target metamodel. An extension of the AORA UML profile is proposed to instantiate the
metamodels and to obtain concrete AORA models.
We illustrate the AORA approach, the guidelines for forward traceability, the tool and the application
of the Analytical Hierarchical Process and weighted average methods by using the Subway system
case study.
10.3 Future work on AORA
There is still room to improve AORA. On the one hand, the identification of concerns, which was
never our goal to automate, could be improved by using natural language processing tools to mine
202

frequently used terms and semantically meaningful relationships to support semantic-based
composition, instead of syntactic composition. Consequently, this would help the identification of
crosscutting concerns, in particular the ability to identify crosscutting functional concerns.
Another area of further research is related to conflict management. Explore other methods from both
the crisp and fuzzy multi-criteria domains to assess which method is more appropriate to solve other
kinds of conflicts that could emerge at the requirements level. Moreover, we need to explore other
methods to identify other kinds of conflicts that could emerge at requirements level. At this moment,
Aspect Oriented Requirements approaches improve concerns composition though interactions and
these interactions could be either about temporal dependencies between requirements (or concerns), or
some kind of semantic interdependency (Chitchyan, 2007b). Once such dependencies are expressed,
these interrelationships can be analyzed for identify temporal and semantic conflicts.
In what concerns tool support, the AORA tool needs to be extended to incorporate a parser to integrate
a reference model to support forward traceability. Adopting a reference traceability metamodel would
greatly help this activity.
Finally, we also need to study how the level of granularity and dependency between concerns can
influence the decision process. The refinement of concerns will help us study the level of granularity at
which a conflicting situation can be handled. We already started to tackle this problem by refining
concerns and their responsibilities so that composition rules can be defined at a finer granularity level.
Our first attempt at preparing AORA for a model-driven development approach is still to develop
further. As pointed out in the future work listed in Chapter 8.
10.4 Final remarks
There are currently a significant number of aspect-oriented requirements approaches. The approach
presented here undertakes some of the aspect-requirements engineering goals and principals, which
have been neglected by some approaches, such as treating all kinds of requirements systematically.
More needs to be done to improve identification, specification and composition of crosscutting
concerns, as well as traceability to the next stages of the development process. AORA, with its
associated process, techniques and tool, supports some of the identification, specification, composition
and conflict management problems.
203

We have shown that it is possible to bridge the gap left by the traditional requirements engineering
approaches by providing systematic means for the identification, modularization, representation and
composition of crosscutting requirements, both functional and non-functional.
The idea for this PhD work was born in 2000 when I approached my supervisor in a conference
requesting a topic for my PhD. Aspect-Oriented Requirements Engineering was then a novel idea and,
as far as we knew, nobody else was addressing the topic yet. For a couple years, AORA was a hot and
innovative topic. Later, around 2003, other researchers started working on the topic, giving birth to the
Early-Aspects movement (www.early-aspects.net), and many more joined the field in coming years.
During all this time, I have done my research while being a full-time lecturer at Instituto Politécnico
de Beja. Initially I thought I could count with one year leave from teaching and dedicate myself to this
work. That period was later reduced to one semester. At the end, I couldn’t count with that semester
either and ended up having to substitute a colleague that fell sick.
So, knowing the difficulties in finding free time for this research, my supervisor suggested I should
start working and register as a PhD student only later. I have followed her advice and submitted the
PhD plan in 2002 and later registered as a PhD student in 2004.
Personally, at the end of these five years of research, I realize that a thesis is never strictly finished.
There are many things that are left to be done and the project could last forever. However, my personal
goals are achieved. I have acquired new knowledge and gained new experiences through the projects
related to AORA in which I was involved along the time. From the challenges that are still left to
investigate in the near future, I would definitely choose to invest my energy on contributing to a
seamless model-driven development from AORA and on conflict management.
204

205
References
ACM (2001). "Special Issue on Aspect-Oriented Programming." Communications of the ACM.
44(10).
Agostinho, S. (2006). Aspect Specification for the Space Domain and Aspect Development Assistant
Tools. Master dissertation. Faculdade de Ciências da Universidade Nova de Lisboa. Portugal.
http://aosd.di.fct.unl.pt/sergioag/dissertation.html.
Alves, C., Finkelstein, A. (2003). "Investigating Conflicts in COTS Decision-Making." International
Journal of Software Engineering & Knowledge Engineering. 13(5): 1-21.
Annett, J. (2004). Hierarchical Task Analysis: The Handbook of Task Analysis for Human-Computer
Interaction. Diaper, D., Stanton, N. (eds). 67-82.
AOSD-European Network of Excellence (2007). http://www.aosd-europe.net/.
Araújo, J., Baniassad, E., Clements, P., Moreira, A., Rashid, A., Tekinerdogan, B. (2005). Early
Aspects: The Current Landscape. TR: CMU/SEI-2005-TN-xxx. http://trese.cs.utwente.nl/early-
aspects-AOSD2005/Papers/EarlyAspects-LandscapePaper-FirstDraft-2005.pdf.
Araújo, J., Whittle, J., Kim, D. (2004). Modeling and Composing Scenario-Based Requirements with
Aspects. In 12th Requirements Engineering Conference (RE'04), Kyoto, Japan, IEEE Computer
Society. 58-67.
AspectC Project (2007). http://www.cs.ubc.ca/labs/spl/projects/aspectc.html.
AspectJ Project (2007). http://www.eclipse.org/aspectj/.
ASSD (2006). Aspect Specification for the Space Domain project.
http://www2.uninova.pt/ca3/en/project_ASSD.htm.
Baniassad, E., Clarke, S. (2004). Theme: An Aproach for Aspect-Oriented Analysis and Design. In
26th International Conference on Software Engineering (ICSE'04), Edinburgh, Scotland, IEEE
Computer Society. 158-167.

Baniassad, E., Clarke, S. (2004a). Finding Aspects in Requirements with Theme/Doc. In Early
Aspects Workshop: Aspect-Oriented Requirements Engineering and Architecture Design at 3rd
Aspect-Oriented Software Development International Conference (AOSD'04), Lancaster, UK.
http://trese.cs.utwente.nl/workshops/early-aspects-2004/Papers/Baniassad-Clarke.pdf.
Baniassad, E., Clements, P., Araújo, J., Moreira, A., Rashid, A., Tekinerdogan, B. (2006).
"Discovering Early Aspects." IEEE Software Special Issue on Aspect-Oriented Programming. 23(1):
61-70.
Barais, O., Cariou, E., Duchien, L., Pessemier, N., Seinturier, L. (2004). TranSAT: A Framework for
the Specifcation of Software Architecture Evolution. In Coordination and Adaptation Techniques for
Software Entities Workshop at 18th European Conference on Object-Oriented Programming
(ECOOP'04), Oslo, Norway.
http://wcat04.unex.es/papers/04_barais_cariou_duchien_pessemier_seinturier.pdf.
Bell, D. (2004). UML's Sequence Diagram, IBM. http://www-
106.ibm.com/developerworks/rational/library/3101.html.
Berg, K., Conejero, J. (2005). A Conceptual Formalization of Crosscutting in AOSD. In Workshop on
Aspect-Oriented Software Development at X Jornadas de Ingenieria del Software y Bases de Datos
(JISBD'05), Granada, Spain.
http://trese.cs.utwente.nl/publications/files/0367VanDenBerg%20Conceptual%20Formalization%20Cr
osscutting-Final.pdf.
Bergmans, L., Aksit, M. (2000). Composing Software from Multiple Concerns: A Model and
Composition Anomalies. In Multi-Dimensional Separation of Concerns in Software Engineering
Workshop at 22nd International Conference on Software Engineering (ICSE'00), Limerick, Ireland,
http://www.research.ibm.com/hyperspace/workshops/icse2000/papers-index.htm.
Bézivin, J. (2005). Tutorial on Model Driven Engineering: Principels, Scope, Deployments and
Applicability. International Summer School, Generative and Transformational Technique in Software
Engineering, Braga, Portugal.
Boehm, B., Bose, P., Horowitz, E., Ming-June, L. (1994). Software Requirements as Negotiated Win
Conditions. In 1st Requirements Engineering Conference (RE'94), Colorado Springs, USA, IEEE
Computer Society. 74-83.
206

Boehm, B., Hoh, I. (1996). "Identifying Quality-Requirement Conflicts." IEEE Software Journal.
IEEE Computer Society. 13(2): 25-35.
Boehm, B., Madachy, R. (1998). "Using the WinWin Spiral Model: A Case Study." IEEE Computer
Journal. IEEE Computer Society. 31(7): 33-44.
Brackett, J. (1990). Software engineering. Software Engineering Institute, Carnegie Mellon
University. TR: SEI-CM-19-1.2, ADA235642. http://gd.tuwien.ac.at/softeng/sei/sei.documents.pdf.
Brinksma, E. (1988). Information Processing Systems -- Open Systems Interconnection -- LOTOS: A
Formal Description Technique Based on the Temporal Ordering of Observational Behaviour. ISO
8807.
Brito, I., Moreira A. (2004). Integrating the NFR approach in a RE model. In Early Aspects
Workshop: Aspect-Oriented Requirements Engineering and Architecture Design at 3rd Aspect-
Oriented Software Development Conference (AOSD'04), Lancaster, UK.
http://trese.cs.utwente.nl/workshops/early-aspects-2004/Papers/BritoMoreira.pdf.
Brito, I., Moreira, A. (2003a). Towards a Composition Process for Aspect-Oriented Requirements. In
Early Aspects Workshop: Aspect-Oriented Requirements Engineering and Architecture Design at 2nd
Aspect-Oriented Software Development Conference (AOSD'03), Boston, USA.
http://www.cs.bilkent.edu.tr/AOSD-EarlyAspects/Papers/BritoMoreira.pdf.
Brito, I., Moreira, A. (2003b). Advanced Separation of Concerns for Requirements Engineering. In
VIII Jornadas de Ingeniería del Software y Base de Datos (JISBD'03), Alicante, Spain. 47-56.
Brito, I., Moreira, A., Araújo, J. (2002). A Requirements Model to Quality Attributes. In Early
Aspects Workshop: Aspect-Oriented Requirements Engineering and Architecture Design at 1st
Aspect-Oriented Software Development Conference (AOSD'02), Enschede, The Netherlands.
http://trese.cs.utwente.nl/AOSD-EarlyAspectsWS/Papers/Brito.pdf.
Brito, I., Moreira, A., Araújo, J. (2006a). Towards an Integrated Approach for Aspectual
Requirements. In 14th IEEE Requirements Engineering Conference (RE'06), Minneapolis, USA, IEEE
Computer Society. 334 - 335.
Brito, I., Moreira, A., Araújo, J. (2006b). Tool Support for Aspect-Oriented Requirements. In 10th
IASTED International Conference on Software Engineering and Applications (SEA'06), Dallas,
Texas, USA, Acta Press. http://www.actapress.com/Abstract.aspx?paperId=28877.
207

Brito, I., Vieira, F., Moreira, A., Ribeiro, R. (2007). "Handling Conflicts in Aspectual Requirements
Compositions." Transaction on Aspect-Oriented Software Development Special Issue on Early
Aspects, Lecture Notes in Computer Science, Springer. 4620: 144-166.
CAESAR (2007). http://caesarj.org/.
Chen, S., Hwang, C., Hwang, F. (1992). Fuzzy Multiple Attribute Decision Making: Methods and
Application. 9780387549989. Springer-Verlag.
Chitchyan, R., Rashid, A.,Waters, R., Brito, I., Moreira, A., Araújo, J. (2007b). Requirements-Level
Aspectual Trade-off Analysis Approach. TR:AOSD-Europe-ULANC-28. http://www.aosd-
europe.net/deliverables/d74.pdf.
Chitchyan, R., Rashid, A., Rayson, P.,Waters, R. (2007a). Semantics-Based Composition for Aspect-
Oriented Requirements Engineering. In 6th Aspect-Oriented Software Development Conference
(AOSD'07), Vancouver, Canada, ACM Press. 36-48.
Chitchyan, R., Rashid, A., Sawer, P., Garcia, A., Alarcon, M., Bakker, J., Tekinerdogan, B., Clarke,
S., Jackson, A. (2005). Survey of Analysis and Design Approaches. TR: AOSD-Europe-ULANC-9.
http://www.comp.lancs.ac.uk/computing/aose/papers/d11.pdf.
Chitchyan, R., Sampaio, A., Rashid, A., Sawer, P., Khan, S. (2006). Initial Version of Aspect-Oriented
Requirements Engineering Model. TR: AOSD-Europe-ULANC-17. http://www.aosd-
europe.net/deliverables/d36.pdf.
Chung, L., Nixon, B. (1995). Dealing with Non -Functional Requirements: Three Experimental
Studies of a Process-Oriented Approach. In 17th International Conference on Software Engineering
(ICSE'95), Seattle, USA, ACM Press. 25-37.
Chung, L., Nixon, B., Yu, E., Mylopoulos, J. (2000). Non-Functional Requirements in Software
Engineering. 0-7923-8666-3. Kluwer Academic Publishers.
Clarke, S., Baniassad, E. (2005). Aspect-Oriented Analysis and Design: The Theme Approach. 978-
0321246745. Addision-Wesley.
Clarke, S., Walker, R. (2001). Composition Patterns: An Approach to Designing Reusable Aspects. In
23rd International Conference on Software Engineering, (ICSE'01), Ontario, Canada, ACM Press. 5-
14.
Composition Filters Project (2007). http://trese.cs.utwente.nl/oldhtml/composition_filters/.
208

Cornell, K., Funk, E., Nguyen, D., Ruest, D. (2007). Dynamically Configurable Model-to-Model
Transformation Engine, http://www.freshpatents.com/Dynamically-configurable-model-to-model-
transformation-engine-dt20060615ptan20060130009.php.
Costello, R., Liu, D. (1995). "Metrics for Requirements Engineering." Journal of Systems and
Software. 29(1): 39-63.
Dardenne, A., Van Lamsweerde, A., Fickas, S. (1993). "Goal-Directed Requirements Acquisition."
Science of Computer Programming Journal. ACM Press. 20(1-2): 3-50.
Dijkstra, E. (1976). A Discipline of Programming. 0-13-215871-X. Prentice-Hall.
Dong, W., Wong, F. (1987). "Fuzzy Weighted Averages and Implementation of the Extension
Principle." Fuzzy Sets and Systems. ACM Press. 21(2): 183-199.
Dusire, S., Flynn, M., Dardenne, N. (2002). Requirements Engineering: Applying Theory to Reality.
In 10th Requirements Engineering Conference (RE'02), Essen, Germany, IEEE Computer Society.
300-302.
Ebert, C., Dumke, R., Bundschuh, M., Schmietendorf, A. (2005). Best Practices in Software
Measurement. How to Use Metrics to Improve Project and Process Performance. 3-540-20867-4.
Springer.
eXist (2005). http://exist.sourceforge.net/.
Fernandes, L. (2005). An Aspect-Oriented Approach to Model Requirements. In 13th Requirements
Engineering Conference (RE'05), Doctoral Consortium, Paris, France. http://www.inf.puc-
rio.br/~lyrene/silva_dc-re2005.pdf.
Ferreira, R., Moura-Pires, J. (2007). Extensible Metadata Repository for Information Systems and
Enterprise Applications. In 9th International Conference on Enterprise Information Systems
(ICEIS'07), Funchal, Portugal. 344-350.
Ferreira, R., Raminhos, R., Moreira, A. (2005). Metadata Driven Aspect Specification. In Workshop
on Aspect Oriented Modeling at 8th Model Driven Engineering Languages and Systems Conference
(MoDELS'05), Montego Bay, Jamaica. http://dawis2.icb.uni-
due.de/events/AOM_MODELS2005/Ferreira.pdf.
Filman, R., Elrad, T., Clarke, S., Aksit, M. (2005). Aspect-Oriented Software Development. 0.321-
21976-7. Addison-Wesley.
209

Finkelstein, A., Sommerville, I. (1996). "The Viewpoints FAQ." Software Engineering Journal:
Special Issue on Viewpoints for Software Engineering. IEE/BCS. 11(1): 2-4.
France, R., Ghosh, S. (2004). "A UML-Based Pattern Specification Technique." IEEE Transactions on
Software Engineering. IEEE Computer Society. 30(3): 193-207.
France, R., Rumpe, B. (2007). Model-Driven Development of Complex Software: A Research
Roadmap. In Future of Software Engineering Conference, Minneapolis, USA, IEEE Computer
Society. 37-54.
Garcia, A., Sant'Anna, C., Chavez, C., Silva, V., Lucena, C., Von Staa, A. (2004). "Separation of
Concerns in Multi-Agent Systems: An Empirical Study." Software Engineering for Multi-Agent
Systems II. Lecture Notes in Computer Science, Springer. 2940: 49-72.
Garcia, A., Sant'Anna, C., Figueiredo, E., Kulesza, U., Lucena, C., Von Staa, A. (2005). Modularizing
Design Patterns with Aspects: a Quantitative Study. In 4th Aspect-Oriented Software Development
Conference (AOSD'04), Chicago, USA, ACM Press. 3-14.
Geldermann, J., Spengler, T., Rentz, O. (2000). "Fuzzy Outranking for Environmental Assessment.
Case Study:Iron and Steel Making Industry." Fuzzy Sets and Systems Journal. Elsevier. 115(1): 45-65.
Gilb, T., Graham, D. (1993). Software Inspection. 0-201-63181-4. Addison-Wesley.
Glinz, M., Wieringa R. (2007). "Stakeholders in Requirements Engineering." IEEE Software. IEEE
Computer Society. 24(2): 18-21.
Gotel, O., Finkelstein, A. (1994). An Analysis of the Requirements Traceability Problem. In 1st
Requirements Engineering Conference (RE'94), Colorado, USA. IEEE Computer Society. 94-102.
Grundy, J. (1999). Aspect-oriented Requirements Engineering for Component-based Software
Systems. In 4th Requirements Engineering Conference (RE'99), Limerick , Ireland, IEEE Computer
Society. 84-91.
Hailpern, B., Tarr, P. (2006). "Model-Driven Development: The Good, the Bad, and the Ugly." IBM
System Journal. 45(3).
Harrison, W., Ossher, H.,Tarr, P. (2002). Asymmetrically vs. Symmetrically Organized Paradigms for
Software Composition. IBM Research Division. TR: RC22685.
http://domino.watson.ibm.com/library/cyberdig.nsf/papers/2A4097E93456D0CF85256CA9006DAC2
9/$File/RC22685.pdf.
210

Herrero, J., Sánchez, F., Lucio, F., Toro, M. (2000). Introducing Separation of Aspects At Design
Time. In Aspects and Dimensions of Concerns Workshop at 14th European Conference on Object-
oriented Programming (ECOOP'00), Cannes, France.
Hunter, J., McLaughlin, B. (2005). Easy Java/XML integration with JDOM.
http://www.javaworld.com.
HyperJ (2007). http://www.alphaworks.ibm.com/tech/hyperj.
IEEE 610.12 (1990). IEEE Standard Glossary of Software Engineering Terminology. IEEE Computer
Society.
http://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf?isnumber=4148&prod=STD&arnumber=1593
42&arSt=&ared=&arAuthor=.
IEEE 1471 (2000). IEEE Recommended Practice for Architectural Description of Software-Intensive
Systems. IEEE Computer Society. http://www.enterprise-
architecture.info/Images/Documents/IEEE%201471-2000.pdf.
Jacobson, I., Booch, G., Rumbaugh, J. (1998). The Unified Software Development Process. 0-201-
57169-2. Addison Wesley.
Jacobson, I., Chirsterson, M., Jonsson, P., Overgaard, G. (1992). Object-Oriented Software
Engineering - a Use Case Driven Approach. 978-0201544350. Addison-Wesley.
Jacobson, I., Ng, PW. (2004). Aspect-Oriented Software Development with Use Cases. 978-0-321-
26888-4. Addison-Wesley.
JAsCo Project (2007). http://ssel.vub.ac.be/jasco/.
JBoss Project (2007). http://labs.jboss.com/jbossaop/.
Karlsson, J. (1995). Towards a Strategy for Software Requirements Selection. PhD Thesis. Linköping
University. Sweden.
Karlsson, J., Ryan K. (1997). "A Cost-Value Approach for Prioritizing Requirements." IEEE
Software. IEEE Computer Society. 14(5): 67-74.
Kazman, R., Klein, M., Clements, P. (2000). ATAM: Method for Architecture Evaluation. Software
Engineering Institute, Carnegie Mellon. CMU/SEI-2000-TR-004.
http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr004.pdf.
211

Kiczales, G. (2003). The Fun Has Just Begun. In 2nd Aspect Oriented Software Development
Conference (AOSD'03), Boston, USA.
http://www.nitrd.gov/subcommittee/sdp/vanderbilt/position_papers/gregor_kiczales_aspect_oriented_
programming.pdf.
Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., Irwin, J. (1997).
Aspect-Oriented Programming. In 11th European Conference Object-Oriented Programming
(ECOOP'97), Jyvaskyla, Finland, Lecture Notes on Computer Science 1241. Springer. 220-242.
Kotonya, G. (1999). "Practical Experience with Viewpoint-Oriented Requirements Specification."
Requirements Engineering Journal. Springer. 4(3): 115-133.
Kovacevic, J., Aferez, M., Kulesza, U., Moreira, A., Araujo, J., Amaral, V., Alves, V., Rashid, A.,
Chitchyan, R. (2007). Survey of the State-of-the-Art in Requirements Engineering for Software
Product Line and Model-Driven Requirements Engineering. AMPLE Project. TR: AMPLED1.1.
http://ample.holos.pt/gest_cnt_upload/editor/File/public/Deliverable%20D1.1.pdf.
Laddad, R. (2002). I want my AOP!, JavaWorld. http://www.javaworld.com/javaworld/jw-01-
2002/jw-0118-aspect.html?page=2.
Lieberherr, K., Orleans, D., Ovlinger, J. (2001). "Aspect-Oriented Programming with Adaptive
Methods." Comunication of the ACM. ACM Press. 44(10): 39-41.
Malan, R., Bredemeyer, D. (2002). Functional Requirements and Use Cases,
http://www.bredemeyer.com/papers.htm.
MDSoC (2007). MDSOC: Software Engineering Using Hyperspaces, IBM Research.
http://www.research.ibm.com/hyperspace/.
Mehner, K. (2006). On Using Metrics in the Evaluation of Aspect-Oriented Programs and Designs. In
Linking Aspect Technology and Evolution Workshop at 5th Aspect-Oriented Software Development
Conference (AOSD'06), Bonn, Germany.
http://www.aosd.net/workshops/late/2006/later/submissions/mehner.pdf.
Metamodel.com (2007). What is a metamodeling?,
http://www.metamodel.com/staticpages/index.php?page=20021010231056977.
212

Moreira, A., Araújo, J., Brito, I. (2002). Crosscutting Quality Attributes for Requirements
Engineering. In 14th Software Engineering and Knowledge Engineering Conference (SEKE'02),
Ischia, Italy, ACM Press. 167 - 174.
Moreira, A., Araújo, J., Whittle, J. (2006). Modeling Volatile Concerns as Aspects. In 18th Advanced
Information Systems Engineering Conference (CAISE'06), Luxembourg, Luxembourg, Lecture Notes
in Computer Science 4001. Springer. 544-558.
Moreira, A., Fiadeiro, J., Andrade L. (2003). Evolving Requirements Through Coordination
Contracts. In 15th Advanced Information Systems Engineering Conference (CAISE’03), Lecture
Notes in Computer Science 2681. Springer. 633-646.
Moreira, A., Rashid, A., Araújo, J. (2005a). Multi-dimensional Separation of Concerns in
Requirements Engineering. In 13th Requirements Engineering Conference (RE'05), Paris, France,
IEEE Computer Science. 285-296.
Moreira, A., Rashid, A., Araújo, J. (2005b). Concern-Oriented Requirements Engineering Model. In
17th Advanced Information Systems Engineering Conference (CAISE'05), Porto, Portugal, Lecture
Notes in Computer Science 3520. Springer. 293-308.
Mussbacher, G., Amyot, D., Araújo, J., Moreira, A., Weiss, M. (2007). Visualizing Aspect-Oriented
Goal Models with AoGRL. 2nd International Workshop on Requirements Engineering Visualization at
15th Requirements Engineering Conference (RE'07), New Delhi, India.
http://csis.pace.edu/~ogotel/professional/REV07.html.
Mylopoulos, J., Chung, L., Nixon, B. (1992). "Representing and Using Non-Functional Requirements
Engineering: A Process-Oriented Approach." IEEE Transactions on Software Engineering. IEEE
Computer Society. 18(6): 483-497.
Nord, R., Wood, W., Clements, P. (2004). Integrating the Quality Attribute Workshop and the
Attribute-Driven Design Method. Software Engineering Institute, Carnegie Mellon. CMU/SEI-2004-
TN-017. http://stinet.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA443486.
Nuseibeh, B., Easterbrook, S. (2000). Requirements Engineering: A Roadmap. In 22nd International
Conference on Software Engineering (ICSE'00), Limerick, Ireland, ACM Press. 35-46.
OMG (2005). UML Superstructure Specification v2.0, OMG Document number formal/05-07-04,
http://www.omg.org/docs/formal/05-07-04.pdf.
213

OMG, Catalog of UML Profile Specifications (2007).
http://www.omg.org/technology/documents/profile_catalog.htm.
OMG/MOF2.0 (2002). OMG document AD/2002-04-10, http://www.omg.org.
Pinto, M., Fuentes, L., Troya, J. (2003). DAOP-ADL: An Architecture Description Language for
Dynamic Component and Aspect-Based Development. In 2nd Generative Programming and
Component Engineering Conference, Erfurt, Germany, Springer. 118-137.
Pleeger, S., Bohner, S. (1990). A Framework for Software Maintenance Metrics. In Software
Maintenance Conference, San Diego, USA, IEEE Computer Society. 320-327.
Pressman, R. (2005). Software Engineering - A Practitioner's Approach. 6th Edition. 007-123840-9.
McGraw Hill.
Rashid, A., Moreira A. (2006b). Domain Models are NOT Aspect Free. In 9th Model Driven
Engineering Languages and Systems Conference (MoDELS/UML'06). Genova, Italy, Lecture Notes in
Computer Science 4199. Springer. 155-169.
Rashid, A., Moreira, A., Araújo, J. (2003). Modularization and Composition of Aspectual
Requirements. In 2nd Aspect-Oriented Software Development Conference (AOSD'03), Boston, USA,
ACM Press. 11-20.
Rashid, A., Moreira, A., Araújo, J., Tekinerdogan, B., Baniassad, E., Clements, P. (2006a). Early
Aspects.Net. http://www.early-aspects.net/.
Rashid, A., Moreira, A., Tekinerdogan, B. (2004). "Editoral Early Aspects: Aspect-Oriented
Requirements Engineering and Architecture Design." IEE - Proceedings Software. IEE. 151(4): 153-
156.
Rashid, A., Sawyer, P., Moreira, A., Araújo, J. (2002). Early Aspects, A Model for Aspect Oriented
Requirements Engineering. In 10th Requirements Engineering Conference (RE'02), Essen, Germany,
IEEE Computer Society. 199-202.
Robinson, W., Pawlowski, S., Volkov, V. (2003). "Requirements Interaction Management." ACM
Computing Surveys. 35(2): 132-190.
Robinson, W., Volkov, S. (1999). Conflict-Oriented Requirements Restructuring. Georgia State
University. TR: GSU CIS Working Paper 99-5. http://cis.gsu.edu/~wrobinso/papers/GSUwp99-5.pdf.
214

Ross, D., Goodenough, J., Irvine, C. (1975). "Software Engineering: Processes, Principles, and Goals."
IEEE Computer. IEEE Computer Society. 8(5): 17-27.
Saaty, T. (1980). The Analytic Hierarchy Process. 0-07-054371-2. McGraw-Hill.
Sampaio, A., Chitchyan, R., Rashid A. (2005). EA-Miner: A Tool for Automating Aspect-Oriented
Requirements Identification. In 20th Automated Software Engineering Conference (ASE'05), ACM
Press. 352-355.
Sanchez, P., Magno, J., Fuentes, L., Moreira, A., Araújo, J. (2006). Towards MDD transformations
from Aspect-Oriented Requirements into Aspect-Oriented Architecture. In 3rd European Workshop on
Software Architecture (EWSA'06), Nantes, France, Lecture Notes in Computer Science 4344. 159-
174.
Sant’Anna, C., Garcia, A., Chavez, C., Lucena, C., Von Staa, A. (2003). On the Reuse and
Maintenance of Aspect-Oriented Software: An Assessment Framework. In XVII Brazilian Symposium
on Software Engineering, Amazonas, Brasil. 19-34. ftp://ftp.inf.puc-
rio.br/pub/docs/techreports/03_26_santanna.pdf.
Schneider, G., Winters, J. (1998). Applying Use Cases – A Practical Guide. 978-0201309812.
Addison-Wesley.
SEI, Software Engineering Institute (2007). Domain Engineering: A Model-Based Approach,
http://www.sei.cmu.edu/domain-engineering/domain_engineering.html.
Selic, B. (2003). "The Pragmatics of Model-Driven Development." IEEE Software. IEEE Computer
Society. 20(5): 19-25.
Soares, S., Borba, P. , Laureano, E. (2006). "Distribution and Persistence as Aspects." Software:
Practice & Experience. 36(7): 711-759.
Soeiro, E. (2007). Especificação e Composição de Requisitos Aspectuais. Master Thesis, Faculdade de
Ciências da Universidade Nova de Lisboa. Portugal.
Soeiro, E., Brito I., Moreira A. (2006). An XML-Based Language for Specification and Composition
of Aspectual Concerns. In 8th International Conference on Enterprise Information Systems
(ICEIS'06). Paphos, Cyprus. 410-419.
SOFTAS (2007). Software Development with Aspects, http://aosd.di.fct.unl.pt/softas/.
215

Sommerville, I. (2004). Software Engineering. 5th Edition. 0321210263. Pearson Education.
Sommerville, I., Sawyer, P. (1997b). Requirements Engineering - A Good Practice Guide. 978-
0471974444. John Wiley.
Sommerville, I., Sawyer, P., Viller, S. (1997a). Viewpoints: Principles, Problems and a Practial
Approach to Requirements Engineering. Lancaster University. TR: CSEG/15/1997. http://www.cs.st-
andrews.ac.uk/~ifs/Research/Publications/Papers-PDF/1995-99/VPsAnnalsOfSE.pdf.
Spinczyk, O., Lohmann, D., Urban, M. (2005). "AspectC++: an AOP Extension for C++." Software
Developer's Journal 1: 68-76.
Stahl, T., Voelter, M. (2006). Model-Driven Software Development: Technology, Engineering,
Management. 978-0470025703. John Wiley.
Stein, D., Hanenberg, S., Unland, R. (2002). Designing Aspect-Oriented Crosscutting in UML. In
Aspect-Oriented Modeling with the UML Workshop at 1st Aspect-Oriented Software Development
Conference (AOSD'02), Enschede, The Netherlands, http://lglwww.epfl.ch/workshops/aosd-
uml/Allsubs/Dominik.pdf.
Sun (2005). J2SE 1.5.0, http://java.sun.com/j2se/1.5.0/.
Sutton Jr, S., Rouvellou, I. (2002c). Modeling of Software Concerns in Cosmos. In 1st Aspect-
Oriented Software Development Conference (AOSD'02), Enschede, Netherlands, ACM. 127-133.
Sutton Jr, S., Rouvellou, I. (2004). Concern Modeling for Aspect-Oriented Software Development.
Chapter of Aspect-Oriented Software Development Book, Addison-Wesley.
Sutton Jr, S., Tarr, P. (2002a). Aspect-Oriented Design Needs Concern Modeling. In Aspect Oriented
Design Workshop: Identifying, Separating & Verifying Concerns in the Design at 1st Aspect-Oriented
Software Development Conference (AOSD'02), Enschede, The Netherlands.
http://www.iit.edu/~akkawif/workshops/AOSD2002/AOSD1.html.
Suzuki, J., Yamamoto, Y. (1999). Extending UML with Aspects: Aspect Support in the Design Phase.
In Object-Oriented Technology Workshop at 13th European Conference on Object-Oriented
Programming (ECOOP'99), Lisbon, Portugal, Lecture Notes In Computer Science 1743. Springer.
299-300. http://trese.cs.utwente.nl/aop-ecoop99/papers/suzuki.pdf.
TAO Project (2007). TAO: A Testbed for Aspect Oriented Software Development.
http://www.comp.lancs.ac.uk/research/projects/project.php?pid=215.
216

Tarr, P., Ossher, H., Harrison, H., Sutton Jr, S. (1999). N Degrees of Separation: Multi-Dimensional
Separation of Concerns. In 21th International Conference on Software Engineering (ICSE'99),
Ontario, Canada, IEEE Computer Society. 107-119.
Tekinerdogan, B. (2004). ASAAM: Aspectual Software Architecture Analysis Method. In 4th
Working IEEE/IFIP Conference on Software Architecture (WICSA'04), Oslo, Norway. 5-14.
http://www.cs.bilkent.edu.tr/AOSD-EarlyAspects/Papers/Tekinerdogan.pdf.
Triantaphyllou, E. (2000). Multi-Criteria Decision Making Methods: A Comparative Study. 978-
0792366072. Kluwer Academic Publishers.
UML (2004). Unified Modeling Language Specification v. 2.0 in Object Management Group,
http://www.omg.org.
VanLamsweerde, A. (2001). Goal-Oriented Requirements Engineering: A Guided Tour. In 5th
Requirements Engineering Conference (RE'01), Toronto, Canada, IEEE Computer Society. 249 - 262.
VanLamsweerde, A., Darimont, R., Letier, E. (1998). "Managing Conflicts in Goal-Driven
Requirements Engineering." IEEE Transactions on Software Engineering. IEEE Computer Society.
24(11): 908-926.
Vieira, F. (2007). Um Modelo Multicritério para Gerir Conflitos na Composição de Aspectos. Master
Thesis, Faculdade de Ciências da Universidade Nova de Lisboa. Portugal.
Vieira, F., Brito, I., Moreira, A. (2006). Using Multi-criteria Analysis to Handle Conflicts During
Composition. In Early Aspects: Traceability of Aspects in the Early Life Cycle Workshop at 5th
Aspect-Oriented Software Development Conference (AOSD'06), Bonn, Germany.
http://trese.cs.utwente.nl/workshops/early-aspects-Traceability-
AOSD2006/Papers/Vieira_Brito_Moreira.pdf.
Volere Requirements Resources (2007). Volere Requirements Resources,
http://www.volere.co.uk/index.htm.
Whittle, J., Araújo, J. (2004). "Scenario Modeling with Aspects." IEE Proceedings Software. 151(4):
157-172.
Wiegers, K. (2003). Software Requirements. 978-0735606319. Microsoft Press.
Williams, A., Sweeny, D., Williams,T. (2000). Quantitative Methods for Business. 0324184131.
South-Western.
217

Wirfs-Brock, R., Wilkerson, B., Wiener, L. (1999). Designing Object-Oriented Software. 0-13-
629825-7. Prentice-Hall.
Yen, J., Tiao, W. (1997). A Systematic Tradeoff Analysis for Conflicting Imprecise Requirements. In
3rd Requirements Engineering Conference (RE'97), Annapolis, USA, IEEE Computer Society. 87-96.
Yu, E. (1997). Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering.
In 3rd Requirements Engineering Conference (RE'97), Annapolis, USA, IEEE Computer Society. 226-
235.
Zave, P. (1997). "Classification of Research Efforts in Requirements Engineering." ACM Computing
Surveys. ACM. 29(4): 315-321.
Zimmerman, H. (1991). Fuzzy Sets Theory and Its Application. 978-0131011717. Kluwer Academic.
Zultner, R. (1992). "Quality Function Deployment for Software: Satisfying the Customers." American
Programmer 1: 28-41.
218