Specifying and Separating Concerns from Requirements to Design: A Case Study

Aspect-Oriented Software Development (AOSD) aims at providing a systematic support for the identification, separation, representation (through proper modeling and documentation), and composition of crosscutting concerns as well as mechanisms that can make them traceable throughout software development. In this paper, we discuss a sequence of systematic activities towards an early consideration of specifying and separating crosscutting functional requirements (FRs) and nonfunctional requirements (NFRs). This approach would make it possible to identify and resolve conflicts between NFRs earlier in the development cycle and can promote traceability of broadly scoped requirements throughout system development, maintenance and evolution. We provide a formalism for FRs by specifying their preand postconditions using firstorder predicate logic. Measures of conflictiveness and interdependency are proposed to assess the effort required for the composition of the requirements. A new measure of cohesiveness of the use-case model is proposed based on the crosscutting modeling approach. 1. Background and introduction The increasing level of software complexity has highlighted the need to consider quality as an integral part of software development. According to the software engineering standard IEEE Std.830-1998 [1], NFRs describe not what the software will do, but how the software will do it, for example, software performance requirements, software design constraints, software external interface requirements and software quality attributes. During requirements engineering, NFRs tend to be stated in terms of the qualities or the constraints on the tasks which are expressed as FRs as the former affect the semantics of the latter. An iterative software development process such as the one defined by the Unified Software Development Process (UP) [2] is organized into a series of short fixed-length mini-projects called iterations, where each iteration represents a complete development cycle: it includes its own requirements, analysis, design, implementation and testing activities. In the Rational Unified Process (R)UP, NFRs are listed in the Supplementary Specifications Document which starts during the Inception phase and normally gets refined in the subsequent phases over a number of iterations throughout development. However, the UP does not provide a special vocabulary or notation to support requirements specifications. Similarly the IEEE Standard 830-1998 describes a list of NFRs to be included in a Software Requirements Document. The FURPS+ model used by the (R)UP refers to the following categories of requirements: Functional, Usability, Reliability (replaced by Dependability), Performance, Supportability and others. NFRs that fall into the URPS categories are called quality requirements. NFRs outside URPS are called constraints or pseudo-requirements. Once a software system has been deployed, it is normally straightforward to observe whether or not a certain FR has been met, as the areas of success or failure in their context can be rigidly defined. However, the same is not true for NFRs as these can refer to quantities that can be interdependent and difficult to measure. A decomposition approach proposed by [3] encompasses the refinement of NFRs into more detailed NFRs. Software quality models are used to determine to what extent software components satisfy the requirements of a given context of use. A quality model is defined by means of general characteristics of software, which is further decomposed into sub-characteristics in a multilevel hierarchy; at the bottom of the hierarchy appear measurable software attributes. Furthermore, an interdependency may pose a tradeoff between NFRs. For example, as reliability increases, performance or cost are affected. In cases where conflicts between NFRs tend to arise, developers must work out a satisfactory level of balance (tradeoffs) between them. Despite the success of object-orientation in the effort to achieve separation of concerns, certain properties in object-oriented systems cannot be directly mapped from the problem domain to the solution space, and thus they cannot be localized in single modular units. This is due to the fact that functional decomposition is performed along the notion of class. This crosscutting phenomenon imposes two symptoms over programs: (1) the scattering of concerns across the decomposition hierarchy of the system, and (2) the tangling of concerns in modular units. Problems associated with low level of cohesion of modular units, strong coupling between modular units, low level of reusability of code, low level of adaptability and difficult comprehensibility resulting in programs that are more error prone, have been extensively discussed in the literature over the recent years. Aspect-Oriented Programming (AOP) [4] is a term adopted to describe an increasing number of technologies and approaches that support the explicit capture of crosscutting concerns (or aspects) whereby the implementation of functional components and aspects is performed (relatively) separately, and their composition and coordination (referred to as weaving) is specified by a set of rules. Crosscutting does not necessarily imply that aspects must correspond to NFRs even though NFRs seem to be major candidates for crosscutting concerns, as these normally relate to the system as a whole (or to parts of it) rather than to individual system features. Furthermore, the description of crosscutting leaves space for its manifestation in disciplines that precede programming. Aspect-Oriented Software Development has extended AOP to provide a systematic support for the identification, separation, representation (through proper modeling and documentation) and composition of crosscutting concerns as well as mechanisms that make them traceable throughout software development. The rest of this paper is organized as follows: In Section 2 we will present related work. In Section 3 we will describe our motivation. In Section 4 we will describe our approach that includes measurements for crosscutting which are further described in Section 5. In Section 6 we will present a case study to provide a proof of concept to our proposal and in Section 7 we will conclude and discuss recommendations for further research. 2. Related work and open issues Current aspect-oriented architectural frameworks aim at drawing an abstract pathway that concentrates on a general purpose modeling procedure within a certain domain, or to support particular NFRs in the system (e.g., performance or security [5, 6]). In addition, these approaches do not fully support a smooth transition among the requirements, analysis and the design phases. This is due to the lack of setting a systematic and well-defined set of composition rules which will enable the provision of the following: • A general mechanism of integration among orthogonal and non-orthogonal FRs and NFRs at particular interaction points. • A smooth flow to the next phases of the development process based on a well-established mechanism that may extend traditional artifacts. • A clear and systematic method to identify and resolve direct and indirect conflicts among aspects. • An integration within a framework architecture that could be used for different categories of complex systems (such as reactive, interactive, embedded, etc.) In [7], the authors adopt model analysis to detect semantic conflicts between aspects. However, the approach is dedicated to serve the detection of direct conflicts only. Resolving conflicts is recommended through a process of correction and refinement of the model, which is not clearly investigated. In [8], the composition of the concerns is defined as the last step of a proposed model for separation of concerns at requirements engineering using the formal method LOTOS. Resolving conflicts among concerns is recommended through negotiation with stakeholders which may not always be applicable except for developers. Defining the dominant concern at a certain matching point as recommended in this approach is not always applicable as well because of the dynamic behavior of the system. In addition, it is not clear how to map the combination set defined in LOTOS to the next stages of the development. In [9, 10, 11] composition of concerns is accomplished by extending UML models to integrate the candidate aspects to the functional behavior. Although the composition process must be considered at the meta-level, these approaches only model certain NFRs in a way that is not necessarily applicable for other requirements. In [12], the authors reason about the semantics of the composition mechanisms of the programming language through an approach that is based on a single meta-model: Composition Graphs meta-model. While these graphs may provide a sufficient homogenous comprehension for the semantics among different programming languages that make them easier to compare and to be transformed, the process to construct such graphs without existing tools can be tedious. In addition, the graphs are generated from an existing implementation that we may not necessarily have when we initially develop the application. In [13, 14], the obliviousness property was adopted to model orthogonal aspects independently from each other and from the functional requirements. The usage of formal methods in these approaches (e.g. GAMMA, LOTOS, Time Temporal Logic) to specify the functional behavior and the associated aspects helps to enable formal validation and facilitates a specification-driven design. On the other hand, the weaving process is not presented in a precise systematic way and it is limited to a specific type of requirements that could not necessary be applicable for others. In addition, it is not clear where and how the formalism is to be placed within the AOSD framework or how to integrate it with the traditional iterative development processes. 3. Motivation