--- title: "Modular decomposition with a level-2 DFD" subject: "Software Engineering" chapter: 3 key: "semester_5/software_engineering:modular-decomposition" source: https://www.bctengineer.com/q/semester_5/software_engineering/modular-decomposition site: BCT Engineering --- # Modular decomposition with a level-2 DFD Software Engineering · Chapter 3: Architectural design - Asked in: year not given, 4+6 marks - Video: [Levels of DFD | 0-Level, 1-Level, 2-Level with examples](https://www.youtube.com/watch?v=qtTWBs49BCA) — Gate Smashers - Answer checked by Claude Sonnet 5.5 on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_5/software_engineering/modular-decomposition - Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-3 ## Question How modular decomposition is practiced in system design? Illustrate with example of level-2 DFD. ## Short answer Modular decomposition refines each sub-system into smaller modules by drawing a context diagram, then level-1 and level-2 DFDs, stopping when each process does one clear job; each such process becomes a module, and DFD inputs and outputs must balance. For a library system, process 2.0 Issue book is decomposed into validate member, check availability, record issue, and update book status modules. ## Answer **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** ```text +--------+ 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) ```text +--------------+ | 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. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. What is the aim of modular decomposition? A. Modules that are loosely cohesive and tightly coupled B. Modules that are highly cohesive and loosely coupled C. Modules that share global data for speed D. One large module with many functions Answer: B. Each sub-system is broken into modules that are highly cohesive inside and loosely coupled to each other. (Key point: Aim of modular decomposition) 2. Which pair are the two main decomposition models described? A. Object-oriented decomposition and function-oriented pipelining B. Top-down and bottom-up integration C. Waterfall and spiral decomposition D. Client-server and layered decomposition Answer: A. Sommerville describes object-oriented decomposition and function-oriented (data-flow) pipelining. (Key point: Two decomposition models) 3. What does the balancing rule require of a level-2 DFD of process 2.0? A. It must have exactly four processes B. It must contain no data stores C. Its inputs and outputs must match the flows of 2.0 at level 1 D. It must be drawn before the context diagram Answer: C. Balancing means the child DFD's inputs and outputs match those of the parent process at the higher level. (Key point: Balancing) 4. When does a DFD process become a module in function-oriented design? A. When it has more than five data flows B. When it is at level 0 C. When it uses a data store D. When each process does one clear job after repeated refinement Answer: D. Refinement stops when each process does one clear job, and each such process becomes a module shown in a structure chart. (Key point: DFD to modules) ## Related in Software Engineering - [Book store process model](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Abook-store-process-model) — Software Engineering, chapter 2 - [Role of reference architectures](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Areference-architecture) — Software Engineering, chapter 3 ## Related in other subjects - [Semi-modular pipe outlet design, flexibility 0.9](https://www.bctengineer.com/question.md?key=semester_6%2Firrigation_and_drainage_engineering%3Asemimodular-pipe-outlet-flexibility-09) — Irrigation and Drainage Engineering, chapter 7 - [Algorithmic vs object-oriented decomposition](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aalgorithmic-vs-oo-decomposition) — Object Oriented Analysis and Design, chapter 1 - [Digital system, logic level, BCD vs binary](https://www.bctengineer.com/question.md?key=semester_3%2Fdigital_logic%3Adigital-system-logic-level-bcd) — Digital Logic, chapter 1 - [Triple modular redundancy; reliable C/S](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Atmr-reliable-client-server) — Distributed System, chapter 9