Results 1 - 10
of
85
On the Modular Representation of Architectural Aspects
- In Proc. of the European Workshop on Software Architecture
, 2006
"... Abstract. An architectural aspect is a concern that cuts across architecture modularity units and cannot be effectively modularized using the given abstractions of conventional Architecture Description Languages (ADLs). Dealing with crosscutting concerns is not a trivial task since they affect each ..."
Abstract
-
Cited by 21 (4 self)
- Add to MetaCart
Abstract. An architectural aspect is a concern that cuts across architecture modularity units and cannot be effectively modularized using the given abstractions of conventional Architecture Description Languages (ADLs). Dealing with crosscutting concerns is not a trivial task since they affect each other and the base architectural decomposition in multiple heterogeneous ways. The lack of ADL support for modularly representing such aspectual heterogeneous influences leads to a number of architectural breakdowns, such as increased maintenance overhead, reduced reuse capability, and architectural erosion over the lifetime of a system. On the other hand, software architects should not be burdened with a plethora of new ADL abstractions directly derived from aspect-oriented implementation techniques. However, most aspect-oriented ADLs rely on a heavyweight approach that mirrors programming languages concepts at the architectural level. In addition, they do not naturally support heterogeneous architectural aspects and proper resolution of aspect interactions. This paper presents AspectualACME, a simple and seamless extension of the ACME ADL to support the modular representation of architectural aspects and their multiple composition forms. AspectualACME promotes a natural blending of aspects and architectural abstractions by employing a special kind of architectural connector, called Aspectual Connector, to encapsulate aspect-component connection details. We have evaluated the applicability and scalability of the AspectualACME features in the context of three case studies from different application domains.
Domain Models are NOT Aspect Free
- In MODELS
, 2006
"... domain models are aspect free. Steimann’s hypothesis is that the notion of aspect in aspect-oriented software development (AOSD) is a meta-level concept. He concludes that aspects are technical concepts, i.e., a property of programming and not a means to reason about domain concepts in a modular fas ..."
Abstract
-
Cited by 19 (2 self)
- Add to MetaCart
(Show Context)
domain models are aspect free. Steimann’s hypothesis is that the notion of aspect in aspect-oriented software development (AOSD) is a meta-level concept. He concludes that aspects are technical concepts, i.e., a property of programming and not a means to reason about domain concepts in a modular fashion. In this paper we argue otherwise. We highlight that, by ignoring the body of work on Early Aspects, Steimann in fact ignores the problem domain itself. Early Aspects techniques support improved modular and compositional reasoning about the problem domain. Using concrete examples we argue that domain models do indeed have aspects which need first-class support for such reasoning. Steimann’s argument is based on treating quantification and obliviousness as fundamental properties of AOSD. Using concrete application studies we challenge this basis and argue that abstraction, modularity and composability are much more fundamental. 1.
How AspectJ is used: An analysis of eleven Aspectj programs
- J. Obj. Tech. 9
, 2008
"... Abstract. While it is well-known that crosscutting concerns occur in many software projects, little is known on how aspect-oriented program-ming and in particular AspectJ have been used. In this paper, we ana-lyze eleven AspectJ programs by different authors to answer the ques-tions: which mechanism ..."
Abstract
-
Cited by 16 (12 self)
- Add to MetaCart
(Show Context)
Abstract. While it is well-known that crosscutting concerns occur in many software projects, little is known on how aspect-oriented program-ming and in particular AspectJ have been used. In this paper, we ana-lyze eleven AspectJ programs by different authors to answer the ques-tions: which mechanisms are used, to what extent, and for what purpose. We found the code of these programs to be on average 86 % object-oriented, 12 % basic AspectJ mechanisms (introductions and method ex-tensions), and 2 % advanced AspectJ mechanisms (homogeneous advice or advanced dynamic advice). There is one class of crosscutting concerns – which is mostly concerned with introductions and method extensions – that matches this result well: collaborations. These results and our discussions with program authors indicate the bulk of coding activities was implementing collaborations. Several studies and researchers suggest that languages explicitly supporting collaborations are better suited than aspects a ̀ la AspectJ for this task. 1
On the Maintainability of Aspect-Oriented Software: A Concern-Oriented Measurement Framework
- Proc. of European Conf. on
, 2008
"... Aspect-oriented design needs to be systematically assessed with respect to modularity flaws caused by the realization of driving system concerns, such as tangling, scattering, and excessive concern dependencies. As a result, innovative concern metrics have been defined to support quantitative analys ..."
Abstract
-
Cited by 14 (2 self)
- Add to MetaCart
(Show Context)
Aspect-oriented design needs to be systematically assessed with respect to modularity flaws caused by the realization of driving system concerns, such as tangling, scattering, and excessive concern dependencies. As a result, innovative concern metrics have been defined to support quantitative analyses of concern’s properties. However, the vast majority of these measures have not yet being theoretically validated and managed to get accepted in the academic or industrial settings. The core reason for this problem is the fact that they have not been built by using a clearly-defined terminology and criteria. This paper defines a concern-oriented framework that supports the instantiation and comparison of concern measures. The framework subsumes the definition of a core terminology and criteria in order to lay down a rigorous process to foster the definition of meaningful and well-founded concern measures. In order to evaluate the framework generality, we demonstrate the framework instantiation and extension to a number of concern measures suites previously used in empirical studies of aspect-oriented software maintenance. 1.
Measuring and Characterizing Crosscutting in Aspect-Based Programs: Basic Metrics and Case Studies
- In Proc. Int’l Conf. Fundamental Approaches to Software Engineering
, 2007
"... Abstract. Aspects are defined as well-modularized crosscutting concerns. Despite being a core tenet of Aspect Oriented Programming, little research has been done in characterizing and measuring crosscutting concerns. Some of the issues that have not been fully explored are: What kinds of crosscuttin ..."
Abstract
-
Cited by 14 (8 self)
- Add to MetaCart
(Show Context)
Abstract. Aspects are defined as well-modularized crosscutting concerns. Despite being a core tenet of Aspect Oriented Programming, little research has been done in characterizing and measuring crosscutting concerns. Some of the issues that have not been fully explored are: What kinds of crosscutting concerns exist? What language constructs do they use? And what is the impact of crosscutting in actual Aspect Oriented programs? In this paper we present basic code metrics that categorize crosscutting according to the number of classes crosscut and the language constructs used. We applied the metrics to four non-trivial open source programs implemented in AspectJ. We found that for these systems, the number of classes crosscut by advice per crosscutting is small in relation to the number of classes in the program. We argue why we believe this result is not atypical for Aspect Oriented programs and draw a relation to other non-AOP techniques that provide crosscutting. 1
Towards a catalogue of refactorings and code smells for AspectJ
- IN T. ASPECT-ORIENTED SOFTWARE DEVELOPMENT I
, 2006
"... In this paper, we contribute to the characterisation of a programming style specific to aspect-oriented programming. For this purpose, we present a collection of refactorings for aspect-oriented source code, comprising refactorings to enable extraction to aspects of crosscutting concerns from objec ..."
Abstract
-
Cited by 13 (3 self)
- Add to MetaCart
In this paper, we contribute to the characterisation of a programming style specific to aspect-oriented programming. For this purpose, we present a collection of refactorings for aspect-oriented source code, comprising refactorings to enable extraction to aspects of crosscutting concerns from objectoriented legacy code, the subsequent tidying up of the extracted aspects and factoring out of common code from similar aspects to superaspects. The second group of refactorings is documented in detail. In addition, we propose some new aspect-oriented code smells, including one smell that is specific to aspect modules. We also propose a reinterpretation of some of the traditional objectoriented code smells in the light of aspect-orientation, to detect the presence of crosscutting concerns.
A Framework and Tool Supports for Testing Modularity of Software Design
- ASE'07
, 2007
"... Modularity is one of the most important properties of a software design, with significant impact on changeability and evolvability. However, a formalized and automated approach is lacking to test and verify software design models against their modularity properties, in particular, their ability to a ..."
Abstract
-
Cited by 9 (6 self)
- Add to MetaCart
Modularity is one of the most important properties of a software design, with significant impact on changeability and evolvability. However, a formalized and automated approach is lacking to test and verify software design models against their modularity properties, in particular, their ability to accommodate potential changes. In this paper, we propose a novel framework for testing design modularity. The software artifact under test is a software design. A test input is a potential change to the design. The test output is a modularity vector, which precisely captures quantitative capability extents of the design for accommodating the test input (the potential change). Both the design and the test input are represented as formal computable models to enable automatic testing. The modularity vector integrates the net option value analysis with wellknown design principles. We have implemented the framework with tool supports and tested aspect-oriented and object-oriented design patterns in terms of their ability to accommodate sequences of possible changes. The results showed that previous informal, implementation-based analysis can be conducted by our framework automatically and quantitatively at the design level. This framework also opens the opportunities of applying testing techniques, such as coverage criteria, on software designs.
On the Duality of Aspect-Oriented and Feature-Oriented Design Patterns
- In Workshop on Aspects, Components, and Patterns for Infrastructure Software
, 2007
"... Design patterns aim at improving reusability and variability of object-oriented software. Despite a notable success, aspect-oriented programming (AOP) has been discussed recently to improve the design pattern implementations. In another line of research it has been noticed that featureoriented progr ..."
Abstract
-
Cited by 8 (4 self)
- Add to MetaCart
(Show Context)
Design patterns aim at improving reusability and variability of object-oriented software. Despite a notable success, aspect-oriented programming (AOP) has been discussed recently to improve the design pattern implementations. In another line of research it has been noticed that featureoriented programming (FOP) is related closely to AOP and that FOP suffices in many situations where AOP is commonly used. In this paper we explore the assumed duality between AOP and FOP mechanisms. As a case study we use the aspect-oriented design pattern implementations of Hannemann and Kiczales. We observe that almost all of the 23 aspect-oriented design pattern implementations can be transformed straightforwardly into equivalent featureoriented design patterns. For further investigations we provide a set of general rules how to transform aspect-oriented programs into feature-oriented programs.
A reusable observer pattern implementation using package templates
- In ACP4IS ’09: Proceedings of the 8th workshop on Aspects, components, and patterns for infrastructure software
, 2009
"... This is the authors ' version of the work. It is posted here by permission of ACM for your personal use. ..."
Abstract
-
Cited by 6 (5 self)
- Add to MetaCart
(Show Context)
This is the authors ' version of the work. It is posted here by permission of ACM for your personal use.
Implementing Framework Crosscutting Extensions with EJPs and AspectJ
- Proceedings of the ACM SIGSoft 20 th Brazilian Symposium on SoftwareEngineering (SBES’2006
, 2006
"... Abstract. In a previous work, we proposed a framework extension approach based on the use of a new concept, called Extension Join Points (EJPs). EJPs enable the framework systematic extension by means of variability and integration aspects. In this paper, we show how EJPs can be implemented using th ..."
Abstract
-
Cited by 5 (4 self)
- Add to MetaCart
(Show Context)
Abstract. In a previous work, we proposed a framework extension approach based on the use of a new concept, called Extension Join Points (EJPs). EJPs enable the framework systematic extension by means of variability and integration aspects. In this paper, we show how EJPs can be implemented using the mechanisms of the AspectJ language. To evaluate the usefulness of the EJPs in the framework extension process, we have used them in the development of three OO frameworks from different domains. As a result of our case studies, we present: (i) an initial categorization of different kinds of contracts between frameworks, EJPs and aspects which can be implemented in AspectJ; and (ii) a set of lessons learned when specifying the EJPs. Resumo. Uma abordagem para extensão de frameworks baseada em um novo conceito, denominado Extension Join Points (EJPs), tem sido proposta anteriormente. EJPs possibilitam a extensão sistemática de frameworks, através do uso de aspectos de variabilidade e integração. Neste artigo, nós mostramos como os EJPs podem ser implementados usando os mecanismos da linguagem AspectJ. Para avaliar a utilidade dos EJPs no processo de extensão de frameworks, nós os utilizamos no desenvolvimento de 3 frameworks OO de diferentes domínios. Como um resultado de nossos estudos de caso, nós apresentamos: (i) uma categorização inicial de diferentes tipos de contratos entre frameworks, EJPs e aspectos, os quais podem ser implementados em AspectJ; e (ii) um conjunto de lições aprendidas quando especificando os EJPs. 1.
