Learning Objectives
- Explain that a computer system can be divided into sub-systems.
- Decompose a problem into smaller component parts.
- Show hierarchical decomposition using a structure diagram.
- Explain how decomposition supports design, coding and testing.
Key Terms
- System
- A set of connected components working together for a purpose.
- Sub-system
- A smaller system that forms part of a larger system and performs a particular function.
- Decomposition
- Breaking a complex problem or system into smaller, manageable component parts.
- Module
- A distinct part of a solution responsible for a defined task.
- Hierarchy
- An arrangement in levels, from a whole system to increasingly detailed components.
- Interface
- The point at which sub-systems exchange data or control information.
Computer Systems Contain Sub-Systems
A complete computer system is rarely one indivisible process. An online shop may contain account management, product search, basket, payment and delivery sub-systems. The payment sub-system may contain validation, price calculation and transaction-confirmation components.
A sub-system has its own task but contributes to the purpose of the larger system. Sub-systems exchange information. For example, the basket sends the order total to payment, and payment sends a success or failure result to order processing.
Decomposing A Problem
Decomposition changes one difficult problem into several smaller problems. Each component should have a clear purpose and should be small enough to understand, design and test.
For a quiz program, useful components could include entering a player name, asking each question, checking an answer, updating the score and displaying the final result. The exact decomposition depends on the requirements, but every required task should appear somewhere.
Hierarchical Decomposition
Large components can be divided again. “Process order” may be split into “validate product code,” “check stock,” “calculate item cost” and “update stock.” This produces a hierarchy from general tasks to specific tasks.
The decomposition should stop at a level that is useful for design. Breaking “calculate total” into “read the first digit” and “read the second digit” would usually be unnecessary. Good decomposition balances clarity with manageable detail.
Benefits Of Decomposition
| Benefit | Explanation |
|---|---|
| Reduced complexity | The developer can focus on one smaller task at a time |
| Clear responsibility | Each module or sub-system has a defined purpose |
| Easier testing | Individual parts can be tested before the complete solution |
| Parallel work | Different developers can work on separate components when interfaces are agreed |
| Reuse | A suitable component may be used in more than one part of a solution |
| Easier correction | An error can be traced to the component responsible for the incorrect result |
Interfaces Between Components
Decomposition does not mean the parts are independent. The designer must identify what data enters and leaves each component. A “calculate average” module may receive a total and count and return an average.
If the interface is unclear, one part may produce data in a form that another part cannot use. Structure diagrams show the hierarchy, while more detailed flowcharts or pseudocode can show the internal algorithm of each component.
Decomposition In The Life Cycle
Decomposition is used in both analysis and design. During analysis, it helps identify the component parts of the problem. During design, it helps organise the solution into modules and represent their relationship.
During coding and testing, the same decomposition allows each part to be implemented and checked separately before integration.
Worked Examples
School Library System
Question: Decompose a simple school library system into major sub-systems.
- Identify the overall purpose: manage books and loans.
- Create member management.
- Create book management and search.
- Create borrowing and returning.
- Create overdue checking and reports.
- Define information passed between them, such as member ID and book ID.
Answer: The whole system is divided into connected sub-systems, each with a clear function.
Further Decomposition
Question: Break the borrowing sub-system into smaller components.
- Input and validate member ID.
- Input and validate book ID.
- Check that the member is allowed to borrow.
- Check that the book is available.
- Record the loan and due date.
- Output confirmation or an error message.
Answer: Each component can be designed and tested separately, then combined into the borrowing process.
Examination Guidance
- Use a hierarchy from the complete system to sub-systems and smaller components.
- Name components using clear action phrases.
- Ensure every important requirement is represented by a component.
- Explain data passed between components when the question asks how they work together.
- Do not confuse decomposition with abstraction: decomposition breaks into parts; abstraction removes irrelevant detail.
Common Mistakes
- Creating components that overlap without a clear responsibility.
- Leaving out a required task from the decomposition.
- Breaking the problem into an excessive number of trivial steps.
- Treating sub-systems as unrelated.
- Using a sequence flowchart when a hierarchical structure diagram is required.
Knowledge Check
1. What is a sub-system?
2. What is decomposition?
3. Why are interfaces important?
4. How does decomposition help testing?
5. How is decomposition different from abstraction?
