Graphics & Visualization Subgroup:
Here's my response to Pam's call for input on our subgroup's topic.
Let's break down the opportunities afforded by Java in the areas of graphics and visualization into two categories. First, there is teaching students graphics programming. Second, there is there is the use of pre-existing graphics/visualization-based applets to help students understand other kinds of algorithms, e.g, in the area of algorithms and data structures. Given this breakdown, we can then apply it first to introductory courses and then to advanced level courses, as per the original charge.
TEACHING STUDENTS GRAPHIC PROGRAMMING AT THE
INTRODUCTORY LEVEL: In this regard, we aren't really teaching graphics algorithms as much as we are using graphics as an alternative output mode to use in teaching students about introductory programming concepts such as loop control, modular design, and recursive algorithms.
We don't want students to become experts at using a sophisticated graphics library as much as we want them to become excited and enthusiastic about what they're doing - graphics can often build such enthusiasm. What's needed for this type of programming? A simple two-dimensional graphics library. For instance, for many years, I have had students use a simple turtle graphics library, not unlike LOGO, to have them produce fractals in their first recursive programming assignment - they find this a lot more interesting than something like the Fibonacci numbers.
Where does Java stand in this regard? To my knowledge it's the only language that comes with a built-in standardized graphics library. Like everything else with Java, this graphics library is platform-independent, so
we as instructors can easily trade ideas and exercises, and students can program on their own machine at home even if it is a different platform from what they use in the school's computer lab. This is all on the plus side.
On the negative side, the Java graphics library is a device-oriented library in that graphics calls are made relative to a pixel-based coordinate system with (0,0) being the upper left corner. Introductory students think better in a Cartesian coordinate system or, for some recursive work, in a turtle-based graphics system. I've actually developed a simple turtle-based Java graphics library that my students use in programming fractals. I'm not aware of Java libraries others may have written for doing two-dimensional graphics in a
Cartesian world coordinate window, although I'd be surprised if home-brewed versions of such libraries don't exist.
USING PRE-EXISTING GRAPHIC/VISUALIZATION-BASED APPLETS
TO HELP STUDENTS UNDERSTAND DIFFICULT ALGORITHMIC
CONCEPTS AT THE INTRODUCTORY LEVEL: Here students do no programming; they simply view animations and discrete visualizations produced by Java applets to help them understand a variety of algorithms, e.g., sorting, binary trees. Such algorithm animation systems are not new to computer science education, e.g., Marc Brown's MacBALSA for Macs and John Stasko's Samba for Xwindows. What Java adds to the mix is the ability to deliver such visualizations in a system-independent way over the
Web, making it more convenient for students to use such visualizations and more convenient for instructors to augment visualizations with supplementary hypertext in the form of HTML documents. A very complete on-line index of algorithm animation systems is maintained by Peter Brummund of Hope College at
http://www.cs.hope.edu/~alganim/ccaa/ccaa.html. This site also maintains an interactive facility for educators to submit their animations to the index.
Although the index is not limited to Java-based animations, a large number of the systems listed there are written in Java.
The design methodologies behind Java-based animations and visualizations vary widely. Many are not fully general systems but are rather Java applets tailored to animating one particular algorithm. As such, these applets do not necessarily provide a clear separation between the algorithm and its visualization. Other more general systems allow one to build many varied animations into the system. For example, in Tom Naps' GAIGS in Java system (http://gaigs.cmsc.lawrence.edu), input to algorithms is provided by
HTML forms. The input from these forms triggers the execution of an algorithm on the Web server. That execution produces a files of graphic primitives that reside on the server. When the algorithm is done executing, a general purpose Java applet is downloaded to the Web surfer. This applet reads the file of graphic primitives on the server and provides a viewing environment for the resulting graphic snapshots of the algorithm. Another methodology is illustrated by John Stasko's JSamba system (http://www.cc.gatech.edu/gvu/softviz/SoftViz.html). Here the algorithm to be animated resides on the Web client (it need not be written in Java). This algorithm must produce a "script file" of graphic primitives that are provided as input to Stasko's JSamba applet. The applet reads these primitives and provides a viewing environment for the resulting "movie" of the algorithm's execution. (General question for the subgroup: I'm not sure how much in depth we want to go on describing methodologies for systems that animate algorithms via Java applets? Certainly Pam could provide information on her JADE system, and I'd be able to provide significantly more detail on some of the other systems that are available IF we decide this is a direction that we want to go.)
TEACHING STUDENTS GRAPHICS AT A MORE ADVANCED LEVEL:
Here I'm not sure I see any advantage to Java. Certainly any sophisticated graphics written in Java are going to run significantly slower than the same algorithm written in a language such as C that doesn't have to compile to a virtual machine. Nonetheless I believe there is a version of OpenGL available for Java. I don't have a link for it at the moment, but it's something that could be tracked down if we deem it worth mentioning.
USING PRE-EXISTING GRAPHIC/VISUALIZATION-BASED APPLETS
TO HELP STUDENTS UNDERSTAND DIFFICULT ALGORITHMIC
CONCEPTS AT A MORE ADVANCED LEVEL: In one sense the use of such applets at an advanced level is not significantly different from their use at an introductory level. Some recent work by Stasko and Proulx indicates, however, that the real value of algorithm visualization at a more advanced level may lie in having students create their own visualizations of algorithms. Why? Students learn to identify the "interesting events" in an algorithm's execution - a skill very important to develop if a student is to develop an in-depth understanding of the algorithm. According to Stasko,
"Building an animation of an algorithm forces a student to think about the fundamental operations of the algorithm to be portrayed visually. The student must think about the data manipulated by the algorithm, the interactions occurring in the algorithm, and how the important high-level design concepts are manifested. ... The student constructs the algorithm-to-animation mapping and determines what is unique to the algorithm and what deserves to be communicated visually." In what way can Java make it easier for students to construct their own animations of an algorithm than would be possible in another language? Here I'm not sure that Java is they key as much as the abstraction afforded by object-oriented design. Using object-oriented techniques, we can provide students with powerful tools that make producing a visualization of an algorithm relatively painless. (Note:
This is a theme no doubt being pursued by all of the subgroups in our workgroup).
For example, I currently have students in my Java classes use something called a Visualizer class that I've developed for them. By sending messages to a Visualizaer object at key points in their algorithm's execution, a visualization can be produced with virtually no knowledge of graphics. The student is only responsible for identifying the interesting events in the algorithm - events where producing a graphic snapshot is important to understanding the algorithm. (Note: If you're interested in seeing the details of how this Visualizer class works, let me know and I can provide them.)
SOME CONCLUSIONS: So how have my ramblings above provided a response to what Pam asked for? I've cited one Web page at Hope College which provides a wealth of links to other sites offering algorithm animations (many coded in Java). The specifics on the Stasko reference cited above is:
Stasko, John, "Using Student-Built Algorithm Animations as Learning Aids, Proceedings of the SIGCSE Session, ACM Meetings (San Jose, CA., February, 1997).
This paper is not at all Java specific, but it does provide a nice rationale as to why students learn an algorithm better if they produce an animation of it themselves.
Finally, I think I may have provided a second way for our subgroup to break down our work. That is, we started with a perspective that said consider introductory versus advanced courses. I now maintain that this subgroup should also consider a breakdown along the lines of graphics programming
versus using visualizations and animations that already exist. That is, our
breakdown could really be structured as a two by two matrix:
Use of existing visualizations to help students understand
I'm curious to know what others in the subgroup think about this breakdown strategy.
Pam Lawhead's comments:
To expand somewhat on Tom's comments...
In Course I or as we are referring to it here Introductory Programming we want to teach a basic body of information which I have summarized below. I am sure that this list can be modified and I am open to suggestions, changes etc.
First Course content:
Elementary Data types excluding pointers
Pascal: integer,char real boolean,userdefined, sets, arrays
Java: boolean,char,byte,short, int,long,float,double,reference types
Control: interation,looping condionals
parameter passing modes
use of external libraries
software engineering concepts (encapsulation, info. hiding)
At the end of course one the student should be able to:
-devise algorithms to match problem statements
-code and debug on paper on on machines
-determine complexity from observation
-design and choose appropriate data structure and implement them
-be proficient in the chosen programming language
-read and write from a file
-be familiar with some platform and some environment
-be able to test both designs and implementations
I am sure that we can expand or contract this list. But the point is that if we choose to do visualizations in the first course then we need to examine them in light of some body of knowledge that we are trying to convey.
I think that the current generation of students in the US have been reared on "Sesame Street", "Nickelodean" and MTV so they expect more than a chalk talk and an interesting teacher. I think to teach them many of the concepts mentioned above we are called upon to "visualize" for them. Java is a good resource for doing this so as a "show me" tool it is brilliant.
As Tom has said it provides good libraries for creating, quickly and efficiently little demonstrations of desired concepts. We have done this is our JADE project. We used older students to create algorithm demonstrations for younger students. It has been most effective.
What happened in creating JADE was that the older students found that they had to understand the algorithms at a much deeper level in order to create the effective visualizations for the younger students so in a sort of backward manner the visualization creators gained new insights and understanding about how the algorithms worked by using Java to create the algorithm demonstrations.
I am not sure that I agree with Tom about using Java as a language for teaching graphics. I would argue that, like any of the object oriented languages, it is a great tool for teaching design and teaching the idea of enforcing design and interface parameters. Graphics as a discipline is better taught a lower level than is available in an object oriented language like Java. In Java you are woefully ignorant of the system and architecture that you are using and these concepts are critical to performance oriented graphics programming.
I know this is short but it is what I have.
I also have a list of sites and a list of articles included below.
AUTHOR: Martin, P.
TITLE: Java, the good, the bad and the ugly
SOURCE: SIGPLAN Notices, vol.33, no.4, p. 34-9
AUTHOR: Boroni, C.M.; Goosey, F.W.; Grinder, M.T.; Ross, R.J.
TITLE: A paradigm shift! The Internet, the Web, browsers, Java, and
| the future of computer science education
SOURCE: SIGCSE Bull. (USA), SIGCSE Bulletin, vol.30, no.1, p. 145-52
AUTHOR: Borkowski, E.Yu.; Henry, D.; Larsen, L.L.; Mateik, D.
TITLE: Supporting teaching and learning via the Web: transforming
| hard-copy linear mindsets into Web-flexible creative
SOURCE: Journal of Network and Computer Applications, vol.20, no.3,
| p. 253-65
AUTHOR: Wester, F.; Sint, M.; Kluit, P.
|TITLE: Visual programming with Java; an alternative approach to
| introductory programming
SOURCE: SIGCSE Bull. (USA), SIGCSE Bulletin, vol.29, no.3, p. 57-8
AUTHOR: Rasmus, D.W.
TITLE: Teaching Java a thing or two
SOURCE: Object Magazine, vol.7, no.6, p. 16-17
AUTHOR: Weiss, M.A.
| TITLE: Experiences teaching data structures with Java
SOURCE: SIGCSE Bull. (USA), SIGCSE Bulletin, vol.29, no.1, p. 164-8
AUTHOR: Singh, T.; Zhu, M.; Thakkar, U.; Ravaioli, U.
| TITLE: Impact of World Wide Web, Java, and virtual environments on
| education in computational science and engineering
SOURCE: Technology-Based Re-Engineering. Engineering Education.
| Proceeding of Frontiers in Education FIE'96 26th Annual
| Conference (Cat. No.96CH35946), p. 3 vol. xl+1517, 1007-10
AUTHOR: Michail, A.
TITLE: Teaching binary tree algorithms through visual programming
SOURCE: Proceedings. IEEE Symposium on Visual Languages (Cat.
| No.96TB100066), p. xi+346, 38-45