P06 CISC474 07S-Model,View,JavaDoc,SVN

Due Date Extended one week to April 18th (to make room for H07)

New: Please see Updates/Clarifications about
Tomcat, Javadoc and Download deployment
under steps 6 and 7 (highlighted below)

Due date extended to April 20th to allow for this adjustment.

Next steps towards a working "Common Free Time" webapp

In this project, you'll take several next steps towards a working "common free time" webapp (see the description of this app in P03 and P05). You may have already started on some of these steps.

• Creating a wiki page for your groups work on the Common Free Time webapp.
• Establishing an SVN repository for your groups work on the Common Free Time webapp
• Fleshing out the Model (along with JUnit tests) and the View for your web app.

Part today in class, rest over the next 12 days

Here's what you need to do today in class (there is more detail below)

• Read through this assignment thoroughly and completely. Ask questions about parts you don't understand.
• Establish your group's wiki page at the appropriate link below
• Divide up roles among your three or four team members, and document this on the wiki page.

What you'll do over the next 12 days

• Establish an SVN repository
• Complete the first attempt at the view
  • HTML to represent the form where the user will provide input
  • static HTML to represent sample output (you'll convert this into a working JSP in P07).
• Complete the Model, together with JUnit classes that test the model thoroughly.
• Create a Javadoc/Download site for your team.
• Establish one of the group members Tomcat installations (on porsche) as the primary deployment environment for your group.

Detailed Instructions for What You Need To Do Today

Step 1: Divide up Roles

The list of roles appears below.

The first roles to assign: Team Leader, and Wiki Editor

Assign these roles first, since the Team Leader will organize the discussion, and Wiki Editor will document who has what role on the wiki (look ahead to Step 2)

About dividing up the roles

• Note that since there are more than four roles, some team members may have more than one role.
• Roles should be shared equitably.
• That doesn't necessarily mean "equally", as in "an equal number of roles"—some roles may be more time consuming than others.

The list of roles

• Team Leader
  • responsible for making sure everything comes together, and that final submission is made on WebCT
• Primary Wiki Editor
  • everyone can and should contribute to the wiki as appropriate, but this person takes primary responsibility for making sure the Wiki is up to date and well organized.
• SVN Repository Administrator
  • sets up repository and passwords, distributes passwords, troubleshoots access problems
• Lead Java Developer and JUnit tester (Model)
  • Primary responsibility for designing and testing the Model
  • Primary responsibility for the build.xml file tasks for compiling and for running JUnit
  • The lead developer should be the primary author of at least one class in the model.
• Associate Java Developer and JUnit tester (Model)
  • Works with the lead developer on the Java code
  • You are required to have at least two folks working on the Java code, so this is a required role
  • You may have more than one person in this role—ideally, everyone has some hand in writing Java code—but you must have at least one Lead developer and one Associate developer.
  • The associate developer should by the primary author of at least one class in the Model.
• Lead Web Designer (View)
  • Primary responsibility for the User Interface
  • Primary responsibility for HTML/CSS/JavaScript files
  • You may have also an associate Web Designer if you like—that is optional
• Javadoc/Download site administrator
  • Sets up the ACLs so that all team members can update the site
  • Sets up the tasks in the build.xml file for updating the Javadoc, and entries in the global.properties file to point to the correct directory
  • Sets up the tasks in the build.xml file for building the src distribution, and entries in the global.properties file to point to the correct directory.
  • is NOT responsible for writing the Javadoc—that responsibility falls on the Java coders as they write code not as a separate step "after the fact".
• Tomcat Administrator
  • The Tomcat Administrator establishes the main deployment environment for your group's web app.
  • Sets up the build.xml and global properties files with an "ant deploy" task that deploys the web app
  • For now, that consists only of copying over the static HTML files for the view.

Step 2: Document Roles on the Wiki

The wiki editor should indicate who is doing which role.

It may be helpful to copy the wiki markup for the team members names directly from the page CISC474_07S_NumberedTeams and just fill in an extra column in that table for the roles.

What you need to do over the next 12 days

Note that some of the steps below can and should be done in parallel

I've numbered the steps "sequentially" only to make it easier to refer to them.

One of the most important jobs of the team leader is to make sure that the most important work is getting done so that the team completes its work on time. That includes figuring out which steps can be done in parallel, as well as any dependencies between or among the different steps.

Step 3: Establish an SVN Repository (SVN Administrator)

The SVN Administrator for your group should follow the instructions at the wiki page SVN_Repository_Setup to set up a repository for your group.

Add accounts for all team members, plus accounts for Oana (account name "tudor") and Professor Conrad (account name "pconrad").

Send each team member (along with Professor Conrad and Oana) his/her password via email. Use the subject line: CISC474 P06 SVN Password

Use passwords that are arbitrary strings of letters and numbers, e.g. 7vh62esy4

Create a directory structure in the repository that represents your development environment (similar to the example in Ch3 of HFSJ). Before you set up this directory structure, look ahead at Step 5 to be sure you have the correct package name for the directory for the model class.

Be sure that each team member understands how to check code out of the repository into their own working directory (sometimes called a "sandbox"), and how to then check code into the repository.

• Choice Point Opportunity: As and when you find helpful information about working with SVN, make edits to the wiki page SVN_Repository_Setup

Step 4: First attempt at the User Interface
(Lead Web Designer, and Associate Web Designer(s))

The Lead Web Designer, along with the Associate Web Designer (if any) and the Team Leader comprise the User Interface Team.

Complete the first attempt at the view by writing:

• HTML to represent the form where the user will provide input
• static HTML to represent sample output (you'll convert this into a working JSP in P07).

Link your form's submit button to the static HTML that represents the sample output. Note on the sample output that it is in fact, only sample output.

Include a CSS stylesheet (internal or external) to make the user interface look more attractive (see Chapter 3 in Sebesta), and some JavaScript (internal or external) to do client-side validation of user input (see Chapters 4,5,6 in your Sebesta textbook).

Be sure that all files validate with DOCTYPE HTML 4.0.1 (strict), XHTML 1.0 (strict), or XHTML 1.1.

Check both HTML files (along with any .css and/or .js files) into the SVN repository under the web directory.

Step 5: First attempt at the Model (Lead and Associate Java Developers and JUnit Testers)

The Lead Java Developer and the Associate Java Developer(s) should work together to complete the Model, together with JUnit classes that test the model thoroughly. Together with the Team Leader, these folks comprise the Java Development Team.

The model should be sufficient to take input—in some form that comes from the Web form your User Interface Team (see Step 4) is developing—and produce a Java object (e.g. an ArrayList object) that could be converted by code in a JSP into the output that your User Interface Team has developed.

Be sure to work with the User Interface Team closely to be sure that your model matches what they have in mind.

• An important role of the Team Leader is to be sure that the Java Development Team and the User Interface Team are on the same page, so to speak. Some informal documentation on the wiki of major design decisions can be helpful here.

Having said that, as the Java Development Team you also need to be sure that your Model is not dependent in any way on being part of a web app. It may be helpful, in fact, to develop a command line version of the User Interface and hook it up to your model, to illustrate that it works.

You should develop the JUnit classes along with the Model, not after the fact.

Follow the test-driven development approach. Write stubs and JUnit tests before you write the code that implements the methods—watch the tests fail—then write the code and watch the tests pass.

You do not have to turn in tests that fail for this project (that was just an exercise for P05)

Follow the Java Standards indicated on the wiki page General Submission Standards, including but not limited to:

• Creating a build.xml file with appropriate tasks for compiling, testing, creating JavaDoc, and deploying the Javadoc, and creating a tar.gz or zip file of your source.
• Using an appropriate package name, i.e. edu.udel.cisc474_07S_Tnn.CommonFreeTime.model, where Tnn is your Team number, e.g. T01, T02, ... T10.
• Javadoc comments, header comments and internal comments.

Check the build.xml file and the Java code into the repository early and often.

Step 6: Create a Javadoc/Download site for your team (Javadoc/Download site administrator )

Under the ACAD web pages of the Javadoc/Download site administrator (under http://www.ecl.udel.edu/~yourAcadAccount/cisc474, which corresponds to the /usb/username/public_html/cisc474 directory ), create a Javadoc/Download site for your team.

This is a place where your team will store its Javadoc, and also a place from which folks can download a source code distribution of your groups work (as a gzipped tar file, or a zip file).

Setup ACLs so that all team members can update the Javadocs and/or the tarball from the build.xml file.

Update/Clarification (04/13/2007):

We have found that there are some bugs with ACL support on porsche.cis.udel.edu. So, instead of setting the ACLs so that all team members can update the Javadocs and/or tarball directly, instead it will be the responsibility of the team member who is the Javadoc/Download site administrator to copy the Javadocs and the tarball or zip file into his/her personal web space.

For testing purposes, other team members can establish alternate Javadoc or download deployment targets in their own personal web space, by having an alternative properties file (e.g. instead of global.properties, freds.properties, or sheilas.properties.

That is to say:

• the build.xml and global properties files should be set up to deploy javadocs and the source distribution tarball or zip file to the group's main javadoc/download site (under the Javadoc/download Administrator's web space), however only the Javadoc/download Administrator for the team will have write access there.
• other team members should deploy to Javadoc/download directories under their own personal web space for testing purposes
• all team members should check in code changes to the SVN repository periodically
• at major milestones, and at the completion of the project (to be ready for grading) the Javadoc/download Administrator should update his/her development directory, and deploy to group's main Javadoc/download site (the one under his/her personal web space, and the one that is linked to from the main Wiki page for the project.)

See the wiki page AccessControlLists for more information on ACLs. Be sure that you are looking at the portion of the page about ZFS ACLs (you have to scroll down a bit), not UFS.

Note that you may also decide to provide public "read" access to your SVN repository. However, you are still required to have a download site for a source distribution.

Make sure there is a link to this page from the Wiki page for your group, i.e. from one of these pages:

Step 7: Establish a primary deployment environment for your group (Tomcat Administrator)

The Tomcat Administrator for your group should establish one of the group members Tomcat installations (on porsche) as the primary deployment environment for your group.

Create a directory CFT_Tnn (where Tnn is your Team number, T01, T02, etc.) under your ~/tomcat/webapps directory.

Create a deployment environment here, and add code into the build.xml and global.properties files so that typing ant deploy copies the static HTML files developed by your User Interface Team from the web subdirectory into the root directory of your deployment environment (i.e. ~/tomcat/webapps/CFT_Tnn).

Update/Clarification (04/13/2007):

Previously I may have indicated in lecture that you should use ACLs to make that deployment directory writable by all team members. Because of the bugs with ACL support on Porsche, instead, we'll handle this in a similar fashion to the way we handle the Javadoc and Download directories. That is to say:

• the build.xml and global properties files should be set up to deploy a war file to the group's main Tomcat site (CFT_Tnn under the Tomcat Administrator's tomcat instance), however only the Tomcat Administrator for the team will have write access there.
• other team members should deploy to their own personal Tomcat instance for testing purposes
• all team members should check in code changes to the SVN repository periodically
• at major milestones, and at the completion of the project (to be ready for grading) the Tomcat Administrator should update his/her development directory, and deploy a WAR file to group's main Tomcat site.

That is all you need to do for this project—you do not need to worry about deploying the model classes yet. We'll do that by way of a WAR file in either P07 or P08.

Step 8: Make sure it all comes together (Team Leader, and entire team)

Every team member should look over the section "Your deliverables for P06" and the Grading rubric, and make sure he/she has done her/his part.

Look at everything and make sure it is a coherent whole. This is primarily the team leader's job, but everyone on the team should take responsibility for supporting the team leader in this task.

Your deliverables for P06 (due April 18 20 , by 11:55pm).

The team leader of your group should submit, on WebCT, a gzipped tar file or a zip file containing a directory called P06 that contains your deployment environment. This file should be created automatically by an Ant task. (We'll go over how to do this in lecture on 04/04 or 04/06.)

The team leader and primary wiki editor should verify that the wiki page has:

• the list of roles
• links to the Javadoc page and download page
• links to the Tomcat instance where the view is deployed

The team leader should also double check that

• The source distribution available on the download page matches the tarball or zip file that you submitted.

The team leader (along with the entire team) should also verify that if/when you download the tarball and adjust any global.properties values as appropriate, that there are tasks in the Ant file that successfully

• compile the code
• running JUnit tests (that pass)
• create the Javadoc
• deploy the Javadoc
• create a tarball or zip file (source distribution)
• deploy the source distribution to the download page
• deploy the "view" to the running tomcat

Finally, the team leader, User Interface Team and Tomcat Administrator should verify that when you go to that Tomcat instance and click the submit button (or equivalent) on the user interface, that it takes you to a "sample" results page (in static HTML).

Next steps

Upcoming assignments will turn this all into a working web app—here's a preview:

• In P07, we'll add a controller to stitch everything together into a working useful webapp
• Then we'll add sessions, logins, a database to store schedule information

Grading: 150 pts