Assessing the Understanding of Expressions: A Qualitative Study of Notional-Machine-Based Exam Questions
Joey Bevilacqua
Luca Chiodini
Igor Moreno Santos
Matthias Hauswirth

2024

Proceedings of the 24th Koli Calling International Conference on Computing Education Research

Background and Context: Notional machines are widespread in computing education. While they often are used to explain programming concepts, prior work on visual program simulation demonstrated their use for assessment. This paper presents a qualitative study of the use of a notional machine identified in prior literature“expression as tree”—as an instrument to assess the understanding of expressions. Objectives: The study answers the following research questions: What are the mistakes that students make when answering questions based on the “expression as tree” notional machine? What underlying reasons plausibly explain these mistakes? Are there plausible relationships between the mistakes and programming language misconceptions? Method: We collect a corpus of 542 hand-drawn expression tree diagrams from 12 exams in 6 university programming courses at two different levels over the course of 4 years. We devise and use a coding approach tailored to the qualitative analysis of those diagrams. Our qualitative data analysis approach is unique due to the specific form of the data—hand–drawn diagrams—that admits a wide variety of mistakes, due to the theoretically well–defined programming language constructs that underpin the visualizations, and due to the fact that for each diagram there exists a unique solution that can serve as a reference. Findings: Our results show that even a single question based on the notional machine is able to reveal a rich variety of mistakes related to the structure, typing, and evaluation of expressions. We identify and categorize 48 mistakes and describe outstanding ones in detail, supported by example diagram snippets. We find mistakes that are plausibly connected to known misconceptions, and others that suggest the existence of new ones. Implications: Our findings shed light on novel pedagogical strategies to teach programming and provide insights instructors can use to transform their practices. The use of the “expression as tree” notional machine as an assessment instrument can provide valuable insights into students’ understanding of several key aspects of programming.

Study Information
Manually extracted from the paper by the Progmiscon.org team

Programming Languages

Java

Method

Qualitative and quantitative systematic research

Subjects

542 hand-drawn expression trees from 12 exams in 6 university courses

Artifact

https://zenodo.org/records/13898595

Related Study Results
Phenomena studied in this paper that map to Progmiscon.org misconceptions

The following list summarizes those phenomena reported in this study that provide evidence for misconceptions documented on Progmiscon.org. (The paper may provide evidence for other misconceptions as well. This list focuses exclusively on misconceptions documented on Progmiscon.org.)

Diagram mistakes
Mistakes in student-drawn expression trees, related to structure, types, or values

LiteralInlined
A literal is inlined into the parent node
41 / 447
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
VariableInlined
A simple variable access or field access is inlined into the parent node
83 / 346
Cases
TargetInlined
The target (expression before dot) has been inlined (e.g., into a method invocation or a field access with explicit targets).
97 / 303
Cases
IndexInlined
The index in an array access expression has been inlined.
25 / 79
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
NewIsolated
Token 'new' is kept in separate node, which possibly includes a hole for connection.
3 / 124
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
RightToLeftAssociativity
Binary operator that is left-to-right associative is treated as right-to-left associative.
15 / 49
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
TreeIsChainInSourceOrder
The tree is primarily a chain, reflecting, in order (e.g., left to right -> top to bottom) the constructs of the source code.
5 / 40
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
SubstitutionTakenFromEvaluation
A node is replaced with a subtree containing code that appears inside methods or constructors called by the expression.
62 / 480
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
ImplicitThis
An *implicit* this is explicitly reported in the expression tree.
1 / 139
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
ArrayLengthWithParentheses
Access to the length field of an array is represented with extra parentheses.
1 / 44
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
ParameterlessWithoutParentheses
A method / constructor with no arguments is represented in the tree with its proper name but without parentheses.
12 / 266
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
InstantiationWithoutNew
Missing token 'new' in a class, interface, or array instance creation.
26 / 124
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
LiteralWithoutType
A literal is missing the type annotation.
25 / 406
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
VariableWithoutType
A simple variable access is missing the type annotation.
14 / 322
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
TypeIsParentHoleType
The type of the node is not the actual type of the node, but rather the type specified for the surrounding 'hole'.
17 / 64
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
CharacterTypeString
The type of a character literal node is String.
11 / 53
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
LiteralWithoutValue
A literal is missing the value annotation.
61 / 159
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
VariableWithoutValue
A simple variable access is missing the value annotation.
17 / 115
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
StringValueWithoutQuotes
String value reported without quotes.
9 / 328
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions:
BothBranchesOfCondExprEvaluated
Both branches of a conditional expression are annotated with values.
67 / 115
Cases
This provides evidence potentially relevant for the following Progmiscon.org misconceptions: