01 | WHAT MAKES SOMETHING A SYSTEM?

Imagine organising a school trip. There are bookings to collect, transport to arrange, payments to record and information to send to families. Each job matters, but none of them alone makes the trip happen. They work together towards a shared goal.

A system is a set of parts that work together to achieve a purpose. In computing, those parts can include hardware, software, data and the people or procedures involved in using them.

A school library system, for example, helps manage books and loans. A barcode scanner, a program, stored book records and the librarian’s actions all contribute to that purpose. A pile of unrelated devices would not form the same useful system simply because they were in one room.

The key question is: what is the whole system trying to achieve, and how do its parts help? This lesson focuses on understanding the parts before writing code.

02 | A SUB-SYSTEM IS A SYSTEM WITHIN A SYSTEM

A sub-system is a smaller system that performs a particular role within a larger system. The library’s loan-management sub-system deals with borrowing and returning books. Its catalogue sub-system helps people find books. Both contribute to the larger library system.

A sub-system has a purpose of its own, but it also connects with other parts. The catalogue might show whether a book is available using information maintained by loan management. If those parts disagree, a student could be told that a book is available when it is already on loan.

A familiar hardware example is a computer. Its storage sub-system retains data, while its processing sub-system carries out instructions. These have different jobs and cooperate when you open a saved document.

“Sub-system” describes a relationship. Something can be a complete system when studied on its own and a sub-system when viewed as part of something larger.

03 | KEEP LOOKING INSIDE THE PARTS

The syllabus explains that computer systems are made up of sub-systems, which are made up of further sub-systems. We can examine a system at different levels of detail.

At the broadest level, we see “library system”. Looking inside it reveals catalogue management, loan management and member management. Looking inside loan management reveals borrowing, returns and overdue-loan checking.

Borrowing can be broken down again: identify the member, identify the book, check whether the loan is permitted and record an accepted loan. We move from a large purpose towards smaller tasks that are easier to describe precisely.

This relationship is called a hierarchy: a larger part contains smaller parts, and those parts may contain others. It does not mean the tasks always run in the order in which they are drawn.

This is one possible decomposition of a simplified school library. Real requirements may lead to a different arrangement.

04 | DECOMPOSITION: TURN ONE LARGE TASK INTO SMALLER TASKS

Decomposition means breaking a problem into smaller, manageable parts. Instead of asking “How do I build the whole library program?”, ask “What jobs must it perform?”

The smaller questions might be: how do we find a book, check whether it can be borrowed, record a loan and process a return? Each question has a narrower focus than the original problem.

This does not remove work from the project. The complete solution must still meet all its requirements. Decomposition makes the work easier to understand, plan, implement and check.

It can also reveal missing tasks. If your plan includes borrowing but nothing about returning a book, you can spot that gap before spending hours coding. A clear collection of smaller tasks helps you compare the proposed solution with the original requirements.

05 | START WITH REQUIREMENTS, NOT RANDOM PARTS

Let us return to the school-club booking system. Its requirements are to accept bookings when places remain, prevent duplicate bookings, show remaining places and retain accepted bookings for later use.

Those requirements suggest purposeful parts. A request-entry part receives an identifier. A booking-checking part decides whether the request is acceptable. An accepted-booking part updates the records. A reporting part shows the result and remaining places. A storage part saves and retrieves the data.

These parts are based on what the system must achieve. Splitting the work into “green screen”, “large button” and “small heading” might help organise a visual layout, but it would not explain the booking decisions or data handling.

Different valid decompositions are possible. What matters is whether the parts have understandable roles, cover the requirements and can cooperate. There is no rule that every system must have exactly five sub-systems.

06 | BREAK DOWN A PART THAT IS STILL TOO LARGE

“Check the booking” is a useful first step, but it still hides several decisions. We can break it down further into checking whether the identifier is already booked and checking whether capacity has been reached.

Suppose capacity is 3 and S104 and S205 are already booked. For a request from S306, the duplicate check finds no match and the capacity check finds only two existing bookings. Together, their results allow acceptance.

For S104, the duplicate check fails the request. For a new identifier when three places are already filled, the capacity check fails it. A smaller task can now be explained and checked in isolation.

As the design develops, some of these tasks may become separate procedures or functions. You do not need to write those yet. Decomposition describes responsibilities first; coding decides how to implement them.

07 | WHAT DOES EACH PART NEED AND PRODUCE?

A task name alone is not always enough. To make the parts fit together, explain what information each one receives and what it produces or changes.

The capacity check needs the maximum capacity and the current number of accepted bookings. Its result could be a yes/no answer saying whether there is room. It does not need a student’s favourite colour or a decorative page image.

The duplicate check needs the requested identifier and the existing booked identifiers. A count alone cannot tell it whether a particular student already appears in the records.

The accepted-booking task needs the identifier and the collection of bookings, and it must add the identifier only after the relevant checks permit acceptance.

A responsibility is the job assigned to a part. A connection or interface between parts describes how they exchange information. Here, “interface” means the way parts communicate, not necessarily a graphical screen.

08 | SMALL PARTS STILL NEED TO WORK TOGETHER

Imagine one student writes a capacity check that produces True when there is room, while another assumes that True means the club is full. Each may think their own code is correct, but connecting the parts will reverse the intended decision.

The problem is an unclear agreement between the parts. Write down what the result means. For example: “The availability check returns true when a new booking can fit within capacity.”

We also need to agree on data formats. If one part supplies identifiers as text such as S104 and another expects a number, the parts may not connect successfully.

Integration means bringing components together so they operate as a complete solution. Testing individual parts is useful, but integration testing checks whether their cooperation also works. The final booking count should change only when a request is accepted.

09 | HOW DECOMPOSITION HELPS DEVELOPMENT

A small task is easier to reason about because you have fewer decisions to consider at once. You can concentrate on the capacity rule without also trying to design every screen or save every file.

It supports testing. You can check the capacity task with counts below, at and above capacity, then check the duplicate task with existing and new identifiers. If one fails, you have a smaller area to investigate.

It can support teamwork: one person develops the checking component while another develops storage, provided they agree how information will pass between them. It can also support reuse if the same clearly defined task is needed elsewhere.

However, decomposition does not automatically guarantee good code or successful teamwork. Poorly defined responsibilities, missing tasks or incompatible connections can still cause problems. The benefit comes from useful parts and clear agreements.

10 | HOW FAR SHOULD YOU BREAK IT DOWN?

There is no fixed number of levels required for every problem. Keep breaking down a task while it is too broad to understand or design confidently.

“Manage the library” is too large for one clear algorithm. “Process a loan” is smaller, but still includes several checks. “Check whether a book is already on loan” may be specific enough to describe precisely at this stage.

At the other extreme, splitting “display a rejection message” into a separate task for every individual letter usually adds clutter without helping the design. More boxes do not automatically mean a better solution.

A useful stopping point is when you can explain a task’s purpose, the information it needs and its expected result, and can plan how it works. The right level of detail also depends on what the diagram or description is intended to communicate.

11 | DECOMPOSITION IS DIFFERENT FROM ABSTRACTION

In the previous lesson, abstraction simplified the booking model by removing irrelevant details. We kept capacity and identifiers, but left out wall colour.

Here, decomposition divides the work into smaller tasks: receive a request, check it, update records and report a result. We have not discarded those tasks; we have organised them.

Both techniques can be used together. When planning a capacity check, decomposition identifies it as a separate task. Abstraction helps decide that the task needs capacity and booking count, while details about the room’s decoration can be ignored.

A clear comparison is: abstraction focuses on which details matter; decomposition focuses on which smaller parts make up the problem. An answer about leaving out wall colour illustrates abstraction. An answer about separating duplicate checking from capacity checking illustrates decomposition.

12 | TRY A DIFFERENT REAL-WORLD SCENARIO

A school canteen wants a system that takes an order, works out its cost, records payment and sends preparation instructions to the kitchen.

Start with those requirements and propose order entry, price calculation, payment recording and kitchen reporting as smaller parts. Then look inside price calculation: obtain item prices, multiply each price by its quantity and total the item costs.

The quantity is how many of an item have been ordered. If a sandwich costs 4 units and the order contains two, its item cost is 8. Combining the item costs gives the order total.

Notice the connections: price calculation needs the order items and quantities from order entry. Kitchen reporting needs the accepted order details. If payment has not been completed, the agreed rules determine whether preparation can begin.

13 | DESCRIBE AND EXPLAIN WITH PRECISION

If a question asks you to describe decomposition, state that it breaks a problem into smaller manageable parts. If it asks you to decompose a particular scenario, name meaningful parts drawn from that scenario.

For an explain question, connect the technique to a benefit: “Separating duplicate checking from capacity checking allows each rule to be tested independently, therefore an incorrect decision is easier to locate.”

Avoid answers such as “it makes it easier” without saying what becomes easier and why. Avoid treating the hierarchy as an execution sequence: a structure shows which parts belong within others, while an algorithm shows the steps and decisions used to complete a task.

You should now be able to move between a whole system, its sub-systems and smaller tasks, while explaining what each part contributes. The next lesson uses inputs, processes, outputs and storage to describe those parts more precisely.