Software Design Methods
Computer ScienceΒ· Unit 12: Software Development, Topic 3Β· 15 min read
1. Structured (Procedural) Software Designβ β ββββ± 5 min
Structured Design
A top-down software design method that decomposes a system into smaller, hierarchical functional modules, focusing on procedures and processes that act on separate data.
Example:
A payroll program decomposed into modules for input, tax calculation, report generation, and output.
Structured design is built around the principle of separation of concerns, where the system is broken down by function rather than by data. The core technique used is top-down decomposition (also called stepwise refinement), where the overall problem is split into smaller sub-problems, each solved individually.
Key features of structured design:
Decomposition into functional modules with a clear hierarchy
Data is separate from the procedures that act on it
Uses flowcharts and structure charts to visualise design
Promotes reusability of individual functions
Decompose a simple ATM withdrawal system using structured design principles.
- 1
Step 1: Start with the overall top-level function: Complete ATM Withdrawal
- 2
Step 2: Decompose the top function into 3 core sub-functions: 1. Verify user card and PIN 2. Process withdrawal request 3. Dispense cash and update balance
- 3
Step 3: Further decompose the largest sub-function, Process withdrawal request, into smaller sub-functions: 1. Check available account balance 2. Confirm withdrawal amount with user 3. Update internal system balance 4. Generate transaction receipt
- 4
Result: A hierarchical structure of functions, each responsible for one clear task, with data (e.g. user balance) stored separately from the functions that use it.
Exam tip:
Examiners often ask you to describe a structured decomposition of a system. Remember modules are grouped by function, not by data entity.
2. Object-Oriented Software Design (OOD)β β β βββ± 6 min
Object-Oriented Design
A software design method that models a system as a collection of interacting objects, where each object combines data (attributes) and the procedures (methods) that act on that data.
Example:
An ATM system would have objects like User, Card, Account and ATM.
OOD models real-world entities or abstract concepts directly from the problem domain. The core principles of OOD tested in CIE 9618 are:
Encapsulation: An object hides its internal data, only exposing controlled access via methods
Inheritance: New classes can inherit attributes and methods from existing classes, reducing code duplication
Polymorphism: Objects of different types can respond to the same method call in different ways
Identify core classes and their components for an ATM withdrawal system using OOD principles.
- 1
Step 1: Identify key real-world entities (nouns) in the problem domain:
ATM,Card,BankAccount,Transaction,User - 2
Step 2: Define attributes (data) for each class. For example, for the
BankAccountclass:accountNumber,balance,accountHolderName - 3
Step 3: Define methods (behaviour) that act on the class's attributes. For the
BankAccountclass:getBalance(),withdraw(amount),deposit(amount) - 4
Step 4: Define relationships between classes. For example, a
Userhas one or moreBankAccounts, and anATMinteracts withCardobjects to verify users. - 5
Result: Each class combines data and related behaviour, rather than separating them as in structured design.
Exam tip:
When asked to list features of OOD, always mention that data and methods are encapsulated together. This is a common marking point.
3. Comparing Methods & Selecting the Right Approachβ β β βββ± 4 min
Exams regularly ask you to compare the two methods and justify which one to use for a given scenario. The table below summarises the key differences:
Aspect | Structured Design | Object-Oriented Design |
|---|---|---|
Organised by | Functions/processes | Objects/entities |
Data vs behaviour | Data separate from procedures | Data + methods encapsulated together |
Best for | Small, simple systems with static requirements | Large, complex systems with evolving requirements |
Reusability | Only function-level reusability | High reusability via inheritance |
Ease of modification | Hard to modify large systems | Easy to modify with limited system-wide impact |
Maintenance cost | Higher for large systems | Lower for large, evolving systems |
Check your understanding of core differences:
Which design method separates data from the procedures that act on it?
Structured design
Object-oriented design
Which design method is better for a large system that will be updated regularly?
Structured design
Object-oriented design
Reveal answer
1 βCorrect! OOD is easier to maintain for large, evolving systems due to encapsulation and modularity.
4. Common Pitfalls
Wrong move:
Confusing top-down decomposition with structured design as a whole
Why:
Top-down decomposition is just one technique used in structured design, not the entire method.
Correct move:
When describing structured design, mention it uses top-down decomposition, plus other key features like modularity and separation of data and function.
Wrong move:
Claiming OOD is always better than structured design for all problems
Why:
Examiners expect you to match the method to the scenario, not state one is universally superior.
Correct move:
Link your choice to the scenario's size and requirements: structured for small static systems, OOD for large evolving systems.
Wrong move:
Describing encapsulation as only combining data and methods, omitting data hiding
Why:
Most mark schemes require the data hiding component of encapsulation to award full marks.
Correct move:
Always mention that encapsulation hides internal data, only exposing controlled access via methods.
Wrong move:
Listing functions as classes when designing an OOD system
Why:
This confuses structured design organisation with OOD organisation, leading to an incorrect design.
Correct move:
In OOD, classes represent nouns (entities/concepts) from the problem, methods are verbs (actions).
Wrong move:
Claiming structured design does not use modularity
Why:
A common misconception: only OOD is modular. Both methods are modular.
Correct move:
Remember the difference is what modules are based on: structured modules are functions, OOD modules are classes/objects.
5. Quick Reference Cheatsheet
Feature | Structured Design | Object-Oriented Design |
|---|---|---|
Core organisation | By function/process | By object/entity |
Data vs behaviour | Data separate from procedures | Data + methods encapsulated |
Key techniques | Top-down decomposition, structure charts | Class diagrams, use case modelling |
Best for | Small, static systems | Large, evolving systems |
Key advantage | Simple to learn and implement | Easy to maintain, high reusability |
Key disadvantage | Hard to modify large systems | Steeper learning curve |
6. Frequently Asked
Do I need to remember all features of both methods for the exam?
Yes. Exam questions regularly ask to list features, compare methods, and justify a choice for a given scenario. You should be able to name at least 3 key features of each approach.
What is the difference between top-down design and structured design?
Top-down decomposition is a core technique used within structured design. Structured design as a whole method includes top-down decomposition, modularity, and separation of data from procedures.
When this came up on past exams
AI-estimated based on syllabus patterns β cross-check with official past papers for accuracy. Use only as revision-focus signals.
- 2022 Β· 12
Compare OOD vs structured design
- 2023 Β· 11
State features of object-oriented design
- 2024 Β· 12
Justify choice of design method
Going deeper
What's Next
Understanding software design methods is a foundational skill that underpins all other software development topics in CIE 9618. Examiners regularly combine this topic with questions on SDLC, UML modelling, and software maintenance, so a solid understanding here will help you earn marks across multiple areas of the exam. The choice of design method directly impacts the entire development lifecycle, from implementation to long-term maintenance, so it is critical to be able to compare and justify approaches for any scenario.
- βTesting
- βDebugging
- βSoftware maintenance