COMPUTATIONAL THINKING | THINKING ABSTRACTLY

ON THIS PAGE
SECTION 1 | IDENTIFY EXAMPLES OF ABSTRACTION. 
SECTION 2 | EXPLAIN WHY ABSTRACTION IS REQUIRED IN THE DERIVATION OF COMPUTATIONAL 
SOLUTIONS FOR A SPECIFIED SITUATION. 
SECTION 3 |CONSTRUCT AN ABSTRACTION FROM A SPECIFIED SITUATION. 
SECTION 4 | DISTINGUISH BETWEEN A REAL-WORLD ENTITY AND ITS ABSTRACTION. 

ALSO IN THIS TOPIC
THINKING PROCEDURALLY
THINKING LOGICALLY
THINKING AHEAD
THINKING CONCURRENTLY​ 
 YOU ARE HERE | THINKING ABSTRACTLY
 FLOWCHARTS
MORE COMING SOON

---

SECTION 1 | IDENTIFY EXAMPLES OF ABSTRACTION​​

In computational terms, abstraction refers to the concept of hiding the complex reality while exposing only the necessary parts. Abstraction involves encapsulating the complex reality and providing a simplified view. Abstraction is used in several forms and levels to manage complexity, promote reusability, and enhance the maintainability and scalability of systems and solutions. There are various types of abstraction including:

DATA ABSTRACTION

• Definition: Managing data complexity by hiding the details about how data is stored and manipulated.
• Example: Utilising classes and objects in object-oriented programming to manage and manipulate data without revealing internal processing and storage mechanisms.

PROCEDURAL ABSTRACTION

• Definition: Hiding the internal workings of procedures or functions, exposing only the relevant outcomes or interfaces.
• Example: Using a function to calculate the square of a number without needing to know the internal algorithm that the function uses.

HARDWARE ABSTRACTION

• Definition: Shielding the software from the complexities and specifics of the hardware used to implement it.
• Example: Using a printer to print documents without needing to know the internal mechanisms of how the printer functions.

SOFTWARE ABSTRACTION

• Definition: Utilising software entities like methods, classes, and objects to hide complex code implementations from the user.
• Example: APIs (Application Programming Interfaces) provide predefined functions to interact with, without revealing the internal code.

Abstraction can be broken down into two levels.

• High-level Abstraction: Deals with larger entities such as modules or systems, focusing on systemic interactions and overarching functionality, and hiding the internal details.
• Low-level Abstraction: Focuses on smaller entities such as data or methods, dealing with detailed implementations while hiding these specifics from higher abstraction levels.

SECTION 2 | EXPLAIN WHY ABSTRACTION IS REQUIRED IN THE DERIVATION OF COMPUTATIONAL SOLUTIONS FOR A SPECIFIED SITUATION

Abstraction is a pivotal concept in deriving computational solutions, particularly because it aids in managing the inherent complexity of problems and facilitates a focused and efficient approach toward solution development. Here’s why abstraction is indispensable in deriving computational solutions:

MANAGING COMPLEXITY

• Simplify Problems: Abstraction allows the simplification of complex problems by hiding the intricate details and allowing developers to focus on high-level functionalities.
• Problem Decomposition: It assists in breaking down complex problems into simpler, manageable components or layers, enabling a step-wise approach toward solving them.

​
ENHANCING FOCUS

• Focus on Relevant Details: Abstraction enables developers to focus on the aspects relevant to the current stage of problem solving or software development.
• Avoiding Overwhelm: It prevents information overload and allows developers to tackle aspects of the problem systematically without being overwhelmed by the entirety of the complexity.

FACILITATING REUSABILITY

• Reusable Components: Designing abstracted components or modules facilitates their reuse in different parts of the solution or in different projects.
• Efficient Development: Reusability means not reinventing the wheel, leading to more efficient and time-effective development processes.

ENCOURAGING MODULARITY

• Independent Modules: Abstraction promotes the creation of independent modules which can be developed, tested, and modified independently.
• Parallel Development: With clearly defined modules, different development teams can work on different parts of a project concurrently, optimising the development timeline.

IMPROVING UNDERSTANDING

• Clearer Conceptualistion: Abstraction helps in forming a clear, high-level understanding of the problem and the proposed solution among all stakeholders (developers, managers, clients, etc.).
• Effective Communication: Enhanced understanding facilitates better communication and collaboration among team members.

SCALABILITY AND MAINTENANCE

• Scalability: Abstracted solutions often allow for easier modifications and additions, aiding in the scalability of the software.
• Easier Maintenance: Since abstraction leads to well-organised and modular code, maintaining and updating the software becomes more straightforward.

ENHANCING SECURITY

• Hiding Implementation Details: Abstraction hides the internal workings of modules, exposing only what is necessary, thereby safeguarding the system’s internal structures and data.
• Preventing Unauthorised Access: By not exposing the internal details of modules, abstraction minimizes the risk of unauthorised data manipulation or access.

SECTION 3 |CONSTRUCT AN ABSTRACTION FROM A SPECIFIED SITUATION

You should be able to break down a given scenario by abstracting details needed and how the situation can be modularised, here we give a scenario and example solution for this task. 

Scenario: Online Shopping System
Situation: Imagine an online shopping platform where customers can browse through various products, add them to their shopping cart, and proceed to checkout for payment. 

Functionalities might include
- Browsing products
- Adding/removing items to/from the cart
- Checking out
- Making a payment
- Reviewing purchased history

Constructing an Abstraction Example
To design a simplified and efficient system, we can apply abstraction to hide the complexity of each functionality while providing a straightforward interface for users and developers. 

1. Product Browsing Abstraction

• High-Level View (Exposed to Users): A gallery of products with basic information such as name, price, and a small image. Users can click on a product to see more details.
• Hidden Details (Abstracted): Retrieval of product data from the database, handling image loading, managing user sessions, tracking user browsing patterns, etc.

2. Shopping Cart Abstraction

• High-Level View: A shopping cart icon showing the number of items, total price, and options to view the cart or proceed to checkout.
• Hidden Details: Data management of added products, price calculations, memory allocation for cart items, session management, and possibly temporary storage of cart data for future retrieval.

3. Payment Process Abstraction

• High-Level View: A single button for making payments, with simple fields for users to input payment details.
• Hidden Details: Secure data transmission of payment details, server-side payment processing, interaction with payment gateways, handling payment confirmations or failures, managing transaction data, etc.

4. Purchase History Abstraction

• High-Level View: A list of previously purchased items with the date of purchase, total amount, and status.
• Hidden Details: Data retrieval and management from the database, user authentication, managing and formatting purchase history data, and handling any data errors or inconsistencies.

Explanation
Each of these abstractions simplifies user interaction by presenting only the necessary components, such as buttons, images, and simple data input/output. Meanwhile, they conceal the complex underlying processes like data retrieval, user session management, secure data transmission, and interactions with databases or other systems. 

This approach allows developers and users to interact with the system at a high level, without getting bogged down by or even needing to understand the intricacies of the underlying processes unless explicitly working on them. It promotes a modular approach to software design, enabling various functionalities to be developed, refined, and interacted with independently.

SECTION 4 | DISTINGUISH BETWEEN A REAL-WORLD ENTITY AND ITS ABSTRACTION

The real-world entity encompasses all possible details and is subject to constant change, offering a holistic but overwhelmingly complex view. On the other hand, its abstraction distills this complexity into a simplified, purpose-driven, and manageable form. Abstraction, therefore, becomes pivotal in converting the unmanageable detail of reality into usable, accessible information, allowing individuals to plan, predict, and make informed decisions without becoming entangled in unmanageable complexity. This concept is transferrable to computational and software design, where abstraction is used to manage complexity and facilitate the focused, purposeful interaction with systems. Here we give an example of territory and a map.

"The map is not the territory" is a classic adage in various academic disciplines and underscores the pivotal concept of abstraction, especially pertinent to computational thinking and system design.

Real-World Entity: The Territory
Characteristics:

• Complexity: The territory encompasses a wide range of complexities, including diverse landforms, various ecosystems, numerous paths, and multiple structures.
• Detail: Every minor detail, such as the types of vegetation, precise elevations, and specific materials of structures, is present.
• Scale: It is on a 1:1 scale, meaning that every detail is in its true size and form.
• Dynamic: The territory is subject to change, influenced by weather, human activities, and natural processes like erosion or plant growth.

Abstraction: The Map
Characteristics:

• Simplified: The map omits numerous details to maintain simplicity and usability. It doesn’t show every tree or every building detail but offers a simplified view of the layout.
• Scaled Down: A map is a scaled-down representation of the territory, meaning features are depicted much smaller than they are in reality.
• Static: Although territories change, maps remain static until they are updated. They may not reflect real-time changes in the environment.
• Purpose-Driven: Different maps abstract different details depending on their purpose. A road map highlights streets and highways, while a topographic map focuses on elevations and landforms.

Distinguishing Example
Imagine a hiker planning a journey through a mountain range

• The Territory (Real-World Entity): To know every detail, the hiker would have to traverse through every possible path, noting every rock, tree, elevation change, and potential danger, which is immensely time-consuming and impractical.
• The Map (Abstraction): Conversely, using a map, the hiker can plan the route by viewing simplified, relevant details like paths, significant landmarks, and general topography without getting bogged down by the complexities of the actual territory.

SCENARIO
Jenny and Jane, two best friends, are embarking on a 10km walk up a scenic mountain in Switzerland. The weather is favorable with a clear blue sky, and the environment is lively with other hikers and dog walkers. Jane has a walking speed of 7km/h, while Jenny walks at a pace of 5km/h. To enjoy each other's company, they agree to walk together at Jenny’s pace. They set off on their journey at 8am.

TASK
1: Abstract Necessary Details: Identify and extract the critical details from the scenario needed to calculate the expected arrival time at their destination.
2: Perform Calculations: Using the abstracted details, calculate how long the walk will take and consequently, determine the expected arrival time at their destination.
3: Answer the Question: Provide the expected arrival time based on your calculations.

NAVIGATION

COMING SOON