SOFTWARE DESIGN AND IMPLEMENTATION
IN THE INTRODUCTORY CS COURSE:
JAVASCRIPT AND VIRTUAL PESTS

 

 

 

Jeffrey L. Popyack, Ali Shokoufandeh, Paul Zoski
Dept. of Mathematics and Computer Science
Drexel University
Philadelphia, PA 19104-2875

(215) 895-1846, (215) 895-2671, (215) 895-2673

{JPopyack, AShokouf, PZoski}@MCS.Drexel.edu

 

 

ABSTRACT 

Our introductory computer science course is a breadth-oriented exposure to the computing field offered to students majoring in computer science and mathematics, who have widely disparate prior computing and programming experience. It is not a programming course per se, although programming concepts and techniques play a significant role throughout. A challenge faced by the instructor is to give 'universal assignments' that cover core material, are sufficiently interesting to engage advanced students, yet may also be completed by students with weaker backgrounds. We present a project sequence designed for this purpose based on the concept of the handheld "virtual pet". Students designed and implemented web pages using HTML forms for the user interface and JavaScript functions for the behavior that resulted in their own "virtual pests". These assignments stressed the importance of design before coding.
 

I. INTRODUCTION

A. CS0: Introduction to Computer Science

Our introductory course for computer science and mathematics majors, "Introduction to Computer Science", is designed to give students a broad exposure to the computing field. Course content includes many of the core areas of computer science identified in the 1988 report of the Joint Task Force of the ACM and IEEE-CS [7], laboratory experiences with various computing tools, and items of historical and social significance. Included also is a representative amount of programming, intended both to underscore the importance of programming in the field and to acquaint novice programmers with the fundamentals of computer programming. A traditional CS1-2 sequence of programming courses is taken subsequently. Similar courses are offered for students majoring in information systems [1]. There is strong overlap in the audiences for this class and our University Seminar course that is offered concurrently and includes some discipline-specific material.

We have found it beneficial to introduce programming concepts using simple languages embedded in widely used software (such as word processors, spreadsheets, or databases) rather than with a general-purpose language such as C++. Previously we have discussed this approach for non-majors and computer science majors with little or no programming experience [2,3,4,5,6]. This approach allows beginning students to produce nontrivial results quickly without the encumbrance of the "programming overhead" needed to build useful standalone programs. Because of the focus on breadth, the shortness of the term, and the diversity of prior computing knowledge of our incoming students, deeper programming material is deferred to later courses.

In a typical 10-week term, the topics covered will include an overview of databases, computer networks, scientific computation, program translation, artificial intelligence, computer architecture, digital circuits, human-computer interaction, computer graphics, and software engineering, while examining and reinforcing persistent programming concepts (variables, declarations, expressions, conditionals, loops, etc.) as they pertain to the area of study.

In recent offerings, the programming component of the course has been done with HTML and JavaScript [1]. The chief advantages of JavaScript for this course are: 

The most recent syllabus is shown in Appendix A. See [9,10] for online access to course materials.

 

B. Student Audience

Our student audience represents a broad spectrum of abilities and prior experiences in computing. Whereas students with extensive programming and computing experience are drawn naturally to the major, so also are students with very little experience who are interested in learning about computers and computing. While students are allowed to take placement exams to determine the proper programming course to begin with, we have chosen to require all our freshmen to take the introduction to computer science course.

Because of the disparity in student audience, we find it worthwhile to include extensive extra credit options on most assignments. Hence, the most useful assignments are accessible and extensible, reflecting themes from the core of computer science and concepts of computer programming.

 

II. THE PROJECT

 We describe below a project sequence that has been conducted in two separate offerings of the course. In the first offering, the project was split into two parts assigned during the seventh and eighth weeks of our term. In the subsequent year, the project was split into three parts and spread over an extra week. Students had been introduced to basic HTML during the third week and JavaScript was introduced during the fifth week of the term. JavaScript exercises and lab assignments at this point had involved variables, arithmetic expressions, and output only. Except where noted, our discussion is based on the most recent course offering.

A. Purpose

 This exercise suite had several purposes:

The project was inspired by the advent of "virtual pets" (e.g., see [8]). A virtual pet may be described as a miniature electronic device with a graphical display that can imitate some of the characteristics of a real pet, including expressions of happiness, anger, etc., need for food and other types of nurturing, and fluctuations in emotional and physical health due to attention or neglect. A pet's state is influenced by the care it receives, possibly in a non-deterministic way.

For this project, students were required to design and implement "virtual pests" as web pages using HTML forms with JavaScript functions specifying the pests' behavior. The project was divided into three parts, with the first two parts focused on design and the third part on implementation. By insisting that code not be included in the first part (and in fact, by waiting until completion of the first part before lecturing on essential code elements needed for the implementation), the students were obliged to design first, code later.

We have found that despite the best efforts of textbooks and instructors to insist that students design their programs before implementing them, beginning programmers almost invariably commence coding with only a vague idea of the overall structure and form their programs will attain or need in order to complete their assignment. Anecdotal evidence suggests that when students are required to include design documents with their final projects, the design documents are often completed last. We wanted to ensure this did not happen, and for this reason introduced the assignment before lecturing on HTML forms and JavaScript conditionals.

 

B. Project Design

 Project design consisted of three distinct components:

For the first part of the assignment, students were required to specify their pest's behavior with a finite-state machine and a table describing potential actions performed by the pest and its owner. At a minimum, a pest was required to have at least five states and the user interface was required to have at least two text boxes and two buttons the owner could click to influence the pest’s state. Section D contains an example virtual pest showing such design documents shared with the class for illustrative purposes. Note that the sample given does not satisfy these specifications, so that students were not able to fulfill the requirements by simply transcribing the example to another domain.

In the second part of the assignment, students were to implement their user interfaces as web pages with HTML forms and design their JavaScript programs. The program design contained the names of all functions needed, including verbal descriptions (not "JavaScript code") for each of the functions, describing what the function does, what form elements it operates on, and under what conditions.

In order to reduce the total amount of coding time needed for this project (especially for novices), fairly explicit directions were given regarding this phase of the design. Students were told to include a "startup" function that is invoked when the page is loaded and which sets the initial state, a "display" function that updates values of form elements as appropriate according to the state, a function that investigates the current state periodically (cycling by using JavaScript’s "setTimeout()" function) and makes state transitions as specified in the original design. For each button defined, a corresponding function also was prescribed to investigate the state and make state transitions as described in the design. Each time the state is changed, the program calls the "display" function to update form elements as needed.

 

C. Project Implementation

After completing the design phase, each student had a (hopefully unique) specification for their project, which was to be converted to a completed product. Using JavaScript function templates, students followed a generally straightforward process of linking functions to buttons, retrieving values from text boxes, processing these values, and updating the display as appropriate. Students were required to submit disk copies of their virtual pests, and include a written description of any differences between their original design and final implementation. JavaScript code for the example pest was provided and is shown in Appendix B.

 

D. Example Virtual Pest Design

Consider a very simple "virtual dog" that is perpetually in one of four states: happy, angry, provoked, or lonely. A virtual dog that is lonely remains lonely until its owner pats it, which makes it happy. (Here, we say the dog has changed states from lonely to happy.) A virtual dog that is happy remains happy 90% of the time, but may also become angry 10% of the time. (This means that the dog's state is evaluated periodically (say, every 30 seconds) and 10% of the time, the state will be changed. Note that in this case, the dog's state is unaffected by the owner's hand, and its mood - i.e., its state - changes randomly.) An angry dog stays angry until the owner pats it, which causes it to become provoked. A provoked dog remains in its provoked state 80% of the time, but may become lonely the other 20% of the time (because nobody goes near it).

 

Finite-State Machine. The diagram below describes this simple behavior as a finite-state machine. The system (i.e., the dog) in this case has four states, signified by the circles labeled with the state's name. The system is always in exactly one of these states. The system may make a transition from one state to another as specified by the lines connecting them. The arrows signify which states are reachable from the current state. For example, there are arrows connecting the happy state to itself or to the angry state, which means a happy dog can either remain happy or become angry. A happy dog cannot directly become lonely, but a lonely dog can become happy.

The virtual pets available commercially generally have very many states and there are many ways in which their owners can interact with them. They also sometimes have terminal states, that is, states from which the pet cannot exit. Typically, the pet is said to have died if this happens. Nodes that have no lines pointing outward from them typify such states.

 

Behavior Table. Specifying the pest’s behavior requires more than simply delineating its state transitions. How does the pest communicate its state to the owner? (For instance, when it is angry, it may growl. When it is happy, it may wag its tail.) It is also necessary to specify how the owner's actions affect its state. A table of the following form was required to describe the pest's behavior:

Element

Type

Possible values

Meaning

Action

PetSound

text box

Grrr...
Woof woof 

 state=angry

 state=lonely

OwnerHand

button

pat the dog

changes state to "provoked" if angry,
and to "happy" if lonely.

PetAction

text box

Bite
Wag Tail

state=provoked
state=happy

...

...

...

...

...

 An HTML form corresponding to this table is shown below: 

 

Program Design. The following functions were prescribed for the implementation of this virtual pest:

 

III. RESULTS

This assignment appealed to students' creativity, and they responded well. As a minimum, the design required only two text boxes and two buttons, yet most students submitted more elaborate designs. While some students' submissions were predictably similar to the example given, other submissions included farm and sea animals, parrots, dragons and alien creatures, minor deities, family members, instructors (!), and television characters. Most contained graphics of some sort. Some contained graphics that changed with the pest's state and some included sounds. See [10] for a "gallery" of collected student work.

Completed projects were generally consistent with the original designs. Typical reasons given for deviations were design inconsistencies that became apparent during implementation, desire to enhance the original design, and inability to understand the programming. Some students continued adding "bells and whistles" to their projects even after they had been handed in.

Some problems were encountered in describing behaviors in a way that could be implemented. Some students had difficulty during the design phase differentiating between a state, its meaning, and its display value. A common implementation problem was understanding the way values were passed between text boxes and functions. The JavaScript debugging tools provided by then-current web browsers were also primitive, which led to some confusion.

The first time this project was assigned, no discussion of finite-state machines was included and students were not required to submit a diagram clearly defining state transitions. This material was added in the next offering, and the project was much better defined as a result.

 

IV. CONCLUSIONS

As a 'universal assignment', this project did have elements that appealed to our broad spectrum of students. The major lesson learned was that thoughtful design allowed students (some with only modest programming experience) to create relatively sophisticated projects for a course of this nature. Whereas pest behaviors were generally no more intricate than simple if/else statements to implement, the whole was decidedly greater than the sum of the parts. It is certainly possible to experience in a meaningful way the software design process in an introduction to computer science course.

 

REFERENCES

[1] Mercuri, R., Herrmann, N., Popyack, J. "Using HTML and JavaScript in Introductory Programming Courses." SIGCSE Bulletin 28, 1 (March 1998), 176-180.

[2] N Herrmann and JL Popyack. "A Software-Based Approach to Scientific and Statistical Computing for Science, Social Science, and Engineering Freshmen," Computers Across the Curriculum: A Conference on Technology in the Freshman Year, City University of New York, NY, May 1992.

[3] JL Popyack and N Herrmann. "Mail Merge as a First Programming Language," SIGCSE Bulletin 25, 1 (March 1993), 136-140.

[4] N Herrmann and JL Popyack. "An Integrated, Software-Based Approach to Teaching Introductory Computer Programming." SIGCSE Bulletin 26, 1 (March 1994), 92-96.

[5] Herrmann N and JL Popyack. "Creating an Authentic Learning Experience in Introductory Programming Courses." SIGCSE Bulletin: The Papers of the Twenty-Sixth SIGCSE Technical Symposium on Computer Science Education, 27(1), 199-203, 1995.

[6] Popyack JL and N Herrmann. "Why Everyone Should Know How to Program a Computer." Proceedings of WCCE '95, Sixth IFIP World Conference on Computers in Education, Birmingham, UK, July, 1995, 603-611.

[7] Denning, Comer, Gries, Mulder, Tucker, Turner, and Young, "Computing As a Discipline: Final Report of the ACM Task Force on The Core of Computer Science", Aug. 1988.

[8] Giga Pet by Tiger Electronics, Inc. (http://www.gigapets.com/gigaworld/index.html).

[9] Drexel University CS390 Fall 1999 website (http://www.mcs.drexel.edu/~introcs/F99/index.html).

[10] Virtual Pest Gallery (http://www.mcs.drexel.edu/~jpopyack/VirtualPests/index.html).

 

 

APPENDIX A - RECENT SYLLABUS

CS 390 Fall 1999 Syllabus

Wk

Month

Mon

Tues

Wed

Thurs

Fri

Topics

Reading

1

September

20

21

22

23

24

Course Overview. Student Survey and Section Placement.
Lab: meet with departmental advisors

AE: Mod 1

2

September/ October

27

28

29

30

1

Core areas of computer science. Computing devices and programmable devices.

AE: Mod 2,3

3

4

5

6

7

8

Local and global applications. Programmable aspects of software applications. Databases. Programming Language concepts. Intro to HTML.

AE: Mod 4.1-4.4

4

11

12

13

14

15

University Holiday (Columbus Day) Mon. Oct. 11
More on programming in HTML. Computers and Codes: ASCII, Binary/Hex.

AE: Mod 4.5-4.6

5

18

19

20

21

22

JavaScript overview. Computers and Codes: ASCII, Binary/Hexadecimal. Program translation.

AE: Mod 5.1 AE: Mod 6
JG: Chap 1

6

25

26

27

28

29

Arithmetic operations in JavaScript. Computer Hardware.
Scientific Computing and roundoff error.

AE: Mod 7
JG: Chap 2

7

November

1

2

3

4

5

Selection and Iteration in JavaScript.
Public-Key Cryptography

JG: Chap 6

8

8

9

10

11

12

Functions in JavaScript. Artificial Intelligence.

AE: Mod 9
JG: Chap 5

9

15

16

17

18

19

Objects in JavaScript.

JG: Chap 3

10

22

23

24

25

26

Computer Graphics
Thanksgiving Holiday, Nov. 24-26

11

November/ December

29

30

1

2

3

Course Wrap-up. Prelude to Programming in C++

12

6

7

8

9

10

FINAL EXAM WEEK

All readings are from The Analytical Engine by Decker and Hirshfield (AE) and JavaScript Goodies by Burns (JG)

 

APPENDIX B - EXAMPLE JavaScript CODE:

<HTML>

<!--
  This page presents a prototype Virtual Pest according to the 
  requirements specified in assignments "Virtual Pest I/II/III",
  CS 390:61-70, Fall 1999.  It is purposely minimal, behaving
  according to the example used in those assignment descriptions.

  The functions in the SCRIPT section are generally adaptable 
  to pests designed according to the criteria given in Parts
  I and II of the assignment.

  JL Popyack
-->

<HEAD>
    <TITLE>Simulation of a Virtual Pest</TITLE>

    <SCRIPT Language="JavaScript">
    <!-- hide from uneducated browsers

    function Init(form) {
    // This function is called when the page is 
    // loaded initially.  
    // It does the following:
    //   Initializes the value of the form's "state" element, 
    //   Calls ShowState in order to initialize the display
    //   Sets the simulation in motion by preparing a call
    //     to Simulate after 1000 msec (= 1 second).

          form.state.value = "happy"
          form.counter.value = 0  // counts the number of times 
                                  // Simulate is called.
          ShowState(form)
          setTimeout("Simulate(document.forms[0])",1000)
      return ""
    }

    function ShowState(form) {
    // This function updates the form in order to 
    // make visible the effects of the pest's state.
    // No changes are made to the pest's state by
    // this function

    // The pest's state is retrieved from the "state"
    // element of the form
       var state = form.state.value

    // The value of the state is examined and form
    // elements are updated as appropriate.
      if( state == "happy" )
           form.petaction.value = "Wag Tail"
      else if( state == "provoked" )
          form.petaction.value = "BITE!!!"
      else if( state == "angry" )
          form.petsound.value = "Grrr..."
      else if( state == "lonely" )
          form.petsound.value = "Woof woof"
      else
          form.petaction.value = "Error - unknown state"
      return ""
    }
    
    function Pat(form) {
    // This function is called when the "Pat Dog" 
    // button is clicked.  This button only has an
    // effect if the pest is in the "angry" or "lonely"
    // state.  Otherwise, nothing is changed.

    // The pest's state is retrieved from the "state"
    // element of the form
      var state = form.state.value

    // The pest's state is changed as appropriate:
      if( state == "angry" )
          form.state.value = "provoked"
      else if( state == "lonely" )
          form.state.value = "happy"

    // The display is updated to reflect the pest's state
          ShowState(form)

      return ""
    }
    
    function Simulate(form) {
    // This function is the heart of a simulation
    // of state transitions reflected in a finite-state
    // machine.

      form.counter.value++  // updates the Simulate counter.
      
    // The pest's state is retrieved from the "state"
    // element of the form
      var state = form.state.value

    // A random number in the interval (0,1) is generated.
      var n = Math.random()

    // The state changes according to the following rules:

    // If the current state is "provoked", the pest has a 20%
    // chance of becoming "lonely" and an 80% chance of remaining
    // "provoked".
    // If the current state is "happy", the pest has a 10%
    // chance of becoming "angry" and a 90% chance of remaining
    // "happy".

      if( state == "provoked" && n < 0.2 )
          form.state.value = "lonely"
      else if( state == "happy" && n < 0.1 )
          form.state.value = "angry"

    // The display is updated to reflect the pest's state
          ShowState(form)

     // The Simulate function is set to run again after a delay
        setTimeout("Simulate(document.forms[0])",1000)

      return ""
    }
  // end hiding from uneducated browsers  -->
  </SCRIPT>

</HEAD>

<BODY BGCOLOR="#FFFFFF" onload="Init(document.forms[0])">
<H1>Virtual Pest "Startup Kit"<HR></H1>
<P>
This page presents a "skeleton page" for a "minimal virtual pest" for
use in CS 390:61-70, Fall 1999, assignments 
<A HREF="../VPest1/index.html">Virtual Pest I</A>, 
<A HREF="../VPest2/index.html">Virtual Pest II</A>, 
<A HREF="index.html">Virtual Pest III</A>.

<P>Included in the page source are functions that:

<UL>
<LI>initialize the pest's state,</LI>
<LI>display indicators of the
pest's state in the text boxes,</LI>
<LI>react to button clicks as appropriate,
<LI>update the pest's state according to the finite state machine and
behavior table shown at the bottom.</LI>
</UL>
You may use these functions as guides to programming your own 
virtual pest.

<HR>

<CENTER>
<H2 ALIGN=center>
<FONT COLOR="#339966">Tralfaz, the Wonder Dog</FONT>
<BR>
<IMG SRC="dog.gif" WIDTH=137 HEIGHT=125 ALIGN=middle>
</H2>
</CENTER>
 
Tralfaz behaves according to the finite-state machine
and behavior table shown at the end of this document.  
There are four possible states.  
The state is updated once per second.
<P>
Click the button to pat Tralfaz when state is either "lonely" or "angry".
When "happy" or "provoked", the state changes randomly; clicking
the button will have no effect in these states.

<FORM>
   <B>Sound</B>: <INPUT NAME="petsound" SIZE="50">
   <P>
   <B>Action</B>: <INPUT NAME="petaction" SIZE="50">
   <P>The pest's state:  <I>Normally, this item is hidden</I>
<!--
  This item normally will not be displayed on the page, but for
  purposes of program development and debugging, it is visible.  To
  hide it, change the TYPE attribute to "hidden".
-->
   <INPUT TYPE="text" NAME="state">

<!--
  This item normally will not be displayed on the page, but for
  purposes of program development and debugging, it is included.  To
  hide it, change the TYPE attribute to "hidden".
-->
  Step counter: <INPUT TYPE="text" NAME="counter">

   <P>
   <INPUT TYPE="button" VALUE="Pat Dog" onClick="Pat(this.form)">
</FORM>

</BODY>
</HTML>