Analyse dependencies

Introduction

Embold’s module dependency view enables you to visualize 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 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.

Embold’s module dependency view plots dependencies aggregated from the code components to its parent modules 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 the following languages: Java, C, C++, and C#.

Visualisations Types

It offers 2 visualizations:

1. Hierarchical: This view plots the modules and their dependencies in a hierarchical structure determined by actual dependencies. This helps visualize perceived “layers” in the system organized automatically based on dependencies.

2. Clustered: This view adds size and quality dimensions to the module dependency graph, organized as a cluster of nodes, where each node represents a module, its size represents lines of code of its components, and color represents Embold quality rating. This view is useful to spot busy, large modules which typically concentrate hotspots.

Steps to navigate to Module Dependency

• Navigate to ‘Module Dependency’ view in your desired repository.
• Click on ‘Hierarchical’ dropdown option to see the hierarchical view. This is represented by line arrows and numbers are displayed on it.
• Click on “Clustered” dropdown option to see the clustered view. This is represented by a dotted arrow and no numbers are displayed.
• 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:

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.