Results 11 - 20
of
55
Aspectual Mixin Layers: Aspects and Features in Concert
- In Proc. of Intl. Conf. on Software Engineering
, 2006
"... Feature-Oriented Programming (FOP) decomposes complex software into features. Features are main abstractions in design and implementation. They reflect user requirements and incrementally refine one another. Although, features crosscut object-oriented architectures they fail to express all kinds of ..."
Abstract
-
Cited by 29 (10 self)
- Add to MetaCart
Feature-Oriented Programming (FOP) decomposes complex software into features. Features are main abstractions in design and implementation. They reflect user requirements and incrementally refine one another. Although, features crosscut object-oriented architectures they fail to express all kinds of crosscutting concerns. This weakness is exactly the strength of aspects, the main abstraction mechanism of Aspect-Oriented Programming (AOP). In this article we contribute a systematic evaluation and comparison of both paradigms, AOP and FOP, with focus on incremental software development. It reveals that aspects and features are not competing concepts. In fact AOP has several strengths to improve FOP in order to implement crosscutting features. Symmetrically, the development model of FOP can aid AOP in implementing incremental designs. Consequently, we propose the architectural integration of aspects and features in order to profit from both paradigms. We introduce aspectual mixin layers (AMLs), an implementation approach that realizes this symbiosis. A subsequent evaluation and a case study reveal that AMLs improve the crosscutting modularity of features as well as aspects become well integrated into incremental development style.
A Model for Developing Component-Based and Aspect-Oriented Systems
- in 5th Int. Symposium on Software Composition (SC), ser. LNCS
, 2006
"... Abstract. Aspect-Oriented Programming (AOP) and Component-Based Software Engineering (CBSE) offer solutions to improve the separation of concerns and to enhance a program structure. If the integration of AOP into CBSE has already been proposed, none of these solutions focus on the application of CBS ..."
Abstract
-
Cited by 24 (1 self)
- Add to MetaCart
Abstract. Aspect-Oriented Programming (AOP) and Component-Based Software Engineering (CBSE) offer solutions to improve the separation of concerns and to enhance a program structure. If the integration of AOP into CBSE has already been proposed, none of these solutions focus on the application of CBSE principles to AOP. In this paper we propose a twofold integration of AOP and CBSE. We introduce a general model for components and aspects, named Fractal Aspect Component (FAC). FAC decomposes a software system into regular components and aspect components (ACs), where an AC is a regular component that embodies a crosscutting concern. We reify the aspect domain of an AC and the relationship between an AC and a component, called an aspect binding, as first-class runtime entities. This clarifies the architecture of a system where components and aspects coexist. The system can evolve from the design to the execution by adding or removing components, aspects or bindings. 1
AOP for Dynamic Configuration and Management of Web Services
, 2003
"... Web service technologies accelerate application development by allowing the selection and integration of third-party web services, achieving high modularity, flexibility and configurability. However, current approaches only allow this integration by hard wiring the references to concrete web serv ..."
Abstract
-
Cited by 22 (6 self)
- Add to MetaCart
Web service technologies accelerate application development by allowing the selection and integration of third-party web services, achieving high modularity, flexibility and configurability. However, current approaches only allow this integration by hard wiring the references to concrete web services into the client applications. Moreover they do not provide any management support, which is fundamental for achieving robustness. We observe the need for the application to be independent of specific services and present the WSML, a management layer placed in between the application and the world of web services. In this paper we identify the requirements for this layer to realise the dynamic selection and integration of services, client-side management of services, and support for rules that govern the selection, integration and composition.
Model-View-Controller and Object Teams: A Perfect Match of Paradigms
- In AOSD’03 [2
, 2003
"... From the early days of object-oriented programming, the model-view-controller paradigm has been pursued for a clear design which separates different responsibilities within an interactive application. In contrast to its untyped implementation in Smalltalk, any implementation in a statically typed la ..."
Abstract
-
Cited by 20 (5 self)
- Add to MetaCart
From the early days of object-oriented programming, the model-view-controller paradigm has been pursued for a clear design which separates different responsibilities within an interactive application. In contrast to its untyped implementation in Smalltalk, any implementation in a statically typed language involves certain trade-offs which either blur the clear structure, destroy the intended independence, or introduce undue administrative overhead. Each alternative creates a dierent caricature of the originally crisp architecture. The programming model Object Teams provides a new modeling unit called Team plus a number of binding mechanisms by which a Team and its contained roles can be bound to existing parts of an application. It turns out that these mechanisms fit nicely for implementing a clear model-view -controller design not only for single elements but also for complex structures of GUI elements plus their binding to complex model structures. We furthermore propose to use the model-view-controller paradigm as a benchmark for AOSD approaches, since it combines a set of typical problems concerning the separation and integration of concerns.
DADO: Enhancing middleware to support cross-cutting features in distributed, heterogeneous systems
, 2003
"... Some "non-' or "extra-functional" features, such as reliability, security, and tracing, defy modularization mechanisms in programming languages. This makes such features hard to design, implement, and maintain. Implementing such features within a single platform, using a single language, is hard eno ..."
Abstract
-
Cited by 19 (4 self)
- Add to MetaCart
Some "non-' or "extra-functional" features, such as reliability, security, and tracing, defy modularization mechanisms in programming languages. This makes such features hard to design, implement, and maintain. Implementing such features within a single platform, using a single language, is hard enough. With distributed, heterogeneous (DH) systems, these features induce complex implementations which cross-cut different languages, OSs, and hardware platforms, while still needing to share data and events. Worse still, the precise requirements for such features are often locality-dependent and discovered late (e.g., security policies). The DADO approach helps program cross-cutting features by improving middleware. A DADO service comprises pairs of adaplets which are explicitly modeled in IDL. Adaplets may be implemented in any language compatible with the target application, and attached to stubs and skeletons of application objects in a variety of ways. DADO supports flexible and type-checked interactions (using generated stubs and skeletons) between adaplets and between adaplets and objects. Adaplets can be attached at run-time to an application object. We describe the approach and illustrate its use for several cross-cutting features, including performance monitoring, caching, and security. We also discuss software engineering process, as well as run-time performance implications.
Cross-cutting techniques in program specification and analysis
- In 4th International Conference on Aspect-Oriented Software Development (AOSD’05
, 2005
"... We present three aspect-oriented constructs (formats, scopes, and defaults) that, in combination with a specification language based on abstract sets of objects, enable the modular application of multiple arbitrarily precise (and therefore arbitrarily unscalable) analyses to scalably verify data str ..."
Abstract
-
Cited by 18 (11 self)
- Add to MetaCart
We present three aspect-oriented constructs (formats, scopes, and defaults) that, in combination with a specification language based on abstract sets of objects, enable the modular application of multiple arbitrarily precise (and therefore arbitrarily unscalable) analyses to scalably verify data structure consistency properties in sizable programs. Formats use a form of field introduction to group together the declarations of all of the fields that together comprise a given data structure. Scopes and defaults enable the developer to state certain data structure consistency properties once in a single specification construct that cuts across the preconditions and postconditions of the procedures in the system. Standard approaches, in contrast, scatter and duplicate such properties across the preconditions and postconditions. We have implemented a prototype implementation, specification, analysis, and verification system based on these constructs and used this system to successfully verify a range of data structure consistency properties in several programs. Most previous research in the field of aspect-oriented programming has focused on the use of aspect-oriented concepts in design and implementation. Our experience indicates that aspect-oriented concepts can also be extremely useful for specification, analysis, and verification.
Optimizing JAsCo dynamic AOP through HotSwap and Jutta
- Dynamic Aspects Workshop
, 2004
"... The main drawback of all dynamic AOP technologies available today is the rather high performance overhead in comparison to static weaving approaches. In this paper, we propose an approach to improve the performance of both the interception mechanism and the aspect interpreter of a dynamic AOP system ..."
Abstract
-
Cited by 13 (4 self)
- Add to MetaCart
The main drawback of all dynamic AOP technologies available today is the rather high performance overhead in comparison to static weaving approaches. In this paper, we propose an approach to improve the performance of both the interception mechanism and the aspect interpreter of a dynamic AOP system. The interception of the base application is optimized by employing the Java HotSwap technology in such a way that only those joinpoints where aspects are applied upon are trapped. When new aspects are added, all corresponding joinpoints are hotswapped for a trapped version. Likewise, when aspects are removed, the corresponding traps are removed, if no other aspect is applicable at the given trap. In order to improve the aspect interpreter, we propose the Jutta system that allows generating and caching a highly optimized code fragment for each joinpoint. This code fragment contains the combined aspectual behavior for the joinpoint at hand. We integrate HotSwap and Jutta in the JAsCo dynamic AOP system and perform extensive benchmarks to evaluate the performance gain of this approach. In addition, the enhanced JAsCo performance is compared to a selection of current state-of-the-art dynamic AOP approaches. These benchmarks indicate that JAsCo, enhanced with HotSwap and Jutta, is able to improve on the current state-of-the-art performance-wise.
Aspect-Oriented Programming with Jiazzi
, 2003
"... We present aspect-oriented programming in Jiazzi. Jiazzi enhances Java with separately compiled, externally-linked code modules called units. Besides making programming in Java generally more modular, units are also effective "aspect" constructs that can separate concerns. The unit-linking metaphor ..."
Abstract
-
Cited by 12 (2 self)
- Add to MetaCart
We present aspect-oriented programming in Jiazzi. Jiazzi enhances Java with separately compiled, externally-linked code modules called units. Besides making programming in Java generally more modular, units are also effective "aspect" constructs that can separate concerns. The unit-linking metaphor provides a convenient and explicit way for programmers to explicitly control the inclusion and configuration of code that implements a concern, while separate compilation of units enhances concern independent development and deployment. The expressiveness of concern separation are enhanced by units in two ways. First, classes can be made open to the addition of new fields and methods by multiple units, which enables the direct modularization of concerns that crosscut objects. Second, the signatures of methods and classes used in a unit can be made open to refinement by other units, which makes it easier to integrate concern implementations by isolating them from the naming and calling requirements of shared methods and classes.
Combining Composition Styles in the Evolvable Language LAC
, 2001
"... Languages for Advanced Separation of Concerns (ASoC) have seen some rapid development during the last years. The current state is, however, in a way undefined. Some experience exists, where academic developers have applied ASoC technology to moderately sized systems. There is still more need for emp ..."
Abstract
-
Cited by 11 (8 self)
- Add to MetaCart
Languages for Advanced Separation of Concerns (ASoC) have seen some rapid development during the last years. The current state is, however, in a way undefined. Some experience exists, where academic developers have applied ASoC technology to moderately sized systems. There is still more need for empirical studies in this field. None of the proposed languages really has yet proven its maturity for industrial style application. The different language models pursued by different groups of researchers share the same intention of improving modularity in situations that where not support well by traditional languages. In spite of this common motivation, available ASoC languages are not necessarily compatible. Partly, they in fact address different sub-problems of broken modularity, partly, they utilize incompatible concepts for similar problems. The great merger has not happened. While the two leading language implementations, AspectJ and Hyper/J are elaborated up-to a p...
Aspect Oriented Software Architecture: a Structural Perspective
- In Proceedings of the Aspect-Oriented Software Development, 2002, The
, 2002
"... The positive results obtained by researchers on aspect-oriented programming during the last few years are promoting the aim to export their ideas to the whole software development process. One of the stages in which Aspect Oriented Software Development (AOSD) techniques can be introduced is software ..."
Abstract
-
Cited by 8 (1 self)
- Add to MetaCart
The positive results obtained by researchers on aspect-oriented programming during the last few years are promoting the aim to export their ideas to the whole software development process. One of the stages in which Aspect Oriented Software Development (AOSD) techniques can be introduced is software architectural design. This would make design of complex systems an easier task whilst cost development, cost maintenance, reuse, etc., would be improved. However, integrating both architectural design and aspect orientation is a non-trivial task. The different nature of the aspects that can be involved in an application and the different requirements that applications impose on the treatment of aspects make it difficult to handle aspects in a uniform way while at the same time preserving the simplicity of the design process. In this study the structure of the problem of separation of crosscutting concerns in the architectural design based on the aspect oriented approach is analysed. The analysis will identify the kind of changes that must be made in the current technology to manage this sort of integration. In particular, this paper focuses on how aspects separation can be handled by Architecture Description Languages and architectural styles. The aim of this article is not to propose a particular solution but to propose some general guidelines on which solutions can be based.

