Document 6499857

An Integrated
Program Development Tool for Teaching and
Learning How to Program
Uta Ziegler
Department of Computer Science
Western Kentucky University
Bowling Green, KY 42101
(502) 7452911
Thad Crews
Department of Computer Science
Western Kentucky University
Bowling Green, KY 42101
(502) 74!54643
uta.zieglerO wku.edu
[email protected]
design am not supported in commercial IDES. Whereas
professionaldevelopersuse powerful CASE tools to support
the software life cycle, novice programmets receive no
support from their development environment Thirdly, the
debugging features of IDES am aimed at experienced
pmgrammem,overwhelming studentswho arejust beginning
to get an understandingfor programexecutionand debugging.
Abstract
Teaching and learning how to program requires
environmentsdesignedto support theseactivities rather than
available
development
commercially
integrated
environments. This paper presents an instructional
enviromnent which embracesthe entire process of design
algorithm development, testing and debugging while
rhhhing
the syntactic details with which students must
cope. Students using this environment develop a view of
programming in which design and testing are integral parts
of program development.
This paper proposesan instructional program development
enviromnent for use in a CSl course. The instru&onal
environmentpresentedhere consistsof an integratedsoflwate
environment that supports the entire process of design
implementation,testing and debugging.Furthermore,students
receive timely and helpful feedback on their work to
nxaximk learning. All along, the environment minim&es
syntacticdetails and is languageindependent.
Keywords
Introduction to programming, instructional environment,
integratedprogram developmenttool
The next section summarizesresearchefforts relevant to the
work presentedin this paper. This is followed by a detailed
description of the instructional program environment under
developmentat WesternKentucky University and how it can
beusedinaCS1 course.
1 Introduction
Instructing students in program development requires an
environment tailored to the needs of teaching and learning
how to program. Such an environment is different from
commercially available production environment, such as
BORLAND or CODEWAKKTOR, which are designed for
matureusersdevelopinglarge programs.
Using commercially available integmted development
enhnments (IDES) has several disadvantagesfor students
new to programmmg.First, only the complex syntax of a fullblown programming language is supported. Students often
struggle with the syntax rules and come to the wrong
conclusion that program development is primarily writing
correct program statements.Secondly, problem solving and
~~,,,,,~s,on
persona,
,o
make
cop,es
a,e no, made
tage
an,, tha, c,,ples
70
copy
otherwtse,
,ed,s,,,b”,e
to
SIGCSE’99
0
,999
d,g,tal
r,, ~,as~rrmm
,,SIS,
3/99
ACM
or hard
use
copes
IS granted
of all or part
without
fee
of this
provided
o, d,str!buted
for proflt
Or COmmerCia’
bea, th,s “otlce
and the tUtI CltatlOn
to republish.
requres
New
10 Post
prior
Orleans.
1.58113.085.6/99/0003...$5.00
SP’XlflC
LA.
USA
on
Ser’~erS
PermlSSlon
work
advanOn the flrs1
01 tp
and/or
for
tha’
a fee
page
2 Environments for leaching
Programming
lnstrudonal environments for CSl courses are an area of
active research. Two efforts, which sharesomesimilarity to
our work, are described below. Other works deal with
providing feedbackto students,mostly using visualization and
animation [l, 7].
2.1 lconic Programming
BACCII/BACCII++ [2, 31 addresses the problem of
mhimizhg syntactic detail. Calloni and Bagert developedan
“iconic programmi& enviromnent. All program constructs
(including variables) are represented through icons. The
studentselectsan icon with the mousefrom the tool palette
and drops it at the appropriateplace in the coding window.
After the student has built a program, BACCII can generate
syntactically correct source code for the program in one of
276
languages. The student must compile
the source code and execute and test it elsewhere to get
feedback on the program’s correctness.
Students using BACCll performed significantly better on
progmmming assignments, closed lab assignments, as well as
exams compared to a control group that only used VAX
PASCAL [2]. Students using the iconic interface to construct
programs and to generate C+t code for assignments had a
higher comprehension of C++ syntax than the control group
and mote uniform learning took place among the students
using the iconic interface [3].
2.2 Pseudo Programming
Shackelford and colleagues at Georgia Tech address the
problem of teaching program design [4, 10, 11]. They teach
program development in a two-course sequence. During the
first course, students use a pseudo language to develop their
algorithms. A high-level programming language is not
introduced until the second course. The focus of the first
course is on abstraction and the use of data structures and - to
a lesser degree - the evaluation of the chosen algorithmic
design. The pseudo language cannot be executed. Therefore,
the students spend most of their time in program design and
algorithm development (since there is nothing else to do).
However, students also do not get immediate feedback on
their work, which limits their testing and debugging
opportunities. Feedback is provided thmugh weekly one-onone meetings with paid, undergraduate TAs.
3.1 Program Design in FLINT
Program design answers the question “what must he done?”
at increasing levels of detail. In FLINT, students use the
process of step-wise refinement to construct a program design
that is recorded in a top-down structure chart [6]. During this
phase, students organize their approach to the problem and
develop a plan for solving the problem. Often, the design
phase must be revisited once problems have been uncovered
during algorithm development or testing. FLINT supports
such revisions and records all student design activities. These
designs give the teacher valuable insight into a student’s
design habits and abilities. ‘Ibis information may also be
useful to students for reflective analysis after the project is
complete.
Figure 1 shows an example design. The first line in each box
indicates the type of work that must be accomplished, such as
getting information or calculating some values. The bold
printed line is the name of the step. The algorithm that is later
developed for this step is stored with that name (so it must be
unique). The remaining text in each box is added by the
student to describe what must be done. FLINT does not
analyze this text, but stores the entire design to be later
reviewed by the teacher and/or the student.
3 FLINT - An Integrated Program Dsvslopment Tool
Each of these steps is discussed in more detail in the
following sections.
Figure 1: An example top-down design. The student wants to
add another box to continue the refinement of the step
“Calculate pay for the week”
271
Many teachers stress design, but too often their advice is not
heeded. Too many students first get the program to run and
then “abstract” the design from the algorithm. This is not
possible in FLINT. The design must be specified before any
algorithm construction can begin. An algorithm can be
constructed for each box by double clicking on it. Once the
student starts constructed the first algorithm for a problem,
the design is stored in the system for later evaluation by the
teacher.
FLINT ensures that the algorithms developed by a student for
a problem are consistent with the design. For example, for the
design in Figure 1, FLINT rejects any algorithm for the top
most box that does not include at least one reference each to
Get_work_info, Calc_pay, and Print-y. Furthermote, it
rejects any algorithm that includes a reference to a step that is
not a direct successor of the top most box. Thus the student is
forced to implement the design and if changes are necessary
they must begin with changes in the design
3.2 Algorithm Dewebpment in FLINT
Algorithm development answers the question “How can the
program accomplish what must be done?” Each of the steps
that have been developed during the design phase must now
be complemented with a description of how that step is
implemented.
FLINT uses structured flowcharts to represent algorithms.
Studies have shown that flowcharts are easier to understand
and faster to evaluate than pseudo code for experienced
A recent study of introductory
programmers [8].
programming students examined students’ comprehension,
confidence and speed when using flowcharts versus QBASIC
code. Students in the flowchart group performed significantly
better with respect to the correctness of their work, the time
they needed to complete the work and the confidence they had
in the correctness of their work [5]. The study also indicated
that the benefits of flowcharts increased with the complexity
of the algorithms.
FLINT supports structured algorithms by allowing only
complete program constructs to be added deleted, moved or
copied (see Figure 2). Thus, the constructed flowchart will
always be - and syntactically valid. FLlNT only
supports the basic program structures of sequence, selection
and repetition [6]. GOTOs and EXIT statements are not
supported. Therefore, every logical part of an algorithm has
only one entry and one exit, facilitating understanding,
modifications and &bugging.
Figure 2: Only complete program constructs can be added.
The student added a conditional statement and a loop
statement. The conditions to be tested are specified in
separate dialogs. The true and false branches, as well as the
joining of the branches are added by FLINT. The student
cannot directly manipulate the connections among flowchart
symbols.
colors for easy recognition. only the important information
for each statement is displayed on screen at all times. The
other information (for example, the prompt for an input
statement) is available by double clicking on the element on
the screen. Figure 4 shows an algorithm for one of the steps in
Figure 1.
While developing the design and constructing the algorithms,
students must declare what variables they want to use. For
each variable, they must specify a name and provide a short
description. During the construction of the algorithm,
students can only select variables that have already been
“declared” in this way (see Figure 3). Providing an
explanation for each variable forces students again to clarify
their plan and prevents them from using two different variable
The point-and-click interface of the flowchart builder is easy
to use and intuitive. Thus the teacher needs to spend very little
class time on how to use the flowchart builder. The flowcharts
are displayed using the conventional shapes and various
Figure 3: Variable declarations in FLINT.
278
names for the same item (for example Pay and Wage) or one
name for two different items.
The algorithm development allows teachers to show students
how to construct algorithms incrementally. For example, an
algorithm can be developed (and tested and debugged) which
only implements the bare minimum. After that is
accomplished, bells and whistles can be added as desired.
3.3 Testing and Debugging in FLINT
Testing attempts to answer the question “Are the design and
the algorithms correct?" Students can execute the algorithms
they developed with FLINT to get immediate feedback on
their work. When using FLINT, students experience testing
and debugging not as an add-on, but as an integral part of
program development. In particular, black box testing
techniques [9] are supported. When determining a program’s
correctness, students need to clarify for themselves what
output to expect for a given input. With FLINT, a teacher can
specify how many test runs students need to perform with the
program. FLINT prompts a student for the input and the
expected output for each test run. It stores that information
for later use by the teacher. When performing each test run,
the student must specify whether the output is as expected.
If a test reveals an error, the student must find the source of
the error. For this, the student needs more control over the
trace, such as executing each statement under student control
or setting lmakpints. FLINT offers these possibilities.
When tracing a program, each statement is highlighted before
it is executed as are the variables involved. After the
statement is executed the changed variables remain
highlighted for a short time. Then the next statement to be
executed is highlighted and so on. Thus the sequential nature
of program execution becomes literally visible to students.
The speed of the trace can be adjusted for maximum
comprehension and the trace can be aborted at any time.
Teachers can use FLINT’s program tracing to demonstrate
how programs are executed and to show how new
programming constructs operate. Students can watch
execution traces to develop a thorough understanding of
program execution as the sequential execution of program
steps.
Once the location of an error has been identified, the student
must use his/her knowledge of the design and the algorithms
to correct the error. This can involve slight or major changes
to the algorithms and/or the design.
279
4 Use of FLINT in Classroom and Assignments
FLINT can be used for in-class demonstration of program
execution and tracing. However, its primary strength is
support within a lab environment. During closed labs,
studentscan perform short tasks individually on a computer,
investigating a design or algorithm provided by the instmctor
or another student. When used for out-ofGlass assignments,
FLINT supports studentsthroughout the entire development
processwith valuable assessmentdataautomatically collected
for the instructor.
FLINT is currently designedto be used for roughly the first
half of the semesterin a CSl course. During this time,
students are introduced to the topics of design
implementation (including sequentialstatements conditional
statements,loops and subroutines),testing and debugging.No
high level languageis discusseduntil studentshave designed,
implementedand evaluatedprogramsof significant size. This
“concepts first” approach allows students to develop an
appreciation for the entire sotbvare development process.
Only then a high level languageis introduced,with the focus
on the syntaxnecessaryto implementthe flowcharts.
5 conclusifxls
FLINT is an instructional program developmentenvironment
for use in a CSl course. FLINT provides au integratedview
of program development by supporting design, algorithm
developmentand testing and debugging.In FLINT, program
developmentalways startswith a design phaseand students’
testing and debuggingskills grow along with their algorithm
constmction skills. Whether a teacher focuses on new
programming constructs,design skills or testing procedures,
all activities are supported by FLINT’s over-spanning
framework and understoodas such by the students. When
usingFLINTastudentwilllearn--startingwiththevery~
program -- that programdevelopmentbeginswith a plan how
to solve the problem and ends after the program passed
sutlicient tests(and not simply after it “runs”). Since students
actively design and develop their programs in FLINT, they
will be able to test them efhzctively and to debug them
efficiently if needed.
The instructional environment described in this paper can
change the way students perceive program development. It
will benefit any student taking an introduction to
progmmming courseby focusing on design and development
rather than syntax. Moreover, it is expectedthat FLJNT will
lay a solid foundation for students continuing with
pro-g
classes.
6 References
0. Astrachan, S. H. Rodger (1998). Animation,
Visuulizatio~ and Interaction in CSI Assignments,
in the pmceedhgs of the 29th SIGCSE Technical
Symposiumon ComputerScienceEducation p 317321.
[2] B. A. Calloni, D. J. Bagert(1994). Iconic Programming in
BACCII Vs Textual Programming: which is a Better
Learning Environment? in the proceedings of the
25th SIGCSE Technical Symposium on Computer
ScienceEducation,p 188-192
[3] B. A. Calloni, D. J. I&@ (1997). Iconic Programming
Proves Effective for Teaching the First Year
Programming Sequence,in the proceedingsof the
28th SIGCSE Technical Symposium on Computer
ScienceEducation,p 262-266.
[4] M. J. Canup,R L. Shackelford(1998). Using software to
SolveProblemsin Large Computing Courses,in tie
proceed&s of the 29th SIGCSE Technical
Symposiumon ComputerScienceEducation,p 135139.
[S] T. R Crews,U. Ziegler (1998). TheFlowchart Interpreter
for Introductory Programming Courses, in the
I’meed@ of FlE ‘98 Conference,p 307-312.
[6] J. K. Hughes, J. I. Michtom (1977). A Structured
Approach to Programming,PrenticeHall.
[7] R. S. Sangwan,J. R. Korsh, P. S. LaFollette (1998). A
Systemfor Program Visualization in the Classroom,
SIGCSEBulletin Vol30, No 1, p 272-276.
[8] D. Scalan (1989). Structured Flowcharts Outperjkm
Pseudocode:An Experimental Compariso@IEEE
Soflware,Vo16, No 5, p 28-36.
[9] S. R Schach (1999). Classical and Object-Oriented
Sojiware Engineering, 4’ Edition, McGraw-Hill.
[lo] R L. Shackelford(1998). Zntroductionto Computingand
Algorithms, Addison-Wesley.
[ 1l] R. L. Shackelford, R. Blanc (1997). Introducing
Computer Science Ftou&unen.tais Before
Programming, in the -8s
of FJE ‘97 Science
Education,p 188-192.
280
[l]