# Software Design Methods

> Computer Science · CIE A-Level 9618
> Source: https://www.owlsprep.com/study/cie-9618-u12-software-design-methods/

This module covers the two core software design methods for CIE A-Level Computer Science: structured (procedural) design and object-oriented design (OOD). You will learn their key features, advantages, and appropriate use cases for exam scenarios.

**Prerequisites:** [Software Development Life Cycle fundamentals](https://www.owlsprep.com/study/cie-9618-u12-software-development-life-cycle/); Basic programming concepts (modules, functions)

## Learning objectives

- Compare and contrast structured and object-oriented software design methods
- Identify key features and core principles of each approach
- Justify the choice of design method for a given software scenario
- Apply each design method to decompose a simple system

## Structured (Procedural) Software Design

**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.

*Notation:* Also called procedural design

*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

**Worked example:** 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.

## Object-Oriented Software Design (OOD)

**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

**Worked example:** 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 `BankAccount` class: `accountNumber`, `balance`, `accountHolderName`
3. Step 3: Define methods (behaviour) that act on the class's attributes. For the `BankAccount` class: `getBalance()`, `withdraw(amount)`, `deposit(amount)`
4. Step 4: Define relationships between classes. For example, a `User` has one or more `BankAccount`s, and an `ATM` interacts with `Card` objects 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.

## Comparing Methods & Selecting the Right Approach

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 |

**Exam command terms**

For CIE 9618, common command terms for this topic have the following expectations:

- **Compare** — Give both similarities and differences between the two methods *(Compare structured design and OOD (usually 6-8 marks))*

- **Justify** — State your chosen method, then give reasons that link its features to the scenario requirements *(Justify your choice of design for a large e-commerce system (usually 4 marks))*

- **State features** — List the required number of key features, no extra explanation needed unless asked *(State three features of OOD (usually 3 marks))*

**Check your understanding**

Check your understanding of core differences:

1. Which design method separates data from the procedures that act on it?

   - Structured design
   - Object-oriented design

   *Answer:* Structured design

   *Why:* Correct! Structured design keeps data separate from functions, while OOD encapsulates both in objects.

2. Which design method is better for a large system that will be updated regularly?

   - Structured design
   - Object-oriented design

   *Answer:* Object-oriented design

   *Why:* Correct! OOD is easier to maintain for large, evolving systems due to encapsulation and modularity.

## Common pitfalls

- **Wrong:** Confusing top-down decomposition with structured design as a whole
  - Why it fails: Top-down decomposition is just one technique used in structured design, not the entire method.
  - Correct: When describing structured design, mention it uses top-down decomposition, plus other key features like modularity and separation of data and function.
- **Wrong:** Claiming OOD is always better than structured design for all problems
  - Why it fails: Examiners expect you to match the method to the scenario, not state one is universally superior.
  - Correct: Link your choice to the scenario's size and requirements: structured for small static systems, OOD for large evolving systems.
- **Wrong:** Describing encapsulation as only combining data and methods, omitting data hiding
  - Why it fails: Most mark schemes require the data hiding component of encapsulation to award full marks.
  - Correct: Always mention that encapsulation hides internal data, only exposing controlled access via methods.
- **Wrong:** Listing functions as classes when designing an OOD system
  - Why it fails: This confuses structured design organisation with OOD organisation, leading to an incorrect design.
  - Correct: In OOD, classes represent nouns (entities/concepts) from the problem, methods are verbs (actions).
- **Wrong:** Claiming structured design does not use modularity
  - Why it fails: A common misconception: only OOD is modular. Both methods are modular.
  - Correct: Remember the difference is what modules are based on: structured modules are functions, OOD modules are classes/objects.

## 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 |

## 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](https://www.owlsprep.com/study/cie-9618-u12-testing/)
- [Debugging](https://www.owlsprep.com/study/cie-9618-u12-debugging/)
- [Software maintenance](https://www.owlsprep.com/study/cie-9618-u12-software-maintenance/)

---

From [OwlsPrep](https://www.owlsprep.com) — free study guides for A-Level, IB, AP and IGCSE, written against the official syllabus. Canonical page: https://www.owlsprep.com/study/cie-9618-u12-software-design-methods/