FHTW Berlin Fachbereich 4 Internationale Medieninformatik PROG1: Programmierung I Wintersemester 03/04

---

Laboratory 11: Calculator

B. Lab Preparation

Running the Demo(optional)

You do not need to run the week's program before coming to lab, since you surely know what a calculator does. However, a simple implementation is available when you have downloaded the calculator.jar file.

%  java calculator.RunCalc

Designing the controller(s)

Your target should be to design and build a calculator that can handle simple arithmetic on one-digit numbers. This assignment is written to guide you through a variety of stages in the development of the calculator; the project is open-ended and you will certainly leave lab with further ideas for the additional calculator functionality.

Specifically, you will implement an active object class which will interact with a Calculator object to respond to the user. The Calculator can do such things as figuring out which button the user presses,  and managing redrawing, displaying, and other various things that happen on your computer screen. However, it does not actually know how to interpret these button presses, or what answer to display.  That is your object's job.

For this lab, you will need to define an active (i.e., animate) object class that will interact with the Calculator object.  You may rely on both a Calculator and a CalculatorState, provided that you conspire to have these objects available for your class. Your object's job is to tell the Calculator exactly what to do, such as recognizing and appropriately responding to the user's button presses. You will presumably find a CalculatorState a useful helper in this task.

In lab, you will be writing a class that will interact with an instance of the Calculator object, and serve as a controller for it.  You should name your class ButtonHandler, and it should be a self-animating active object (much like the class you created for the Balancer lab).  At each point in time, your class should ask the Calculator for the next button pressed, and then, if appropriate, perform any desired computations and update the Calculator's display.  (Needless to say, it should also update its own internal state appropriately at each step.)

You will also be writing a class that has a main method, so that your program can get started. Your main class should work with your controller class (as well as with the Calculator and CalculatorState objects that you will need).

As usual, you should follow an incremental design strategy -- keeping the end goal (a working calculator) in mind, but starting with simple implementations first. Before going to lab, think about how you would implement the following:

Implementing Echo

A simple test that will help ensure that your infrastructure is working is to simply echo each button pressed back to its Calculator's screen.  (Of course, you can also use Console.println, but echoing to the calculator is so much cooler!)  You can start by echoing back the buttonIDs (which are ints) as they are handed to you, but you'll get prettier results if you use getButtonLabel method, which provides you with more informative String names for the non-numeric buttons.

Scaling Up to the Target 

Once you've gotten echoing to work, you can start to build in some logic.  At this point, you can now try to design a simple controller that relies straightforwardly on the CalculatorState object that you've been given. This is the target point of the problem set.

Implementing Reset

A useful feature to have is a reset feature -- that is, a certain button or sequence of button presses that will bring your calculator back into a known state.

Write code that will allow you to reset your calculator. 

Q.  How would you make the calculator reset (i.e., call the reset() method you have defined in your class) when then the CLEAR button is pressed, but not at any other time?

Extending CalculatorState

If you have additional time, experiment with that calculator program and see whether you can get it to behave badly. If so, write this up and turn it in with your writeup. You may also augment the existing CalculatorState behavior. The following additional features may be of interest, if you have the time. Most or all of them will require modifying, extending, or overriding the CalculatorState class.:

• Reset the calculator when the clear button is pressed.
• Make the clear button clear the display instead of resetting the calculator.
• Add the ability to handle op or = in other positions.
• Make the clear button clear the last key pressed.
• Make the clear button clear the last key pressed if pressed once, but clear the entry or reset the calculator if pressed twice.
• Add memory.  This will require a revised interface and a revised GUI class to implement, so you should only expect to actually build this if you have time to kill.  This requires external storage.

Remember, don't try to implement too a complex calculator all at once.  Break it down into pieces that you can test independently, and test them thoroughly before moving on to the next step. In each case, be sure that your logic can handle any button press at any time.  Think of examples that your code should work on, as well as examples where it might not behave as you would like.  Write these examples down and experiment with them in lab.

Drafting your code

As always, you should draft your code before coming to lab.

Your code should define a class whose instance should arrange to have access to a Calculator and to a CalculatorState. It should be a self-animating object, i.e., it should have its own AnimatorThread. At each point in time, it should gobble up a button press (by calling the Calculator object's getButton() method) and, if appropriate, update the Calculator's display.

You will also be responsible for defining some startup code that will allow your class to be instantiated.

Laboratory

What to Bring to Lab

You need to bring your finger exercises, documentation of the CalculatorState class from last week, code draft, and development plan with you to lab. You will not be checked in without them. You should also have read the entire problem set and be prepared to discuss an implementation strategy before you arrive.

Getting Started

Before you begin work on the calculator directly, you should implement and test the two classes from your finger exercises.

First, build a main class. You will need to create a .java file containing your class definition. The name of the file should match the name of the class. The class should be declared public. In JBuilder, identify this class as the Main class. Compile and run your code. Does it work as you expected? If not, debug it. Also take notes and include this in your writeup. [TURN-IN]

Next, define your animate object class. Don't forget to make your class, its (no-args) constructor, and the run method public. Each public class must be defined in its own file, and the name of the file must match the name of the class.

When you have finished this code, you can test it by modifying your main class to create an instance of your animate object class. Run your program and see what happens. Also take notes and include this in your writeup. [TURN-IN]

Compile and run your code to make sure that you've built things correctly. If you have problems, now is a good time to work them out.

Running the Calculator

We have provided you with a graphical user interface (GUI) for the calculator. Your mission is to write the logic controller (the "brains") behind this graphical interface. We've hidden the details of the GUI implementation, but have supplied you with a calculator.Calculator interface (in the java sense) that describes the GUI's functionality in all of the detail that you should need. You can create an instance of the class that implements this interface by executing code that includes the expression

(assuming that you're in package calculator or have imported calculator.*).

The Calculator GUI can do such things as figuring out which button the user presses,  and managing redrawing, displaying, and other various things that happen on your computer screen. However, it does not actually know how to interpret these button presses, or what answer to display.  That is your object's job.

For this lab, you will need to define an active (i.e., animate) object class that will interact with the Calculator object. Although it will eventually need to be modified, you can start with the animate object you've already written. (Remember: if you rename the class, you will also need to rename the file and vice versa.) If you actually literally reuse your animate object code to produce this simplest calculator, make sure that you save a copy of the animate object code to turn in with your lab.

You may want to make your new class a part of the package calculator.

Unlike the simple animate object that you built, your calculator controller will need access to a particular Calculator and to a particular CalculatorState. There are several ways that this can be arranged.

[CHECK-IN] Q. Whose job is it to create each of these objects (the Calculator, the CalculatorState, and your controller)? How do they become connected?

[CHECK-IN] Q. What changes do you need to make to your main class in order to test this new code?

[TURN-IN] Q. What happens if your main method starts two separate instances of your calculator class?

Scaling up

Once you are able to start up your calculator, try pressing some buttons. [TURN-IN] What happens?

Now modify your controller class to connect the Calculator with the CalculatorState in a sensible way. Run some experiments. [TURN-IN] What happens now? This code, together with its documentation and the documentation of CalculatorState, are the targets of this assignment.

If you still have time, you can implement some of the additional features mentioned above. The bored may translate and display the numbers using Roman Numerals instead of our usual Arabic numerals.

Remember: You should always begin your labwork with a simple, independently testable implementation and build on it as each stage works robustly.

Also remember the following  "... you will in general get a higher score for basic but elegant, well-tested, well-documented, and well-understood code than for adding features to poorly written/documented/tested code.  I am more interested in how well you do what you do than in how much you do."

Record your experiences, including tests that various stages of your implementation succeed and fail. Make sure that you understand how your code behaves, and how it will behave under inappropriate as well as appropriate circumstances.

Post-Lab, AKA What To Turn In

Your completed assignment should include:

• your pre-lab assignment.
• your documented code for CalculatorState. In addition, you should tell us about how you figured out what the code does. You may include (descriptions of) any particularly useful props or strategies.
• your original code including its documentation and a description of its functionality.
• your observations concerning
  • the code understanding process
  • the coding/debugging process,
  • the behavior and reliability of your code.
• the name of the staff member who checked off your laboratory work, a brief description of the check-off interaction, and answers to any specific issues s/he may have asked you to address.
• the names and roles of any collaborators in any parts of the project.

You should also turn in as well as the overall design writeup.

You should, as always, include information on your collaborators and their roles.