Project 2 Teams

Collaborative Sports Playbook
Brian C

Engineering Project Organizer

Collaborative Corporate Scheduler

Collaborative Planning Tool

Collaborative Landscaping Tool

Collaborative Home Remodeling Tool
Brian F


Project 1 asked you to play with collaborative Web tool architecture by enhancing an existing Java code base. Project 2 asks you to imagine a more substantial, longer-life coding effort where you spend the design effort up front. You have less than three weeks to deliver Project 2 on Sunday, March 17th at 5PM (or hand it in earlier if your team wants to be done with it).

You are to spend team time envisioning the collaborative software system you would build to meet the process objectives you have set for yourselves. Remember the questions each class asks of itself from the Java primer. Take that back a step and ask the first two questions for the whole system (and the packages as well if you are going to design your system in package size chunks):

Brainstorm on these two simple questions. Discuss which of the three example architecture approaches (Habanero, Notes, OWorld) you want to apply during design. I mean: Think through how your team (organizational) goals affect how you would design and deliver your system.

I am looking for you to include the same four core components in your system design:

But, you can bundle the GUI and the Event Model as I did in class (each GUI component handling its own events). In that case, your GUI classes should have one or more event-handling methods identified (you can identify a simple, generic method called HandleEvent() if you wish).

Consider starting with a bunch of index cards (pieces of paper, or sticky notes) where you write candidates for classes, one per piece of paper. Arrange the classes spatially so those that seem to work closely are located close to each other on a wall, table, or floor. Ask the three basic questions of each potential class:

The first question should suggest the key attributes that class is responsible for. The second should suggest key methods. The third should help you decide on your interfaces, inheritances, and containments (meaning when one class has an attribute that is another class type to access objects readily). If you have a hard time answering these questions for a potential class, consider throwing that class away and including its responsibilities in other classes instead.

Focus on the interface your intended users will use to put information into your system and view information already in your system (the forms and view model perhaps). Components of your GUI will probably extend Frame, Dialog, Panel, or Canvas (no need to use the java.swing components -- stick to the simple java.awt components). One class will probably extend Applet, Hablet, or Frame (in this case, a Java application frame with a static main() method provided). I will naturally expect system processing to begin with initializing an object based on that class.

For the networking part, imagine you already have an advanced VNet-like package available for your use. You do NOT have to show any networking classes except the class or classes that will dispatch messages to and from the network package(s). So, if we were diagramming project 1, you would only include the Dispatcher class from the VNet package.

You system processing should be orderly. The classes responsible for processing data should jump out at you just by considering a flowchart of the processing. Those steps in a flow chart that are worthy of their own diagram box are usually the ones worthy of their own class.

Now, tie the whole project together as a series of three deliverables:

I will grade your team based on the completeness of the design (answering the questions you provide in your executive summary), the job you've done of organizing the system into classes and documenting them, and the job you've done of providing me the vision (as if I had to do the actual development myself).

The System Diagram

Here is an example of a system diagram:
The diagram goes from base classes at the bottom to extended subclasses on the top. An arrow means the top class extends from the bottom one. A dotted lined box means an interface. A line with a rectangle on the end means implements with the end with the box being the class that does the implementation. The line with a solid dot at the end means the class with the dot contains (has-a) an object of the type from where the other end of the line originates.

The letter A is where you would cross-referece a list of the key attributes of that class. The letter B is where you would list key methods. If your class implements an interface, you don't need to list the methods in the implementing class, just in the interface (so you would put them where you see letter C). You can certainly list the key attributes and methods on the diagram itself (making bigger boxes and more pages), or you can develop an indexing scheme and write the components on separate pieces of paper. We'll talk more about this in class on Thursday and next Tuesday.

Remember that the goal of this project is to give you some insight as to how project teams work together to provide (needed) collaborative software tools to a target user base. You are just one of thousands of teams discussing the same types of issues around the world right now. Use this project to see if you like working in the team environment. Consider which necessary skills of the team needs are the ones you most enjoy providing. Think how that might help you decide on your life goals. Think about your teammates' behaviors. Think about emulating the ones you like and avoiding the ones you don't. Think about whether you thrive better in a project where design is all worked out ahead of time (as in most large business projects) or if you like to wing it and design as you go (as is the case in many research efforts). A practical note: the latter often pays less unless you stumble upon a wonderful patentable idea that you shrewdly bring to market.

Good Luck. I hope you find this project stimulating.