Co-evolving code and design with intensional views

Mens, Kim; Kellens, Andy; Pluquet, Frédéric; Wuyts, Roel

doi:10.1016/j.cl.2005.09.002

Cited by 56 publications

(49 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In earlier work [10], we presented the formalism of intensional views as a technique for describing a conceptual model of a program's structure and verifying consistency of that model with respect to the program. For the sake of completeness, we briefly repeat the formalism here, with a particular focus on those features that enable it to detect interesting evolution conflicts.…”

Section: Intensional Viewsmentioning

confidence: 99%

“…use the formalism of intensional views [10], and its associated tool suite IntensiVE 6 , to express a conceptual model of a program and to keep it synchronised with the source code of that program; 2. specify pointcuts in terms of this conceptual model, using an extension to the aspect-oriented language CARMA.…”

Section: Model-based Pointcutsmentioning

confidence: 99%

“…More specifically, we implement our particular solution to the fragile pointcut problem through an extension of the CARMA aspect language [9] combined with the formalism of intensional views [10]. The resulting approach tightly integrates the intensional views development tool with an aspect-oriented language.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Managing the Evolution of Aspect-Oriented Software with Model-Based Pointcuts

Kellens

Mens

Brichau

et al. 2006

ECOOP 2006 – Object-Oriented Programming

Self Cite

View full text Add to dashboard Cite

Abstract. In spite of the more advanced modularisation mechanisms, aspect-oriented programs still suffer from evolution problems. Due to the fragile pointcut problem, seemingly safe modifications to the base code of an aspect-oriented program can have an unexpected impact on the semantics of the pointcuts defined in that program. This can lead to broken aspect functionality due to accidental join point misses and unintended join point captures. We tackle this problem by declaring pointcuts in terms of a conceptual model of the base program, rather than defining them directly in terms of how the base program is structured. As such, we achieve an effective decoupling of the pointcuts from the base program's structure. In addition, the conceptual model provides a means to verify where and why potential fragile pointcut conflicts occur, by imposing structural and semantic constraints on the conceptual model, that can be verified when the base program evolves. To validate our approach we implemented a model-based pointcut mechanism, which we used to define some aspects on SmallWiki, a medium-sized application, and subsequently detected and resolved occurrences of the fragile pointcut problem when this application evolved.

show abstract

Section: Intensional Viewsmentioning

confidence: 99%

Section: Model-based Pointcutsmentioning

confidence: 99%

See 1 more Smart Citation

Managing the Evolution of Aspect-Oriented Software with Model-Based Pointcuts

Kellens

Mens

Brichau

et al. 2006

ECOOP 2006 – Object-Oriented Programming

Self Cite

View full text Add to dashboard Cite

show abstract

“…Besides reflexion models, another common solution for architecture conformance is centered on domain-specific languages, such as SCL [24], LogEn [7], DCL [6], Grok [25], Intensional Views [8], and DesignWizard [26]. Certainly, by using such languages it is possible to detect the same absences and divergences than ArchLint.…”

Section: Architecture Conformance Toolsmentioning

confidence: 99%

“…As a result, reflexion models can reveal two kinds of architectural anomalies: absences (relations prescribed by the high-level model that are not present in the concrete model) and divergences (relations not prescribed by the high-level model, but that are present in the concrete model). Alternatively, domain-specific languages with focus on architecture conformance provide means for architects to express in a customized syntax the constraints defined by the planned architecture [6]- [8].…”

Section: Introductionmentioning

confidence: 99%

Heuristics for discovering architectural violations

Maffort¹,

Valente²,

Bigonha³

et al. 2013

2013 20th Working Conference on Reverse Engineering (WCRE)

View full text Add to dashboard Cite

Abstract-Software architecture conformance is a key software quality control activity that aims to reveal the progressive gap normally observed between concrete and planned software architectures. In this paper, we present ArchLint, a lightweight approach for architecture conformance based on a combination of static and historical source code analysis. For this purpose, ArchLint relies on four heuristics for detecting both absences and divergences in source code based architectures. We applied ArchLint in an industrial-strength system and as a result we detected 119 architectural violations, with an overall precision of 46.7% and a recall of 96.2%, for divergences. We also evaluated ArchLint with four open-source systems, used in an independent study on reflexion models. In this second study, ArchLint achieved precision results ranging from 57.1% to 89.4%.

show abstract

Supporting requirements update during software evolution

Charrada

Koziolek

Glinz

2015

J Software Evolu Process

View full text Add to dashboard Cite

Updating the requirements specification when software systems evolve is a manual task that is expensive and time consuming. Therefore, maintainers usually apply the changes to the code directly and leave the requirements unchanged. This results in the requirements rapidly becoming obsolete and useless. In this paper, we propose an approach that supports the maintainer in keeping the requirements specification consistent with the implementation, by identifying the requirements that are impacted whenever the code is changed. Our approach works as follows. First, we analyze the changes that have been applied to the source code and detect if they are likely to impact the requirements or not. Second, we trace the requirements-impacting changes back to the requirements specification to identify the parts that might need to be modified. The output of the tracing is a list of requirements that are sorted according to their likelihood of being impacted. Automatically identifying the parts of the requirements specification that are likely to need maintenance reduces the effort needed for keeping the requirements up-to-date and thus makes the task of the maintainer easier. When applying our approach in three cases studies, 70% to 100% of the impacted requirements were identified within a list that includes less than 20% of the total number of requirements in the specification. SUMMARYUpdating the requirements specification when software systems evolve is a manual task that is expensive and time consuming. Therefore, maintainers usually apply the changes to the code directly and leave the requirements unchanged. This results in the requirements rapidly becoming obsolete and useless. In this paper, we propose an approach that supports the maintainer in keeping the requirements specification consistent with the implementation, by identifying the requirements that are impacted whenever the code is changed. Our approach works as follows. First, we analyze the changes that have been applied to the source code and detect if they are likely to impact the requirements or not. Second, we trace the requirements-impacting changes back to the requirements specification to identify the parts that might need to be modified. The output of the tracing is a list of requirements that are sorted according to their likelihood of being impacted. Automatically identifying the parts of the requirements specification that are likely to need maintenance reduces the effort needed for keeping the requirements up-to-date and thus makes the task of the maintainer easier. When applying our approach in three cases studies, 70% to 100% of the impacted requirements were identified within a list that includes less than 20% of the total number of requirements in the specification.

show abstract

Co-evolving code and design with intensional views

Cited by 56 publications

References 6 publications

Managing the Evolution of Aspect-Oriented Software with Model-Based Pointcuts

Managing the Evolution of Aspect-Oriented Software with Model-Based Pointcuts

Heuristics for discovering architectural violations

Supporting requirements update during software evolution

Contact Info

Product

Resources

About