for all of them this
was the first time that they had studied CS in school. Both
groups studied the same unit for the same number of hours,
using the same textbook and covering the same material. As
noted above, the only difference was that in the experimental
group the teachers were instructed to treat abstraction explicitly
and teach according to the underlying teaching framework,
whereas in the control group the teachers, as well as the
students were not explicitly exposed to these ideas.

the girls represented approximately 47% of the students.
As will be elaborated on later, we used a pre-test to learn about
the students' backgrounds. About 30% of the students in each
group had prior experience with CS. About 60% of the students
with prior CS experience were boys, evenly distributed between
the groups. Usually, this consisted of one after-school course in
basic programming with Scratch.

The research population included 187 students (out of 213) who
took the final exam. Of these, 106 students participated in the
first year of the research, and 81 participated in the second year.
A full detailed distribution is listed in our report here

Both groups were taught using a
textbook [4] that was written for students aged 13-15. The book
introduces many ideas and concepts of CS through the use of
Scratch. In general, the textbook is written in the spirit of
Armoni's framework [3]. For example, every task in the textbook
is solved from Level 4 through Level 3 and only then are the
corresponding Scratch scripts presented or developed. However,
the treatment of abstraction in this textbook is not explicit

These guidelines were revisited with the teachers
using specific examples during the school year. Teachers in the
control group were instructed to teach the unit using the
guidelines of the STEP program and were not given any
additional special instructions or information about the goals of
the study, or exposed to any further abstraction-related
treatment during the study

We used a comparative setting with two groups: (1) an experimental
group consisting of students that were taught by using the
framework for teaching abstraction, and (2) a control group that
was taught the same unit over the same number of hours but
without using the framework. The teachers in the experimental
group attended a guidance session that included an explanation about abstraction in the context of this unit and introduced the
guidelines for teaching, accompanied by corresponding
examples.

As mentioned before, the study described here was part of a
wider one. This study was conducted during two full school
years, in the context of an existing introductory CS unit taught
to 7th-grade students (ages 13-14). This unit is part of the STEP
program [45] developed by the Israeli Ministry of Education for
middle schools. Students are introduced to CS ideas and concepts
such as algorithms, control structures, message passing, and
variables, using the Scratch programming environment.

As for the previous measure, we also
examine general CS performance, and here CS performance is
indicated by the overall correctness of an answer to a test
question. Here we evaluate additional CS knowledge besides
basic Scratch knowledge, and consider various aspects, such as
the kind and extent of errors in the solution, and the use of
algorithmic patterns.

Dynamic instruction-timing information is captured for load instructions within loop iterations; other instructions are scheduled with static timing information. Instruction issue is done via priority queue ordered by expected ready time. The simplicity of the mechanisms implementing these functions provides the benefit; for example, complex resource-scheduling schemes can be replaced by assigning queues to resources.

We assume that
since abstraction is a fundamental idea of CS, abstract thinking,
expressed in better abstraction skills, will lead to better overall
CS performance, that is, to higher achievements in CS
performance tests. This measure expresses one aspect of CS
performance that is relevant to this course, namely, how
students answered simple Scratch questions.

Some of the measures above (for example,
using black-box arguments and providing verbal descriptions)
constitute clear evidence for working at certain levels of
abstraction, which, according to the literature, students tend to
neglect. However, good abstraction skills are also reflected in the
ability to move freely between levels of abstraction, and in a
meta-layer of being aware of the abstraction level at which one
is currently working, and of the transitions between abstraction
levels.

a good
initialization process indicates understanding and perceiving a
program as an object that will be executed over and over again
with different inputs. Therefore, we also measure the use and
quality of initialization within the Scratch solutions.

an
initialization phase indicates an understanding that every script
is an entity that can be executed many times (thus, an execution
can be affected by previous executions unless appropriate
initialization is performed). Using initialization and
understanding the need for it reflect working at Level 2 and
above, whereas neglecting initialization indicates working at
Level 1 (considering only a single execution).

In Scratch, an environment that emphasizes
spatial behavior of sprites, initialization is beyond the traditional
setting of initial values to variables, and it involves sprites attributes (e.g., location, direction, and costume) and other
parameters such as the background of the stage.

An explanation of a solution,
which also justifies its correctness, and can also serve as evidence for
abstraction. In order to provide such an explanation, the students
must examine the problem from a higher level of abstraction,
and work at Level 3 and even Level 4. Note that this explanation
need not be written before the script is written, as is the case
with preplanning in the form of a verbal description. However,
both demonstrate the ability to describe the solution at a high
level of abstraction, Level 3.

This
yields a more concise answer, which is clearly on a higher level
of abstraction (Level 3 rather than Level 2). Recognizing that a
verbal description is sufficient and also indicates a higher level of
abstraction, acknowledging that a Level-3 description manifests
a solution to an algorithmic problem.

In some of the questions
in the post-test, the students were asked to describe a solution
(an example is Question 6, described in Section 3.4).
Consequently, when solving these questions, the students could
choose to provide only a verbal description as a solution (rather
than presenting a verbal description with a complete Scratch
script, or even providing only a complete Scratch script).

Creating a verbal description before writing a script is an
expression of preplanning as a preliminary phase of the solution
process. Obviously, as directly follows from the definition of the
PGK-hierarchy, writing a verbal description constitutes a clear
evidence for working at Level 3. Writing a verbal description, as
a first step in the solution process expresses the understanding
that solving an algorithmic problem is encapsulated in Level 3,
and that programming is an implementation of Level-3 solutions
at a more concrete level.

In the textbook that was used in
the introductory course [4], the intuitive term “verbal
description” is used instead of the scientific term, algorithm. This
was motivated by the young age of the students, and the intent
to focus on the essence of the introduced concepts, and not
necessarily to incorporate the corresponding “professional”
terms.

The study described here was part of a wider study, which aimed
at investigating the effect of explicitly teaching CS abstraction to
7th-grade students using Armoni's framework [3]. Motivated by
some differences between boys and girls that emerged during the
analysis.

Order from high to low: all discussions start from higher levels
of the hierarchy (starting with Level 4 of the problem) and then
start oscillating between the levels as appropriate, going down to
lower levels only when a more concrete treatment is required.
As Dijkstra put it ([18], p. 1), “[T]his oscillation between ‘the
representation’ and ‘what it stands for’ is an intrinsic part of the
programmer's game, of which he had better be aware! (It could
be also this oscillation, which makes programming so difficult
for people untrained to switching between levels.)”.

Use linguistic components as an aid to distinguish between
levels. For example, in the context of Scratch, restrict the use of
the word “repeat”, which is used in the corresponding Scratch
blocks, to Level 2, and at higher levels use various words or
phrases, such as “perform until”. Similarly, problems belong to
Level 4, whereas algorithms belong to Level 3; therefore, at level
4 one will use the word “sort”, whereas the use of specific names
of sorting algorithms, such as QuickSort, belongs to Level 3.

Be persistent and precise: instructors should be aware of
which abstraction level they work at, and should clearly (even
meticulously) distinguish between the levels, to make students
aware of the current level of abstraction, and when it is changed.