CSE115 Fall 2007 - Lab #7

Scenario

You are working in a genetic engineering lab, and you are working with bacteria to see if you can "teach" old bacteria new tricks, by modifying their genetic content. Note that the author of this lab knows next to nothing about DNA and genetics, so take what is said here with a little bit of humor and big pinch of salt :-)

To make sure you don't unleash some deadly strain on humanity, you are trying out your genetic modifications in a simulated Petri dish first. This simulated Petri dish allows you to add one or more bacteria. Modifications involve swapping bits of genetic code which change the behavior of a bacterium. To enable you to see the effect of your genetic tinkering, the passage of time is simulated by each baterium being asked to "update" itself at set intervals of real time.

Framework

The framework we provide can be visualized as follows:

The framework contains, among other objects, a timer, an object which generates an event at regular intervals. We have defined it to generate an event every 50 milliseconds (though the lab7lib.Window incorporates a slider which lets you dynamically change that as the simulation is running). Whenever the timer "fires", that event is handled by notifying all the IUpdatable objects the framework is keeping track of, by calling their update method.

In the visualization of the framework shown in the above diagram, interfaces are colored a "sea green" color, and class instances are shown in a "light orange" color. Notice that the framework itself uses the IUpdatable interface (this is just as it was in lab 6). The Bacterium objects satisfy the IUpdatable interface (notice how the pieces "fit" together). The Bacterium objects in turn use the IBehavior interface. Both the TurnBehavior and NullBehavior objects satisfy the IBehavior interface (notice how these pieces also "fit" together).

The framework is essentially the same as what you worked with in lab 6, though certain aspects of it have been updated to support additional functionality we wanted for lab 7.

What you have to do

Now let's describe what you have to do. The follow sections describe functionality which you must add to the system by defining classes which work with the framework.

PetriDish

You need to define a class for the Petri dish. The role of this class is to create all the main components of your system.

Bacterium

You also need to define a class which models a bacterium in your system. This class must implement the lab7lib.IUPdatable interface. Its role and structure is similar to that of the various classes you defined in lab 6.

Event handlers

There are several event handling classes you need to define to make all the components of the simulation work together. You may have learned about some simple event handling in lecture, or you may not. In either case, your lab TA will review the basic idea behind event handling, and explain what you need to do to write an event handler, in the general case. In fact, part of what you did when defining the classes for lab 6 (and also for the bacterium class in this lab) was to make those classes event handlers for the event of the timer "firing". The interface which mediates that particular interaction is called IUpdatable. Writing event handlers for the following tasks is essentially equivalent.

• Event handler for "Create bacterium with selected behaviors" button

You need to be able to add new bacteria to the Petri dish. The bacteria need to be created with their current behavior being the (composite) behavior currently selected in the menu. To do this you need to add a javax.swing.JButton to the window, and you need to attach an event handler (a class implementing the ActionListener interface) to create the bacterium, set its behavior properly, and add the bacterium to the Petri dish.

• Event handler for "Behaviors" menu

You need to be able to select and deselect behaviors from the menu. The menu must be able to provide the currently selected (composite) behavior, so that it can be applied to a given bacterium. To do this you must start by defining a class which implements the IBehaviorMenuSelector interface.

• Event handler for BacteriumBacterium's graphic

The bacteria must react when they are clicked to take on the (composite) behavior currently selected in the menu. You can add an ActionListener to a bacteriumbacterium's graphic.

Behavior classes (a.k.a. genes)

To modify a bacterium's overall behavior you need to splice together different genes in a strand of DNA. You can either add a gene with enables a particular behavior, or add a "null" gene, which does nothing. In order to be able to do this, the behaviors are modelled as separate objects. Each of the classes you need to define must implement lab7lib.IBehavior. Here are the behaviors you must define:

• change color

This gene (behavior) changes the color of the bacterium to a randomly selected color.

• turn

This gene (behavior) causes the bacterium to rotate a little.

• breathe

This gene (behavior) causes the bacterium to appear to breathe, swelling and shrinking according to a sine wave.

• null

This gene (behavior) does nothing. Use this to disable a particular behavior in a strand of DNA.

• composite

The composite behavior is basically a pair of behaviors. We can use a pair of behaviors to group together several behaviors as one (composite) behavior. Think of a composite behavior as a strand of DNA, consisting of several genes.

Design Patterns

Design patterns are particular arrangements of classes which lead to flexible, robust and extensible software. You can read our short descriptions of what the patterns do, and for the purposes of this lab that should do. But if you're a bit curious, you can find out more by reading a good general description of patterns, one of which can be found online here. In particular, look at the following pattern descriptions:

• Strategy
• Composite
• Null Object

Strategy

The purpose of the strategy pattern is to allow the behavior of an object to change according to the "strategy" chosen. A strategy is an "objectified" method, i.e. a method which is wrapped up in an object. In the strategy pattern an interface specifies what method (or methods) each strategy implementation must provide. There can be many implementations of a given strategy pattern interface. In this lab the behavior classes are strategies, which implement the lab7lib.IBehavior pattern.

Null Object

The purpose of the null object pattern is to model something which does nothing. This may sound odd, but it is an incredibly useful idea. A null object is instantiated from a class which implements a given interface by "stubbing out" all its methods. To "stub out" a method means to define a method with an empty body (in the case of a void method) or to define a non-void method to simply return null.

Composite

The purpose of the composite pattern is to allow two objects of the same type as the composite to be treated as one (composite) object. The composite implements the same interface as the objects it holds, and defines its methods to call the corresponding methods on its two composed objects. The swarm and flock in lab 5 were close to being composites (except that the Swarm and Bee classes did not implement a common interface, nor did the Flock and Bird classes).

Class diagram

Finally, here is a class diagram which shows the part of the lab design where these three patterns come into play. The whole diagram shows an application of the strategy pattern: the Bacterium knows an IBehavior, which is implemented in many different concrete ways. The NullBehavior class is an example of a null object pattern. Finally, the CompositeBehavior class and IBehavior interface form the composite pattern (though the other implementors of IBehavior are the things that will be composed within the composite).

Working from home

If you are working from home ensure you have the most current copy of the Classlibs.jar file.

Due dates