On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study

Greenwood, Philip; Bartolomei, Thiago Tonelli; Figueiredo, Eduardo; Dósea, Marcos; Garcia, Alessandro; Cacho, Nélio; Sant’Anna, Cláudio; Soares, Sérgio; Borba, Paulo; Kulesza, Uirá; Rashid, Awais

doi:10.1007/978-3-540-73589-2_9

Cited by 115 publications

(232 citation statements)

References 27 publications

Supporting

Mentioning

222

Contrasting

Order By: Relevance

“…The advocates of AOP claim that the refactored versions of Telestrada [8,16], Pet Store [8,16] , CVS Core Plugin [8,16], EImp Plugin [8], Health Watcher [19,36], and Prevayler [18] exhibit lower coupling. However, they take into account only a subset of the dependencies that generate coupling in AO systems.…”

Section: Table 2 Results For Size Coupling and Cohesion Metricsmentioning

confidence: 99%

“…AOP emergenced as a new paradigm to modularize the concerns whose implementations would otherwise have been spread throughout the whole application, because of the limited abstractions of the underlying programming languages. Since then, several studies [15,16,17,19,35,36] have suggested that AOP is successful in modularizing crosscutting concerns. Unfortunately, these studies either wrongly identify modularization with the lexical SoC offered by AOP, or wrongly measure coupling in AO systems.…”

Section: Motivations and Goalsmentioning

confidence: 99%

“…The next work (Health Watcher) [19], [36] goes beyond refactoring of exception handling including concerns such as data persistence, concurrency and distribution (basic remote access to system services using Java RMI). Both the OO and AO designs of the Health Watcher system were developed with modularity and changeability principles as main driving design criteria.…”

Section: Selected Systemsmentioning

confidence: 99%

“…In the first group [8,16,19,25], new kinds of coupling introduced by pointcuts are not considered at all. In the second group [21,42], the coupling introduced by a pointcut is considered only if a module is explicitly named by the pointcut expression.…”

Section: Related Workmentioning

confidence: 99%

See 3 more Smart Citations

Where the Truth Lies: AOP and Its Impact on Software Modularity

Przybyłek

2011

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

Abstract. Modularity is the single attribute of software that allows a program to be intellectually manageable [29]. The recipe for modularizing is to define a narrow interface, hide an implementation detail, keep low coupling and high cohesion. Over a decade ago, aspect-oriented programming (AOP) was proposed in the literature to "modularize the un-modularizable" [24]. Since then, aspect-oriented languages have been providing new abstraction and composition mechanisms to deal with concerns that could not be modularized because of the limited abstractions of the underlying programming language. This paper is a continuation of our earlier work [32] and further investigates AO software with regard to coupling and cohesion. We compare two versions (Java and AspectJ) of ten applications to review AOP within the context of software modularity. It turns out that the claim that "the software built in AOP is more modular than the software built in OOP" is a myth.

show abstract

Section: Table 2 Results For Size Coupling and Cohesion Metricsmentioning

confidence: 99%

Section: Motivations and Goalsmentioning

confidence: 99%

Section: Selected Systemsmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Where the Truth Lies: AOP and Its Impact on Software Modularity

Przybyłek

2011

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

show abstract

“…A number of pure code-level approaches have also shown that AO source code may improve certain software qualities (e.g. [30,31]). Obviously, this approach will not work if OO source code is required.…”

Section: Interspace Compositionsmentioning

confidence: 99%

Specifying and Composing Concerns Expressed in Domain-Specific Modeling Languages

Hovsepyan

Baelen

Berbers

et al. 2009

Objects, Components, Models and Patterns

View full text Add to dashboard Cite

Summary. Separation of concerns and levels of abstraction are key software engineering principles that can help master the increasing complexity of software applications. Aspect-oriented modeling (AOM) and domain-specific modeling languages (DSML) are two important and promising approaches in this context. However, little research is done to investigate the synergy between AOM and DSMLs. In this paper we present an asymmetric approach to compose modularized concerns expressed in different DSMLs with an application base model expressed in a general-purpose modeling language (GPML). This allows to specify each concern in the most appropriate modeling language. We introduce the concept of a concern interface, expressed in a GPML, that serves as a common language between a specific concern and the application base. In addition, we use an explicit composition model to specify the syntactic and the semantic links between entities from the different concerns. We explore these concepts using an application where we modularize the user interface modeled in WebML and the access control specified in XACML. The modularized concerns are then composed with an application base that has been specified in UML.

show abstract

Aspect‐Oriented Software Development: an Introduction

Brichau

Chitchyan

Rashid

et al. 2008

Wiley Encyclopedia of Computer Science and Engineering

View full text Add to dashboard Cite

Modularity of software has long been the primary mechanism used in software development to improve reuse and support maintainability. However, certain concerns do not fit the module boundaries in contemporary software‐development paradigms. The consequence of such crosscutting concerns, such as logging, persistence, security, and so forth, is that the responsibilities of the individual modules are not clearly demarcated. Not only is a module responsible for its core state and behavior (pertaining to its business functionality, for instance) but also for that of the crosscutting concern (such as logging). This phenomenon is referred to as tangling. At the same time, we observe the scattering effect whereby a given crosscutting concem,for example, logging, is not modularized in a single element and hence hampers our ability to reason about its effect and behavior with respect to the other modules; such reasoning requires inspection of all the modules where logging is realized. This requirement goes against the established best practice of separation of concerns because the crosscutting effect results in software that is difficult to understand and maintain. Addressing this problem of crosscutting is the main focus of aspect‐oriented software‐development (AOSD) techniques. In this article, we provide an introduction to AOSD by highlighting how it provides systematic support for identification, modularization, and composition of crosscutting concerns throughout the software lifecycle.

show abstract

On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study

Cited by 115 publications

References 27 publications

Where the Truth Lies: AOP and Its Impact on Software Modularity

Where the Truth Lies: AOP and Its Impact on Software Modularity

Specifying and Composing Concerns Expressed in Domain-Specific Modeling Languages

Aspect‐Oriented Software Development: an Introduction

Contact Info

Product

Resources

About