You are here

A Primer on Reuse - Techniques for Preparing an Applet for Reuse

Author(s): 
Mark Chung and Chris DiGiano

Separate text from the mathlet

In our experience we've found that teachers often want to customize the text in a mathlet. When we first started developing problems of the week for MathForum we embedded the text inside the interactive activity (for reasons related to our deployment strategy). This made it difficult for end users to modify. Our problems of the week now ship as applets embedded in a web page containing the instructional text, so it is easy to modify with an HTML editor. So the first technique is to separate the text from the mathlet so it is easy to customize. We found that the JOMA mathlets all used this technique. Separation of text is also important for internationalization, although other programming techniques are necessary to internationalize and localize UI text (e.g. the java.util.ResourceBundle class in Java 1.1).

Parameterization

Teachers may want to change the behavior of an mathlet without programming or hiring a programmer. An easy way to enable this in Java is to provide a set of applet parameters to configure your applet. The parameters -- key value pairs -- are set in the HTML tags for the applet and are made accessible to your applet through the applet API.

A good example of this is Bert Wachsmuth's Integrator applet, featured in JOMA Volume 1, Issue 1, which computes Riemann sums for a given function. All of the user-visible and user-adjustable parameters are configurable via applet parameters.  By doing View Source in the browser you can see what the APPLET tag looks like:

             <APPLET CODE="ira.integrate.Integrator.class"
                          WIDTH=420
                          HEIGHT=320>
                   <PARAM NAME="function" VALUE="sin (x)">
                   <PARAM NAME="xmin" VALUE="-3.14">
                   <PARAM NAME="xmax" VALUE "3.14">
                   <PARAM NAME="numpoints" VALUE="20">
                   <PARAM NAME="rightsum" VALUE="yes">
                   <PARAM NAME="leftsum" VALUE="no">
                   <PARAM NAME="uppersum" VALUE="no">
                   <PARAM NAME="lowersum" VALUE="yes">
                   <PARAM NAME="generalsum" VALUE="no">
                   <PARAM NAME="showinfo" VALUE="yes">
             </APPLET>                          
 

The parameters allow the applet to be configured with an arbitrary function, minimum and maximum x values, number of points to partition by, and whether to compute the various kinds of sums.

We'll examine this technique in detail in the next section.

Components

Components offer a powerful means of designing for reuse. We define a component as an independent, reusable software entity which may be assembled with other components into applications with little or no programming. Component vendors need not know in advance how their components will be used. Instead, they can use programming conventions to ensure that their components can interoperate with others. Component software is a thriving industry; there are many software vendors producing components that are not applications in their own right but useful only in combination with other components. There are also extensive efforts to catalog existing components and catalyze development of new ones. An example of this is at Flashline.com.

In Java, components are called JavaBeans ("beans" for short). A bean is a class that adheres to some simple programming conventions and provides a description of the bean's properties and other information relevant to a builder environment, such as icons. The builder uses a process called introspection to determine the bean's properties and automatically create property editors to customize the bean. After customizing and wiring the beans, the final assembly is saved in a human-readable text file. An applet could be a bean, but since an applet implies deployment in a web browser, it may sometimes be more useful to implement most of the functionality of your mathlet as a bean and use an applet as a thin wrapper around the bean. For more information on JavaBeans, see the JavaBeans trail of the Java Tutorial.

Among the developers of JOMA mathlets in Volume. 1, Issue 1, Alan Cooper successfully converted GraphExplorer to a JavaBean.

In the ESCOT project we've adopted a component approach that we call "rapid assembly componentware" [DiGiano & Roschelle, 2000]. We use the JavaBeans component model as a foundation and use a builder environment to rapidly create component assemblies. Whereas standard JavaBeans builder environments such as the JavaBeans Development Kit wire components together using semi-automated programming, we've simplified this so that one need only specify the properties to connect in both components. Our vision is that you could create sophisticated activities by dropping components into a builder environment, customizing them, and wiring them, without doing any coding or debugging. Practically speaking, however, we've found that these environments require technical expertise to use.

A bean is distributed not as source code or class file, but as a jar file, which is similar to a zip file except that it contains one or more class files and a manifest describing the contents of the jar file. This distribution strategy allows you to distribute your bean in one convenient file while protecting your source code, because you can "obfuscate" the class files, effectively hiding them from prying eyes. Jar files are created with the jar tool provided in the Java SDK, or with similar facilities in IDEs.

We will go into more detail about how to create a bean in the next article.

Packages

Another Java tip that bears on reuse is to use packages. While it may seem convenient to keep everything in the default package (i.e. no package declaration at the top of the file), this becomes a problem if you start to reuse code which also defines classes inside the default package, with the same name. You can prevent name collisions by putting your classes in their own package. The convention is to name the package in reverse order of a domain name. For example, our domain name is escot.org, so our packages are named org.escot.*.

Documentation

There are some software engineering techniques that also make designing for reuse easier in Java. For example, documentation is an important means of communicating to other developers what your class does. Java provides a technique and a tool called javadoc, which allows you to generate nicely formatted documentation from source code that has been commented using some simple conventions. The basic convention is to precede classes, methods, and method variables that you want to publicly document with /** comment here */. For example,
 

   /**
       This is an example of a javadoc comment for a class.
   */
   public class MyBean extends Panel {
       /**
           Here  is documentation for the constructor.
       */
       Public MyBean() {
       }
   }

Simple, isn't it? Because the documentation is generated from the source code, it is easy to keep it in sync with the source code. The Java API documentation was produced this way, and if your documentation looks similar, it will be much easier to navigate. See the Javadoc Home Page for more information. (Note that the output of the Java 1.3 javadoc tool is better than the Java 1.1 javadoc tool. Even though you may be writing to Java 1.1, you may want to use the Java 1.3 javadoc tool). Explanatory documentation external to the API documentation is always helpful as well; see Alexander Bogomolny's JOMA article for an example of external documentation.

Testing

Another technique important for reuse is automated testing. How do you guarantee that your software works as advertised? Often with component software it is necessary to make modifications to components based on end user or developer feedback. Automated testing can ensure that the component doesn't break unexpectedly because of changes, and if you have a sufficient test suite, can make you confident that making changes to the source won't break anything. JUnit is a popular, free, and easy to use framework for automated testing in Java. Since it's automated, you don't need to configure tests or check the results of each test; JUnit will report if any tests failed and allow you to get information on the failures. Happily, JUnit was designed with the philosophy that it should be simple, otherwise programmers won't bother writing tests.

Mark Chung and Chris DiGiano, "A Primer on Reuse - Techniques for Preparing an Applet for Reuse," Convergence (December 2004)