Dependencies

Introduction

BrowserStack Code Quality’s module dependency view enables you to visualise dependencies between modules / packages aggregated from the underlying code-level dependencies. This helps in spotting tightly-coupled modules, unexpected dependencies, cyclic dependencies, etc. which can drive refactoring / restructuring decisions in order to have a cleaner dependency structure.

A “module” is defined as a direct or indirect container of a code component (e.g. file, class, struct). This typically maps to a directory.

BrowserStack Code Quality’s module dependency view plots dependencies aggregated from the code components, to its parent modules all the way up to the top-level node in the module tree. Currently, the view plots dependencies within modules that are at the same level in the tree.

Module Dependency is only supported for following languages: Java, C, C++, C#.

Visualisations Types

It offers 2 visualisations:

1. Hierarchical: This view plots the modules and its dependencies in a hierarchical structure determined by actual dependencies. This helps visualise perceived “layers” in the system organised automatically based on dependencies.
2. Clustered: This view adds size and quality dimensions to the module dependency graph, organised as a cluster of nodes, where each node represents a module, its size represents lines of code of its components, and colour represents BrowserStack Code Quality quality rating. This view is useful to spot busy, large modules which typically concentrate hotspots.

Steps to navigate to Module Dependency

1. Navigate to ‘Module Dependency’ view in your desired repository.
2. Click on ‘Hierarchical’ dropdown option to see the hierarchical view. This is represented by line arrows and numbers are displayed on it.
3. Click on “Clustered” dropdown option to see the clustered view. This is represented by dotted arrow and no numbers are displayed.
4. Click on a module to navigate to its internal module dependency view.

Module Dependency types

There are 2 types of module dependency:

A. Cyclic Dependency: Two modules are dependent on each other via its internal code components (direct children or descendants). Such dependencies are many times unwanted and may be considered for refactoring. This is represented by an orange line.

Example: metrics and utils are packages.

The number “6” represents classes in ‘metrics’ module are using 6 other classes in ‘utils’ module.
And number “1” represents classes in ‘utils’ module using 1 other class in ‘metrics’ module.

metrics class:   

utils class:

B. Acyclic Dependency: This represents a uni-directional dependency between 2 modules (module A depends on B, and B does NOT depend on A).
This is represented by the grey line.