Detection and Repair of Architectural Inconsistencies in Java

Abstract

Java is one of the most widely used programming languages. However, the absence of explicit support for architectural constructs, such as software components, in the programming language itself has prevented software developers from achieving the many benefits that come with architecture-based development. To address this issue, Java 9 has introduced the Java Platform Module System (JPMS), resulting in the first instance of encapsulation of modules with rich software architectural interfaces added to a mainstream programming language. The primary goal of JPMS is to construct and maintain large applications efficiently-as well as improve the encapsulation, security, and maintainability of Java applications in general and the JDK itself. A challenge, however, is that module declarations do not necessarily reflect actual usage of modules in an application, allowing developers to mistakenly specify inconsistent dependencies among the modules. In this thesis, we formally define 8 inconsistent modular dependencies that may arise in Java-9 applications. We also present Darcy, an approach that leverages these definitions and static program analyses to automatically (1) detect the specified inconsistent dependencies within Java applications and (2) repair those identified inconsistencies. The results of our experiments, conducted over 38 open-source Java-9 applications, indicate that architectural inconsistencies are widespread and demonstrate the benefits of Darcy in automated detection and repair of these inconsistencies. vii

Hero: On the Chaos When PATH Meets Modules

“…Different from such conflict issues, our studied DM issues are due to incompatible library-referencing modes and their broad impacts on related projects in the Golang ecosystem. Garcia et al's work [76] is closely related to our He r o , in which eight inconsistent modular dependencies were formally defined for Java-9 applications on the Java Platform Module System (JPMS). They proposed a technique Da r c y to detect and repair such inconsistencies but their targeted issues are architecture-implementation mapping ones, which are different from our focus.…”

Hero: On the Chaos When PATH Meets Modules

“…Different from such conflict issues, our studied DM issues are due to incompatible library-referencing modes and their broad impacts on related projects in the Golang ecosystem. Garcia et al's work [76] is closely related to our HERO, in which eight inconsistent modular dependencies were formally defined for Java-9 applications on the Java Platform Module System (JPMS). They proposed a technique DARCY to detect and repair such inconsistencies but their targeted issues are architecture-implementation mapping ones, which are different from our focus.…”

ArchiNet: A Concept-token based Approach for Determining Architectural Change Categories

“…A meaningful architectural document helps reduce the cognitive load and maintenance activities of the software development team [16]. Moreover, appropriate architectural formulation is becoming more critical to circumvent software bloat, scalability, and security backdoors [11]. However, elements of architecture can be changed [20] continuously as code components of a software system changes to support continuous development and maintenance [29] such as adding new features, restructuring the design models, and fixing flaws.…”

“…Moreover, an automated technique can be employed to produce design documentation for every release recording types of structural changes happened and associated components [17]. Automated architectural change classification technique [40], [32] can be used to develop strategies for implementing a system change, support continuous architecture, augment DevOps and Model-Driven Engineering tools [6], [12], [11]. Existing active software projects (even if we consider a tiny portion of the 100 million repositories in GitHub [1]) could immediately benefit if a structural change classification technique is available to help develop an architectural versioning schema.…”

“…Literature has focused on classifying typical software changes, architectural design concerns and design solutions [41], [28], [14]. Yet, supporting architectural change classification is still in its infancy [29], [11], perhaps, due to lack of benchmark data and requirements of laborious human analysis. Nevertheless, a few of the studies explored for both manual [8], [32] and semi-automated [29] techniques for classifying architectural changes.…”