In this chapter, we dive into the concept of modularity in software architecture, providing a clear understanding and practical examples of how modularity impacts software design and maintainability.
Understanding Modularity
Modularity is a fundamental principle in software architecture that involves grouping related code into modules. These modules can be classes, functions, packages, or namespaces, depending on the programming language. The goal is to create a system that is easy to understand, maintain, and extend.
Definition of a Module
A module is defined as “each of a set of standardized parts or independent units that can be used to construct a more complex structure.” In software, this means logically grouping related code, like classes in Java or functions in Python. For example, in Java, the package com.mycompany.customer would contain all code related to customer operations.
The Importance of Modularity
Good modularity helps maintain order and consistency in software systems, which naturally tend towards entropy (disorder). Architects must work to ensure structural soundness, akin to adding energy to a physical system to maintain order. Poor modularity can lead to tightly coupled systems, making maintenance and evolution difficult.
Measuring Modularity
To understand and measure modularity, we use several metrics: cohesion, coupling, and connascence.
Cohesion
Cohesion refers to how closely related the parts of a module are. High cohesion means all parts of the module are essential to its functionality. For example, a class Account with methods like deposit, withdraw, and print_balance shows high cohesion as all methods operate on the account's balance.
Types of cohesion (from best to worst)
Functional Cohesion: All parts are necessary for the function.
Sequential Cohesion: One module's output is another's input.
Communicational Cohesion: Modules that form a communication chain.
Procedural Cohesion: Modules must execute in a specific order.
Temporal Cohesion: Modules are related by time dependencies.
Logical Cohesion: Logically related but functionally different operations.
Coincidental Cohesion: Elements are unrelated, just in the same file.
Measuring Cohesion
The Lack of Cohesion in Methods (LCOM) metric helps identify the cohesion level of a class. A high LCOM score indicates low cohesion, suggesting the class should be refactored.
Example of LCOM:
class Account:
def __init__(self):
self.balance = 0
def deposit(self, amount):
self.balance += amount
def withdraw(self, amount):
self.balance -= amount
def print_balance(self):
print(self.balance)
In this Account class, all methods interact with balance, indicating high cohesion (LCOM = 0).
Coupling
Coupling measures the degree of interdependence between software modules. Lower coupling is preferred as it makes the system more flexible and maintainable.
Types of Coupling:
Afferent Coupling (Ca): Number of incoming dependencies.
Efferent Coupling (Ce): Number of outgoing dependencies.
Example of Coupling:
# data_processor.py
def process_data(data):
# Process data
return processed_data
# other_module_1.py
from data_processor import process_data
def analyze_data(data):
processed_data = process_data(data)
# Analyze data
# other_module_2.py
from data_processor import process_data
def visualize_data(data):
processed_data = process_data(data)
# Visualize data
In this example, data_processor.py has high afferent coupling as it is used by multiple other modules.
Metrics for Abstractness and Instability:
Abstractness (A): Ratio of abstract (interfaces) to concrete (implemented) elements.
Instability (I): Ratio of efferent coupling to total coupling.
Distance from the Main Sequence:
- D = |A + I - 1|: Measures the balance between abstractness and instability.
Real-World Example:
Assume data_processor.py has 2 abstract classes and 8 concrete classes:
- Abstractness: A=2/8=0.25
If it has 5 incoming and 3 outgoing dependencies:
- Instability: I=3/(3+5)=0.375
Distance: D=∣0.25+0.375−1∣=0.375
Connascence
Connascence describes the degree of interdependence between code components. If a change in one part requires a change in another, they are connascent.
Types of Connascence
Static Connascence: Dependencies visible in source code.
Connascence of Name (CoN): Agreement on names.
Connascence of Type (CoT): Agreement on data types.
Connascence of Meaning (CoM): Agreement on values.
Connascence of Position (CoP): Agreement on order.
Connascence of Algorithm (CoA): Agreement on algorithms.
Dynamic Connascence: Dependencies visible at runtime.
Connascence of Execution (CoE): Order of execution matters.
Connascence of Timing (CoT): Timing of execution matters.
Connascence of Values (CoV): Values must change together.
Connascence of Identity (CoI): Shared data structure dependencies.
Real-World Example:
class EmailService:
def __init__(self):
self.recipient = None
self.sender = None
self.subject = None
def set_recipient(self, recipient):
self.recipient = recipient
def set_sender(self, sender):
self.sender = sender
def send(self):
if self.recipient and self.sender:
print(f"Sending email to {self.recipient} from {self.sender}")
# Usage
email = EmailService()
email.set_recipient("foo@example.com")
email.set_sender("me@me.com")
email.send()
email.set_subject("whoops")
The order of setting properties in EmailService is an example of connascence of execution.
From Modules to Components
While we use the term module generically, most platforms support components as key building blocks. Components encapsulate related functionality, making systems easier to manage and extend. We will explore deriving components from problem domains in later chapters.
Conclusion
Modularity, measured through cohesion, coupling, and connascence, is vital for creating maintainable and flexible software architectures. By understanding and applying these concepts, architects can design systems that are easier to understand, modify, and scale.