Section 2 · Design Modularity
On this page 17 headings
Learning goals: Distinguish coupling from cohesion; recognise four coupling mechanisms and five cohesion categories; explain why modular design favours high cohesion and low coupling.
A modular design is not merely software divided into files. Its boundaries must make sense internally and limit unnecessary exchanges externally.
Easy-to-Understand vs Tangled Module Designs
Two systems can implement the same features yet have very different designs. In the lecture, both pictures have modules M1 to M5. The simpler diagram has relatively few links; the tangled diagram has many module-to-module calls and exchanges. A developer generally finds the simpler design easier to understand, debug, and change.
Each connecting arrow stands for a function call or information exchange, not for inheritance. More arrows are not automatically wrong, because software must communicate to get work done. The problem is unnecessary dependencies: when a small change in one module forces changes throughout the system, development becomes risky and expensive.
Coupling vs Cohesion: Outside vs Inside
Coupling is about the relationship between different modules. It measures the degree to which modules depend on or interact with each other. Cohesion is about the relationship among functions within one module. It considers whether those functions cooperate toward a sensible common purpose.
A helpful way to remember this is 'coupling is outside; cohesion is inside.' Ideally, modules have only the external dependencies they need, while the functions inside each module belong together. That is the reason the lecture repeatedly recommends high cohesion and low coupling for modular software.
Recall: Between modules = coupling; within one module = cohesion.
Refactoring a Highly Coupled System
Many modules share information because functionality is spread across modules rather than grouped into one module. If M3’s required functions were all inside M3, it would not depend on M2, M4, M5.
Refactoring groups related functions back into a focused module and replaces some tangled connections with a small, well-defined interface. The aim is not to delete essential functions or communication. It is to organise responsibility so that each module has a clear job and other modules can use it without needing to know its internals.
Seller Portal Modules and Limited Interactions
In the simplified Seller Portal, Product, Catalogue, Seller, and Inventory are different objects or functional units with relationships among them. A catalogue is made of products, and the seller works with the catalogue and the inventory.
The design need not draw a direct connection between every pair. Treat the picture as a conceptual architecture, not a precise UML inheritance diagram. Later UML notation will specify whether a link is an association, a whole–part relationship, or an inheritance relationship.
Data Coupling: Pass One Seller ID
Data coupling occurs when one module calls another and supplies simple data values through parameters. In the lecture's example, Seller invokes `view_inventory(seller_id)` on Inventory. Only the seller identifier needed for the request is passed. The Inventory module then decides how to retrieve that seller's records.
This is usually preferable to letting Seller inspect Inventory's internal collection directly. The two modules agree on a narrow interface, making them less dependent on each other's implementation. Remember: the identifier is a passed parameter, not a global variable shared throughout the program.
Exam clue: The seller ID is passed as a parameter, not shared globally.
Control Coupling: Operation Flag Chooses Behavior
Control coupling occurs when one module passes control information that tells another module which branch to execute. In the lecture example, Seller calls `perform_actions(OPERATION_FLAG)` and the receiver interprets 0 as View, 1 as Add, and 2 as Delete.
The flag is a parameter, but its purpose is different from passing a seller ID. Rather than describing the business item being processed, it steers the receiving module's internal decision. As more flags and modes accumulate, the caller needs to know more about the callee's behavior. Designing separate clear operations can sometimes reduce this dependency.
Common Coupling: One Shared Global Flag
In common coupling, two or more modules depend on a shared global data item. Here Seller and Inventory read or change the same `GLOBAL OPERATION_FLAG`, and another module can potentially access it too. The value is not being supplied privately to one call.
Other modules may also access the global variable; multiple concurrent changes can happen, leading to an unstable system. This type of coupling is generally not recommended.
Content Coupling: Reaching Into Another Module
Content coupling occurs when one module reaches into the internal implementation or data of another module rather than using its promised interface. Imagine Module A directly changing Module B's private internal variables. B may now lose the ability to enforce its own rules.
This rarely happens in procedural or object-oriented languages like Python and Java, because data and member functions are encapsulated into a single unit, so it rarely occurs in practice.
Four Types of Coupling at a Glance
The four coupling examples differ by what is shared and who controls the behavior. Data coupling passes ordinary values as parameters. Control coupling passes a flag that steers the receiving module. Common coupling shares global data. Content coupling exposes or manipulates another module's internals.
In exam questions, identify the mechanism rather than judging only the arrow count. Ask: Is it a primitive input? A branch-selecting flag? A shared global variable? Or direct access to somebody else's implementation? A useful design generally tries to limit unnecessary dependencies and expose narrow interfaces.
Exam clue: Identify what passes across the boundary before naming the coupling type.
Functional Cohesion: Inventory Team with One Goal
Functional cohesion is present when the functions inside a module cooperate to complete one well-defined task. The Inventory Management module is a straightforward example. `view_inventory()`, `add_item_to_inventory()`, and `delete_item_inventory()` are different operations, but all contribute to the purpose 'Manage Inventory.'
Notice the boundary: these functions belong together because they work toward the same objective, not simply because they run one after another. This is a desirable form of cohesion. If the Inventory module also carried unrelated functions such as login, the module's single purpose would become less clear.
Sequential Cohesion: One Output Feeds the Next
Sequential cohesion means the result produced by one function becomes the input to the next function. The lecture's order-processing example runs `create_order()` → `check_availability()` → `place_order()`. One stage prepares information that the next stage consumes.
check_availability looks at the product and the inventory, so it does not really belong to order processing — it is placed here so the functions execute one after the other.
Exam clue: Check whether data produced by stage A feeds stage B.
Communicational Cohesion: Shared Product Data
Communicational cohesion: instead of separate inventory or catalogue modules, a single product module where add/edit/delete of catalogue and inventory all update the same list of products.
This is different from sequential cohesion: there is no requirement that Edit must run after Add every time, or that the output of Add must directly feed Edit. The functions belong together because they operate on the same logical records. Be careful not to confuse a common data structure *inside one module* with common coupling, which concerns *global data shared across modules*.
Exam clue: Shared *internal* product list is not the same as shared *global* coupling.
Procedural Cohesion: Steps but Different Purposes
Procedural cohesion groups activities primarily because they belong in one prescribed execution sequence, even when their purposes differ. The long Seller Portal flow includes login, product creation, catalogue addition, inventory update, order placement, and logout. These actions can occur in that order, but they do not collectively represent one narrow module responsibility.
A workflow can be necessary for the user while still being a poor basis for designing one giant module. Authentication, product management, and order processing are distinct responsibilities. Separating these concerns improves testability and makes it easier to change one feature without destabilising others.
Coincidental Cohesion: Functions with No Meaningful Relationship
Coincidental cohesion: functions with meaningless relationships; an extreme type rarely seen in good designs.
There is no one objective, no shared logical data structure, and no essential processing chain. Such modules are hard to name accurately, explain, or maintain. The lecture's core warning is that arbitrary grouping is not modular design, even if the code is physically organised into different files.
Compare All Five Cohesion Types
Compare the five categories by asking *why* the functions are grouped. Functional: they jointly solve one task. Sequential: one step's output feeds the next. Communicational: operations use the same data. Procedural: operations follow a sequence but pursue distinct tasks. Coincidental: no meaningful connection is present.
The course covers five types: functional (best), sequential, communicational, procedural and coincidental (worst).
Recall: Sequential depends on output-to-input flow; procedural depends on ordering.
The Design Goal: High Cohesion, Low Coupling
Modular — problem decomposed into modules with only limited interactions, so each module can be understood separately. High cohesion — functions of a module cooperate to perform a single objective. High coupling — function calls between two modules involve passing large chunks of shared data (not desirable).
If coupling is high, cohesion is generally low and vice versa — so high/high and low/low (options A and D) are ruled out. Low cohesion (functions doing varied operations, making the module’s purpose hard to understand) with high coupling (lots of shared data) is not desirable. A good design has high cohesion and low coupling (option C).
Golden rule: High cohesion + low coupling.
Quick revision and self-check
Question: Which is preferable: high or low coupling?
Answer: Low coupling, provided essential communication still works.
Question: A flag is passed to choose View/Add/Delete. Which coupling?
Answer: Control coupling.
Question: Two modules use one global variable. Which coupling?
Answer: Common coupling.
Question: Does step B consume step A output?
Answer: That is evidence of sequential cohesion.
Question: How is the Inventory Management example classified in this lecture?
Answer: Functional cohesion: view, add and delete support the stated goal of managing inventory.