Your class project is the delivery of an executable software system that makes use of at least four patterns.  You must choose from a minimum of one architectural pattern that we cover, and three design patterns.  For your design patterns, you must choose at least one from the design patterns we cover in class.  The remaining patterns can be selected either from those covered in class, or from any published design pattern in either Gamma, et. al. or Buschmann, et. al.

You should produce a project proposal for review by me by 11:00 pm, May 22nd, 2013.  The project proposal will specify a particular business or scientific problem that you are solving, and will list the patterns involved in your proposed solution to the problem, with a brief discussion of how these patterns participate in an intelligent solution to the original problem.  Allowing me to review your project concept will give you the goahead for proceeding.  You should come up with a legitimate problem concept that will benefit from your selection of patterns.  That is to say, your pattern selection should all fit together to solve some legitimate business need.  In short, come up with an interesting problem, and solve it using the available patterns.

Some example project ideas:

One might select the Blackboard pattern as the architectural pattern, and then write a GUI interface using the Model-View-Controller pattern, and then integrate that with the State and Visitor patterns.  The controlling business idea here might be a simple stock analysis program.

Or, one might select the Broker as the architectural pattern, and then write a simple gui (or none at all), and integrate in to the system implementations of the Visitor, Composite and Iterator patterns.  The controlling business idea here might be any application that deals with dynamic structures (composites) of things.

Or, one might choose the Layers architectural pattern, and produce a simple system built on a layered architecture that also incorporates Singletons, Visitors, and the Bridge pattern.  The controlling business idea here might be any application that deals with a need for dynamic versions of things.

GRADING:

You can "extend" or "reuse" the patterns (and thus your code) used in a hw/lab assignment in your final project, but the reused parts CANNOT be the primary focus of the project; instead, they can only be a starting point for developing something completely new, or a small tool in the overall project. The reused work should be an order of magnitude less significant than the final project itself.  If you choose to reuse hw/lab work, you give us the license to take off a substantial amount of points if we feel the final project wasn't different enough from the previously-submitted work.

In short, you can "reuse" any pattern(s) that you've used in a given lab, including some pieces of the code, but you can't just "extend" a given lab...for example, you could reuse the structure of the broker from the broker lab but it has to be extended into the domain of online trading, or something like that...that is, it had better do something more than add two numbers and calculate the length of a string....

Also, we need a detailed proposal of about 400 - 600 words (note that these general comments in this email are at the lower end of that range) detailing the following (those who have already been approved do not need to resubmit):

1.  The General Topic
2.  The Problem to be Solved
3.  The Architectural Pattern to be leveraged.  HOW and WHY?
4.  The Design Patterns to be leveraged.  HOW and WHY?
5.  A Summary of the anticipated deliverable:  About how many classes in the system?  About how many source files?

A final project deliverable that is complex enough to make the graders happy should be somewhere between 500 lines of code or more (for succinct languages such as Ruby, Python) up to a thousand lines of lines of code or more for verbose languages such as C++.  Java, C# would be somewhere in the middle.   Your mileage may vary.

A final note.  The focus of the grading of the final project will be on (a) the depth of the problem engaged (b) the quality of your pattern implementations in your coded solution to that problem more than on the sheer number of lines of code submitted.  The above is more of a guideline.  No one will be counting your lines of code.  This guideline is for YOU to use as a yardstick to conclude that a submission of 110 lines of Java that has an "AddEmUp" function at its core is probably not going to make anyone happy, most of all yourself.