Early aspects: aspect-oriented requirements engineering and architecture design

This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications

Towards a scope management of non-functional requirements in requirements engineering

Getting business stakeholders’ goals formulated clearly and project scope defined realistically increases the chance of success for any application development process. As a consequence, stakeholders at early project stages acquire as much as possible knowledge about the requirements, their risk estimates and their prioritization. Current industrial practice suggests that in most software projects this scope assessment is performed on the user’s functional requirements (FRs), while the non-functional requirements (NFRs) remain, by and large, ignored. However, the increasing software complexity and competition in the software industry has highlighted the need to consider NFRs as an integral part of software modeling and development. This paper contributes towards harmonizing the need to build the functional behavior of a system with the need to model the associated NFRs while maintaining a scope management for NFRs. The paper presents a systematic and precisely defined model towards an early integration of NFRs within the requirements engineering (RE). Early experiences with the model indicate its ability to facilitate the process of acquiring the knowledge on the priority and risk of NFRs

Aspect-oriented domain analysis

Dissertação de Mestrado em Engenharia InformáticaDomain analysis (DA) consists of analyzing properties, concepts and solutions for a given domain of application. Based on that information, decisions are made concerning the software development for future application within that domain. In DA, feature modeling is used to describe common and variable requirements for software systems. Nevertheless, they show a limited view of the domain. In the mean time, requirement approaches can be integrated to specify the domain requirements. Among them, we have viewpoint oriented approaches that stand out by their simplicity, and efficiency organizing requirements. However, none of them deals with modularization of crosscutting subjects. A crosscutting subject can be spread out in several requirement documents. In this work we will use a viewpoint oriented approach to describe the domain requirements extended with aspects. Aspect-oriented domain analysis (AODA) is a growing area of interest as it addresses the problem of specifying crosscutting properties at the domain analysis level. The goal of this area is to obtain a better reuse at this abstraction level through the advantages of aspect orientation. The aim of this work is to propose an approach that extends domain analysis with aspects also using feature modeling and viewpoint

Expressing aspectual interactions in requirements engineering: Experiences, problems and solutions

AbstractAspect Oriented Requirements Engineering (AORE) provides support for modularizing crosscutting requirements. In the context of an industrial project in the domain of Slot Machines we needed to perform AORE, with a special emphasis on dependencies and interactions among concerns. We were however unable to find any report of large-scale industrial applications of AORE approaches that treat dependencies and interactions. We therefore evaluated two AORE approaches: Theme/Doc and MDSOCRE, to establish their applicability in our setting. In this paper we report on the limitations of both approaches we encountered and propose extensions that allow them to cope with concern interactions. We also show how these extensions provide the needed expressiveness by applying them to our industrial case study

Expressing aspectual interactions in requirements engineering: Experiences, problems and solutions

Aspect Oriented Requirements Engineering (AORE) provides support for modularizing crosscutting requirements. In the context of an industrial project in the domain of Slot Machines we needed to perform AORE, with a special emphasis on dependencies and interactions among concerns. We were however unable to find any report of large-scale industrial applications of AORE approaches that treat dependencies and interactions. We therefore evaluated two AORE approaches: Theme/Doc and MDSOCRE, to establish their applicability in our setting. In this paper we report on the limitations of both approaches we encountered and propose extensions that allow them to cope with concern interactions. We also show how these extensions provide the needed expressiveness by applying them to our industrial case study.Laboratorio de Investigación y Formación en Informática Avanzad

Surveying navigation modelling approaches

Recently, a number of authors who work on web application modelling have paid attention to the ideas regarding separation of concerns that underlie aspect-orientation, as well as some ideas that come from the model-driven development community. They attempt to improve the representation and separation of some concerns such as customisation or navigational concerns that are scattered throughout different software artifacts and tangled with other concerns in order to give a best support to the evolution of web applications. This paper surveys recent proposals in this field and compares them within a homogeneous framework that bridges the gap between the many different terminologies used, and highlights open problems that need further research.Ministerio de Ciencia y Tecnología TIN2007-64119Ministerio de Ciencia y Tecnología TIN-2007-67843-C06-0

Deriving security requirements from crosscutting threat descriptions

It is generally accepted that early determination of the stakeholder requirements assists in the development of systems that better meet the needs of those stakeholders. General security requirements frustrate this goal because it is difficult to determine how they affect the functional requirements of the system. This paper illustrates how representing threats as crosscutting concerns aids in determining the effect of security requirements on the functional requirements. Assets (objects that have value in a system) are first enumerated, and then threats on these assets are listed. The points where assets and functional requirements join are examined to expose vulnerabilities to the threats. Security requirements, represented as constraints, are added to the functional requirements to reduce the scope of the vulnerabilities. These requirements are used during the analysis and specification process, thereby incorporating security concerns into the functional requirements of the system

Implementation of Aspect-oriented Business Process Models with Web Services

In software development, crosscutting concerns, such as security, audit, access control, authentication, logging, persistence, transaction, error handling etc. can be modularized using the aspect-oriented paradigm. In busi- ness process modeling, aspects have been used to reduce visualization complexity, increase reuse and improve model maintainability. There are techniques which address aspects in modeling and implementation phases of business process; however, these techniques adopt different semantic representations, hindering the integration of these phases into the BPM lifecycle. This work proposes an architecture for service discovery capable of selecting web services that implement crosscutting concerns and meet the goals established in the aspect modeling phase, executing them accordingly with a prioritization. A proof of concept to analyze the proposed architecture and generated artifacts was performed. Afterwards, the proposal was evaluated by means of an experiment. The results suggest that the def- inition of an operational goal enables the business spe- cialists to concentrate on the modeling of the aspect without necessarily concerning its implementation, since a proper option for implementation is discovered during the execution of the process