Modularity Violation

Rationale: Baldwin and Clark's Design Rule theory [1]  proposed that independent modules can be changed or even replaced without influencing each other. Wong et al. introduced the term Modularity Violation [26], which describes two structurally independent modules that change together frequently, meaning that they are not truly independent. The more often two structurally unrelated files change together, the more likely that there are implicit dependencies between them [26], [27]. DV8 calculates the minimal number of file groups with modularity violations. 

Description: A Modularity Violation Group (MVG) contains a set of modularity violation files. We calculate the minimal number of MVGs so that their union covers all violated file pairs (two files without structural relations but changed together) in a project. In a Modularity Violation Group, there exists a core file, f_core, which all other files are not structurally related to but have frequently changed together with. To identify a Modularity Violation Group (MVG), DV8 first generates all file sets by considering each file in a project as a core file, then greedily searches a file set that covers most violated file pairs as an MVG until the union of all the MVGs covers all violated file pairs in a project.

Visualization:

Fig. : An example instance of Modularity Violation Group

Each number indicates the co-changes between two files.  

The above figure presents an instance of MVG detected in Apache Cassandra. There are no structural dependencies between DropIndexStatement.java and the other files. However, the cells annotated with a number in the DSM reveal that all other files changed together 3 times or more with DropIndexStatement.java, the core file. 

To visualize an instance of Modularity Violation using the DV8 GUI, click "Analysis-> Load Issue File", and select a ".dv8-issue" file.  For a Modularity Violation issue, DV8 will automatically arrange the files to place the core files at the top of the DSM.