ROOM 123

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: Utilizing 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: Utilizing 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, optimizing the development timeline.

 

IMPROVING UNDERSTANDING

​

• Clearer Conceptualization: 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-organized 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 Unauthorized Access: By not exposing the internal details of modules, abstraction minimizes the risk of unauthorized 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 modularized, 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 purchase 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 transferable 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.