Informatics in Education

When we “think like a computer scientist,” we are able to systematically solve problems in different fields, create software applications that support various needs, and design artefacts that model complex systems. Abstraction is a soft skill embedded in all those endeavours, being a main cornerstone of computational thinking. Our overview of abstraction is intended to be not so much systematic as thought provoking, inviting the reader to (re)think abstraction from different – and perhaps unusual – perspectives. After presenting a range of its characterisations, we will explore abstraction from a cognitive point of view. Then we will discuss the role of abstraction in a range of computer science areas, including whether and how abstraction is taught. Although it is impossible to capture the essence of abstraction in one sentence, one section or a single paper, we hope our insights into abstraction may help computer science educators to better understand, model and even dare to teach abstraction skills.

The notion of algorithm may be perceived in different levels of abstraction. In the lower levels it is an operational set of instructions. In higher levels it may be viewed as an object with properties, solving a problem with characteristics. Novices mostly relate to the lower levels. Yet, higher levels are very relevant for them as well. We unfold the importance of higher level abstractions for novices, by demonstrating the role of declarative observations of algorithmic problems, and the benefit of developing awareness of such observations in algorithmic problem solving. This is shown in a two-stage study, which first reveals the unfortunate lack of declarative observations, and then displays comparative results of experimental and control groups, which stems from different awareness and competence with declarative observations.

Computer science students often evaluate the behavior of the code they write by running it on specific inputs and studying the outputs, and then apply their comprehension to a more general understanding of the code. While this is a good starting point in the student’s career, successful graduates must be able to reason analytically about the code they create or encounter. They must be able to reason about the behavior of the code on arbitrary inputs, without running the code. Abstraction is central for such reasoning.

Teaching software engineering (SWE) as a core computer science course (ACM, 2013) is a challenging task. The challenge lies in the emphasis on what a large-scale software means, implementing teamwork, and teaching abstraction in software design while simultaneously engaging students into reasonable coding tasks. The abstraction of the system design is perhaps the most critical and theoretical part of the course and requires early engagement of the students with the necessary topics followed by implementation of the abstract model consistently. Normally, students would take such courses in the undergraduate curriculum sequence after data structures and/or object-oriented design/programming. Therefore, they would be able to learn about systematic modeling of software as a system. In this work, we address how to facilitate the teaching of SWE by introducing abstract modeling. Furthermore, functional decomposition is reviewed as a critical component which in turn, requires understanding of how different tasks are accomplished by enterprise software. Combining such pieces with concepts of architecture and design patterns of software provides foundational knowledge for students to be able to navigate around enterprise software in the real world.

For over a decade, a declarative approach to problem solving based on the use of abstract data types (ADTs) has been taught to high-school students as part of the logic programming instructional unit. We conducted a study aimed at assessing students' problem-solving processes when utilizing ADTs. The findings indicated that students' strategies that diverged from the conceptual model often cause the students to develop incorrect programs. Specifically, students have difficulties in establishing correct mapping between the problem and its abstract model - the corresponding ADT, and in establishing proper connectivity between layers of abstraction related to different stages of the problem-solving processes (e.g., between distinct programming modules). These difficulties are apparently associated with general difficulties that novices encounter when learning programming, and with the cognitive load encountered when dealing with high levels of abstraction. With the intention to reduce student difficulties, we suggest using an instructional approach designed to gradually educate the students toward attaining proficiency as ``problem solvers'' through the use of integrative knowledge and autonomous problem-solving techniques. This approach should be further evaluated regarding its feasibility and applicability to reducing students' difficulties in dealing with abstraction processes.