Project 2 Teams

Collaborative Sports Playbook
Rachelle
Brian C
Binh
Trong

Engineering Project Organizer
Rick
Matt
Trina

Collaborative Corporate Scheduler
Sheila
Curtis

Collaborative Planning Tool
Gildas
Jenette
Brandon

Collaborative Landscaping Tool
Dan
Russ
Justin

Collaborative Home Remodeling Tool
Brian F
Gordon
Cathy

PROJECT 2 REQUIREMENTS

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):

What information should your system (package) store and share among users?
What processing would a user expect the overall system (package) to perform or control?

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:

Are your users primarily scientific users who will be able to use any feature you make available?
Or, are you hoping to center a general-public business on this software effort and if so will you apply an 80/20 approach (focus your efforts on those features 80 percent or more of your users will use but don't build for the other features with less than 20 percent use).
Or, are you looking toward an Open Source effort where different groups will actually code or obtain the different components in your system, making those components work well together via inter-process communication.

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:

Graphical User Interface (the visuals)
System Event Model (the interaction)
Calculation Engine (the internals)
Messaging (network interface)

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:

What information should I be responsible for?
What processing does the overall system expect me to perform or control?
What information and processes should I share with others and how should others access those assets?

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:

A System Diagram (to be discussed later in this document with example).
A written Executive Summary of what your system does and what/why users will use it. There are lots of examples of executive summaries that are technology based on the Web. Take a look at how Sun describes their products by choosing the different products from the drop-down list on their Products and APIs page. Take a look at the Groove project (the lastest from Ray Ozzie's Lotus Notes team. Avoid too much rah-rah marketing hype though. Cover the technical overview more so.
A Storyboard of what the interface will look like (you can use pencil and paper to show me what the different GUI components will look like) -- call the storyboard components 'screenshots' if that makes more sense to your thought process.

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.