For this assignment, you are to develop a Java application that implements a calculator with a graphical user interface (GUI), similar to that developed by your instructor, which is avaiable to you here in the form of a .jar file.
After downloading the .jar file, you can use jGrasp's JAR/ZIP Extractor (the last item in the Project menu) to extract the files from it. Then you can open the lone source code file, CalcRun.java, and run it. (It simply invokes the main() method of the CalculatorGUIApp class, and is included only because there seems to be no way, in jGrasp, of running an application without having its source code.)
You are encouraged to play with this program a lot, as yours will be expected to behave in a very similar manner. Notice, for example, that, if you enter a key that doesn't make sense (e.g., an operator at a time when a digit is expected), an appropriate error message is displayed.
At a minimum, your calculator should support integer arithmetic, including the four basic operations (addition, subtraction, multiplication, and division). If you wish, you can make it support real numbers (having digits following a decimal point). You can also add unary operations such as square root or reciprocal. If you are really ambitious, you can even support a memory function (allowing the user to "store" a value and then to call it up later), such as is available in Microsoft Calculator (which you can probably find on your machine, if you are running MS Windows). Another option is a Backspace key to allow a user to "undo" input characters.
After downloading the files listed above and compiling the KeyPadLockGUIApp class, you should be able to run that application to see how it works. (Note that to give the KeyPadLock a secret code of your choosing, you must provide it via a command line argument.)
It is recommended that your solution be similar to that embodied in the KeyPadLock-related code. (You aren't required to have a CalculatorSpec interface, however.) Specifically, notice that a KeyPadLockGUI object embodies GUI-related logic governing what a keypad lock looks like on the screen, the positioning of its buttons, etc. These functions/responsibilities are referred to as the view. It also embodies, within its ActionListener objects, the logic used for manipulating a KeyPadLock object (e.g., invoking its enterDigit(), open(), and close() methods when appropriate). These functions/responsibilities are referred to as the controller.
On the other hand, a KeyPadLock object (which has all of the methods listed in the KeyPadLockSpec interface) embodies all of the logic governing how a keypad lock works (i.e., how its state changes as a result of a digit being entered or a request being made to open or close it). These functions/responsibilities are referred to as the model.
It is good practice to assign the view, model, and controller responsibilities to separate classes. Here, at least we have separated the model from the other two.
In a similar fashion, you should probably develop a class CalculatorGUI governing how a calculator is presented on the screen (i.e., the view) and how user interaction with that view should effect the calculator (i.e., the controller), and a separate class Calculator that governs how a calculator works (i.e., the model).
In the case of the Keypad lock, most of the interaction/communication goes from the view/controller to the model, in the form of calls (in KeyPadLockGUI) to enterDigit(), etc., in KeyPadLock. Information going the other way around is limited to the model (KeyPadLock) telling the view (KeyPadLockGUI) whether or not it is open (via a call to isOpen() from latter to former).
In the case of the calculator, you may find the need for the model (Calculator) to provide much more information to the view (CalculatorGUI). Such items would probably include the value(s) of the current operands (if any), of the current operator (if any), and of the current error message (if any). Hence, you may want to include methods in Calculator to provide these pieces of information.