Calculate modularity of software architecture

In this article, we explore the concept of modularity in software architecture and its importance. We’ll discuss how to calculate its key components - cohesion, coupling, and connascence - and their significance in assessing architectural quality.

---

1. What is modularity?

Modularity in software architecture refers to the practice of dividing a system into separate, independent modules that encapsulate different functionalities.

At its core, modularity involves organizing a system into cohesive units, each responsible for a specific aspect of the overall functionality. These modules are designed to be self-contained, with well-defined interfaces for interaction with other modules. For example, in a banking system, a module handling financial transactions could be separated from a module responsible for managing customer accounts.

Such a modular structure allows for flexible software design, testing, and development, enhancing scalability and maintainability. However, to reap the full benefits of modularity, an architect must also consider aspects such as cohesion, coupling, and connascence, which impact the efficiency and flexibility of the system. Thus, modularity becomes a crucial element in creating modern and sophisticated information systems capable of meeting dynamic market demands.

---

2. Dividing modules and establishing boundaries

Dividing a software system into modules and establishing clear boundaries between them is a crucial aspect. Effective module division and boundary establishment promote maintainability, scalability, and flexibility. Here are some strategies for achieving this:

2.1. 1. Single Responsibility Principle (SRP)

Follow the SRP, which states that a module should have only one reason to change. Identify cohesive functionalities within your system and group them together into modules. Each module should encapsulate a single, well-defined responsibility. For example, in a web application, you might have separate modules for user authentication, order processing, and product management.

2.2. 2. Separation of Concerns (SoC)

Apply the SoC principle to divide your system into distinct concerns, such as data access, business logic, and user interface. Each concern should be addressed by a separate module, allowing for easier maintenance and scalability. For instance, in a web application, you could have separate modules for handling database interactions, business rules, and frontend presentation.

2.3. 3. Domain-Driven Design (DDD)

Utilize DDD to identify the core domains of your application and model them as separate modules. Define bounded contexts for each domain, establishing clear boundaries that prevent domain logic from leaking into other parts of the system. For instance, in an e-commerce application, you might have separate modules for managing products, orders, and customers.

2.4. 4. Interface Segregation Principle (ISP)

Design module interfaces with the ISP in mind, which states that clients should not be forced to depend on interfaces they do not use. Define minimal and focused interfaces that cater to the specific needs of each module, avoiding unnecessary dependencies. This allows for better encapsulation and reduces the impact of changes on other modules.

2.5. 5. Dependency Inversion Principle (DIP)

Apply the DIP by decoupling modules from their concrete implementations and depending on abstractions. Use dependency injection to inject dependencies into modules, allowing for greater flexibility and testability. This promotes loose coupling between modules and makes it easier to replace implementations without affecting the rest of the system.

---

2.6. When to divide modules?

Consider dividing a module when it becomes too large or when it violates the single responsibility principle (or other form the above rulesl depending of which you are using). However, avoid dividing tightly coupled modules, as this can lead to increased complexity and reduced maintainability.

Trying to split a coherent module would only increase coupling and decrease readability. ~Larry Constantine

---

3. Components of modularity

Modularity includes cohesion, coupling and connascence.

Together, these three factors contribute to the modularity of an architecture, affecting its flexibility, maintainability and scalability. Understanding and quantifying these factors is essential for architects to effectively manage and control the current state of the architecture

Let’s take a look at each of them!

---

4. Cohesion

Cohesion measures the degree to which elements within a module belong together. High cohesion implies that elements within a module are closely related and contribute to a single, well-defined purpose.

Let’s explore some types of cohesion, starting from the highest level.

4.1. Functional Cohesion

Methods in a module perform a common, logical task or operate on a common set of data. This is the highest level of cohesion, where all methods in the module collaborate to achieve one well-defined task.

4.2. Sequential Cohesion

Methods in a module are called in a specific sequence, where the output of one method is used as input for the next method. This is sequential cohesion, where methods are linked by the sequence of their invocations.

4.3. Communicational Cohesion

Methods in a module perform similar tasks and often exchange data among themselves. Communicational cohesion occurs when methods in a module are linked by data exchange.

4.4. Procedural Cohesion

Methods in a module perform similar tasks, but not necessarily in a logically related manner. For example, a module containing methods for data processing, where each method performs different operations on data but there’s no logical connection between them.

4.5. Temporal Cohesion

Methods in a module are invoked at the same point in time, but not necessarily to perform related tasks. Temporal cohesion is when methods are linked by the time of their invocation, but not necessarily by their functionality.

4.6. Logical Cohesion

In this case, methods in a module perform related tasks that are logically connected. However, these methods may vary in terms of specific operations, which can affect code efficiency and comprehensibility.

4.7. Coincidental Cohesion

This is the lowest level of cohesion, where methods in a module perform different, unrelated tasks. It results from a random collection of methods in a module that lack logical connection. Modules with coincidental cohesion are difficult to understand and maintain.

---

5. Cohesion metrics

5.1. LCOM version 1

Lack of Cohesion in Methods measures the lack of cohesion within a class. LCOM version 1 is the simplest formula for calculating consistency. It is useful for quick and basic calculations in uncomplicated cases.

It is calculated as the difference between the number of method pairs that do not share any instance variables and the number of method pairs that do share instance variables. Mathematically, LCOM can be expressed as:

$$LCOM_1 = \begin{cases} |P| - |Q| & \text{if } |P| > |Q| \\ 0 & \text{otherwise} \end{cases}$$

Let’s consider a class with 5 methods. Among these methods, 3 pairs of methods share at least one instance variable (|P| = 3), and 2 pairs of methods do not share any instance variables (|Q| = 2).

Substituting these values into the formula - |3| is greater than |2|, so:

$$LCOM_1 = 3 - 2 = 1$$

In this case, LCOM equals 1. This value indicates some cohesion in the class, as there are more pairs of methods sharing at least one instance variable than pairs of methods not sharing any instance variables.

Interpretation of LCOM1 values:

• High Cohesion: If the LCOM result is positive, it means that there are many pairs of methods in the class that share at least one field. A high LCOM 1 value indicates high cohesion within the class, suggesting that methods in the class often operate on the same data and are strongly related.

• Low Cohesion: If the LCOM result is zero, it means that the number of pairs of methods sharing at least one field is equal to or lass than the number of pairs of methods that do not share any field. A LCOM 1 value of zero suggests low cohesion within the class, indicating that methods in the class are not strongly related and may operate on different sets of data.

5.2. LCOM version 4

LCOM 4 is preferred over LCOM 1 because it considers method dependencies, providing a more nuanced understanding of method cohesion, especially in complex class structures. By accounting for all dependencies between methods, LCOM 4 offers a more accurate assessment of method cohesion, reflecting real-world software design practices more effectively.

LCOM in version 4 can be calculated using the following formula:

$$LCOM_4 = \frac{\sum_{i=1}^{m} \left( \binom{d_i}{2} - e_i \right)}{\sum_{i=1}^{m} \binom{d_i}{2}}$$

This formula takes into account combinations of vertex degrees in the method dependency graph to calculate LCOM 4 for the class.

5.2.1. Example

Take look at our example:

$$\begin{array}{ccc} \text{field1} & \xrightarrow{\text{used by}} & \text{method1} \\ \text{field2} & \xrightarrow{\text{used by}} & \text{method2} \\ \text{field3} & \xrightarrow{\text{used by}} & \text{method1}, \text{method2}, \text{method3} \\ \text{field4} & \xrightarrow{\text{used by}} & \text{method1}, \text{method3} \end{array}$$

This allows us to say what the values of $d_i$ and $e_i$ are:

$$\begin{align*} d_1 &= 3, \quad e_1 = 1 \\ d_2 &= 2, \quad e_2 = 0 \\ d_3 &= 4, \quad e_3 = 2 \\ \end{align*}$$

Based on diagram, we get:

• for method1:
  • $d_1 = 3$, because method1 references field1, field3, and field4.
  • $e_1=1$, because the pair field3 and field4 is shared within method1.
• for method2:
  • $d_2=2$, because method2 references field2 and field3.
  • $e_2=0$, because method2 does not share any pairs of fields.
• for method3:
  • $d_3=2$, because method3 references field3 and field4.
  • $e_3=2$, because the pairs field3 and field4 are shared within method3.

And, we can go to the calculations:

$$\begin{align*} LCOM_4 &= \frac{\sum_{i=1}^{3} \left( \binom{d_i}{2} - e_i \right)}{\sum_{i=1}^{3} \binom{d_i}{2}} \\ &= \frac{\left( \binom{3}{2} - 1 \right) + \left( \binom{2}{2} - 0 \right) + \left( \binom{4}{2} - 2 \right)}{\binom{3}{2} + \binom{2}{2} + \binom{4}{2}} \\ &= \frac{(3 - 1) + (1 - 0) + (6 - 2)}{3 + 1 + 6} \\ &= \frac{2 + 1 + 4}{10} = \frac{7}{10} = 0.7 \end{align*}$$

The value of $LCOM_4$ for this example is $0.7$. The closer the value is to zero, the better organized the code is.

5.2.2. Interpreting the results of LCOM 4

1. High Cohesion: If the $LCOM_4$ result is close to zero or low, it indicates that the methods in the class are strongly related and collaborate with each other. This corresponds to a situation where most methods in the class operate on the same data fields and collaborate with each other.

2. Low Cohesion: If the $LCOM_4$ result is high, it suggests that the methods in the class are weakly related and operate in isolation. This may suggest that methods in the class operate on different sets of data and do not collaborate with each other, leading to difficulties in understanding and maintaining the code.

---

6. Coupling

Refers to the degree of interdependence between modules. Low coupling indicates that modules are relatively independent of each other. High coupling means that a change in one module will likely necessitate changes in another, while low coupling means that modules can change independently of one another.

6.1. Afferent Coupling (Ca)

Afferent coupling refers to the number of incoming dependencies to a module or component. It indicates how many other modules or components rely on a particular module. High afferent coupling means that many other modules depend on a given module, suggesting that the module is highly reused or serves as a core part of the system.

Key Points:

• High Afferent Coupling: Indicates that a module is heavily used by other parts of the system. It often implies that the module is stable and well-tested, as changes to it can have widespread impact.
• Implication: Modules with high afferent coupling should be stable and robust because changes to these modules can affect many other parts of the system.

6.2. Efferent Coupling (Ce)

Efferent coupling refers to the number of outgoing dependencies from a module or component. It measures how many other modules a given module depends on. High efferent coupling means that a module relies on many other modules, suggesting that it may be more complex and harder to understand in isolation.

Key Points:

• High Efferent Coupling: Indicates that a module depends on many other modules. This can make the module more complex and tightly coupled to the rest of the system.
• Implication: Modules with high efferent coupling should be designed carefully to manage dependencies and reduce complexity.

6.3. Practical Example

Consider a class A that provides utility functions used by many other classes (high afferent coupling), and another class B that needs to use several external libraries to perform its operations (high efferent coupling).

• Class A (High Afferent Coupling): This class is central to the system and changing it can have widespread effects. It should be well-tested and stable.
• Class B (High Efferent Coupling): This class has many dependencies, making it more complex and potentially more fragile. Refactoring may be needed to reduce dependencies and simplify the class.

---

7. Coupling metrics

In the JavaScript world, there are several tools available that can measure coupling or at least analyze dependencies, including:

• Webpack Bundle Analyzer
• Nx Dependency Graph
• Dependency Cruiser
• madge

But! We can also calculate the coupling manually, for instance, by using the CBO.

7.1. Coupling Between Objects (CBO)

Coupling Between Objects (CBO) is a metric used to measure the degree of interdependence between classes in an object-oriented system. It helps in understanding how changes in one class might affect other classes. High coupling indicates that classes are highly dependent on each other, which can reduce modularity and make the system harder to maintain.

CBO is primarily associated with object-oriented programming (OOP), but the concept of coupling is relevant to other programming paradigms as well.

In non-OOP paradigms, coupling still refers to the degree of interdependence between software modules. For instance, in procedural programming, functions or modules may have dependencies on each other, affecting modularity and maintainability.

$$CBO = N$$

• N - number of classes a given class is coupled with

7.1.1. Example and calculation

Consider a simplified e-commerce system with the following classes and relationships:

• Order
• Payment
• Inventory
• Customer

Example relationships:

• Order class uses Payment and Inventory classes.
• Payment class uses Customer class.
• Customer class uses Order class.

CBO Calculation:

1. Order class:

   • Uses: Payment, Inventory
   • $CBO_{Order} = 2$

2. Payment class:

   • Uses: Customer
   • $CBO_{Payment} = 1$

3. Inventory class:

   • Uses: None
   • $CBO_{Inventory} = 0$

4. Customer class:

   • Uses: Order
   • $CBO_{Customer} = 1$

8. Abstractness

Abstractness is a metric used to quantify the proportion of abstract elements in a component or package. It provides insight into how flexible and extensible a module is.

8.1. Calculating Abstractness

Abstractness ((A)) is calculated using the formula:

$$A = \frac{N_A}{N}$$

The abstractness value ranges from 0 to 1:

• $A = 0$: The component is entirely concrete (no abstract types).
• $A = 1$: The component is entirely abstract (only abstract types).

8.2. Practical Example

Consider a package with the following types:

• 4 concrete classes
• 3 abstract classes
• 2 interfaces

First, identify the number of abstract types $N_A$:

• Abstract classes: 3
• Interfaces: 2
• Total abstract types $(N_A): 3 + 2 = 5$

Next, determine the total number of types $N$:

• Concrete classes: 4
• Abstract classes: 3
• Interfaces: 2
• Total types $(N): 4 + 3 + 2 = 9$

Now, calculate the abstractness $A$:

$$A = \frac{N_A}{N} = \frac{5}{9} \approx 0.56$$

This result indicates that approximately 56% of the types in this component are abstract.

Remember: Code with too little abstraction is difficult to maintain, and code with too much abstraction is weak, easy to break.

---

9. Connascence

Connascence is a concept introduced by Meilir Page-Jones to describe the relationship between software components based on how closely related their elements are. It focuses on the degree of correlation or interdependence between elements rather than the structure or type of dependencies.

9.1. Types of connascence

Connascence comes in different forms, from the least severe (easiest to remove) to the most severe (hardest to remove):

• Connascence of meaning: Two components share a meaning, such as using the same constant or value.
• Connascence of name: Two components share a name, such as using the same identifier or variable name.
• Connascence of position: Two components rely on elements being in a specific position or order.
• Connascence of timing: Two components rely on elements being executed or processed in a specific sequence or time.
• Connascence of algorithm: Two components rely on using the same algorithm or approach.
• Connascence of value: Two components rely on sharing or using the same value.

9.2. Difference between connascence and coupling

While both connascence and coupling relate to dependencies between software components, they focus on different aspects:

Coupling measures the degree of interdependence based on the structure, data exchange, control flow, or timing between modules. Connascence describes the degree of correlation or interdependence between elements within or between modules based on their meaning, name, position, timing, algorithm, or value.

---

In this article, we discussed the key elements of software architecture modularity: cohesion, coupling, and connascence. Understanding these concepts and their calculation methods is crucial for architects to manage architectural quality effectively.