Thinking Procedurally

Thinking procedurally means breaking a complex problem into smaller, manageable sub-problems and determining the correct order in which to solve them. This involves decomposition, identifying components, determining order, top-down design, and structure diagrams.

---

What Is Procedural Thinking?

Procedural thinking is about answering three questions:

1. What are the components (sub-problems) of this problem?
2. In what order must they be solved?
3. How do the components interact with each other?

---

Decomposition

Decomposition is the process of breaking a large, complex problem into smaller, more manageable sub-problems. Each sub-problem can then be solved independently or further decomposed.

Example: Building a school management system.

Level 1	Level 2	Level 3
School Management System	Student Records	Add student
		Edit student
		Delete student
		Search students
	Timetable	Create timetable
		Edit timetable
		View timetable
	Attendance	Mark attendance
		Generate reports
	Exams	Enter results
		Calculate grades
		Print reports

Each sub-problem at the lowest level is small enough to be solved directly.

Benefits of decomposition:

Benefit	Explanation
Manageable complexity	Small problems are easier to solve than large ones
Parallel development	Different team members can work on different sub-problems simultaneously
Testing	Each component can be tested independently
Reusability	Components may be reusable in other systems
Maintenance	Easier to find and fix bugs in small, well-defined components

---

Identifying Components

When decomposing a problem, you need to identify the components — the distinct parts of the system.

Techniques for identifying components:

Technique	Description
Noun analysis	List the nouns in the problem description — these often become data structures or objects
Verb analysis	List the verbs — these often become functions or procedures
Input-Process-Output	Identify what goes in, what processing occurs, and what comes out
User stories	"As a [user], I want to [action] so that [benefit]"

Example — Online shopping system:

Nouns (data/objects)	Verbs (processes/functions)
Customer	Register, login, logout
Product	Search, view, add to basket
Basket	View, update quantities, remove items
Order	Place, confirm, track
Payment	Enter details, validate, process
Delivery	Schedule, track, confirm

---

Determining Order

Not all sub-problems can be solved in any order. Some depend on others being completed first.

Types of ordering:

Type	Description	Example
Sequential	Tasks must be done one after another	Validate input, then process, then display output
Parallel	Tasks can be done simultaneously	Download images while loading text on a web page
Conditional	A task is only performed if a condition is met	Only process payment if items are in the basket
Iterative	A task is repeated until a condition is met	Keep asking for input until it is valid

Dependencies between components:

Component A	Component B	Dependency
User login	View dashboard	Must log in before viewing dashboard
Add to basket	Place order	Must have items in basket before ordering
Enter payment details	Process payment	Must have details before processing

Key Term: A dependency exists when one component requires the output or completion of another component before it can execute.

---

Top-Down Design

Top-down design starts with the most general description of the system and progressively breaks it down into more detailed sub-systems.