CISC474 Group Activity A08 (Spring 2006)
This is a follow on to A06 and A07
What is included in A08
Building a full Model-View-Controller webapp that can take the following input:
- input from up to four individuals about their busy (or free) times, and
- some "global constraint" on when the business day starts and ends
and produce the following output:
- a list of free times when those individuals can meet
The model classes should be the ones that you developed as part of A06 and A07.
Deliverables
- A WAR file that contains everything needed to run your webapp—someone downloading this WAR file should be able to just drop it into a Tomcat "webapps" directory, stop and restart Tomcat, and have the webapp be "up and running" on that Tomcat server.
- A tar or zip file that contains
- all the code needed to produce the WAR file, organized as a "development directory".
- a build.xml file (and accompanying global.properties file(s)) that can make the WAR file. A user should be able to download your tar or zip file, expand it, and with at most changes to your global.properties file, build your WAR file by just typing "ant create-war", or "ant war", or whatever.
- JavaDoc documentation
- A general description of the project
- Documentation of each team members role
- A web page, linked to from your group's web page with the link A08, that allows users to download
- download the WAR file (deliverable 1)
- download the tar or zip file (deliverable 2)
- browse JavaDoc documentation for your model and controller classes (deliverable 3)
- read a general description of your approach to the project (more on this below) (deliverable 4)
- read about the roles each team member played in the production of the final product. (deliverable 5).
Additional requirements
Your build.xml file should
- contain a "clean" rule (e.g. "ant clean") that removes everything that can be made from other things (e.g. the WAR file, the class files, the JavaDoc)
- contain a reference to a global.properties file where you define the actual locations of things
- contain a rule to build the WAR file
- contain a rule to build the JavaDoc
- contain a rule to run Unit tests on at least your Model classes. (Running Unit tests on a controller class is something we'll explore in future weeks when we talk about HTTPUnit.)
More information about WAR files can be found at topics/java/deployment/warFiles including an example:
- beerV1.tar contains an example of the BeerV1 app from HFSJ, organized with a build.xml file that uses global.properties, and creates a WAR file.
To the extent possible, your XHTML pages should validate, and have a link on them to the validator web site. This is not possible with some JSP output, so do the best you can—even there, do your best to produce valid XHTML.
More detail on the "general description"
This does not have to be elaborate or long. It should be at least a few sentences that explain your overall approach to the project, focusing on what makes your version different from that of the other groups, e.g.
- the basic data structure you used to represent a schedule
- (e.g. was it an array of each time period marked "busy/free", or a list of time intervals?)
- did you use a time object, an int representing military time, or an int representing minutes since midnight, or some other representation?
- any changes you made to the suggested user input (e.g. did you have users input busy times, or free times?)
- any restrictions you put on the input (e.g. only "whole hours", or can you specify down to the minute level?)
Think of it this way:
- If someone were going to read your code and try to understand it—and perhaps evaluate it for a grade, or to decide whether to use your code as the basis for a more complex project—what are the things it would be really helpful for them to know before they start looking at the code?
- What would you tell them if you only had to explain your approach in just 5-10 sentences?
You can include diagrams if it helps (e.g. make pictures and save as .gif, .jpg., or .png).
More detail on documenting team member's roles (repeated unchanged from A07)
- Each team member should be primarily responsible for at least one of the source files, a fact reflected in the comments at the top of the source file (for build.xml, use XML comments: <!-- this is a comment --> )
- The responsible team member should be able to explain that file's operation to the instructor, the TA, or a reviewer from another Team, and be able to explain its role in the entire project
- Your entire team should have a web page indicating the contributions of each team member to A07. For each team member list
- names of all source files for which that team member had primary responsibility (at least one per person) (make them hyperlinks to the source file itself)
- any other roles that team member filled (e.g. presenter, documentation on the web site, organizing and running the group meetings, investigating how to do Ant, investigating how to do JUnit, investigating how to do Javadoc, etc.)
