Using Memory Diagrams When Teaching a Java-Based CS1

Mark A. HollidayDavid R. LuginbuhlDept of Mathematics and Computer ScienceWestern Carolina University

ACM-SE ConferenceMarch 7, 2003Savannah, GA

3/7/2003ACM-SE

Overview

Motivation and Introduction Diagramming as a teaching tool

– Objects, variables, and references– Primitive types, fields, visibility, and parameter

passing– Static fields and methods– Arrays

Diagramming as an assessment tool Conclusion

3/7/2003ACM-SE

Motivation

Problem:– How to help CS1 students visualize state of

computer as Java program executes– How to introduce and reinforce object-oriented

concepts in an introductory CS course Solution:

– Diagrams• Abstraction; visualization

– “UML”-like• UML not primarily focused on state of memory

– Diagrams used in many textbooks, but without much emphasis

3/7/2003ACM-SE

Criteria

Take into account features of language (for us, Java) Visualize state of computer Distinguish between

– Objects: classes: reference variables– Reference types: primitive types– Private: public

Consistency for similar concepts Method invocation and object construction Labels, as appropriate Arrays vs. other objects

3/7/2003ACM-SE

Memory Diagrams

Similar to other diagrams– See, particularly, [WU2001]– But with extensions and particular emphases

Important aspects– Shape matters– Importance of reference and invocation– Indication of values with variables– Visibility rules

3/7/2003ACM-SE

Objects, Variables, and References

String acolor=“blue”;

String favColor=aColor;

String otherColor;

String

“blue”

aColor

favColor

otherColor

Features: Labels on objs and vars Different shapes Reference lines begin

inside variable

3/7/2003ACM-SE

Method Invocation

aColor = aColor.concat(otherColor);

String

“blue”

aColor

otherColor

String

“red”concat

( )

String

“bluered”

XFeatures: Method indicated by line on object

– Indicates each object has method Method is public Squiggly line indicates invocation New object created New value for aColor; old value

removed

3/7/2003ACM-SE

Primitive Types, Fields, Multiple Instances

Primitive type variables have numeric value

– As opposed to ref types Private fields

represented inside object– Using rectangles indicates

fields are just variables associated with objects

Different Student objects have same fields with (possibly) different values

Studentfirst

second

Student

87score

85score

name

name

String

“Sue”

String

“Bob”

3/7/2003ACM-SE

Static fields and methods

Static fields and methods are displayed in a diamond instead of a circle

– Punch clock provides a nice example for static fields and methods

See paper for more examples, including passing parameters and diagramming arrays

Employee

8 16clock

Employeejohn

8start

16end

advance

(8)

3/7/2003ACM-SE

Student Exposure to Diagrams

We introduce these diagrams to students on the first day of CS1 class

We ask students to produce diagrams of their own– In groupwork– In directed lab work– On quizzes and tests

Bottom line: reinforcement of concepts in a number of contexts– But not just for learning…

3/7/2003ACM-SE

Student Assessment

By having students use diagrams themselves, we have them demonstrate their comprehension of object-oriented concepts

We believe these diagrams have potential for measuring programming comprehension– Anecdotal evidence from several

semesters of application

3/7/2003ACM-SE

Example Test Problem From Last Fall

Diagram the program fragment belowDog spot; // fig a)spot = new Dog("spot");

// right hand side is fig b)// left hand side and equal sign is fig c)

System.out.println(spot.toString()); // fig d)

Note last line particularly– Static public variable (System.out)– Method composition– PrintStream object– Dog object– Creation of a String object

3/7/2003ACM-SE

Results(13 students)

Figure a– 11 correct– 2 labeled rectangle

with name of class

Figure b– 4 correct– 2 put “spot” inside var rectangle– 4 didn’t show name field– 2 had more serious errors

Figure c – all but 1 student correct

Dog spot; // fig a)spot = new Dog("spot");

// right hand side is fig b) // left hand side and equal sign is fig c)System.out.println(spot.toString()); // fig d)

3/7/2003ACM-SE

Results(13 students)

Figure d– All but 3 students showed call to toString() correctly– Of those 10

• 2 students failed only to show System.out correctly• 1 showed nothing else correctly• 5 missed the creation of a String object from toString()

– They got the println() call right• 2 showed the String object

– But they missed the println() call

Summary for this exam– “Decent” correlation between overall grades and

grades on diagramming problem

Dog spot; // fig a)spot = new Dog("spot");

// right hand side is fig b) // left hand side and equal sign is fig c)System.out.println(spot.toString()); // fig d)

3/7/2003ACM-SE

Summary for Assessment

We have more work to do We are considering a more rigorous

examination of diagramming as a student assessment tool– Not just to measure progress– We hope we can pinpoint problems and provide

proper reinforcement of specific concepts

3/7/2003ACM-SE

Conclusion – Memory Diagrams

A relatively low-tech approach for teaching OO concepts– Well-suited for classroom, labs, exams– Importance of shape and placement for reinforcing concepts– Having students make their own diagrams adds to this

reinforcement

Promise of diagrams for measuring comprehension– If students can diagram what is happening in memory, they are

probably understanding the deeper meaning of the program– More work to do