WCDB1
Due: Thu, 7 Mar 2013, 8pm
80 pts, 8% of total grade.
Specification
Write a program to import and export validated XML of world crises using Element Tree.
IMDB has two major kinds of relations: movies/shows and people. Movies/shows link to people and people link back to movies/shows.
WCDB will have three major kinds of relations: crises, organizations, and people, and again each will link to the others.
There will be three phases.
| Phase | Features |
|---|---|
| I |
Collect data on 10 crises, 10 organizations, and 10 people. Five crises, organizations, and people, must be unique to your group. Identify common attributes of the data and insure that every data item has a value for that attribute or that the attribute is optional. |
|
Create an XSD and an XML that validates. Use xmllint. It must make use of ID/IDREF to avoid duplication. Design a naming convention for ID/IDREF. Think carefully about the types and attributes of the elements. Post the schema and instance to the public repository. No agreement between groups about the schema in this phase is required, nonetheless, it's in everyone's self interest to come up with the same schema. |
|
|
Create an import/export facility from the XML into Element Tree and back. The import facility must import from a file. The file is guaranteed to have validated XML. The export facility must export to a file. Import/export the XML on only the ten crises, ten organizations, and ten people of the group. |
|
| Create a set of unit tests. |
The relations must contain the following:
| Relation | Attributes |
|---|---|
| Crisis | name, kind, location, date and time, human impact, economic impact, resources needed, ways to help, image URLs (e.g. Bing, Flickr, Google), video URLs (e.g. Bing, Google, Vimeo), map URLs (e.g. Google Maps), social network feed URLs (e.g. Facebook, Twitter), citations, external link URLs, organizations, people |
| Organization | name, kind, location, history, contact info, image URLs (e.g. Bing, Flickr, Google), video URLs (e.g. Bing, Google, Vimeo), map URLs (e.g. Google Maps), social network feed URLs (e.g. Facebook, Twitter), citations, external link URLs, crises, people |
| Person | name, kind, location, image URLs (e.g. Bing, Flickr, Google), video URLs (e.g. Bing, Google, Vimeo), map URLs (e.g. Google Maps), social network feed URLs (e.g. Facebook, Twitter), citations, external links, crises, organizations |
For all projects, the minimum requirement for getting a non-zero grade is to satisfy all of the requirements in the table below, including the precise naming of all the files.
Only one solution must be turned in for the group. If more than one solution is turned in, there will be a 10% penalty, and the latest one will be graded.
Groups
Pick a project leader for the group. A group member can only be project leader once.
Once the TA has graded the project, that will be the project grade.
The project leader will always receive the project grade.
The project leader can add or subtract up to 10 points to or from any member of the group in exchange for adding or subtracting the same amount of points from the other member(s) of the group.
For example, the leader could add 10 points to person A, and subtract 5 points from person B and person C.
The leader will report those adjustments in the Google form.
Tools
- Element Tree
- Git
- Git Cheat Sheet
- Git Immersion
- Git Reference
- GitHub
- Google Python Style Guide
- pydoc
- unittest
- xmllint
Requirements
| Points | Description | Files | Submission | |
|---|---|---|---|---|
| 1 | 5 pts |
Git Repository Set up a private Git repository at GitHub, named cs327e-wcdb. Use this same repository for all three phases. Invite the grader to your repository. Commit at least 5 times. Commit once for each bug or feature. If you cannot describe your changes in a sentence, you are not committing often enough. Write meaningful commit messages and identify the corresponding issue in the issue tracker (below). Create a log of the commits. Push frequently. It is your responsibility to protect your code from the rest of the students in the class. If your code gets out, you are as guilty as the recipient of academic dishonesty. |
WCDB1.log |
GitHub Turnin |
| 2 | 5 pts |
Issue Tracker The GitHub repository comes with an issue tracker. Create an issue for each of the requirements in this table. Create an issue for each bug or feature, both open and closed. Describe, label, and prioritize each issue adequately. Create at least 10 more issues in addition to the requirements in this table. |
GitHub | |
| 3 | 15 pts |
Unit Tests The grader's GitHub account will have a public Git repository for unit tests and acceptance tests. It is critical that you clone the grader's public repo into a different directory than the one you're using for your private repo. Write unit tests before you write the code. When you encounter a bug, write a unit test that fails, fix the bug, and confirm that the unit test passes. Write at least 3 unit tests for each function. Tests corner cases and failure cases. Name tests logically. Push and pull the unit tests to and from the grader's repository. Prepend <cs-username>- to the file names at GitHub (i.e. foo-TestWCDB1.py and foo-TestWCDB1.py.out). Reach consensus on the unit tests. |
TestWCDB1.py TestWCDB1.out |
GitHub Turnin |
| 4 | 15 pts |
Acceptance Tests The grader's GitHub account will have a public Git repository for unit tests and acceptance tests. It is critical that you clone the grader's public repo into a different directory than the one you're using for your private repo. Write acceptance tests before your write the code. When you encounter a bug, write an acceptance test that fails, fix the bug, and confirm that the acceptance test passes. Write an auxiliary program to randomly generate acceptance tests. Create at least 10 acceptance tests with at least 1000 lines total. Tests corner cases and failure cases. Push and pull the acceptance tests to and from the grader's repository. Prepend <cs-username>- to the file names at GitHub (i.e. foo-RunWCDB1.in.xml and foo-RunWCDB1.out.xml). Reach consensus on the acceptance tests. |
RunWCDB1.py RunWCDB1.in.xml RunWCDB1.out.xml |
GitHub Turnin |
| 5 | 15 pts |
XML Schema/Instance Create an XML schema and instance and validate it. Push and pull the schema and instance to and from the grader's repository. Prepend <cs-username>- to the file names at GitHub (i.e. foo-WC1.xml and foo-WC1.xsd.xml). |
WCDB1.xml WCDB1.xsd.xml |
GitHub Turnin |
| 6 | 20 pts |
Implementation Use assert to check pre-conditions, post-conditions, argument validity, return-value validity, and invariants. Worry about this last, but your program should run as fast as possible and use as little memory as possible. |
WCDB1.py |
GitHub Turnin |
| 7 | 5 pts |
Documentation Use pydoc to document the interfaces. The above documentation only needs to be generated for WCDB1.py. Comment each function meaningfully. Use comments only if you need to explain the why of a particular implementation. Choose a coding convention and be consistent. Use good variable names. Write readable code with good indentation, blank lines, and blank spaces. |
WCDB1.html | Turnin |
| 8 |
Submission Rename "makefile.py" to "makefile". Fill out the Google form and submit the ZIP file to Turnin. |
makefile.py WCDB1.zip |
Turnin |
Graders
| Name | GitHub ID | GitHub Test Repository | Turnin ID | Turnin Project Folder | Google form |
|---|---|---|---|---|---|
| Yuchen He | cs327eTA | cs327e-wcdb1-tests | hychyc07 | cs327epj3 | Google form |
Submission
Submit a single ZIP file, named WCDB1.zip, to the grader's Turnin account, with the following files:
- makefile
- RunWCDB1.in.xml
- RunWCDB1.out.xml
- RunWCDB1.py
- TestWCDB1.out
- TestWCDB1.py
- WCDB1.html
- WCDB1.log
- WCDB1.py
- WCDB1.xml
- WCDB1.xsd.xml
- 749 reads