# Components of a Problem in Computational Thinking ## Identifying the Components of a Problem - To create **algorithms** that solve a problem, you must first identify the important parts of the problem - This identification process involves two key techniques: - **Abstracting** away unnecessary details - **Decomposing** the problem into smaller, manageable sub-problems - The goal is to isolate what truly matters for the solution ## How do you Identify the Components of a Problem? ### Understanding Abstraction

Abstraction is the process of removing unnecessary details from a real-world problem and focusing only on the details that matter for the solution

- Abstraction simplifies complex real-world scenarios by filtering out irrelevant information - Focus is placed on the essential features that will form part of the solution (components) - The level of abstraction chosen depends on the problem's requirements and constraints ### Abstraction Examples **Modelling a sports pitch:** - When representing a tennis court or cricket pitch in software, you don't need to model every individual blade of grass - A simple textured surface or flat colour typically suffices for most applications - High-fidelity games might render grass in greater detail, but this comes at the cost of increased processing demands **Other common abstraction examples:** | Task | What Users Don't Need to Know | |------|-------------------------------| | **Saving files** | The underlying filesystem operations, how data is physically written to disk sectors, how the OS manages memory through paging and segmentation | | **Sending emails** | Which protocols are being used (SMTP, POP3, IMAP), how data packets are formatted, what handshaking sequences occur between servers | | **Downloading files** | How SSL/TLS certificates are validated, how digital signatures work, what encryption protocols are negotiated | ### Practical Example: Library Management System - Consider designing a system to manage a school library - Key questions for identifying problem components: - How many books are in the library? - How many students can borrow books? - What information needs to be stored about each book (title, author, ISBN, availability)? - What are the borrowing limits (how many books per student, loan duration)? - If the system needed to generate reports and analytics, additional components might include: - Are books categorized by genre or reading level? - Does the borrowing history matter for generating recommendations? - Should the system track overdue books differently from on-time returns? - Are there peak borrowing times that affect system performance?

Abstract away details that don't affect the core functionality - not every component matters for every problem

## Identifying the Components of a Solution ### From Problem to Solution - Once you've identified the **components of the problem**, you can determine the **components needed to solve** that problem - This involves translating the problem requirements into technical implementation details ### Thinking Procedurally

Procedural abstraction means using procedures to execute sequences of instructions that achieve a specific goal

- Thinking procedurally involves breaking down the solution into executable steps - Each step should be clear, achievable, and contribute toward solving the overall problem - A **procedure** must be created to implement the solution ### Technical Considerations for Solutions Using the library management system example, several key technical areas must be considered: **Data Types:** - What are the input parameters and output data types? - Integer (for book IDs, student IDs, quantity counts) - String (for titles, author names, student names) - Boolean (for availability status) - Date/time (for due dates, borrowing timestamps) **Data Structures:** - What data structures are required? - Arrays for fixed-size collections - Lists for dynamic collections of books - Dictionaries/hash tables for quick book lookups by ISBN - Linked lists for borrowing queues **Libraries and Modules:** - Will any external libraries be needed? - Date/time libraries for calculating due dates - Database libraries for persistent storage - Sorting algorithms for organizing search results **Output Format:** - What format should the output take? - Structured data (arrays, lists, dictionaries) - Formatted strings for display - Reports in specific formats (CSV, PDF) **Processing Requirements:** - What data transformations and control structures are needed? - Calculations (fine calculations, overdue days) - Loops (for processing multiple books, iterating through students) - Selection statements (if/else for availability checks) **Efficiency Concerns:** - Is algorithm efficiency a critical factor? - Does the lookup need to be $O(1)$ or can it be $O(n)$? - Will the system handle thousands of concurrent users? - Should search operations be optimized for speed?

Once solution components are identified, the procedure can then be decomposed into detailed instructions for implementation

### Complex Solutions and Modularity - More complex problems require larger programs with multiple subroutines - These subroutines may: - Call each other to complete tasks - Use imported library functions - Work together to form a complete solution - Modular design makes programs easier to maintain, test, and debug ### Terminology Clarification

"Procedure" in thinking procedurally refers broadly to any unit of computation performing a single task, not strictly a non-returning subroutine

- In programming terminology: - A **function** is a subroutine that returns a value - A **procedure** is a subroutine that does not return a value - However, when discussing "procedural thinking," the term refers more generally to sequential, step-by-step problem-solving approaches