CPSC 315 Team Project 1
Your goal in this project is in two parts. First, you are to implement a general database system with a limited amount of database functionality. You will create a standalone “library” that can be used by other programs to define, populate, and query a database. Second, you will implement a basic database application program that makes use of the database system defined by another team.
Note that in a “real” application, it is unlikely that you would implement one of these database systems “from scratch.” More likely, you would use an existing database system, and access the system via query functions, a DDL, and/or a DML. This project is meant to help you:
Your project will consist of two major pieces of code: a database library and an application module. These two pieces of code should be developed independently. That is, your database library should have an API defined for it (and the API should not expose underlying functionality unnecessarily). The library code should implement that API. Your application program should make use of another team’s interface, and access the database only via that API.
Teams will “deliver” their library to the next team on the list (e.g. Team 1 to Team 2, … , Team 4 to Team 1). So, each team will be acting as both a producer of their own library and a consumer of another team’s.
The details of the code are described below.
Specification of Database Library:
You should create an independent library that gets compiled into a .dll. This library should allow a user to specify a relational database, add data to the database, and perform queries on it. Specific features to be supported are given below (note: items marked with an * do not need to be completed by two-person teams):
In addition, you should enable users to specify a primary key for this data.
You do not need to support weak entity sets for this program!
· *Deletion of tables.
Ideally, you should account for basic errors, such as specifying two tables with the same name, inserting a tuple with a duplicated key, etc. You do not need to check for more fundamental database organization problems.
Note that for modification and deletion of Tuples, you should support limited conditions, as described in the querying function below.
Basic SELECT-FROM-WHERE statements should be supported. These should include support for the following (all are analogous to SQL statements, but this is not saying that these functions need to be provided via an SQL-formatted query – you may choose any method you want in your API to specify the query statement, including supporting standard SQL syntax):
You only need to handle cases where “full parentheses” would be used – i.e. all parentheses would be used around any statements, and will never nest more than 3 deep. For example ( ((A>B) OR (B<C)) AND (D = E) )
Note that for this program, the results of every query should be stored as a view, automatically. That is, any query that is performed should generate a new table. It should be possible to query this table by a future query, just as any of the “defined” tables. A FROM statement should be able to use one of these tables as a source, but it does have to take the query result directly (i.e. there are no nested queries, here).
Commands should be included to return information about the database as a whole. At a minimum this should include
Specification of Application:
You should create a separate application program that uses the API defined by the first team. This program should be written as if you are handling an airline reservation system (you can assume just for one airline if you want). You will need to write routines to create the necessary tables, populate the tables (from a file and/or from user input), and query the tables in useful ways.
You may make the application program as fancy as you want. But, at minimum, among the data you should keep in the database are the following:
· Flight information (e.g. flight number, planes, number of passengers held, starting/ending cities, etc.)
· Passenger information (e.g. Name, address, frequent flyer number if any, etc.)
· Ticket/Reservation information (e.g. flight, date, passenger, cost, etc.)
You should support interaction with this system, including such things as:
· Find all passengers on a particular flight
· Find information (including flights) for a passenger
You are strongly encouraged to extend this beyond such minimal extent – e.g. supporting questions like finding out how full a particular flight tends to be, etc. Doing simply the absolute minimum would not earn a particularly good grade. However, do not overshoot, so that you are unable to get your program working – it is better to have less functionality that works than more functionality that does not.
Note that any two-person team will have much lower expectations in this application program than a three-person team would.
For this assignment, the teams will be as follows:
Team 1: Brandon Kaster
Team 2: Nathan Clark
Team 3: Kyle Broekers
Team 4: Chace Clark
For this project, you may organize and run your team as you would like. In later projects, the team structure and operation will be given more specifically, but in this one, you may organize as you see fit. However, you will be asked to a) describe how you organized your team, b) give a justification for why you decided to organize in that way, and c) provide feedback on how well that organization worked. In other words, you should consciously decide on how you will work together, divide up responsibilities, etc., and not just start working and see how things fall out.
This project is to be completed in C++.
Your team is required to maintain its development using a version control system. You should choose and set up an SVN repository/project site in which your team will keep current versions of source code, documentation, etc. This should be one of the first decisions your team makes. CodePlex, Google Code, and Sourceforge are suggested locations for these repositories, but you may choose another option if you would prefer. Note that your team is to make use of this repository for all development. You should not pass around files by email, saving in shared directories, etc. Significant points will be taken off of the project if code is shared via a method other than the SVN system. (You may use a version control system other than SVN, if you would prefer).
Your team should give access to both the Instructor and the TA to the SVN repository for download. Your team is required to send email to both giving the location of your team’s project, and instructions for access to the SVN repository (this should be done by the time of Project Update 1, below). The instructor/TA may download SVN software at any point.
Organization Statement: Your team is to turn in a written update regarding the overall project design. Specifically, your report should have 3 main components:
API Specification: Your team is to create a complete description of the API for the database library. You should be sure to document exactly what functionality your library will provide, and how to access this functionality. Note that you do not have to have the actual library implemented by this point, but you should have a clearly defined interface designed. Your API should be given in a form that will be easily accessible by the other team. One option is to use a documentation area of whatever source code repository you are using. Another option is to set up an HTML document that you post on the web. This API description should serve as the primary documentation for someone wanting to make use of your library. On the due date for this specification, you are to email both the second team (which will use your library) as well as the instructor and TA to give the location of your API specification.
Note that after your API specification is published, you should generally not make substantial changes to it. However, if it becomes necessary to do so (due to problems discovered when implementing it), you should be sure that your specification clearly shows the change history of the API. Furthermore, you should publish such updates as soon as you possibly can.
Code Checkpoint 1: The code checkpoint is an intermediate point at which you will “release” an early version of your database library. Your code at this point should be substantially complete, with only small features/details missing, and bugs remaining. The second team should be able to include your library at this point, and make all of the specified function calls, however, there may be some missing functionality and/or bugs in the version. Where possible, these missing features and bugs should be noted/documented.
It is strongly suggested that for your code “release”, you release your code via your source code repository web page. You should email the second team, cc’ing the instructor and TA, giving information about where to go to download this intermediate code release.
Besides this release, you should submit a “snapshot” of your code via CSNET.
Code Checkpoint 2: The second code checkpoint is meant to be the point at which the database library functionality is “complete.” The second team should, after this point, be able to use your library within their application, with full functionality matching that specified in the API. Thus, you should plan to have all functionality implemented by this point. Note that after this code checkpoint, your team may still need to respond to bug reports submitted by the second team. It is suggested that, like the first checkpoint, you should “release” your code via your team’s project source code repository. Besides this release, you should submit a “snapshot” of your code via CSNET.
Bug reports: Although not a required part of the intermediate process, the second team should communicate with the first team to report any bugs encountered, and ask for updates/bug fixes. At the first checkpoint, it is expected that there may be many bugs, but hopefully the first team will have noted these in its release; bugs not noted but discovered by the second team should be reported. There is very little time available after the second code checkpoint, but the second team should still report bugs and ask for responses to any bugs encountered at that point. The first team should respond to bug reports, even if only to note that it will be unable to address the bug in the remaining time (and suggest a workaround if possible).
Documentation of Final Project:
Your final report should include three pieces of documentation. In addition, you should submit your code in its final state via CSNET. This submission will be your final graded project, and the turnin time will be based on that code turnin.
First, you are to include documentation describing the API for your library (in its final form) and for operation of the application program you provide. The API should be substantially the same as the initial specification, with changes clearly documented.
Second, you should include a document describing the use of your application program (this is the part that will be graded, below). This document should (without being too wordy) describe the features of your application program, including how to perform all of the basic commands desired. Note that your team may be asked to demonstrate your application program shortly after the time it is turned in.
Finally, your team should turn in an evaluation document that describes the following:
1) A summary (about ˝ to 1 page in length) of how well your team met its planned goals/schedule/etc. as outlined in the initial organization statement.
2) A (1-2 page) summary of the library given to you by the first team. You should clearly specify whether the team met its responsibilities in terms of delivering required pieces (API, code at checkpoints) on time and with the functionality needed. List any difficulties encountered, including any bug reports/fixes that were needed along the way.
Turning in Work:
Except as specified otherwise (e.g. emails), you are to submit work and reports via the CSNET turnin system. Individual reports (e.g. the final report regarding teamwork) should be submitted by individuals. The team reports and code should be submitted by one team member.
Individuals will be required to put together a specific report detailing how the teamwork went. The results of this report will figure into the grade allocation among team members. Details of this final report will be given later.
The overall project will be graded as described below. This grade will be used to determine the team grade, and individual grades will be determined by apportioning the team grade among the team members (the exact breakdown will depend on the individual project reports). Details of that final grading (for individuals) will be given later. Also note that your grade on the database library will be determined in significant part by evaluation by the second team that uses your code.
5% Update 1 – How complete is the update, and how thoroughly were issues addressed
10% API Specification – How complete is the API? Is it specified clearly, and is the documentation provided appropriate
10% Code Checkpoint 1 – Is a usable, mostly-implemented library provided?
10% Code Checkpoint 2 – Is a complete implementation of the specified API provided?
5% Final Application Documentation
25% Completeness/Correct Operation of Database library
25% Functionality/Extent/Correct Operation of Application program
10% Code style: naming/layout/commenting
Dates and Deadlines:
The following are the intermediate deadlines for this project. Details of the particular requirements are described above. Note that these are final deadlines; it is likely that your team would want to complete several of these (e.g. the two Project Updates) well in advance of the “due date”
Tuesday, September 9
Monday, September 15, 5:00 p.m.
Email Instructor and TA regarding SVN repository
Team Project Update 1 (source system, team organization, and design statement)
Wednesday, September 17, 5:00 p.m.
API Specification delivered to second team
Thursday, September 25, 5:00 p.m.
Code checkpoint 1: Initial Release of Database functionality to Next Team
Wednesday, October 1, 5:00 p.m.
Code checkpoint 2: Delivery of Database Functionality to Next Team
Monday, October 6, 11:59 p.m.
All final project code turned in
Project documentation turned in along with code
One day after final code turned in (or Tuesday, October 7, 11:59 p.m.)
Final group report turned in
One day after group report turned in (or Wednesday, October 8, 11:59 p.m.)
Individual Reports on teamwork turned in