Decomposition: break it down, not apart
Breaking a problem into smaller parts that can be solved separately. Exam trap: confusing decomposition with abstraction (ignoring details) or pattern recognition (spotting similarities).
Escuchar esta página (beta)
Decomposition means splitting a complex problem into bite-sized sub-problems, each tackled on its own. Think of planning a conference: you don't book the venue, invite speakers, and arrange catering all at once; you break it into tasks like venue selection, speaker list, and menu planning. In EPSO tests, the key contrast is with abstraction, which hides unnecessary detail, and pattern recognition, which finds commonalities across problems. Decomposition is purely about dividing the work, not simplifying or comparing.
A quick elimination trick: if a scenario describes grouping tasks by type or sequence, it is decomposition; if it describes ignoring certain details to focus on the big picture, that is abstraction. Another hint: decomposition often leads to a to-do list or a flowchart with separate branches, whereas pattern recognition would involve matching a new problem to a known template. Watch out for questions that mix these up, especially when the problem involves both breaking down and finding similarities; the correct answer depends on which step comes first.
To test yourself, take any everyday problem, like cooking a new recipe, and mentally list the sub-problems: gathering ingredients, prepping tools, following steps. If you can separate these without skipping details or comparing to other recipes, you are decomposing. Remember: if the answer involves 'divide and conquer', it is decomposition; if it involves 'ignore and simplify', it is abstraction.
What is decomposition in computational thinking?
Breaking a problem into smaller parts that can be solved separately.