11/13/2020 CMPUT 291 (LEC A1 A2 EA1 EA2 Fall 2020): Mini-project 2 spec
https://eclass.srv.ualberta.ca/mod/page/view.php?id=4329176 1/3
Dashboard / My courses / CMPUT 291 (LEC A1 A2 EA1 EA2 Fall 2020) / 2 November - 8 November / Mini-project 2 spec
CMPUT 291 - File and Database Management (Fall 2020)
Mini-project 2 spec
CMPUT291 - Fall 2020
Mini Project II
(group project)
Due: Nov 25th at 5pm
Clarifications:
You are responsible for monitoring the course discussion forum in eclass and this section of the project specification for more details or clarifications. No
clarification will be posted after 5pm on Nov 23rd.
None.
Introduction
The goal of this project is to teach the concept of working with data stored in files and NoSQL databases. This is done by building and operating on
a document store, using MongoDB. Your job in this project is to write programs that store data in MongoDB and provide basic functions for
searches and updates. 80% of the project mark would be assigned to your implementation, which would be assessed in a demo session, and is
further broken down to two phases with 10% of the mark allocated for Phase 1 and 70% for Phase 2. Another 15% of the mark will be assigned for
the documentation and quality of your source code and for your design document. 5% of the mark is assigned for your project task break-down and
your group coordination.
Group work policy
You will be doing this project with one or two other partner from the 291 class. Register your group at the group registration page for mini-project 2.
It is assumed that all group members contribute somewhat equally to the project, hence they would receive the same mark. In case of difficulties
within a group and when a partner is not lifting his/her weight, make sure to document all your contributions. If there is a break-up, each group
member will get credit only for his/her portion of the work completed (losing the mark for any work either not completed or completed by the
partner). For the same reason, a break-up should be your last resort.
Task
You are given three json files named as Posts.json, Tags.json and Votes.json, which you will use to construct your collections in MongoDB. Here is a
small sample of Posts.json, Tags.json and Votes.json (download and save them locally). The data includes posts made to stack exchange sites (including
stack overflow). Your job is to create MongoDB collections, following Phase 1, and support searches and updates in Phases 2.
Phase 1: Building a document store
Write a program that reads the three json files (as named above) in the current directory and constructs a collection for each. Your program will take as
input a port number under which the MongoDB server is running, will connect to the server and will create a database named 291db (if it does not exist).
Your program then will create three collections named Posts, Tags and Votes respectively for Posts.json, Tags.json and Votes.json. If those collections
exist, your program should drop them and create new collections. Your program for this phase ends after building these collections. As you may notice in
the sample data, the fields of a record are not fixed and some records have more or less fields than others.
Groups of size 3 will need, as part of their program for Phase 1, to extract all terms of length 3 characters or more in title and body fields of Posts, add
those terms as an array named terms to Posts collection, and build an index on those terms. Assume a term is an alphanumeric character string, and that
terms are separated by white spaces and/or punctuations. Also as part of their program for Part 2, they will need to use this index when searching the title
and body fields in the next phase.
11/13/2020 CMPUT 291 (LEC A1 A2 EA1 EA2 Fall 2020): Mini-project 2 spec
https://eclass.srv.ualberta.ca/mod/page/view.php?id=4329176 2/3
Phase 2: Operating on the document store
Write a program that supports the following operations on the MongoDB database created in Phase 1. Your program will take as input a port number
under which the MongoDB server is running, and will connect to a database named 291db on the server. Your program should allow the users of the
system to provide a user id (if they wish), which is a numeric field, formatted as shown in the sample json files. If a user id is provided, the user will be
shown a report that includes (1) the number of questions owned and the average score for those questions, (2) the number of answers owned and the
average score for those answers, and (3) the number of votes registered for the user. Users may also use the system without providing a user id, in which
case no report is displayed.
Next, users should be able to perform the following tasks.
1. Post a question. The user should be able to post a question by providing a title text, a body text, and zero or more tags. The post should be
properly recorded in the database. A unique id should be assigned to the post by your system, the post type id should be set to 1 (to indicate that
the post is a question), the post creation date should be set to the current date and the owner user id should be set to the user posting it (if a user
id is provided). The quantities Score, ViewCount, AnswerCount, CommentCount, and FavoriteCount are all set to zero and the content license is
set to "CC BY-SA 2.5".
2. Search for questions. The user should be able to provide one or more keywords, and the system should retrieve all posts that contain at least one
keyword either in title, body, or tag fields (the match should be case-insensitive). Questions have a post type id of 1 in Posts. For each matching
question, display the title, the creation date, the score, and the answer count. The user should be able to select a question to see all fields of the
question from Posts. After a question is selected, the view count of the question should increase by one (in Posts) and the user should be able to
perform a question action (as discussed next).
3. Question action-Answer. The user should be able to answer the question by providing a text. An answer record should be inserted into the
database, with body field set to the provided text. A unique id should be assigned to the post by your system, the post type id should be set to 2 (to
indicate that the post is an answer), the post creation date should be set to the current date and the owner user id should be set to the user posting
it (if a user id is provided). The parent id should be set to the id of the question. The quantities Score and CommentCount are all set to zero and the
content license is set to "CC BY-SA 2.5".
4. Question action-List answers. The user should be able to see all answers of a selected question. If an answer is marked as the accepted answer, it
must be shown as the first answer and should be marked with a star. Answers have a post type id of 2 in Posts. For each answer, display the first
80 characters of the body text (or the full text if it is of length 80 or less characters), the creation date, and the score. The user should be able to
select an answer to see all fields of the answer from Posts. After an answer is selected, the user may perform an answer action (as discussed
next).
5. Question/Answer action-Vote. The user should be able to vote on the selected question or answer if not voted already on the same post (this
constraint is only applicable to users with a user id; anonymous users can vote with no constraint). The vote should be recorded in Votes with a
unique vote id assigned by your system, the post id set to the question/answer id, vote type id set to 2, and the creation date set to the current
date. If the current user is not anonymous, the user id is set to the current user. With each vote, the score field in Posts will also increase by one.
After each action, the user should be able to return to the main menu for further operations. There should be also an option to end the program.
Testing
At development time, you will be testing your programs with your own data sets but conforming to the project specification.
At demo time, we will be testing your programs with our test data files that have the same names as given above. Using your submitted code, we will (1)
build a MongoDB database in Phase 1, and (2) perform search and update operations in Phase 2. We typically follow a 5 minutes rule for Phase 1,
meaning your database should be built in less than 5min. If not, we may have to use our own database, in which case you would lose the whole mark for
Phase 1.
Every group will book a time slot convenient to all group members to demo their projects. At demo time, all group members must be present. Our TAs
will be asking you for instruction to perform various tasks and to test how your application is handling each task. A mark will be assigned to your demo on
the spot after the testing.
Here are some important details about our testing process and your choices (same as in Project 1):
1. The demo will be run using the source code submitted and nothing else. Don't hard-code the port number in your application since the port number
is not known in advance, and you don't want to change your code at demo time. The test files will follow the same formatting as the samples (in
terms of field names and types) but will be larger. Your application will be tested under a TA account.
2. We must be able to compile and run your code under our account on undergrad machines and using our own database. You are not allowed to
make any changes to the code without a hefty penalty.
3. Our test data and our test cases will be published after the project due date but before our demo times. This means, you have a chance to test your
application and learn about possible issues (if any) before your demo time.
4. Your code cannot be demoed on a laptop (yours or ours) or any machine other than the lab machine with only one exception. The exception is if
you are developing your application using a less traditional programming language or tool that is not available on lab machines, you MAY be
allowed to demo your application on a laptop. Those cases should be discussed with the instructor well before the project due date and an
approval must be obtained. Otherwise, you cannot demo your project on any machine other than the lab machines.
Instructions for Submissions
Your submission includes (1) the application source code for phases 1 and 2, (2) README.txt, and (3) a short report named Report.pdf. Your source code
must include at least two programs, i.e. one for each phase. Your program for Phase 2 would implement a simple query interface in your favourite
programming language (e.g. Python, C or C++, Java).
Create a single gzipped tar file with (1) all your source code, (2) README.txt, and (3) your project report. Name the file prj2code.tgz.
Submit your project tarfile in the project submission site by the due date at the top of this page.
11/13/2020 CMPUT 291 (LEC A1 A2 EA1 EA2 Fall 2020): Mini-project 2 spec
https://eclass.srv.ualberta.ca/mod/page/view.php?id=4329176 3/3
You are logged in as Lucheng Zhou (Log out)
CMPUT 291 (LEC A1 A2 EA1 EA2 Fall 2020)
All partners in a group must submit their own copies (even though the copies may be identical)!
The file README.txt is a text file that lists the names and ccids of all group members. This file must also include the names of anyone you collaborated
with (as much as it is allowed within the course policy) or a line saying that you did not collaborate with anyone else. This is also the place to
acknowledge the use of any source of information besides the course textbook and/or class notes. Your report must be type-written, saved as PDF and
be included in your submission. Your report cannot exceed 3 pages.
The report should include (a) a general overview of your system with a small user guide, (b) a detailed design of your software with a focus on the
components required to deliver the major functions of your application, (c) your testing strategy, and (d) your group work break-down strategy. The
general overview of the system gives a high level introduction and may include a diagram showing the flow of data between different components; this
can be useful for both users and developers of your application. The detailed design of your software should describe the responsibility and interface of
each primary function or class (not secondary utility functions/classes) and the structure and relationships among them. Depending on the programming
language being used, you may have methods, functions or classes. The testing strategy discusses your general strategy for testing, with the scenarios
being tested and the coverage of your test cases. The group work strategy must list the break-down of the work items among partners, both the time
spent (an estimate) and the progress made by each partner, and your method of coordination to keep the project on track. The report should also include
any assumption you have made or any possible limitations your code may have.
Last modified: Wednesday, 4 November 2020, 11:42 PM
◄ Mini-project 1 demo booking Jump to... Mini-Project 2 groups ►

欢迎咨询51作业君