Project 2 Teams
Collaborative Sports Playbook|
Engineering Project Organizer
Collaborative Corporate Scheduler
Collaborative Planning Tool|
Collaborative Landscaping Tool
Collaborative Home Remodeling Tool
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):
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:
- 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?
Think through how your team (organizational) goals affect how you would design and deliver your system.
- 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
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).
- Graphical User Interface (the visuals)
- System Event Model (the interaction)
- Calculation Engine (the internals)
- Messaging (network interface)
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.
- 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?
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).
- 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.
The 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.
Here is an example of a system diagram:
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.