Tag Archives: apcsa

CS Coaching Card

I’m fortunate to be a member of an excellent Professional Learning Community (PLC) focused on the computer science pathway at my school. We are given an hour each week to develop formative assessments, analyze data, reflect on our instructional practices, and improve our students’ experience in our classes.

One of the essential standards for all our computer science courses is “Collaborating around Computing”. (Our essential standards are the CS Practices from the K12 Computer Science Framework.) In our PLC, we determined that some students needed additional support when supporting their classmates. Specifically, we wanted to provide students some “tips to support your peers without stealing from them the joy of discovery”. The result was the CS Coaching Card. While creating the card, we realized it was also a useful resource for those students who didn’t want assistance at the moment but still needed some support; so, we added “… or to support yourself” to the heading.

The CS Coaching Card is organized around activities: design, code, test, debug. There are tips for each activity. The tips are coded to reinforce various pillars of computational thinking: decomposition, abstraction, pattern recognition, and algorithm design. For the most part, the tips simply capture the questions and suggestions that we teachers would offer to a student.

Here’s the CS Coaching Card for AP Computer Science A:

We tweaked it a bit for our introductory Python course:

Updated Physical Representations of Variables, Objects, and References in APCSA

I’ve been meaning to update my post from 2018 – Physical Representations of Variables, Objects, and References in APCSA with how it has evolved the past two years. The impetus to finally do so is due to attending Colleen Lewis and Hannah McDowell’s CSTA 2020 session, “AP CS A: Physical Models of Java Memory”. Colleen has a document with instructions, examples, videos, everything. What I realized during the session is that my approach was missing the concrete representation; it only had the pictorial and abstract representations. (I love the use of “remote controls” to model references!) So, I’m off to buy materials (I hope I can find stuffed animals that are turtles) and add concrete representations this year. I still want to share some updates on my pictorial models that have evolved over the past two years.

The most important change has been how invoking methods are modeled. I’ve captured this pictorial model in a set of slides (slide 22 – 34). These slides capture the following examples of invoking a method:

In the classroom, white rectangles still map to full sheets of paper (objects) and yellow rectangles still map to sticky notes (variables), as described in my original post. The new addition is the green rectangle, which maps to a green half-sheet of paper in the classroom that is presented as a form that is filled out, turned in, and returned when a method is invoked. The form models a method invocation. There are some parts of the form (arguments) that must be completed before the form is turned in (method is invoked). The field “this” must be completed (for non-static methods). When filling in the form, values are always copied from sticky notes (variables) or literals. There may be a part of the form that is “for office use only”. That is, it is not completed when initially filling out the form but will be completed when the form is returned. This models the return value of the method. When the form is returned, this value is copied from the form to a sticky note.

In class, students create these pictorial representations for various examples to develop their understanding. This additional pictorial representation coupled with improvements based on comments on the original post and feedback from students, has resulted in a model that helps students develop a strong understanding of, what I believe is the most challenging concept in APCSA, references in Java. This year, I’ll demonstrate with the concrete representation and then have students create these pictorial representations.

Physical Representations of Variables, Objects, and References in APCSA

Historically, my AP Computer Science A students have struggled with the concept that the value of a variable in Java can be a reference to an object. Actually, even before I started teaching APCSA, students would find me the week of the AP exam and ask for help on this concept. Over the years, I’ve improved both my instruction and student understanding in several ways. I’ve utilized tools like BlueJ’s debugger and the Java Visualizer to help students see the relationship between these concepts. I’ve created practice programming activities that create the cognitive dissonance necessary to spur reconsideration of understanding. I’ve woven these concepts throughout the curriculum to provide students with multiple and increasing complex opportunities to explore these relationships. Finally, I’ve tried to keep my language purposeful, precise, and consistent as, too often, we refer to variables as if they are objects. Despite these actions, students still struggled with these concepts. Last year, I had a new idea, and this year I implemented it.

I decided that these abstract concepts are further abstracted by the computer, and that’s too much abstraction for students at this point. Therefore, I removed the computer, and we explored these concepts via an extended analogy in a CS Unplugged manner:

  • variables are represented by small sticky notes
  • objects are represented by full sheets of paper
  • full sheets of paper are numbered in their upper-right corner; these numbers are references

IMG 9412

Variables When a variable is declared, a new small sticky note is used and the variable’s name is written on the top of the sticky note. The value of the variable is written below the name. There isn’t a lot of room on a small sticky note. There’s only enough room for values that don’t take too much space to store such as primitive values and references to objects. You cannot write all of the properties of a Turtle object on a small sticky note! When the value of a variable changes, the previous value is crossed off, and the new value is written.

Objects When a new object is created, a new sheet of paper is used. To keep track of all the sheets of paper, they are numbered in their upper-right corners. The name of the class of the object is written at the top of the sheet. The names and values of the object’s properties are written below the class name. There is plenty of room on a full sheet of paper to write all the properties of a Turtle object. As the value of an object’s property is changed, the previous value is crossed off, and the new value is written.

References References are the numbers on the upper-right corner of the sheets of paper. They are used to find the desired sheet of paper from among all the sheets of paper. When a variable is assigned the reference to a newly created object, the value of the variable is the number on the upper-right corner of the new sheet of paper for that object.

Methods When a method is invoked on a variable that references an object, the value of the variable is used to find the desired sheet of paper. Once the sheet of paper is found, the method can operate on the object by potentially changing the object’s properties by updating a value on the sheet of paper or returning a value.

In one lesson, I modeled this extended analogy for the class in the context of a simple example involving two Turtle objects, two variables that reference Turtle objets (turtle1, turtle2), and two variables of type int (number1, number2). In the next lesson, pairs of students, with my assistance, traced through a couple of other examples using small sticky notes and sheets of paper.

Based on a short formative assessment, student understanding appears to be improved compared to previous years. I will continue to use this extended analogy as we revisit these concepts throughout the year. I may extend this analogy when students start implementing their own methods to include a paper form that represents a method invocation. Values are copied to complete the form. When the form is returned after the method returns, the returned value is copied as well.

If you have any feedback, please share!