Managing Concern Interfaces

Boulanger, Jean-Sébastien; Robillard, Martin P.

doi:10.1109/icsm.2006.35

Cited by 8 publications

(6 citation statements)

References 12 publications

(21 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…From such, 5 caused the clients to react as in the frameworks. Thus, our results reinforce (at large-scale and ecosystem level) previous studies (Dagenais and Robillard, 2008;Boulanger and Robillard, 2006;Businge et al, 2013;Hora et al, 2016), showing that client systems use internal parts of frameworks to access functionalities not available in the public interfaces for a variety of reasons. Based on these results we conclude the following: Internal APIs are sometimes used by client developers in the ecosystem under analysis.…”

Section: Summary and Implicationssupporting

confidence: 89%

How do developers react to API evolution? A large-scale empirical study

et al. 2016

View full text Add to dashboard Cite

Software engineering research now considers that no system is an island, but it is part of an ecosystem involving other systems, developers, and users. When a framework or a library evolves, its clients often must adapt. For example, client developers might need to adapt to functionalities, client systems might need to be adapted to a new API, and client users might need to adapt to a new user interface. The consequences of these changes are yet unclear: what proportion of the ecosystem might be expected to react, how long might it take for a change to diffuse in the ecosystem, do all clients react in the same way? This paper reports an exploratory study aimed at observing API evolution and its impact on a large software ecosystem, Pharo, which has about 3,600 distinct systems, and six years of evolution. We analyze 118 API changes in the context of method replacement and suggestion, and answer research questions regarding the magnitude, duration, extension, and consistency of such changes in the ecosystem. The results of this study help to characterize the impact of API evolution in large software ecosystems and provide the basis to better understand how such impact can be alleviated.

show abstract

Section: Summary and Implicationssupporting

confidence: 89%

How do developers react to API evolution? A large-scale empirical study

et al. 2016

View full text Add to dashboard Cite

show abstract

“…In fact, contradicting previous research claims [36], not all forms of tangled or scattered concerns were found to be harmful to software maintainability in practice [2]. Other concern properties are likely to better characterize the manifestation of code smells, including: (i) how a concern traverses a particular hierarchical structure of a program [2], (ii) how a concern contributes to properties of a module, such as its interface size [33], coupling and cohesion [33], and (iii) how two or more concerns interact in the source code [8] [33], such as their inter-dependencies and overlapping. Unfortunately, there is no investigation analyzing to which extent such concern properties support programmers on identifying code smells.…”

Section: Introductioncontrasting

confidence: 50%

Identifying Code Smells with Multiple Concern Views

Carneiro¹,

Silva

Mara

et al. 2010

2010 Brazilian Symposium on Software Engineering

View full text Add to dashboard Cite

Code smells are anomalies often caused by the way concerns are realized in the source code. Their identification might depend on properties governing the structure of individual concerns and their inter-dependencies in the system implementation. Although code visualization tools are increasingly applied to support anomaly detection, they are mostly limited to represent modular structures, such as methods, classes and packages. This paper presents a multiple views approach that enriches four categories of code views with concern properties, namely: (i) concern's package-classmethod structure, (ii) concern's inheritance-wise structure, (iii) concern dependency, and (iv) concern dependency weight. An exploratory study was conducted to assess the extent to which visual views support code smell detection. Developers identified a set of well-known code smells on five versions of an opensource system. Two important results came out of this study. First, the concern-driven views provided useful support to identify God Class and Divergent Change smells. Second, strategies for smell detection supported by the multiple concern views were uncovered.

show abstract

“…parts of frameworks for a variety of good reasons, such as accessing functionality that goes beyond the ones available in the public interfaces [1].…”

Section: Introductionmentioning

confidence: 99%

Recommending adaptive changes for framework evolution

Dagenais

Robillard

2008

Proceedings of the 13th International Conference on Software Engineering - ICSE '08

130

View full text Add to dashboard Cite

In the course of a framework's evolution, changes ranging from a simple refactoring to a complete rearchitecture can break client programs. Finding suitable replacements for framework elements that were accessed by a client program and deleted as part of the framework's evolution can be a challenging task. We present a recommendation system, SemDiff, that suggests adaptations to client programs by analyzing how a framework adapts to its own changes. In a study of the evolution of the Eclipse JDT framework and three client programs, our approach recommended relevant adaptive changes with a high level of precision, and detected non-trivial changes typically undiscovered by current refactoring detection techniques.

show abstract

Managing Concern Interfaces

Cited by 8 publications

References 12 publications

How do developers react to API evolution? A large-scale empirical study

How do developers react to API evolution? A large-scale empirical study

Identifying Code Smells with Multiple Concern Views

Recommending adaptive changes for framework evolution

Contact Info

Product

Resources

About