Informatics 45 Spring 2010, Project #1: Keep the Customer Satisfied

Introduction

Software comes in many forms and runs in many contexts. I spend a lot of my time — as I'm sure you do, also — interacting with graphical user interfaces on my personal computer. But I also interact with software in all aspects of my life. Many of my electronic devices (my cell phone, my iPod, and even my cheap alarm clock) are substantially made up of software. My car has a touch screen that lets me see maps and plot directions, change air conditioning settings, view my current mileage, and so on, along with a number of other embedded systems that control things like anti-lock braking, traction control systems, and keyless entry; software is a prominent aspect of these features, even those that don't seem to have a user interface at all. Every time I go to a web site, I'm interacting not only with my browser, but also with separate software called a web server, which is executing on another machine somewhere in the world; that software also has no user interface, but is instead tasked with responding to requests for web pages. In this course, we'll explore a variety of different kinds of software that solves different kinds of problems.

This project opens our exploration of constructing software systems by building your skills at writing Java-based graphical user interfaces. You'll find that these skills will come up again in later projects (though not in all of them), so it will pay to spend some time experimenting with them now. Additionally, you'll be asked to work through this project without having been told every detail of the Java libraries that you'll need in order to build it; a recurring theme this quarter will be cultivating your ability to discover existing components that will help you solve your problems, learning enough about them to decide whether and how they'll help, then figuring out enough of their details to integrate them into your project. (The goal is not to leave you entirely out in the cold; we'll be happy to try to point you in the right direction when you feel lost. But we do want you to build confidence and work toward self-sufficiency.)

This project also introduces you to the three-part project format that you'll be seeing throughout the quarter:

A project plan, where you will write up a document detailing how you're planning on attacking the problem posed.
A program, which is your solution to the problem posed.
A summary of lessons learned, where you will discuss what went well, what didn't, and why.

These three components of each project will never be due simultaneously; we want you to write your plan and submit it before you've proceeded very far with your implementation, then to have some time to think about and document the lessons learned after your implementation has been submitted.

Choosing a partner (optional)

Before you begin working on the project, feel free to choose a partner from among the people in your lab section. (It's fine, even preferable, to read this project write-up on your own ahead of time, though.) On the other hand, you can also feel free to work alone instead.

If you're having trouble finding a partner, notify your TA, so that you can be assisted in finding one. If you have not found a partner and notified your TA of the pairing by the end of the lab meeting on Wednesday, April 1, you will be required to work alone on this project; the goal is for partnerships to be formed before meaningful work is done. Note that paired work includes all phases of the project, including the Project Plan and Lessons Learned documents.

Be sure, too, that you've read the section entitled "Pair programming" on the front page of the Lab Manual. The way we're doing business in Informatics 45 is essentially the same as it was in prerequisite courses that use pair programming, but there may be some subtle differences, and it's worth knowing about them up front.

The problem

You have been asked to write a Java program that provides a graphical user interface (GUI) that acts as a point-of-sale system for a fast food restaurant called Señor Chubs. The goal of the program is to streamline the process that cashiers follow when taking customer orders, calculating totals and taxes, and accepting payment.

The usage scenario is expected to be this: a customer approaches the counter and orders items from the menu, the cashier inputs the order into the program, the program calculates the total and tax, the customer pays the cashier, and the program figures out the appropriate amount of change and prints a receipt. After this, the program resets the current order so that the cashier can start fresh when handling the next customer.

The program must meet the following requirements:

The program must allow a cashier to input any combination of items on the restaurant's menu to fill in a customer's order.
The program must not allow any items not on the restaurant's menu to be entered.
The program is only required to handle one order at a time.
It must be possible to remove items from a customer's order.
It must be possible to cancel the entire order currently in progress.
The program must prominently display a receipt on the screen after an order is specified and paid for — this simulates the ability to print a receipt to a special printer.
The program must be able to distinguish properly between items that are taxable and items that are not. Customers should be charged sales tax on taxable items, but not on others.
The program must always calculate totals and taxes in whole pennies. So, for example, a total can be $3.47, but never $3.475.
The program must provide a way to show the total amount collected for all orders, as well as the total amount of tax collected, since the program started running.

Señor Chubs only accepts cash payments, so it is not necessary to handle checks or credit cards (though you can offer these options, if you'd like; granted, you're unlikely to be able to offer actual credit card processing, but you can feel free to fake it, if you wish).

The restaurant's menu

All Señor Chubs locations offer the same menu, which presently contains the following items:

Item	Price	Taxable?
Cheese Enchilada	$2.59	yes
Chicken Enchilada	$3.59	yes
Beef Taco	$1.69	yes
Chicken Taco	$1.89	yes
Fish Taco	$2.39	yes
Bean and Cheese Burrito	$3.19	yes
Chicken Burrito	$5.49	yes
Steak Burrito	$6.49	yes
Carnitas Burrito	$6.79	yes
Chips and Salsa	$.99	yes
Guacamole	$2.49	no
Small Drink	$1.45	no
Large Drink	$1.95	no

Like most restaurants, Señor Chubs varies its menu from time to time; the program should handle menu changes gracefully.

Sales tax

All the Señor Chubs restaurants are in California, which charges sales tax, though the tax rate varies from one location to another and changes from time to time. (The reason it varies is that sales tax is generally a combination of a statewide tax and taxes imposed by individual counties, cities, and even smaller localities.) The program is not required to know about any of the factors that go into determining the sales tax rate for a particular location, but there must be a way to instruct the program what the proper rate is.

Many details were purposefully left unspecified

The project requirements are deliberately vague, in the sense that they describe the business problem to be solved rather than the exact details of how the program should solve it. In particular, there are no requirements about specifically what the user interface should look like; this is something that you should design in a way that you think is appropriate. I also haven't specified a precise format for how information (e.g., the menu, the sales tax rate) is made available to the program.

The amount of detail specified in real-world software development scenarios varies dramatically — from a complete lack of specification at one extreme to every detail of every part of the system specified at the other; there are tradeoffs along this spectrum, which you'll explore more thoroughly in other courses. I'm leaving this project open-ended to give you a chance to exercise some creativity, as well as to consider and comment on the effects of your decisions along the way. Remember, though, that your goal is not to build something "cool," necessarily; it is to build something that solves the business problem. There's nothing wrong with a cool program that solves the problem, but a straightforward program that addresses all of the requirements is vastly better than a cool program that ignores or misunderstands some of them.

The planning phase

Software development projects generally start with a planning phase. While the specific activities done during the planning phase vary from project to project, and while the line that divides the planning phase from subsequent phases can be a somewhat blurry one, the goals generally include most, if not all, of the following:

Understand the problem domain in enough depth to be able to implement and test the project.
Understand the requirements of the system in enough detail to be able to make design decisions about the project (e.g., what the user interface might need to look like, how the project will integrate with other software).
Explore the libraries that might be available to help provide portions of the required functionality in a form that's already implemented and tested. (It's always preferable to use something complete and battle-tested, assuming that it is a good fit in your design and solves a problem that you have.)
Build one or more prototypes of portions of your system to gain an understanding of the libraries you might use and the design approaches you might take. (This is especially important when you're delving into territory that's new to you, as you'll be doing often this quarter.)
Devise a list of the programming and testing tasks that you'll need to do, establish which ones are dependent on which others, and estimate the amount of time it might take you to complete them. (If there are many people working on the project, this is often followed by divvying up the work among them. In this course, that won't be an issue; when you're paired, you're expected to be doing "pair programming," which is about shared ownership of everything you do, not about splitting the work between you and your partner.)

Not all of these steps apply in every project. For example, you might already understand the problem domain, or you might have enough experience with the technologies you'll be using that prototypes aren't necessary. But this is a reasonable set of goals to aim for.

I encourage you to consider experimenting or prototyping parts of your program early on in the process. You might find that the code you write early on is worth keeping; you might also have learned enough from your experience to know that you should go the other way. Don't feel as though every line of code you write is something you need to keep forever, or even that every line of code you write gets you a step closer to being finished. One of the things that makes a good software designer is a willingness to make alterations to your design as you go, as well as a willingness to sometimes delete or heavily rework large chunks of code as you realize that you've been going in the wrong direction. The value of prototyping is that you'll spend less time polishing code that you may eventually throw away, focusing instead on your overall approach.

The project plan

You are encouraged to experiment with prototypes of your program early on. However, before you write, polish, and test your entire program, you will be required to write a project plan. (This will be a recurring requirement in this course; each project will begin with a brief planning phase, during which you'll be required to write a project plan.)

Your project plan is required to address the following questions. (You are also free to include any other information you'd like to include; part of the goal is to satisfy us for the purposes of grading, but a large part of the goal is for you to consider what you're planning to do before you sit down to do it.)

How will your user interface be designed? How, specifically, will cashiers use your user interface to enter orders, accept payments, cancel orders, view the day's totals, and so on? (It is not necessary to show mock-ups of your user interface, but you're welcome to do so if you'd like.)
List the tasks you expect to have to work on in order to complete the implementation. We're not expecting you to break this down at the level of individual methods or classes; we'd just like to see what the big-picture tasks are (e.g., "implement a feature that shows the receipt"). Which tasks are dependent on which others?
What do you expect will need to change about your program when the restaurant's menu changes? What do you expect will need to change about your program when the sales tax rate changes?
What aspects of the project pose the biggest risk to your success? Where do you anticipate having the most difficulty?
What aspects of the project post the least risk to your success? What parts do you expect to be able to handle with relative ease?

The project plan is due on Monday, April 5 at 11:59pm. See the section titled "Deliverables" below for more information about how to submit the various parts of your project.

Writing the program

The program should be written entirely in Java. The GUI should be built using the Swing library, which is part of the large library that ships with Java. In addition to Swing, you are free to use any part of the Java library that you would find helpful, though you are not permitted to use other components (e.g., open source components) on this project. (This restriction may well be relaxed in the future, but for now I'd like you to focus your attention on Java and Swing.) I'd strongly suggest using Eclipse as your development environment, as described on the front page of the Lab Manual.

The Informatics 45 Eclipse workspace

One of the helpful features of Eclipse is how it helps you to organize your work, on one project or many, easily. It also gives you the ability to tweak a wide variety of settings, such as the version of Java to use to compile your programs, the fonts and colors displayed in the editor, the style of the code that Eclipse generates for you, and so on. A workspace is the repository for all of the files that make up your projects and all of your settings.

A workspace is stored on your hard drive within a single folder. When you start Eclipse, you select the workspace (the folder) that you'd like to use. I suggest using a single worksapce for all of your work this quarter, as it will give you easy access to all of your previous work, as well as maintain your settings from one project to the next.

Eclipse provides a large set of options that allow you to configure it. When you don't have a lot of experience using it, though, it's hard to know which options to change and what you should change them to. Unfortunately, the default settings aren't entirely appropriate for us in this course. Additionally, personal preferences tend to differ, which can sometimes make it difficult for a pair to work together productively.

To keep things straightforward for us this quarter, we'll all use the same initial Eclipse workspace. I've created an empty workspace, with settings appropriate for your use this quarter; these settings will match the settings used by your TA when grading your work. The "official" workspace for our course is available at the link below:

Informatics 45 Eclipse workspace

The workspace is provided in zip format; to use it, unzip it to a folder in a place you'll be able to find again. If you're working in the ICS labs, one good place to put it is on your H: drive, so that it will be available to you regardless of which machine you're logged into. For example, you might put your workspace into a folder named H:\45Workspace. You might instead want to store it on a USB memory stick or other portable media, but you should be sure to keep a backup in case you lose the original.

(Note to Mac users who intend to use Eclipse on their own machines: the zip archive may appear empty, because its only contents are a folder called .metadata. Files and folders whose names begin with a "." character are hidden in Mac OS X by default. Go ahead and unzip the archive anyway.)

Limitations

Visual GUI development tools are off-limits for this project; I'd prefer that you write your own code for this GUI by hand, so that you can understand the mechanics of control creation, sizing, layout, and event handling. This is another restriction that I'm apt to relax later this quarter when the focus is placed on other things.

Due date

The program is due on Wednesday, April 14 at 11:59pm. See the section titled "Deliverables" below for more information about how to submit various parts of your project.

Assessing the lessons learned

Once you've completed your implementation and submitted it, take a little time to reflect on your experience. The goal of this course is to build a variety of skills related to constructing quality software; to that end, I'd like you to stop and think about your experience on each project, as a way of easing the path you'll follow in future projects.

After submitting your program, you'll need to write a lessons learned document, which will be another recurring requirement in this course. Your lessons learned document should reflect on, at least, the following questions. (As with the project plan, you're free to include any other information you'd like to include; not only are you doing this to satisfy us, but also as a way of solidifying your thought process and building a journal that you might refer to in a future course.)

To what extent did you follow your project plan while implementing the program? What features did you implement differently than you specified in your plan? Why did you decide to implement them differently?
What are a couple of your biggest successes on this project — features that you felt turned out well, challenges that you were able to overcome? What forces do you think helped you to be so successful in these cases?
What are a couple of aspects of this project that could have gone better? Why do you think they were problematic and what will you do differently next time to ensure that you'll handle them better?
What do you think of the Swing library so far? What do you like about it? What do you dislike about it?

The lessons learned document is due on Friday, April 16 at 11:59pm. See the section titled "Deliverables" below for more information about how to submit various parts of your project.

A word of warning about a minor bug in Java 6

Since Java 6 was released, every few times I execute Java programs in Eclipse, I see the following message in the "Console" window after the program ends:

    ERROR: JDWP Unable to get JNI 1.2 environment, jvm->GetEnv() return code = -2
    JDWP exit error AGENT_ERROR_NO_JNI_ENV(183):  [../../../src/share/back/util.c:820]

This error message didn't seem to have anything to do with my program the first time I saw it, so I searched on Google and discovered a bug report indicating that this is a bug in the Windows implementation of the virtual machine in Java 6, which is installed on the machines in the ICS labs. If you see this message while working on this or subsequent projects, you can safely ignore it.

Deliverables

You are required to deliver the three parts of the project to Checkmate, an ICS-built online assignment submission system. Follow this link for a discussion of how to submit files via Checkmate. Be aware that I'll be holding you to all of the rules specified in that document, including the one that says that you're responsible for submitting the version of the project that you want graded. We won't regrade a project simply because you submitted the wrong version accidentally.

There are three parts to this project, each with its own due date:

The project plan, which is a Microsoft Word (.doc), Rich Text Format (.rtf), or PDF document. This is due on Monday, April 5 at 11:59pm.
The program, which is a collection of .java files. Please do not submit anything other than .java files (e.g., compiled .class files, other parts of your Eclipse workspace), though you are welcome to zip the .java files — which will be necessary if you've used packages, since Checkmate is incapable of representing folder structures in student submittals. The program is due on Wednesday, April 14 at 11:59pm.
The lessons learned document, which is another Microsoft Word (.doc), Rich Text Format (.rtf), or PDF document. This is due on Friday, April 16 at 11:59pm.

For those of you working with a partner, it is only necessary for one of the two partners to submit the project; we would prefer that the same partner submit all three parts, so that they will all be identified together in Checkmate. Your TA is aware of the partnerships and will figure out which project submissions belong to which pairing. Put the names and student IDs of both partners in a comment at the top of each of your .java files and documents. Afterward, take a moment to be sure that you submitted all of the files you intended to; if you missed one, we won't be able to compile and run your program, which can result in a substantial penalty, since we won't be able to evaluate your program's correctness.