Python代写：CSI101 Student Management System

发表于   |   分类于

代写一个基于Web端的学生成绩管理系统，服务需要部署在AWS上，另外数据库需要使用Amazon的RDS.

Introduction

You have been asked to write a simple application to manage students and their grading. The application will be Web-based. Deployment in the Amazon cloud is preferred and Amazon RDS is preferred for storage1.

The project sponsors would like to see periodic incremental updates of the application during its development. This suggests an iterative project methodology with several interim milestone deliverables of partial functionality. The order of the deliverables is up to you, however you must show at least one new major feature for each release.

Project Deliverables

The project will produce the following artifacts:

  • A project plan document
  • UML use case diagrams modeling the requirements
  • Design statements, such as with UML static class diagrams or other illustrations, showing the design of major components of the system for each milestone. Data and functional system components can and should be modeled.
  • Code - in Python, HTML, and SQL
  • User manual

Artifacts should be delivered in a ZIP to the Blackboard. For multi-person teams, one member of the team will upload the ZIP bundle for grading. Other members of the team will upload a document (Word, PDF, text) indicating the name of the team member who has uploaded the actual ZIP for grading. In other words, all members of the team must check in something. Usual late penalties apply.

Milestones

  • UML use case diagrams & project plan document due
  • SQL data model
  • Feature Release #1
  • Feature Release #2
  • Feature Release #3
  • Full Feature Release - completed project

Problem Statement

You have been asked to write a simple application to manage students and their grading.

The Web-based program will provide the following features:

  1. Add Student - If the student doesn’t exist, this feature inserts a new student into the database including the student’s first and last name, and grades for a midterm, final, and three homework assignments. If the student already exists (first and last name is a match) then the feature behaves as an update of the grades.

  2. Remove Student - if the first and last name are a match, delete the student and their grades from the database.

  3. Lookup Student - for an exact match of first and last name, return and display the full student record.

  4. Compute Averages - display class averages for the midterm, final, and the three homework assignments.

  5. Class Report - allowing for partial matches on first name and/or last name, output a neatly formatted tabular report which shows the students and their grades. Partial matches means that “Smi” would match “Smith” and “Smithers”. Not entering a search criteria would result in all records being returned. The report should be sorted by last name and first name.

  6. Data Export - same as the tabular report, allowing for partial search matches, but return a comma separated list. This is suitable for importing into a spreadsheet tool like Microsoft Excel.

  7. Menu - an on-screen menu of the above features able to be selected and run.

  8. Secure Login - required for multi-person teams (2 or more), optional and extra credit for solo single-person teams. The initial app page will show fields for username and password. The usernames and passwords will be stored in the DB. Only validated users will be allowed into the app. Any encryption algorithm may be used.

The system shall produce meaningful error messages. For example, when trying to remove a non-existent student, or when failing to login.

Grading

  • Code and documentation artifacts must be turned in on the Blackboard with each milestone. These artifacts may include HTML code, Python code, SQL, diagrams and other documents, etc., as required for each milestone. Files should be packaged in a ZIP.

  • Each milestone must also include a user manual, describing to the grader the URL of the application and the feature which is testable. This document does not have to be wordy or flashy - just functional, relating the necessary information to the grader. Any notes for the grader about the performance of the application, bugs, or other lacking requirements should be communicated to the grader in this document accompanying the release (Word, PDF, or text formats only). If the app has a secure login, the user manual should provide a working username and password. A milestone deliverable without a note is at risk of not being able to be graded - for example, the grader will not guess your URL!

  • The grader will assess the deliverables relative to the documented plan.

  • Code will be inspected by the graders at each milestone - however, points for coding style will not be taken into account until the end of the project. In other words, in the early milestones the emphasis will be on getting some amount of code working. By the end of the project however, the code will be expected to have matured, so will also be assessed on style factors such as modularity, indentation, meaningfully named variables, and code comments.

  • As with code, points for GUI style will also be reserved for the final milestone. In other words, get the application working first, then make it look good.

Grading Process

The grader will, for each project team:

  • Go to the Blackboard to locate submitted homework. The artifacts to be reviewed will include those named above - project plans, Python and HTML code, design diagrams, SQL schemas - and a user document for that milestone.
  • The user document will indicate which feature or features are ready for test. The document will also provide the URL of the AWS EC2 hosting a testable Web app.
  • The grader will invoke the URL and test the application features.
  • The grader will review the artifacts - code, diagrams, etc.

Project Plan

The project will be permitted to have from 1 to 3 persons.

  • Team members may not change once the project plan has been submitted.
  • All members of the team will receive the same grade for each milestone.
  • Code sharing between teams will be considered an ethical violation.

Your project plan document must include the following items:

  • Names and email contact information for team members. Indicate the name of the student who will be submitting project deliverables to the Blackboard.
  • The Elastic IP of the EC2 to be used for the team when submitting to the graders - only one IP is necessary for the entire team.
  • A list of project features which will be delivered at the feature release milestones. Teams may decide on their own the order they will implement the required system features. Teams may also change their mind on the order of these feature releases. A change in the plan should be documented in an update of the project plan and submitted with the artifacts for that milestone release and should be called out in the user manual.
  • Some mapping of team member names to the tasks to be completed for each milestone. This gives the team a way to share the labor and promise to each other to deliver.

Suggestions

  • Code early. As soon as possible - when some early design emerges - start writing code.
  • Test early test often. Test your own code. Test each other’s code.
  • Meet as a team and decide on the division of labor. Document it in the project plan. Re-meet often - leverage email, text, Skype to keep in communication. Hold each other to commitments.
  • Keep individual sandboxes in AWS. Developers on a multi-person team should keep their own AWS instance for use in testing their own code before sharing it with the rest of their team.
  • Multiple-person teams should adopt some mechanism for sharing code between themselves. One possible means is using the built in features of CodeAnywhere, as described here: https://codeanywhere.com/features/editor#collab
  • Make an early decision on how you will keep then in-development Web app separate from the version you submit for grading. See a discussion of sharing and publishing for grading below.
  • Make an early decision on how to keep backups of your work. See a discussion below.
  • Take notice of commonalities in the descriptions of the system features below, and the implied opportunities for code reuse. For example, both the Report and Export features need a partial search function.

Code Sharing

Multi-person teams may want to share code. CodeAnywhere provides a means to do this:

  • In CodeAnywhere, right click on your project and select “Share”. Indicate the email addresses of your collaborators. Give them write permissions.
  • The collaborators will receive an email with a link to the code.
  • Within CodeAnywhere, under Preferences General, turn on Pair Programming. This will let you see changes the other person is making in real time. Consider having a Skype session with your partner(s) and also utilizing this CodeAnywhere sharing - you will have become a telecommuting distributed programming team!

Code Backups

  • You will want to make backups of your code in the event you accidently delete something or make some other kind of rookie mistake. There are several ways to do this:
  • CodeAnywhere, the free version, provides a copy of your last edit. The paid versions of CodeAnywhere provide a longer version history.2
  • In CodeAnywhere, you can right click on a file and download a copy.
  • In CodeAnywhere, you can “clone” a file - just give it a different name as a backup copy.
  • In AWS you can make an snapshot of your EC2 - called an AMI. This is a snapshot in time of your entire EC2, including your code. AMI instances can also be made public and shared.

Error and Access Logs

In CodeAnywhere you will find a logs/ subdirectory. In there you will find:

  • Access log - shows the hits on your Web app
  • Error log - shows any errors produced by the Web server and your Web app

Use these mechanisms in conjunction with errors displayed in your browser to help debug your Python code.

Publishing Your App for Grading

Here’s the problem - it make take days after the due date of a project milestone for the TA to get to view your app. In the meantime, you may have made changes to the app to support the next milestone which have now left your app in a half-broken state. If the TA should look at your app at exactly the wrong time, they may not see your app as it was at the time of the due date.
You need to have a second copy of the app to give to the TA. For this you have several options:

  • Use a single EC2 with a single RDS. Be careful when making changes after a milestone due date. This is the “do nothing” option, doesn’t really address the problem, has low overhead but is risky.
  • Use two EC2 instances with a single RDS. Since the Python code will likely change more often than the database structure, make an AMI snapshot of your EC2 development instance and spin it up as a second copy. Submit the address of the copy for grading. We expect this to be the most popular way to handle publishing for grading.
  • Use two EC2 instances with two databases. The code running on each EC2 will need to be slightly modified to point to its own database instance. This strategy is more labor intensive, but allows you the freedom to make structural changes to the database while an older copy is still waiting on grading.

Extra Credit - Optional Features

For those students wishing to maximize their experience on this project, implementation of the following additional functional and non-functional requirements will be eligible for extra credit. The team is expected to be largely self-directed when engaging in these value-add options (i.e. the TAs will not be providing extra help).

  • Use of a Python framework like Flask. (This will require installing Flask on your EC2, which will require an SSH session and some basic Unix knowledge. The key pair created when your EC2 was launched will be needed to make the SSH connection.)
  • Use of modern JavaScript framework / widgets / skins to enhance the visual look and feel.
  • Use of a modern source code repository such as Git. The team should provide a URL to the repository for inspection by the grader.
  • A login screen accepting user and password to enter the app. Passwords should be stored in the DB encrypted. The user manual needs to be clear on the username & password to use for grading.
  • An audit trail, stored in the DB, which notes when and what student data (insert, update, delete) is performed, and if a login screen is used, also notes who made the change, and an additional report feature report which displays the audit trail.
  • Use of a Web-app test tool such as Selenium. Teams should turn in their Selenium scripts as part of their deliverables.
  • Online help / user documentation included in the app itself.

Useful References

https://docs.python.org/3/library/csv.html
https://www.decalage.info/python/html
https://wiki.python.org/moin/WebProgramming
https://docs.python.org/3/library/cgi.html