Results 1 - 10
of
19
Semantics-based composition for aspectoriented requirements engineering
- In Aspect Oriented Software Development conf
, 2007
"... In this paper, we discuss the limitations of the current syntactic composition mechanisms in aspect-oriented requirements engineering (AORE). We highlight that such composition mechanisms not only increase coupling between aspects and base concerns but are also insufficient to capture the intentiona ..."
Abstract
-
Cited by 34 (4 self)
- Add to MetaCart
(Show Context)
In this paper, we discuss the limitations of the current syntactic composition mechanisms in aspect-oriented requirements engineering (AORE). We highlight that such composition mechanisms not only increase coupling between aspects and base concerns but are also insufficient to capture the intentionality of the aspect composition. Furthermore, they force the requirements engineer to reason about semantic influences and trade-offs among aspects from a syntactic perspective. We present a requirements description language (RDL) that enriches the existing natural language requirements specification with semantic information derived from the semantics of the natural language itself. Composition specifications are written based on these semantics rather than requirements syntax hence providing improved means for expressing the intentionality of the composition, in turn facilitating semantics-based reasoning about aspect influences and trade-offs. We also discuss the practicality of the use of this RDL by outlining the automation support for requirements annotation (realized as an extension of the Wmatrix natural language processing tool suite) to expose the semantics which are in turn utilized to facilitate composition and analysis (supported by the MRAT tool).
Rely-guarantee approach to reasoning about aspect-oriented programs
- In SPLAT Workshop at AOSD
, 2007
"... Over the last few years, the question of reasoning about aspectoriented programs has been addressed by a number of authors. In this paper, we present a rely-guarantee approach to such reasoning. The rely-guarantee approach has proven extremely successful in reasoning about concurrent and distributed ..."
Abstract
-
Cited by 13 (4 self)
- Add to MetaCart
(Show Context)
Over the last few years, the question of reasoning about aspectoriented programs has been addressed by a number of authors. In this paper, we present a rely-guarantee approach to such reasoning. The rely-guarantee approach has proven extremely successful in reasoning about concurrent and distributed programs. We show that some of the key problems encountered in reasoning about aspectoriented programs are similar to those encountered in reasoning about concurrent programs; and that the rely-guarantee approach, appropriately modified, helps address these problems. We illustrate our approach with a simple example. D.2.4 [Software Engineer-
On the Necessity of Empirical Studies in the Assessment of Modularization Mechanisms for Crosscutting Concerns
- In ACoM ’07: Proceedings of the 1st International Workshop on Assessment of Contemporary Modularization Techniques
, 2007
"... Collaborations are a frequently occurring class of crosscutting concerns. Prior work has argued that collaborations are better implemented using Collaboration Languages (CLs) rather than AspectJ-like Languages (ALs). The main argument is that aspects flatten the objectoriented structure of a collabo ..."
Abstract
-
Cited by 9 (6 self)
- Add to MetaCart
(Show Context)
Collaborations are a frequently occurring class of crosscutting concerns. Prior work has argued that collaborations are better implemented using Collaboration Languages (CLs) rather than AspectJ-like Languages (ALs). The main argument is that aspects flatten the objectoriented structure of a collaboration, and introduce more complexity rather than benefits – in other words, CLs and ALs differ with regard to program comprehension. To explore the effects of CL and AL modularization mechanisms on program comprehension, we propose to conduct a series of experiments. We present ideas on how to arrange such experiments that should serve as a starting point and foster a discussion with other researchers. 1.
A taxonomy of asymmetric requirements aspects
- LNCS
"... Abstract. The early aspects community has received increasing atten-tion among researchers and practitioners, and has grown a set of mean-ingful terminology and concepts in recent years, including the notion of requirements aspects. Aspects at the requirements level present stake-holder concerns tha ..."
Abstract
-
Cited by 4 (4 self)
- Add to MetaCart
(Show Context)
Abstract. The early aspects community has received increasing atten-tion among researchers and practitioners, and has grown a set of mean-ingful terminology and concepts in recent years, including the notion of requirements aspects. Aspects at the requirements level present stake-holder concerns that crosscut the problem domain, with the potential for a broad impact on questions of scoping, prioritization, and architectural design. Although many existing requirements engineering approaches ad-vocate and advertise an integral support of early aspects analysis, one challenge is that the notion of a requirements aspect is not yet well es-tablished to efficaciously serve the community. Instead of defining the term once and for all in a normally arduous and unproductive concep-tual unification stage, we present a preliminary taxonomy based on the literature survey to show the different features of an asymmetric require-ments aspect. Existing approaches that handle requirements aspects are compared and classified according to the proposed taxonomy. In addition, we study crosscutting security requirements to exemplify the taxonomy’s use, substantiate its value, and explore its future directions. 1
On the Footprints of Join Points: The Blueprint Approach
- Journal of Object Technology
, 2007
"... Aspect-oriented techniques are widely used to better modularize object-oriented programs by introducing crosscutting concerns in a safe and non-invasive way, i.e., aspectoriented mechanisms better address the modularization of functionality that orthogonally crosscuts the implementation of the appli ..."
Abstract
-
Cited by 4 (3 self)
- Add to MetaCart
Aspect-oriented techniques are widely used to better modularize object-oriented programs by introducing crosscutting concerns in a safe and non-invasive way, i.e., aspectoriented mechanisms better address the modularization of functionality that orthogonally crosscuts the implementation of the application. Unfortunately, as noted by several researchers, most of the current aspect-oriented approaches are too coupled with the application code, and this fact hinders the concerns separability and consequently their re-usability since each aspect is strictly tailored on the base application. Moreover, the join points (i.e., locations affected by a crosscutting concerns) actually are defined at the operation level. It implies that the possible set of join points includes every operation (e.g., method invocations) that the system performs. Whereas, in many contexts we wish to define aspects that are expected to work at the statement level, i.e., by considering as a join point every point between two generic statements (i.e., lines of code). In this paper, we present our approach, called Blueprint, to overcome the abovementioned limitations of the current aspect-oriented approaches. The Blueprint consists of a new aspect-oriented programming language based on modeling the join point selection mechanism at a high-level of abstraction to decouple aspects from the application code. To this regard, we adopt a high-level pattern-based join point model, where join points are described by join point blueprints, i.e., behavioral patterns describing where the join points should be found.
Vigilant usage of Aspects
- PROCEEDINGS OF ADI 2007 - WORKSHOP ON ASPECTS, DEPENDENCIES, AND INTERACTIONS AT ECOOP 2007
, 2007
"... In the last 10 years the Aspect-Oriented Software Development (AOSD) has gradually become a concern stone in Software Engineering as an engine to reduce complexity and increase reuse by providing modularization of concerns that tend to crosscut. Nevertheless, its use in certain situations can prese ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
(Show Context)
In the last 10 years the Aspect-Oriented Software Development (AOSD) has gradually become a concern stone in Software Engineering as an engine to reduce complexity and increase reuse by providing modularization of concerns that tend to crosscut. Nevertheless, its use in certain situations can presents some problems that can not only discourage its mainstream adoption, but also hinder the realization of software quality goals. The first problem, the AOSD-Evolution paradox, encompasses the difficulties with evolving software developed using AOSD. The second arises as a result of the invasive nature of aspects. The use of aspects without any control can result in a harmful practice. This work describes these problems and exposes the strength and limitations of the current approaches to solve them. Thus allowing us to reason in a clear fashion about the problems and their solutions, then justifying a contract base approach, which aims to control the usage of aspect without constraining the power of AOSD.
Aspect Orientation for Your Language of Choice
"... Abstract. Modern software development uses lots of so-called domain-specific languages (DSLs), providing domain-specific abstractions as a means to cope with the increasing complexity of modern software systems. While such languages are developed with a strong focus on the domain issues they are to ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
Abstract. Modern software development uses lots of so-called domain-specific languages (DSLs), providing domain-specific abstractions as a means to cope with the increasing complexity of modern software systems. While such languages are developed with a strong focus on the domain issues they are to address, more technical considerations of language engineering are typically left out. This can become problematic when the size of descriptions or programs in such a DSL increases, leading eventually to a need for advanced modularisation techniques, such as aspect orientation. To counter the complexities involved in designing modularisation for every new DSL, this paper shows a generic approach for implementing aspect orientation for arbitrary languages. The approach is especially useful for declarative DSLs, but can be used for other languages as well. 1
W.: From aspect-oriented models to aspect-oriented code? the maintenance perspective
- In: Proceedings of the 9th International Conference on Aspect-Oriented Software Development. ACM (2010
"... Aspect-Oriented Modeling (AOM) provides support for sep-arating concerns at the design level. Even though most AOM approaches provide means to execute the composition of the modularized concerns to obtain a composed model, it is also possible to keep the concerns modularized at the im-plementation l ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
(Show Context)
Aspect-Oriented Modeling (AOM) provides support for sep-arating concerns at the design level. Even though most AOM approaches provide means to execute the composition of the modularized concerns to obtain a composed model, it is also possible to keep the concerns modularized at the im-plementation level by targeting an aspect-oriented platform. Model-driven approaches have emerged to support both al-ternatives via tools. Clearly, these choices are not equiva-lent. Rather, they have a direct impact on several dimen-sions, including maintainability. Hence, the main research problem addressed by this work is to figure out which al-ternative provides for shorter maintenance time. To answer this question, we have conducted a series of quantitative studies and experiments.
Cross-Document Dependency Analysis for System-of-System Integration
"... Abstract. Systems-of-systems are formed through integration of individual complex systems, often not designed to work together. A number of factors can make this integration very challenging which often leads to catastrophic failures. In this paper, we focus on three major classes of system-of-syste ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
(Show Context)
Abstract. Systems-of-systems are formed through integration of individual complex systems, often not designed to work together. A number of factors can make this integration very challenging which often leads to catastrophic failures. In this paper, we focus on three major classes of system-of-system integration problems: managerial independence, interface incompatibility, and component-system complexity. We then present an aspect-oriented requirements description language (RDL) which uses natural language analysis capabilities to reason about dependencies across the documentation of the constituent systems of a system-of-systems. The aspect-oriented compositions in the RDL also facilitate specification of cross-document constraints and inconsistency resolution strategies, which can be used for deriving proof obligations and test cases for verification and validation of the emergent behaviour of a system-of-systems. We showcase the capabilities of our RDL through a case study of a real-world emergency response system. Our analysis shows that the querying and composition capabilities of the RDL provide valuable support for reasoning across documentation of multiple systems and specifying suitable integration constraints. 1
Patterns of Aspect-Oriented Design
- In Proceedings of European Conference on Pattern Languages of Programs. Irsee
, 2007
"... Aspect-oriented programming languages are becoming commonplace, and programmers are accumulating experience in building and maintaining aspect-oriented systems. This paper addresses how the use of these languages affects program design: how aspect-oriented languages change the design space, which de ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
(Show Context)
Aspect-oriented programming languages are becoming commonplace, and programmers are accumulating experience in building and maintaining aspect-oriented systems. This paper addresses how the use of these languages affects program design: how aspect-oriented languages change the design space, which designs should be emulated and which avoided, and the strengths and weaknesses of particular kinds of design. We identify five patterns of aspect-oriented design: Spectator, Regulator, Patch, Extension, and Heterarchical Design. For each pattern, we describe the problem it solves, show how aspect-oriented language features are used in the pattern, give characteristic examples of the pattern’s use, and assess its benefits and liabilities. Our patterns provide the beginnings of a taxonomy of aspect-oriented design. We believe that they should help programmers to understand and evaluate existing aspect-oriented designs, to improve new designs, to make better use of the aspect-oriented features of new programming languages, and also guide those who wish to implement these patterns in non aspect-oriented languages. 1
