Computer Science - ICT Grade 7: Computational Thinking Decomposition and Abstraction

Grade 7 Computer Science (ICT) Study Guide Topic: Computational Thinking – Decomposition and Abstraction

1. The Driving Question

"How do you plan a birthday party for 30 kids without forgetting the cake, the games, or the parents who need to pick them up — and why does breaking it into smaller pieces make the whole thing feel less overwhelming?" If you’ve ever tried to solve a big problem and felt stuck, decomposition and abstraction are the tools that let you zoom in on the details without losing sight of the big picture. How do you decide which parts matter, which parts don’t, and how they all fit together?

2. The Core Idea – Built, Not Listed

Imagine you’re designing a video game level where the player has to escape a haunted mansion. The mansion has 50 rooms, each with puzzles, enemies, and hidden keys. If you tried to code the whole thing at once, you’d get lost in the details—where does the ghost spawn? How does the door unlock? What if the player skips a room?

Decomposition is like drawing a floor plan of the mansion first. You split the problem into smaller, manageable parts: one room at a time. Instead of thinking, "How do I code the whole mansion?" you ask, "How do I code the library?" Then the kitchen, then the basement. Each room is its own mini-problem, and once they all work, you can connect them.

Abstraction is deciding what details to ignore so you don’t get overwhelmed. For the library, you don’t need to know the color of the curtains—you just need to know: - The player can pick up a key here. - The ghost appears after 30 seconds. - The door locks behind them. You hide the how (the code for the ghost’s AI) and focus on the what (the ghost exists and scares the player). Later, you can go back and tweak the ghost’s speed or sound effects without breaking the rest of the game.

This is how programmers, engineers, and even chefs solve big problems: break it down, then hide the messy details so you can focus on what matters.

Key Vocabulary:
1. Decomposition - Definition: Breaking a complex problem into smaller, independent parts that can be solved separately. - Example: Planning a school field trip by splitting tasks: permission slips, bus schedule, lunch orders, emergency contacts. Each is its own "sub-problem." - Grade 7 Note: Later, in coding, you’ll decompose programs into functions (like "checkPassword()" or "drawPlayer()").

1. Abstraction
2. Definition: Focusing on the essential details of a problem while ignoring the irrelevant ones to simplify it.
3. Example: Using a Google Maps pin to mark a location. You don’t need to know how GPS satellites work—you just need the pin to show up on your screen.

4. Grade 7 Note: In high school, abstraction gets deeper: you’ll learn how data structures (like lists or dictionaries) hide complexity so you can use them without knowing their inner workings.

5. Modularity

6. Definition: Designing parts of a system so they can be reused or changed without affecting the whole.
7. Example: A Lego set—each brick is a module. You can swap out a red 2x4 brick for a blue one without rebuilding the entire spaceship.

8. Grade 7 Note: In coding, modularity means writing functions that do one thing well (e.g., "calculateTax()") so you can reuse them in different programs.

9. Interface

10. Definition: The "visible" part of a system that lets you interact with it without knowing how it works inside.
11. Example: A light switch. You don’t need to know about wiring or electricity—you just flip the switch to turn the light on or off.
12. Grade 7 Note: In software, interfaces are like buttons or menus—they let you use a program without seeing the code behind them.

3. Assessment Translation

How This Appears in Class (Grade 7): - Formative Assessments: Short tasks where you decompose a problem or identify abstractions in a scenario. Example: - "Design a robot to clean your room. List 3 smaller tasks the robot must do (decomposition) and 2 details you can ignore (abstraction)." - "Explain how a vending machine uses abstraction. What details does it hide from the user?" - State Standardized Tests (e.g., ISTE, CSTA): Multiple-choice or short-answer questions testing your ability to: - Identify decomposition in a real-world scenario (e.g., "Which of these is an example of breaking a problem into smaller parts?"). - Recognize abstractions (e.g., "Which detail is NOT important when designing a traffic light system?"). - Distractor Patterns: Wrong answers often include: - Overcomplicating (e.g., listing too many details for abstraction). - Mixing up decomposition and abstraction (e.g., saying abstraction is "breaking a problem into parts"). - Irrelevant details (e.g., including the color of a robot when asked about its tasks).

Model Proficient Response: Prompt: "You’re designing a mobile app to help students organize their homework. How would you use decomposition and abstraction to plan it?"

Student Response: *"First, I’d decompose the app into smaller parts:
1. A calendar to track due dates.
2. A to-do list for daily tasks.
3. A reminder system for upcoming deadlines.
4. A way to categorize assignments by subject.

For abstraction, I’d hide details like: - How the calendar syncs with Google Calendar (users just need to see their schedule). - The code for sending notifications (users just need to get a ‘Math test tomorrow!’ alert). This way, I can focus on making each part work well without getting stuck on how the whole app connects."*

What Makes This Proficient? - Clearly lists specific decomposed parts (not just "features"). - Identifies concrete abstractions (not vague like "the app works"). - Explains why abstraction is useful (hiding complexity).

4. Mistake Taxonomy

Mistake 1: Decomposition Without Independence Prompt: "Decompose the problem of planning a school dance into 3 smaller tasks."

Common Wrong Response:
1. Book the DJ.
2. Decorate the gym.
3. Make sure the DJ plays good music during the dance.

Why It Loses Credit: - The third task depends on the first (the DJ’s music quality isn’t a separate problem). Decomposition requires independent parts that can be solved separately. - It’s also too vague—"good music" isn’t actionable.

Correct Approach:
1. Book the DJ (research, contract, payment).
2. Decorate the gym (theme, supplies, setup crew).
3. Promote the dance (posters, social media, announcements). Each task can be assigned to a different team without overlapping.

Mistake 2: Abstraction as "Hiding Everything" Prompt: "Explain how a car’s speedometer uses abstraction."

Common Wrong Response: "The speedometer hides all the details about the car so you don’t have to think about them."

Why It Loses Credit: - Abstraction isn’t about hiding everything—it’s about hiding irrelevant details. The speedometer does show one detail (speed) while hiding others (engine RPM, fuel level). - The response doesn’t explain what is hidden or why.

Correct Approach: "The speedometer abstracts away details like: - How the car measures speed (wheel sensors, GPS, etc.). - The engine’s RPM or fuel level. It only shows the essential detail—the current speed—so the driver can focus on driving safely without distractions."

Mistake 3: Confusing Abstraction with Simplification Prompt: "Give an example of abstraction in a video game."

Common Wrong Response: "The game is abstract because it’s not real life—it’s simpler."

Why It Loses Credit: - Abstraction isn’t about making things simpler—it’s about focusing on what matters. A game can be complex (e.g., Minecraft’s redstone circuits) but still use abstraction. - The response doesn’t name a specific abstraction.

Correct Approach: "In Minecraft, the crafting table abstracts away the details of how items are made. You don’t need to know the exact materials or steps—you just drag items into the grid and get a pickaxe. The game hides the ‘recipe’ code so you can focus on building."

5. Connection Layer

1. Within Computer Science: [Decomposition]-[Algorithms] Decomposition is how you turn a big problem (e.g., "sort a list of names") into smaller steps (e.g., "compare two names, swap if needed, repeat"). Without decomposition, you can’t write algorithms.

2. Across Subjects: [Abstraction]-[Scientific Models] In science, a model (like a diagram of a cell) is an abstraction—it hides some details (e.g., the exact number of mitochondria) to highlight what’s important (e.g., the nucleus controls the cell). Both models and abstractions let you focus on the key parts of a system.

3. Outside School: [Modularity]-[IKEA Furniture] IKEA’s flat-pack furniture is modular—each part (shelf, screw, panel) is designed to fit with others. You can replace a broken shelf without buying a whole new bookcase. This is how software libraries work: you can update one module (e.g., a login system) without rewriting the entire app.

6. The Stretch Question

"If decomposition and abstraction are so powerful, why do some big projects (like video games or space missions) still fail?"

Pointer Toward the Answer: - Decomposition can create new problems: If you break a project into too many parts, you might struggle to put them back together (like a puzzle with missing pieces). Example: No Man’s Sky (2016) had so many modular systems that they didn’t interact smoothly at launch. - Abstraction can hide critical flaws: If you ignore too many details, you might miss a dealbreaker. Example: The Ariane 5 rocket exploded because its code reused an abstraction from the Ariane 4—without accounting for the new rocket’s faster speed. - The real world is messy: Decomposition assumes problems are independent, but in reality, parts often depend on each other (e.g., a game’s physics engine affects both graphics and gameplay). Abstraction works best when you choose the right details to hide—and that’s harder than it sounds.

Follow-Up: "How would you design a system to avoid these pitfalls?" (Hint: Think about testing each decomposed part before combining them, and documenting abstractions so others understand their limits.)