Five Years of Software Architecture Checking: A Case Study of Eclipse

Abstract

Over time, source code tends to drift from the intended software architecture, often resulting in loss of desired software qualities. To help keep code aligned with intended architecture, the developers of core parts of the open source Eclipse platform introduced a tool to express and check architectural rules. We analyze five years of Eclipse architecture checking reports produced by the tool. We describe the kinds of rules the developers found helpful to check, how code diverges from intended architecture, and how developers deal with architectural violations over time.

Architecture consistency: State of the practice, challenges and requirements

“…Interestingly, all of the`participants that had used AC tools before their interviews, mentioned how they had identified inconsistencies, but had not subsequently fixed the majority of these inconsistencies. These results are in line with observations previously reported in empirical studies of RM (Rosik et al 2008) and other kinds of consistency approaches (Brunet et al 2015). In those studies several reasons were given for the lack of remediation that align with the findings reported here: the inconsistencies did not impact directly enough on customers or on the quality of the system, and their entanglement in their (highly coupled) code-bases suggested that remediation might lead to possible errors and ripple effects.…”

“…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).…”

“…Other empirical studies where practitioners' feedback has been provided are (Ali et al 2012;Brunet et al 2015;Buckley et al 2015;Le Gear et al 2005). In these works, the objective was to understand how practitioners have used the current AC approaches and report on the effectiveness of these approaches in identifying inconsistencies (e.g., what kinds of architectural inconsistencies are identified or how do developers identify inconsistencies).…”

“…& Feature-oriented views of the system , where a feature is considered an end-user functionality. & The ability to specify architectural rules in a more intuitive way (Brunet et al 2015).…”

“…The studies presented in (Ali et al 2012;Buckley et al 2015) also characterized users' architecture modelling, in terms of their mapping of code to the architecture, the types of architectural inconsistencies that they encountered and their usage of an AC tool in general, over five industrial case studies. Likewise Brunet et al (2015) studied how developers of the Eclipse open source project used an AC tool for describing architectural rules, the kind of inconsistencies they found, and how they dealt with them. However, none of these empirical studies have explored the stated AC needs of practitioners in practice and whether AC tools meet these requirements.…”