A recommendation system for repairing violations detected by static architecture conformance checking

Ricardo Terra, Marco Tulio Valente, Krzysztof Czarnecki, Roberto S. Bigonha
2013 Software, Practice & Experience  
This paper describes a recommendation system that provides refactoring guidelines for maintainers when tackling architectural erosion. The paper formalizes 32 refactoring recommendations to repair violations raised by static architecture conformance checking approaches; it describes a tool-called ArchFix-that triggers the proposed recommendations; and it evaluates the application of this tool in two industrial-strength systems. For the first system-a 21 KLOC open-source strategic management
more » ... em-our approach has indicated correct refactoring recommendations for 31 out of 41 violations detected as the result of an architecture conformance process. For the second system-a 728 KLOC customer care system used by a major telecommunication company-our approach has triggered correct recommendations for 624 out of 787 violations, as asserted by the system's architect. Moreover, the architects have scored 82% of these recommendations as having moderate or major complexity. A RECOMMENDATION SYSTEM FOR REPAIRING ARCHITECTURAL VIOLATIONS 317 2. BASIC CONCEPTS In this section, we provide definitions of the following fundamental concepts employed in this paper: recommendation system, architectural model, architectural violation, architecturally defective code, and refactoring recommendation. Recommendation system A recommendation system is a software system that provides potentially valuable information in a given context [22] [23] [24] . In the particular context of software engineering, recommendation systems can recommend, for example, relevant source code fragments to help developers use frameworks and APIs (e.g., Strathcona [25]), software artifacts that should be changed together (e.g., eRose [26]), and replacement methods for adapting code to a new library version (e.g., SemDiff [27]). In this paper, we propose a novel recommendation system, called ArchFix, which provides refactoring recommendations to repair architectural violations. The proposed system is defined by the following function: In short, our system receives as input the intended architectural model (Arch. Model), the description of the violation (Arch. Violation), and the piece of source code that raised the architectural violation (Arch. Defective Code). ArchFix then returns a Refactoring Recommendation that might be useful to repair such violation. In the remainder of this section, we discuss such elements in more detail. Architectural model Kruchten defines software architecture using five concurrent views, each one addressing a specific set of concerns of interest to different stakeholders [28] . Particularly, our work is centered on the development view (a.k.a. module view), which describes the software's static organization in its development environment. It concerns low-level design decisions, patterns, and best practices. From this viewpoint, an object-oriented software architecture is defined by a set of modules and their interactions, where we will consider a module as a set of classes [16] . Therefore, we model relations at the level of classes. More specifically, a dependency .A, dep, B/ is established whenever a class A uses services provided by a target class B. We consider that dependencies can be established using the following types of common operations in object-oriented languages (i.e., these types are possible values of the dep field): calling methods or attributes (access), declaring variables (declare), creating objects (create), extending classes or implementing interfaces (derive), throwing exceptions (throw), or using annotations (useannotation). For example, the relations .A, create, B/ and .A, access, B/ indicate that class A creates and calls methods of an object of type B, respectively. The architectural model considered by ArchFix is expressed in terms of architectural constraints, which are formalized as follows: where dep denotes the dependency type, that is, dep can be access, declare, create, and so on. As an illustrative example, assume that M A and M B are modules, that is, sets of classes. A constraint in the form M A cannot-dep M B indicates that types from module M A cannot establish a dependency of the dep kind with types from module M B , for example, ViewLayer cannot-access ModelLayer. On the other hand, a constraint in the form M A must-dep M B indicates that types from module M A must establish a dependency of the dep kind with types from module M B , for example, DTO must-implement Serializable. A RECOMMENDATION SYSTEM FOR REPAIRING ARCHITECTURAL VIOLATIONS § A problem marker (an object of type org.eclipse.core.resources.problemmarker) represents an error or warning listed in the Problems view of the Eclipse integrated development environment.
doi:10.1002/spe.2228 fatcat:ohycoiq5ond6jou6dob3vra6ri