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. The Bacterium objects satisfy the IUpdatable interface (notice how the pieces "fit" together). The Bacterium objects in turn use the IBehavior interface (which you need to write). Both the TurnBehavior and NullBehavior objects satisfy the IBehavior interface (notice how these pieces also "fit" together).

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. This class will be strictly an Application for this lab. This lab will not work as an Applet. However, like Lab 6, Lab 7 will be a standalone program and not use DrJava to run.

Bacterium

You also need to define a class which models a bacterium in your system. This class must implement the lab7lib.IUpdatable interface. It must also extend one of the lab7lib's shapes (ellipse, square, or hexagon). The Bacterium should be composed of a behavior and have the ability for its behavior to be changed. That is, you'll need a mutator for the behavior. The Bacterium also should partially override it's superclass' update method.

Event handlers

There are several event handling classes you need to define to make all the components of the simulation work together.

• 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 (there is a method for this defined on the Window class), and then create the appropriate event handler to 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 Bacterium

The bacteria must react when they are clicked upon with the mouse to take on the (composite) behavior currently selected in the menu. You simply need to add a MouseListener to the bacteria to accomplish this.

Behavior classes

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. First, you must define the general interface that all the behaviors implement. You can name your interface whatever you'd like, but it must extend the lab7lib.IBehavior interface. You will define several behavior objects that implement the interface you created. 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.

• breathe

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

• move randomly

This gene (behavior) causes the bacterium to move randomly (direction and distance) each time it is to update on the screen.

 

• 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 interface for a behavior that you write. Below is a UML that gives information about the general 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).

Working from home

If you are working from home ensure you have the most current copy of the Classlibs.jar file (available from the resources page).

What you hand in

When you are finished, you need to export your solution from the Eclipse environment so that you can submit it. You need to follow the same steps as you did for disconnecting from the repository in Lab 2 . If you are not sure how to do this, please refer back to those instructions. This time, you should name your Jar file Lab7.jar. Your JAR should include your Java Source Code files and a UML diagram representing your solution to the problem named Lab7.grn.

Then you can submit the Lab7.jar file using the electronic submission program. If you do not remember how to use the the submission program, refer back to earlier labs.

Not so secret tip - we spent time in Lab 6 focusing on what our code looked like and you will be awarded/deducted points based on that as well as your code's functionality. You can safely assume that the same will apply to Lab 7 and all future labs for that matter.

Due dates

The due dates are summarized in the table below. You are always welcome to submit early. If you submit more than once, the later submission will simply overwrite the previous one.

To check that your lab was submitted, you can always refer back to the Submit Inspector on the Resources page of the website. After you have entered your user name, your submissions will be shown. Clicking on the name of a file that is a zip file will show you the contents of the zip file so you can verify that you indeed zipped up all the correct files.

If you submit during the week of March 24th, your raw lab score will be scaled up to potentially earn a maximum of 120%.

If you submit during the week of March 31st, your lab will be graded as normal, out of 100%.

If you submit during the week of April 7th, your raw lab score will be scaled down to earn out of a potential 80%. The absolute last day to submit Lab 7 to earn any credit is Thursday, April 10th. No late labs are accepted or will be graded.