Traceability and AOSD - From Requirements to Aspects

The traceability question is addressed through the development of a framework to go from requirements to aspects using the Design by Contract methodology. It is demonstrated that by starting at the requirements stage, and specifying an early aspect in the same semi-formal language as the system's existing requirements, we have the basis from which to design the aspects at the implementation stage. The language of pre- and post-conditions is shown to match closely that of aspects, in that pre-conditions match the aspect's pointcut, and the post-condition matches the advice part of the aspect. This thus gives us traceability from 'early aspects' to 'late aspects'. This approach will shed some light on the relationship between requirements and their refinements to pre- and post conditions, and the traceability of requirements in the face of reuse over time. The addition of a new crosscutting requirement is investigated in terms of the framework, demonstrating the relationship between early and late aspects and traceability. The framework promises to help with the design of the late aspects. We propose the concept of relevancy: information in a requirement beyond its specification as pre- and post-conditions, as a way of identifying join points

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

Towards an aspect weaving BPEL engine

This position paper proposes the use of dynamic aspects and the visitor design pattern to obtain a highly configurable and extensible BPEL engine. Using these two techniques, the core of this infrastructural software can be customised to meet new requirements and add features such as debugging, execution monitoring, or changing to another Web Service selection policy. Additionally, it can easily be extended to cope with customer-specific BPEL extensions. We propose the use of dynamic aspects not only on the engine itself but also on the workflow in order to tackle the problems of Web Service hot deployment and hot fixes to long running processes. In this way, composing aWeb Service "on-the-fly" means weaving its choreography interface into the workflow

The case of KAO

Dissertação apresentada na Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa para obtenção do grau de Mestre em Engenharia InformáticaRequirements engineering aims at eliciting, analyzing, specifying, validating and managing system requirements. When eliciting system requirements, it is possible to use various approaches, including goal-oriented and aspect-oriented approaches. Although those are two well-known approaches, they are seldom used in conjunction. On the other hand, when using goal-oriented approaches, one common and usual problem is the fact that some of the goals repeat themselves all over the system. This makes goal-oriented models to have a boost in complexity because of the repeating goals, and thus, making the evolution of this model harder than necessary. This complexity could be minimized if an aspect-oriented approach would be used. The big advantage of using a hybrid approach, in our case goal-oriented and aspect-oriented one is the possibility to identify all the scattered goals and modularize them as aspects. In this way we can represent this kind of goal (now an aspect) only once in the model. This means the complexity of the model will be greatly reduced and the readability of the model will also be improved. The final result will be an evolution that could be easily controlled, thus minimizing errors. Although this seems a good idea, there are some challenges to overcome when merging goals and aspects. First of all, a notation and a set of rules must be built in order to compose the model. In order to do this we will use patterns based on roles, as these will help elaborating the model. This work will present an approach that will make possible after modeling the system with a goal-oriented approach, identify aspects and then refine the model taking into account the aspects. In order to accomplish this, the KAOS methodology will be extended with aspects

Towards a New Framework for Product Development

In the mid-1980s, Andreasen and Hein first described their model of Integrated Product Development. Many Danish companies quickly embraced the principles of integrated product development and adapted the model to their specific business and product context. However, there is concern amongst many Danish companies that Integrated Product Development no longer provides a sufficient way of describing industry’s product development activity. More specifically, five of these companies have supported a programme of research activities at the Technical University of Denmark, which seeks to develop a new framework for product development. This paper will describe the research approach being taken, present some initial findings, and outline a vision of a new working approach to product development

Challenging incompleteness of performance requirements by sentence patterns

Performance requirements play an important role in software development. They describe system behavior that directly impacts the user experience. Specifying performance requirements in a way that all necessary content is contained, i.e., the completeness of the individual requirements, is challenging, yet project critical. Furthermore, it is still an open question, what content is necessary to make a performance requirement complete. To address this problem, we introduce a framework for specifying performance requirements. This framework (i) consists of a unified model derived from existing performance classifications, (ii) denotes completeness through a content model, and (iii) is operationalized through sentence patterns. We evaluate both the applicability of the framework as well as its ability uncover incompleteness with performance requirements taken from 11 industrial specifications. In our study, we were able to specify 86% of the examined performance requirements by means of our framework. Furthermore, we show that 68% of the specified performance requirements are incomplete with respect to our notion of completeness. We argue that our framework provides an actionable definition of completeness for performance requirements