Project Description:       Community Calendar Program

Overview

You will develop a calendar system that will allow a community of users to schedule events and allocate resources.  The application contains the following entities:

• Users.  Each user has a name, password, and email.
• Groups. Each group is a set of users. Groups can be overlapping, for example there could be a group of chess-players and a group of stamp-collectors that overlap. Users should be able to create new groups, to subscribe to an existing group, to add other users to an existing group, or to remove users from an existing group. You may want to define a policy that states who is allowed to add/delete whom to/from which group: for example everyone is allowed to add himself to any group, a group's owner is allowed to add anyone to that group.
• Events. An event is the basic unit of information in the calendar system. It consists of a date, a start time, an end time, a short description, a owner (a user), a list of attendees (users and/or groups), and a list of resources reserved for that event.
• Resources. These can be rooms, A/V equipment, or other resources. Each resource has a name, and an associated number indicating the number of available units for that resource. For example, ("Thinkpad laptop", 4 units).  When a user schedules an event she may reserve several resources, and more than one unit from each resource: e.g. she may reserve 2 "Thinkpad laptops", and 3 "Data projectors". Normally, at any moment, the total number of units reserved for each resource cannot exceed the number of available units.
• Actions. Every time a new event is created, all its attendees will be notified by email.

Events will always be scheduled by a single user (the owner of the event) but may apply to a set of users or groups. You will act as administrator of the calendar system, and will establish a set of users and resources to begin with. Events that overlap in time may be in conflict either because they have a common attendee, or because they use more units of a resource than available. You should allow conflicting events, but should warn the user, e.g. by highlighting conflicting events with a different color.

Access Modes

Your system should allow users to perform operations on events (view, schedule, modify, and delete events), manage group membership, and browse the data in the calendar in various ways.   The system will be accessed in two modes: through a Web interface or as a Web service.

Web Interface. In the first mode the system is accessed through a Web interface. All operations are performed here through the Web browser. You need to implement several ASP pages, called views, that query the database, display a Web page with the calendar, and/or allow the user to update the database. A WEEK VIEW page is required, which, for a given user or group and a specified week, returns all relevant results in table form, as in this sample (of course, your's may look differently).  Other views or pages are left for you to design.  You are likely to need an EVENT VIEW and a USER VIEW.  Updates to the calendar database (scheduling, modifying, or deleting events) should be done through web forms.   There are many useful queries that might be incorporated into your interfaces, in the appropriate context.  Here are some examples:

• What rooms are available on Friday from 1pm - 2pm ?
• Are there any conflicts in my scheduled events ?
• What is the next hour-long time period which is available to all members of the database group ?
• How many database group members are free to attend a meeting next Tuesday from 2:30 to 3:30 ?
• To what groups do I belong ?

You should be creative in identifying additional useful queries, and making them accessible to the user through the web.  This may be through form-based pages, but in some cases, a link in the right place which returns query results will suffice.  Obviously, we don't expect the user to submit SQL queries to extract information, so assisted interfaces are required.  Also, you will need to authenticate the user before allowing access through the Web interface.

Web service. In the second mode the system is accessed by a Web service.  A Web service is a relatively new technology implementing a form of Remote Procedure Calls on the Internet. At a minimum you should implement the WEEK VIEW operation, by providing a Web service which expects a week number as an argument and returns all events scheduled in that week.

To demonstrate your web service, you would need to create a client for it. Implement some functionality in your web service that is not already available through your web interface (could be something really simple, e.g. counting events of certain types). Then create an ASP page (or add a feature to an existing page) which is a client to your web service and demonstrates the use of your Web service.

Note: The correct way to implement such a system is to first create a Web service offering the full functionality of the Web interface, then build the Web interface as a client for the Web service. However, we recommend an alternative architecture: implement the Web interface directly, without a Web service, then build a much more limited Web service that replicates some of the functionality of your Web interface. The reason is that the technology for the Web interface is mature, and you are expected to implement a fully functional Web interface, while that for Web services is new, and you are only required to show a 'proof of concept' (and we do expect to encounter problems along the road). 

Security

Your calendar implementation must include a reasonable but simple security policy using password authentication for all web-based access. You will define a minimal access policy, and implement it.  For example, a user may only be allowed to modify his/her own events, or those in which he/she participates.  You also need to define what attributes of an event will be shown to users that have no relationship to that event (e.g. only the date and time, or the date and time and all participants, etc). 

There are many ways to implement authentication. The simplest one is to have a table of users and passwords in your database and use that in combination with cookies to authenticate your users.
You can choose to implement a more sophisticated authentication scheme and let us know about it during your presentation--that would count as an additional feature to your project

Systems Resources  [Support Page]

This project will require you to use a variety of tools.  We have provided a collection of recommended tools and systems for which we will provide some assistance and support.  Your data will be stored in a SQL database system running on an instructional machine.   Your dynamic web-pages will be constructed using ASP. The support page linked above contains sample code and tutorials that should serve as a starting point.

You are free to use other tools, but at your own risk: that is, if you get stuck we may not have the time and resources to help you out. Alternative tools that you may want to consider are: Postgres (an open-source database management system which is a popular choice for Linux), Perl, JSP, PHP. Please let Yana know if you choose other tools.

Project Milestones:

Milestone 1 - Oct. 7. Form groups of 3 or 4, choose a team name, and notify your TA by email of each member.s name and username.

Milestone 2 - Oct.21   Design an E/R diagram for the calendar application.  Create the corresponding schema in SQL Server, and add some sample data.  Design a rudimentary web page which connects to your database and extracts some data.  The support page (see the Sample Code) will be helpful for this.  Submit your E/R diagram in writing, and send Yana a link to the trial Web page. Try to make the E/R diagram and the relational schema as complete as you can (you may change it later, but you won't have too much time for major changes). The Web page should can very rudimentary: it's purpose is for you to test the connection to the database.

Nov. 1:     MIDTERM

Nov. 4:    Yana will talk about Web services in class.

Milestone 3 - Nov. 4: Implement WEEK VIEW and complete the Web-based access methods including  interfaces for insertion/modification of events, and other more advanced queries. Email Yana a link to your Week view URL.  Try to make the Week View as complete as you can: you may change it later, but you won't have too much time for major changes.

Milestone 4 - Nov. 13: Add user authentication. This should be a quick step for you if you are using cookies.  Submit a link to your working system. If you get this done early start working on the next one--the next milestone will require some work

Milestone 5 - Nov. 27: Implement a Web service which provides information analogous to the Week View web page and at least one additional method. In addition, write a simple client demonstrating the functionality of your Web Service. The client could be a Web Page or a program--it is up to you. 

Dec. 9, 10:  Project demos

Grading

The grade on your project will be based mostly on the project demo, and also on the timeliness and completeness of your milestones (missed, or incomplete milestones will have negative impact). During the project demo we will evaluate your project based on features and the overall design. We will look for a the number of features and their balance. Nice interfaces that give users easy access to their data are a plus; clumsy interfaces that require the user to type in lots of information to retrieve or change data are a minus. We also look for a balance between features for user management, resource management, and event management. We will evaluate the overall design much less thoroughly, but will look for typical design mistakes: for example your database should have entries only for existing events, and not for the free hours in the calendar.