Monday, September 14, 2009

Project 2b

Due date: Mon, 12 Oct
Group project


An understanding of
Functional Requirements

In this project, you will build the Participatr web service, which provides a very small subset of the functionality of, a social networking portal that facilitates offline group meetings.

This system will support the following entities:
  • Users, which have the following attributes
    • email address (also serves as unique ID)
    • first and last name
    • brief biography
    • groups in which the user is a member
  • Groups, which have the following attributes
    • unique name
    • description
    • user who created the group
    • group members
The system will support the following scenarios:
  • user signs up
  • user changes his/her full name and/or biography
  • user deletes his/her account
  • user creates new group
  • user changes description of group he/she owns
  • user deletes group he/she owns
  • user views list of groups with descriptions and membership count
  • user joins group
  • user views members of group he/she owns or has joined
  • user leaves group
These entities will be exposed as addressable, interconnected resources with suitable representations, and the scenarios will be supported through the uniform HTTP request interface.

Architectural and Other Nonfunctional Requirements

Overall, you should follow the architectural and design principles outlined here:
Your system should support at least these two representations for the user and group resources:
  • XHTML (suitable for a human user)
  • JSON (suitable for a programmatic client)
The key conceptual component of this project is to map the uniform REST verbs to the functionality described in the requirements. To some extent, we should do this part as a group in class and through the mailing list. The bookmarks example from chapter 7 of the REST book will help as well. Use the Spring-loaded version of this example, BookmarksRestletSpring from the course repository as a starting point; this post describes how to use cURL to interact with this service.

In addition, the following nonfunctional requirements apply to this project:
  • The project is managed using Maven.
  • Restlet is used to expose the given functionality in a resource-oriented form. Where appropriate, suitable representations should be included that make the (read-only) functionality accessible through a web browser (XHTML). Otherwise, the functionality should be accessible through cURL and through a suitable client also implemented in Restlet (JSON).
  • There should be a comprehensive test suite following the approaches found in the LinearRegressionRestletSpring and NumguessRestletSpring examples. JUnit should be used to automate both types of tests:
    • Direct, local, component-level unit and integration testing of the domain objects (User, Group, and related objects) and any services you layered on top of the domain objects. (Local JUnit testing of the Restlet resources is not required in this project. I have not yet figured out how to do that.)
    • HTTP-client-based system-level testing of the service using the JSON representation.
  • Persistence is provided using db4o.
  • Dependencies among components should be managed using the Spring framework.
  • Working code in the repository.
  • Also in the repository, detailed documentation of your resource-oriented architecture, including
    • a list of resources with a brief description of each
    • for each resource, the supported HTTP methods and their meaning/effect on the resource state (in terms of the scenarios listed above).
Please use the repository for your group for collaboration and notify me when your work is ready for me to review. No explicit submission will be required. Submission by email will not be accepted.

No comments: