Modular decomposition with a level-2 DFD

Modular decomposition is the architectural design activity in which each sub-system, identified during system structuring, is broken down further into modules. A module is a component that provides services to other modules but is normally not a separate system on its own. The aim is modules that are highly cohesive and loosely coupled.

How modular decomposition is practiced

Sommerville describes two main decomposition models:

1. Object-oriented decomposition – the sub-system is divided into a set of loosely coupled objects with well-defined interfaces. Designers identify object classes, their attributes and operations. Example: an invoice system decomposed into Customer, Invoice, Payment and Receipt objects.
2. Function-oriented pipelining (data-flow model) – the sub-system is divided into functional modules that take inputs and transform them into outputs, like a pipe-and-filter chain. The DFD of the sub-system is refined, and each low-level process becomes a module.

Practical steps followed in function-oriented design:

1. Draw the context diagram (level 0) of the system.
2. Refine it into a level-1 DFD of major functions (sub-systems).
3. Refine each level-1 process into a level-2 DFD of smaller functions.
4. Stop when each process does one clear job; each such process becomes a module.
5. Convert the DFD into a structure chart showing calling hierarchy and the data passed between modules.
6. Check cohesion and coupling and adjust module boundaries.

Example: library management system

• Level 0 (context): one process, Library system, with external entities Member and Librarian.
• Level 1: three processes: 1.0 Manage members, 2.0 Issue book, 3.0 Return book, with data stores D1 Members, D2 Books and D3 Issue records. Each level-1 process is a sub-system.
• Level 2: each level-1 process is decomposed again. Process 2.0 Issue book is shown below; its inputs and outputs (member and book ids in, issue slip out) must match the flows of 2.0 at level 1. This rule is called balancing.

Level-2 DFD for process 2.0 Issue book

+--------+  member id,
| Member |  book id
+--------+-----------+
                     v
             +----------------+       ==============
             | 2.1 Validate   |<----- D1 Members
             |     member     |       ==============
             +----------------+
                     | valid request
                     v
             +----------------+       ==============
             | 2.2 Check book |<----- D2 Books
             |  availability  |       ==============
             +----------------+
                     | available book
                     v
             +----------------+       ==============
             | 2.3 Record     |-----> D3 Issue records
             |     issue      |       ==============
             +----------------+
                     | issue details
                     v
             +----------------+       ==============
             | 2.4 Update     |-----> D2 Books
             |   book status  |       ==============
             +----------------+
                     | issue slip (due date)
                     v
                +--------+
                | Member |
                +--------+

Resulting modules (structure chart)

                 +--------------+
                 |  Issue_Book  |
                 +--------------+
       +--------+-----+-------+--------+
       |        |             |        |
 +----------+ +---------+ +--------+ +---------+
 | Validate | | Check   | | Record | | Update  |
 | Member   | | Avail.  | | Issue  | | Status  |
 +----------+ +---------+ +--------+ +---------+

• Each level-2 process (2.1–2.4) becomes one module with a single function, so cohesion is functional.
• Modules pass only simple data (member id, book id, issue record), so coupling is data coupling.
• Each module can be coded and unit-tested separately, and a change (e.g. a new borrowing limit rule in 2.1) stays inside one module.

Benefits of modular decomposition

• Complexity is controlled: each level adds detail only to one part.
• Modules can be assigned to different programmers and developed in parallel.
• Testing is easier: each module is unit tested, then integrated.
• Maintenance is easier: changes are localised to one module.
• General modules (such as Validate member, used by both 2.0 and 3.0) can be reused.