|CSE Home||About Us||Search||Contact Info|
Project Description: Community Calendar Program
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:
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.
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:
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).
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).
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:Note: Turn in your milestones by sending an email to Yana. In some cases you also have to turn in something in writing: bring it in to class, or to Dan's office or to Yana's office (your choice). Each milestone is due by the end of the day.
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.
Nov. 4: Yana will talk about Web services in class.
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
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.
|Department of Computer Science & Engineering|
University of Washington
Seattle, WA 98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to yana at cs.washington.edu]