On the Evolutionary Nature of Architectural Violations

Brunet, João; Bittencourt, Roberto A.; Serey, Dalton; Figueiredo, Jorge C. A. de

doi:10.1109/wcre.2012.35

Cited by 27 publications

(30 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The last point is clearly the most limiting factor. We investigated a number of further systems, e.g., from (Macia et al 2012a;Brunet et al 2012), but discarded them from our study, because they were either too small in terms of system size or an application of the reflexion modeling approach did not uncover architectural inconsistencies. Apart from these requirements, the source code of the systems is also available, as required for performing reflexion modeling and for applying some of the metric suites we used.…”

Section: Case Selectionmentioning

confidence: 99%

“…Its core search engine, which is the system in focus here, consists of more than 500 classes with more than 60,000 LOC. We modeled the architecture of Lucene using JITTAC based on an article by Brunet et al (Brunet et al 2012) which describes Lucene's architecture in terms of modules and allowed dependencies between modules as well as a mapping of modules to the source code of the system. One of the authors manually created a JITTAC model according to this description which was cross-checked for correctness and soundness by the two other authors.…”

Section: Case Selectionmentioning

confidence: 99%

“…As for Lucene, we use the latest version documented by Brunet et al (Brunet et al 2012), which describes Ant's intended architecture and the mapping to source code. This version is dated from 14 October 2007 and consists of more than 750 classes with roughly 92,000 LOC.…”

Section: Case Selectionmentioning

confidence: 99%

“…Two of these systems and their validated architectural models have been taken from the replication package of a different study (Brunet et al 2012). In case of the third system, the intended architecture has been developed and validated as part of this work during a number of video-conferencing sessions together with the current development team.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Exploring the suitability of source code metrics for indicating architectural inconsistencies

2018

View full text Add to dashboard Cite

Software architecture degradation is a phenomenon that frequently occurs during software evolution. Source code anomalies are one of the several aspects that potentially contribute to software architecture degradation. Many techniques for automating the detection of such anomalies are based on source code metrics. It is, however, unclear how accurate these techniques are in identifying the architecturally relevant anomalies in a system. The objective of this paper is to shed light on the extent to which source code metrics on their own can be used to characterize classes contributing to software architecture degradation. We performed a multi-case study on three open-source systems for each of which we gathered the intended architecture and data for 49 different source code metrics taken from seven different code quality tools. This data was analyzed to explore the links between architectural inconsistencies, as detected by applying reflexion modeling, and metric values indicating potential design problems at the implementation level. The results show that there does not seem to be a direct correlation between metrics and architectural inconsistencies. For many metrics, however, classes more problematic as indicated by their metric value seem significantly more likely to contribute to inconsistencies than less problematic classes. In particular, the fan-in, a classes' public API, and method counts seem to be suitable indicators. The fan-in metric seems to be a particularly interesting indicator, as class size does not seem to have a confounding effect on this metric. This finding may be useful for focusing code restructuring efforts on architecturally relevant metrics in case the intended architecture is not explicitly specified and to further improve architecture recovery and consistency checking tool support.

show abstract

Section: Case Selectionmentioning

confidence: 99%

Section: Case Selectionmentioning

confidence: 99%

Section: Case Selectionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Exploring the suitability of source code metrics for indicating architectural inconsistencies

2018

View full text Add to dashboard Cite

show abstract

“…Studies suggest that they are effective but, by-in-large, these studies focus on identification of inconsistencies only (Lindvall et al 2002;Tesoriero et al 2004) or identification and removal of inconsistencies (Bang and Medvidovic 2015;Brunet et al 2012Brunet et al , 2015Buckley et al 2015;Rosik et al 2011). In order to assess if there was literature directly targeted at practitioners' needs in the AC area, we carried out a targeted literature review of the IEEE and ACM search engines with a query search logically equivalent to Bsoftware AND architecture AND (conformance OR consistency) AND (empirical OR practice OR study).…”

Section: Practitioner Studiesmentioning

confidence: 99%

Architecture consistency: State of the practice, challenges and requirements

Alí

Baker

O’Crowley³

et al. 2017

Empir Software Eng

View full text Add to dashboard Cite

Architecture Consistency (AC) aims to align implemented systems with their intended architectures. Several AC approaches and tools have been proposed and empirically evaluated, suggesting favourable results. In this paper, we empirically examine the state of practice with respect to Architecture Consistency, through interviews with nineteen experienced software engineers. Our goal is to identify 1) any practises that the companies these architects work for, currently undertake to achieve AC; 2) any barriers to undertaking explicit AC approaches in these companies; 3) software development situations where practitioners perceive AC approaches would be useful, and 4) AC tool needs, as perceived by practitioners. We also assess current commercial AC tool offerings in terms of these perceived needs. The study reveals that many practitioners apply informal AC approaches as there are barriers for adopting more formal and Empir Software Eng (2018) 23:224-258 DOI 10.1007 The original version of this article was revised due to a retrospective Open Access order. Karlstad University, Karlstad, Sweden explicit approaches. These barriers are: 1) Difficulty in quantifying architectural inconsistency effects, and thus justifying the allocation of resources to fix them to senior management, 2) The near invisibility of architectural inconsistency to customers, 3) Practitioners' reluctance towards fixing architectural inconsistencies, and 4) Practitioners perception that huge effort is required to map the system to the architecture when using more formal AC approaches and tools. Practitioners still believe that AC would be useful in supporting several of the software development activities such as auditing, evolution and ensuring quality attributes. After reviewing several commercial tools, we posit that AC tool vendors need to work on their ability to support analysis of systems made up of different technologies, that AC tools need to enhance their capabilities with respect to artefacts such as services and meta-data, and to focus more on non-maintainability architectural concerns.

show abstract