Figure 1 - uploaded by Yijun Yu
Content may be subject to copyright.
Source publication
Aspect-oriented programming (AOP) has been attracting much attention in the Software Engineering community by advocating that programs should be structured according to programmer concerns, such as "e#cient use of memory". However, like other programming paradigms in their early days, AOP hasnt addressed yet earlier phases of software development....
Context in source publication
Context 1
... programming (AOP) is founded on the idea of aspect [4] as a cross-cutting concern during software development. Aspects are usually “units of system decomposition that are not functional” [12], such as “no unauthorized access to data” or “efficient use of memory”. Aspects cut across different components of a software system. The basic premise of aspect-oriented programming is that software structured according to aspects is easier to develop, under- stand and maintain. In name and in practice, aspect-oriented programming is a programming methodology. However, this methodology does not deal with the origins of aspects. Where do aspects come from? Is there a systematic way of discovering aspects early on during the software development process? The main objective of this paper is to propose an answer to these questions. Our proposal is based on the notion of goal and the analysis techniques developed in goal-oriented requirements engineering. These techniques are shown to be useful in guiding the discovery of aspects. Goal-oriented requirements engineering[15, 22] fo- cuses on goals which are ”roughly speaking, precur- sors of requirements” [7]. Goal-based models support the description and analysis of intentions that under- lie a new software system. Some goal models, such as i* [25, 13], also model the actors who behold these intentions. Most variations of goal models in the literature use AND/OR trees to represent goal decomposition [14, 23] and define a space of alternative solutions to the problem of satisfying a root-level goal. There are several proposals in the literature for (formal) goal analysis techniques. For example, obstacle analysis [23] explores possible obstacles to the satisfaction of a goal. Along a different dimension, qualitative goal analysis [9] allows qualitative contributions from one goal to another, and shows how to formalize and reason with them. In whatever form, goal-oriented requirements engineering has been attracting consider- able attention within the community [1, 18, 11, 2]. The rest of the paper is structured as follows. Section 2 presents a quick introduction to aspect-oriented programming, while Section 3 defines a particular type of goal model, called a V-graph. Section 4 describes a systematic process for discovering candidate aspects while doing goal analysis; Section 5 illustrates the aspect discovery process using a case study of media shop requirement analysis. Section 6 compares the candidate aspects with aspects found in an open-source implementation of a media shop system, and proposes goal aspects as a way of documenting candidate aspects for later phases. Section 7 concludes the paper and sketches directions for future research. An aspect, such as “efficient use of memory” is a cross-cutting concern for a software system. Dealing with code fragments that address a single aspect in different components of a software system has been a great challenge for software engineers. Structured Design [24] did recognize the importance of packing com- monalities into modules. This is also known in pro- gramming as the DRY principle, that is, “Don’t Repeat Yourself”. Accordingly, a good design should include components with high fan-in. Figure 1 and Figure 2 show how structured design and aspect-oriented programming view the factoring out of common concerns in complementary ways. A typical aspect expressed in AspectJ 1 syntax is as follows: The aspect DisplayUpdating includes the advice Display.update() that will be weaved into the component code after the move() pointcut. A pointcut is a virtual address for the inclusion of the advice in a component. This virtual address is resolved through matching. For example, every time a Line.setP1(Point) ap- pears in a component, the advice, Display.update() will be weaved in that component. The great benefit of software structured according to aspects is the ability to separate issues, Figure 2, and leave it to a pattern matching procedure to weave the issues together at the correct time. Although the original AOP paper [12] pointed out that aspects are mainly non-functional concerns, there has been no clear link with the notion of non-functional requirements. [14, 5, 6] propose that non-functional requirements are first class requirements, that is, requirements that are elicited, modeled and analyzed as the software is developed. We adopt their framework and show in the rest of the paper how the analysis of functional and non-functional requirements can lead to the discovery of aspects. In order to reason about the interplay of functional and non-functional requirements we focus on a particular type of a goal model called a V-graph. The V-graph is a graph with an overall shape of the letter V (Figure 3). The top two vertices of the V represent respectively functional and non-functional requirements in terms of goal models. Following [14] we represent non-functional requirements in terms of softgoals, i.e., goals with no clear-cut satisfaction. Both models are AND/OR trees with lateral correlation links (see Table 1 2 ). The bottom vertice of the V represent tasks that contribute to the satisfaction of both goals and softgoals. This model allows for the description of intentional nodes (goals and softgoals), as well as operational ones (tasks.) Following the NFR framework [5], we name each goal and task with two descriptors: a type and a topic. A topic captures contextual information for the goal/task/softgoal. This contextual information is sim- ilar to what Zave and Jackson call subject matter [26] which will determine the designations used to identify real world objects related to the goals. For instance, in Figure 7, we have the softgoal Responsiveness (type) of Transactions (topic). A type for a goal or a task describes a generic function; while a type for a softgoal describes a generic non-functional requirement (quality attribute), such as performance, safety, security, and traceability. In the V-graph model, topics also confine the pointcut links between functional goals/tasks and non-functional softgoals. Figures 4 depicts two generic decomposition goal/softgoal hierarchies, with contribution and correlation links between them. Of course, in order to produce a V-graph we need an integrated process of elicitation, modeling and analysis. The focus of this paper is on modeling and analysis, with the help of a goal analysis tool [9]. The (manual) process we are proposing constitutes a systematic way for the refinement of a V-graph. The process ends when all root goals are satisfied and all softgoals are satisficed 3 . At this stage, we are able to identify candidate aspects by identifying tasks that have a high fan-in. The resulting graph can be further refined if candidate aspects are grouped into what we call goal aspects. The process of building V-graphs is iterative. Dur- ing each step, the goal analysis tool is used to detect conflicts and deteriorations. A conflict occurs in a goal model when a given labeling of leaf goals as satisfied or denied leads to other goals being labeled both satisfied and denied. A deterioration occurs when the labeling of softgoals during one step of the iteration is weaker (lower) than during the previous step of the iteration. Below we present the proposed process using a programming language-like ...
Similar publications
The selection of requirements engineering (RE) techniques during software project development is a challenge for most developers. One of the reasons is that there is a great lack of requirements engineering education in most academic programs, so software developers have to learn requirements engineering practices on the job. This can easily result...
Citations
... Other work relating to checking consistency using an aspect-oriented paradigm, this time for web applications, is by Yijun (2004). The author presents a tool called HILA which was designed as an extension of UML state machines to model the adaptation rules for web applications (Yijun 2004). However, this work is not limited to web engineering applications but may also be applicable to other areas (Yijun 2004). ...
... The author presents a tool called HILA which was designed as an extension of UML state machines to model the adaptation rules for web applications (Yijun 2004). However, this work is not limited to web engineering applications but may also be applicable to other areas (Yijun 2004). HILA could be helpful in improving the modularity of models and helps to automate the consistency checking of aspects to ensure rules are always in a consistent state (Yijun 2004). ...
... However, this work is not limited to web engineering applications but may also be applicable to other areas (Yijun 2004). HILA could be helpful in improving the modularity of models and helps to automate the consistency checking of aspects to ensure rules are always in a consistent state (Yijun 2004). Likewise, Zhang and Holzl (2012) uses HILA with their weaving altgorithm and implementation of semantic aspects to check and to resolve conflicts between various aspects. ...
Requirements captured by requirements engineers (REs) are commonly inconsistent with their client’s intended requirements and are often error prone. There is limited tool support providing end-to-end support between the REs and their client for the validation and improvement of these requirements. We have developed an automated tool called MaramaAIC (Automated Inconsistency Checker) to address these problems. MaramaAIC provides automated requirements traceability and visual support to identify and highlight inconsistency, incorrectness and incompleteness in captured requirements. MaramaAIC provides an end-to-end rapid prototyping approach together with a patterns library that helps to capture requirements and check the consistency of requirements that have been expressed in textual natural language requirements and then extracted to semi-formal abstract interactions, essential use cases (EUCs) and user interface prototype models. It helps engineers to validate the correctness and completeness of the EUCs modelled requirements by comparing them to “best-practice” templates and generates an abstract prototype in the form of essential user interface prototype models and concrete User Interface views in the form of HTML. We describe its design and implementation together with results of evaluating our tool’s efficacy and performance, and user perception of the tool’s usability and its strengths and weaknesses via a substantial usability study. We also present a qualitative study on the effectiveness of the tool’s end-to-end rapid prototyping approach in improving dialogue between the RE and the client as well as improving the quality of the requirements.
... There are many works considering early aspects (Rashid, 2008;Yu et al., 2004;Jacobson and Ng, 2004;Whittle and Araujo, 2004;Sutton and Rouvellou, 2002;Moreira et al., 2005;Grundy, 1999). Most of these approaches deal with goal-oriented approaches and use-case models. ...
Nowadays, the requirements of various stakeholders for a system do not only increase the complexity of the system-to-be, but also contain different cross-cutting concerns. In such a situation, requirements engineers are really challenged to master the complexity and to deliver a coherent and complete description of the system-to-be. Hence, they are in need for methods which reduce the complexity, handle functional and quality requirements, check completeness and reveal interactions, and are tool supported to lower the effort. One possible option to handle the complexity of a system-to-be is the separation of concerns. Both, aspect-oriented requirements engineering and the problem frames approach implement this principle. Therefore, we propose a combination of both, the AORE4PF (Aspect-Oriented Requirements Engineering for Problem Frames) method. AORE4PF provides guidance for classifying requirements, separating the different concerns, modeling requirements for documentation and application of completeness and interaction analyses, and weaving the reusable parts to a complete and coherent system. AORE4PF provides tool support for most activities. We exemplify our method using a smart grid case obtained from the NESSoS project. For validation, the results of a small experiment in the field of crisis management systems are presented.
... These keys may apply to LKB for better components retrieval and selection process. According to[19]proposed evaluation process for COTS that is adaptable to suit the needs of a variety of web application projects. This evaluation process addresses the assessment of COTS component to determining their suitability in a web application. ...
Most of the business web applications are complex, difficult to implement, risky to maintain and customization requires deep understanding of requirements. In software engineering the needs for software designers has become evident to design an efficient and cost effective software framework. Research shows that reusability can improve software quality, productivity, save countless hours in development time and save millions of dollars. Unfortunately, implementing systematic reuse has proven to be a difficult process. As web engineers continue to struggle with cost and time, reuse has emerged as a sound engineering principle and practice in many fields. However, technology for completely integrated user interfaces, reuse design, customize and implement it is still relatively immature. Object-oriented framework mechanism provides reusability and enables web engineers to customize various aspects in web development. This study will contribute to the fields of object-oriented web engineering, component-based software engineering, web application customization and object visualization. In particulars, this study will provide a novel mechanism for designing, customizing, reusing and visualizing web elements for developing quality web application within shortest development time and cost. This study will also present an underlying code generation technique for integrating Model-View-Controller pattern, improve development productivity and reduce errors. At the end, this study conducted a complete assessment on the proposed customization mechanism.
... Requirement validation is the process of ensuring that the application meets functional and non-functional requirements before coding and during development. Additionally, validation is an approach, in which the analyst finds out the actual requirements before coding will start [16, 17]. Software validation takes place primarily during the system requirements analysis and design phase. ...
The requirement validation is vital for every successful software development. In this process, the requirements from the users are checks and analyzed with its consistency, completeness and correctness. The validation of requirements is a very vast research area in software engineering. In this presented article, some quality research approaches are cited for the software engineering researchers and software professionals.
... In a previous paper, we compared the fundamental difference in the methods reflected by component-based programming and AOP [46]. Figure 15 illustrates two modularisations to divide a problem into subproblems and to compose their solution later. ...
Security-critical systems are challenging to design and implement correctly and securely. A lot of vulnerabilities have been found in current software systems both at the specification and the implementation levels. This paper presents a comprehensive approach for model-based security assurance. Initially, it allows one to formally verify the design models against high-level security requirements such as secrecy and authentication on the specification level, and helps to ensure that their implementation adheres to these properties, if they express a system's run-time behaviour. As such, it provides a traceability link from the design model to its implementation by which the actual system can then be verified against the model while it executes. This part of our approach relies on a technique also known as run-time verification. The extra effort for it is small as most of the computation is automated; however, additional resources at run-time may be required. If during run-time verification a security weakness is uncovered, it can be removed using aspect-oriented security hardening transformations. Therefore, this approach also supports the evolution of software since the traceability mapping is updated when refactoring operations are regressively performed using our tool-supported refactoring technique. The proposed method has been applied to the Java-based implementation Jessie of the Internet security protocol SSL, in which a security weakness was detected and fixed using our approach. We also explain how the traceability link can be transformed to the official implementation of the Java secure sockets extension that was recently made open source by Sun.
... The Goal-driven Discovery of Aspects approach offers detailed procedures for discovering aspects from V-shaped goal graphs [38]. ...
The benefits of defining explicit pointcut interfaces in aspect-oriented applications have been advocated by many. A pointcut interface exposes a set of crosscutting abstract behaviors that multiple aspects of an application can leverage and use. In order to maximally promote pointcut reuse across applications from a certain problem domain, a pointcut interface should preferably expose stable abstractions in that problem domain.
In this paper, we propose a top-down method for designing such stable pointcut interfaces. The method builds upon state-of-the-art domain analysis techniques and employs systematic re-engineering of use case models to discover stable abstractions that are anchored in the domain model of the application. At architecture creation time, these stable domain abstractions are mapped onto pointcut interfaces.
We provide algorithmic procedures for use case re-engineering and guidelines for architecture creation. This enables further experimentation with the proposed method and its automation, which in turn improves the ease of adoption. The paper enhances the detailed description of the method by applying it in a running example.
We have applied our method in two case studies, where we observe that the resulting pointcut interfaces can be reused for implementing the composition logic of different aspects without requiring modification to their pointcut signatures. In summary, both case studies provide compelling examples that illustrate non-trivial reuse of the pointcut interfaces that have been created using our method.
... The relationship among the quality attributes and aspect-oriented development has been explored in [53] and [54]. Later on, others have identified the important role the NFR Framework -in particular, softgoals -plays in dealing with early aspects [27], [55] [56] [57] [58] [59] (See [60] for a survey on the topic). ...
Essentially a software system's utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.
... Preliminary work on goal aspects was published in [45,46,47]. The emphasis of [45] was to discover candidate aspects during goal-oriented requirements analysis, while the idea of tracing and validating the early identified goal aspects was sketched in [47] and detailed in [46]. ...
... Preliminary work on goal aspects was published in [45,46,47]. The emphasis of [45] was to discover candidate aspects during goal-oriented requirements analysis, while the idea of tracing and validating the early identified goal aspects was sketched in [47] and detailed in [46]. This paper brings together the essentials from our earlier work, integrates the full-fledged aspect tracing method, and describes a systematic empirical study, to offer a more complete treatment and a more critical evaluation of our framework. ...
... Aspects in goal models can be discovered using the correlations from hard goals to softgoals along with a goal elicitation and refinement process based on the V-graph model [45]. The formal process can be briefly explained as follows. ...
Goal modeling fits model-driven engineering (MDE) in that it captures stakeholder concerns and the interdependencies using concepts that are much less bound to the underlying implementation technology and are much closer to the problem languages. Aspect-oriented software development (AOSD) provides language constructs to facilitate the representation of multiple perceptions and to alleviate tangling and scattering concerns. Synthesis of AOSD and MDE not only manages software complexity but also improves productivity, as well as model quality and longevity. In this paper, we propose a model-driven framework for tracing aspects from requirements to implementation and testing, where goal models become engineering assets and straightforward model-to-code transformation bridges the gap between domain concepts and implementation technologies. We test our hypotheses and evaluate the framework’s applicability and usefulness with a case study of an open-source e-commerce platform written in PHP.
... Five years have passed since this original vision paper at RE 2002 that galvanised a community of researchers focusing on this topic. A number of AORE techniques, e.g., [1,2,3,7,8,10,11,12,14,17,18,19,23,26,27,28], to note a few, have been proposed. In this paper, we review the AORE research space and aim to answer two key questions: We highlight that while AORE approaches have extensively studied the issues of requirements tangling, identification of crosscutting requirements and their analysis and subsequent mapping onto the solution space, they lack strong empirical evaluation and only partially address issues relating to traceability and consistency of aspect specifications. ...
... • AO Goal Modelling Approach [28]; ...
It has been five years since a Vision Paper at the Requirements Engineering Conference in 2002 laid out an initial vision for As-pect-Oriented Requirements Engineering (AORE). This vision included objectives such as offering better means to identify and manage conflicts arising due to tangled representations and identifying the mapping and influence of crosscutting requirements on architecture, design and implementation artefacts. Since then a number of AORE techniques have been proposed in literature. In this paper, we review these techniques and discuss whether and how effectively the original AORE vision from RE 2002 has been realised so far. We also discuss how the original vision needs to be extended given our improved understanding of AORE challenges and present a roadmap for the next five years as a chal-lenge to both existing AORE researchers and those planning to pursue work in this area.
... These solutions however do not address the problem of identifying and modeling concerns during the requirement phase of software development. Some examples of early aspects in requirements phase are the non-functional aspects demonstrated in a matrix based approach of Rashid et al. [15], and V-graph based approach of Yu et al. [20] for identifying nonfunctional aspects. A notion of functional aspects in i * [19] based Agent oriented requirement modeling was discussed in [1,8]. ...
A method of capturing task and dependency aspects in an agent oriented requirements methodology based on Formal Tropos is presented. The emphasis is on capturing functional aspects in formal specifications through aspect extensions. With the help of a few exam- ples, the benefit of aspect extensions in terms of reducing scattering from specifications are demonstrated.
