Using Third-Party Components’ Metadata to Analyze Cross-cutting Concerns

Abstract

Context: Modularity is a key concept in software development. Well-modularized systems are easier to maintain and evolve, but achieving good modularity is difficult. Concerns that are important, but not central to a systems' main business rules, frequently end up scattered and entangled throughout several software modules. Those so called cross-cutting concerns are a major source of loss of modularity and code decay in software systems. Motivation: Studies on cross-cutting concerns often resort to manual identification of concerns, but manual identification is effort demanding, does not scale, and tends to be imprecise. Automatic approaches are therefore very attractive when the codebase is extensive. In modern systems, developers implement modules to address central business rules, but they tend to add third-party components in the codebase to materialize concerns related to other secondary aspects. Logging, database access, and tests automation are examples of concerns that are usually implemented with the help of imported components and are prone to scatter and tangle throughout the codebase. Aims: This paper proposes a method to track this type of cross-cutting concern. Our work takes advantage of the addition of metadata about components to track them. The method scales by automating the identification and analysis of concerns scattered throughout the software codebase. We define a new metric, Dedication to Concern (DtC), to measure how much source code modules focus on implementing the identified concerns. Working Method: We describe our method to mine cross-cutting concerns from the metadata related to the use of components. The method is instantiated as a tool, architectural knowledge suite (AKS). The tool is used to analyze concerns in a set of large Java projects. The results are used to feed an action research study, during which software development specialists analyze the AKS outputs to evaluate and evolve the method. Conclusion: The semi-automated approach is feasible and scalable, and can be used to analyze secondary concerns that are currently being imported into modern software systems via third-party components.