Catálogo de publicaciones - libros

Early Aspects are aspects found in the early life cycle phases of software development, including requirements elicitation and analysis, domain analysis and architecture design activities. Aspects at these stages crosscut the modular units appropriate for their lifecycle activity; traditional requirements documentation, domain knowledge capture and architectural artifacts do not afford separate description of early aspects. As such, early aspects necessitate new modularizations to be effectively captured and maintained. Without new tools and techniques, early aspects remain tangled and scattered in lifecycle artifacts, and may lead to development, maintenance and evolution difficulties.

Aspect-oriented requirements engineering (AORE) provides separation of concerns at the requirements level. In order to cope with concern identification and structuring into different requirements models, tool support is vital to effectively reduce the burden of performing various AORE tasks. This paper describes how the EA-Miner tool-based approach provides automated support for mining various types of concerns from a variety of early stage requirements documents and how these concepts can be structured into specific aspect-oriented requirements models (e.g., viewpoints-based, use-case-based). The key insight for early-stage requirements automation is the use of natural language processing to reason about properties of the requirements as well as the utilization of semantics revealed by the natural language analysis in building the models. Evaluation of EA-Miner shows promising results concerning time-effectiveness and accuracy of undertaking AORE activities and building requirements models. Moreover, an industrial case study conducted at Siemens AG investigated how the tool performs in a real-world setting by analysing what benefits it brings and challenges it faces during AORE analysis. The EA-Miner analysis enabled to find concerns that were considered relevant by a research team at Siemens that is re-implementing the investigated system with aspect-oriented languages. Moreover, the exposure of the tool to industrial requirements written by different developers also revealed some challenges imposed by the structure of the documentation and the different use of vocabulary terms hence providing new paths to explore and improve the tool in the future such as better pre-processing support, “domain synonym” identification and detection of poorly written requirements.

are stakeholder concerns that crosscut the problem domain, with the potential for a broad impact on questions of scoping, prioritization, and architectural design. Analyzing early aspects improves early stage decision-making, and helps trace stakeholder interests throughout the software development life cycle. However, analysis of early aspects is hard because stakeholders are often vague about the concepts involved, and may use different vocabularies to express their concerns. In this paper, we present a rigorous approach to conceptual analysis of stakeholder concerns. We make use of the repertory grid technique to identify terminological interference between stakeholders’ descriptions of their goals, and formal concept analysis to uncover conflicts and trade-offs between these goals. We demonstrate how this approach can be applied to the goal models commonly used in requirements analysis, resulting in the clarification and elaboration of early aspects. Preliminary qualitative evaluation indicates that the approach can be readily adopted in existing requirements analysis processes, and can yield significant insights into crosscutting concerns in the problem domain.

Crosscutting is usually described in terms of scattering and tangling. However, the distinction between these three concepts is vague. Precise definitions are mandatory for certain research areas such as the identification of crosscutting concerns at phases of the software life cycle. We propose a conceptual framework for crosscutting where crosscutting is defined in terms of trace relations. The definition of crosscutting is formalized using linear algebra, and represented with matrices and matrix operations. In this way, crosscutting can be clearly distinguished from scattering and tangling. With this definition and transitivity of trace relations, crosscutting can be identified and traced through software development, also in early phases. We describe some illustrative case studies to demonstrate the applicability of the analysis.

Once aspects have been identified during requirements engineering activities, the behavior, structure, and pointcut expressions of aspects need to be modeled unobtrusively at the requirements level, allowing the engineer to seamlessly focus either on the behavior and structure of the system without aspects or the combined behavior and structure. Furthermore, the modeling techniques for aspects should be the as for the base system, ensuring that the engineer continues to work with familiar models. This paper describes how, with the help of Use Case Maps (UCMs), scenario-based aspects can be modeled at the requirements level unobtrusively and with the same techniques as for non-aspectual systems. Use Case Maps are a visual scenario notation under standardization by the International Telecommunication Union. With Use Case Maps, aspects as well as pointcut expressions are modeled in a visual way which is generally considered the preferred choice for models of a high level of abstraction.

Composing aspectual concerns with base concerns may raise conflicting situations that need to be identified and resolved. A conflict is detected whenever two or more concerns that contribute negatively to each other and have the same importance need to be composed together. This paper discusses the use of Multiple Criteria Decision Making (MCDM) methods to support aspectual conflict management in the context of Aspect-Oriented Requirements Engineering. The final solution relies on the use of the obtained concern rankings to handle unresolved conflicts. An illustrative example is presented to discuss how MCDM methods can be used for aspectual conflict handling.

Handling aspects within models looks promising for managing crosscutting concerns early in the software life-cycle, up from programming to design, analysis and even requirements. At the modeling level, even complex behavioral aspects can easily be described for instance as pairs of sequence diagrams: one for the pointcut specifying the behavior to detect, and the second one for an advice representing the wanted behavior at the join point. While this is fine for informal documentation purposes, or even intuitive enough when a single aspect has to be woven, a more precise semantics of both join point detection and advice weaving is needed for using these modeling artifacts for Model Driven Engineering activities such as code generation or test synthesis. This paper proposes various interpretations for pointcuts that allow multiple behavioral aspects to be statically woven. The idea is to allow join points to match a pointcut even when some extra-messages occur in between. However, with this new way of specifying join points, the composition of the advice with the detected part cannot any longer be just a replacement of the detected part by the advice. We have to consider the events (or the messages) of the join point, but also the events which occur between them, and merge them with the behavior specified within the advice. We thus also propose a formal definition of a new merge operator, and describe its implementation on the Kermeta platform.