代写一个Web风格的桌面应用程序，方便TA对学生作业的管理。
Introduction
Teaching Assistants in Computer Science courses typically must grade large numbers of student assignments each semester. The setup time for each assignment can be lengthy, depending on the technology used by a given course for managing student submissions. Stony Brook University uses Blackboard for providing student assignment grades, which also has a feature for students to submit their work. The problem with Blackboard is the process of retrieving student submissions and then extracting them into a format that works for grading is time consuming and involves a number of different steps and tools.
Code Check will be a desktop application that will make it easier for Teaching Assistants to extract student submissions into a proper format to setup grading as well as setting up checks for code plagiarism (what we’ll call a code check).
Purpose
The purpose of this document is to specify how our Code Check program should look and operate. The intended audience for this document is all the members of the development team, from the instructors to the software engineers and designers. This document serves as an agreement among all parties and as a reference for how the code extraction tool should ultimately be constructed. Upon completing the reading of this document, one should clearly visualize how the application will look and operate as well as understand the way a generated site is setup.
Scope
For this project the goal is for Teaching Assistants to have an easier time extracting student assignments for the purposes of grading and plagiarism checking. The assumption is that all submissions were made via Blackboard, which has its own submission formats. This will serve as our starting point. So, the application will not be about downloading submissions, that must be done via Blackboard using a Web browser. This application will take a collection of student submissions zipped up into a single file downloaded from Blackboard and will then extract these submissions and organize them into directories of unzipped work, ready to grade. In addition, Teaching Assistants will be given the opportunity to extract and organize the submitted source code to help with code plagiarism checks.
Definitions, acronyms, and abbreviations
- Framework - In an object-oriented language, a collection of classes and interfaces that collectively provide a service for building applications or additional frameworks all with a common need.
- GUI - Graphical User Interface, visual controls like buttons inside a window in a software application that collectively allow the user to operate the program.
- IEEE - Institute of Electrical and Electronics Engineers, the “world’s largest professional association for the advancement of technology”.
- UML - Unified Modeling Language, a standard set of document formats for designing software graphically.
- Use Case Diagram - A UML document format that specifies how a user will interact with a system.
References
IEEE Std 830-1998 (R2009) - IEEE Recommended Practice for Software Requirements Specification
Overview
This SRS will clearly define how the Code Check application should look and operate. Note that this is not a software design description (SDD), which would design how to construct the software using UML. This document does not specify how to build the appropriate technologies; it is simply an agreement concerning what to build. Section 2 of this document will provide the context for the project and specify all the conceptual design. Section 3 will present how the user interface should be laid out. Section 4 provides a Table of Contents, an Index, and References.
Overall description
Here you are a Teaching Assistant in a Computer Science course like CSE 219 (Computer Science III), where you may be obligated to grade HW 1 submissions for 65 students. The current process for doing so would involve the following steps:
Open a Web browser like Chrome
Login to Blackboard
Navigate to the course page
Go to the Grade Center. Here one will find a table with student submissions waiting to be graded denoted.
For the assignment to be graded, click on the column and select the Assignment File Download option. This will bring one to the view shown in Figure 2.2 where one can select the student submissions to grade.
Click the check box next to the student names to be graded and press the Submit button. Upon doing this Blackboard will combine all selected student submissions into a single ZIP file and present a link to the user such that they may download this file.
Right click on the link, this will open up a popup menu of choices.
Select Save Link As, which should open a dialog for saving the file.
Navigate to the directory where you wish to place it.
Name the ZIP file as you like and click the Save button.
Now, via these 10 steps the TA can select and download student HW submissions. As shown the TA can select which assignment and which students. The result would be a single ZIP file that has all student ZIP files contained inside. We will not change this process in our application. The goal of our application is to make the remaining steps easier.
Current Extraction Process
In order to make the grading process as smooth as possible students are encouraged to zip up and include their entire project regardless of IDE. So, if one is working in NetBeans, a student would select the project’s parent directory for compression into a single ZIP file. It’s also useful for students to submit multiple projects such that needed frameworks don’t have to be linked but instead are included as part of the submission. This helps TAs as well.
Currently, selected student assignments from our previous process are zipped up by Blackboard into a single file named and located according to the user’s request. What happens to this file is where our program will come in. Currently, the Teaching Assistants would perform the following tasks.
Open a File Explorer type application
Navigate to the directory where the submissions were saved. For example, a TA may save the Blackboard-generated ZIP file as HW1.zip and save it into a directory called /blackboard/.
Right click on the file named HW1.zip. This should open a list of choices in a popup menu including something like Extract to HW1 directory.
Select the Extract to HW1 directory choice. This will unzip the single submission file into that directory, which will include all the student submissions and a text file for each student. Note that the student submission files will have long, hard to read and deal with names that will include the student homework number, the student Net ID, and a timestamp. This is one thing that’s not so convenient for us. Super long paths like this can present problems so some graders who prefer to abbreviate these files to just the NetID. Note that students can submit all sorts of files, including PDFs or DOCs, like for writing assignments. We’ll want to handle those cases as well, meaning cases where the submission is NOT a Zip file. But we’ll have to be careful regarding how to deal with assignments where students are required to submit IDE projects, which must be as a single ZIP. One thing to note is that our project will be developed for the Java platform, which provides an easy to use library for dealing with ZIP files, but not RAR files. So students must be discouraged from submitting RAR files, and such submissions will be regarded as invalid as our program won’t be able to extract data from them.
Navigate to the HW1 directory that was just unzipped.
Right-click on the student submission to extract. A popup menu should open up with an option to Extract to X directory, where X would be the name of the zip file.
Select Extract to X directory, which should unzip the student submission. Note that a TA has to do this separately for each student. This is very time consuming. Imagine a TA grading 100 students having to do this 100 times.
Product perspective
Note that this process is just for grading. It doesn’t even address plagiarism checks. Our program will aim to make all of these extraction and code organization steps much more convenient for the Teaching
Assistant such that they can get on with the grading process more quickly.
System Interfaces
The Code Check application will be a workspace-type application in the fact that we can create new “code checks”, save work regarding what’s been extracted, and load an extraction that’s already been saved. Understand, however, that the program uses a series of linked screens and corresponding operations that will allow the user to transition student work from a single ZIP file saved from Blackboard into work that can be graded or checked for plagiarism.
Step 1: Select HW1.zip file
- input: ZIP files of student ZIP files downloaded from Blackboard
- input directory: work/assignment/blackboard
- function: Extract
- output: contents of downloaded ZIP files (student ZIP files)
- output directory: work/assignment/submissions
Step 2: Rename Student submission files
- input: student submission ZIP files
- input directory: work/assignment/submissions
- function: Rename
- output: renamed student submission files (ZIP files)
- output directory: work/assignment/submissions
Step 3: Unzip Student submission files
- input: student submission ZIP files
- input directory: work/assignment/submissions
- function: Unzip
- output: unzipped contents, one for each student
- output directory: work/assignment/projects/NetID (one directory for each student)
Step 4: Extract Student Source Code
- input: student project directories of files
- input directory: work/assignment/projects/NetID
- function: Extract Source Code
- output: directories of source code only
- output directory: work/assignment/code/NetID (one directory for each student)
Step 5: Code Check
- input: directories of source code
- input directory: work/assignment/code/NetID
- function: Perform Code Check
- output: URL that contains a visual description of the Code Check results
Tips
Hardware Interfaces
The application should be runnable on any platform that supports Java, but would require a keyboard and mouse.
Software Interfaces
Code Check will be developed using the Java language. Note that since it is a traditional workspace-type application, it may be best to use the Desktop Java Framework.
Communications Interfaces
Note that this editing application will operate locally but an Internet connection will be required to perform the Code Check plagiarism submission and to check results.
Memory Constraints
The application is dependent upon student submissions. If those are gigantically large it could affect product performance.
Operations
Note that grading would be done using the IDE used for creating the ZIPped up project files.
Site Adaptation Requirements
N/A
Product functions
N/A.
User characteristics
The editor should aim to be as user friendly as possible, using the principles of foolproof design as well as sound UI design principles.
Constraints
N/A
Assumptions and dependencies
N/A
Apportioning of the Requirements
N/A
Specific requirements
A Code Check has five steps, as indicated by the previously described five screens. Following are visual depictions of these screens. Note that all operations requiring file extraction and copying will employ progress bars to show the user how far along work has progressed.
External interfaces
The following wireframe mockups provide a look at the types of controls and layout to be used for the User Interface. Note that the User Interface designer should select the appropriate icons for all buttons and should carefully choose color and font combinations that provide good contrast and attract the eye. Note that the User Interface designer should also consider additional dialogs for providing adequate feedback to the user as well as for navigation through the file system to select files and directories as part of certain use cases.
Functions
One of the important things to consider in our application is providing the appropriate feedback to the user. Users need feedback to enjoy their experience. This is typically done with visual cues like dialog boxes.
Performance requirements
N/A
Logical database requirements
N/A
Design constraints
JavaFX will be used because it effectively leverages each system’s available rendering technologies and provides platform independence for personal computers.
Software system attributes
As professionals, all members of this project must take this project seriously. We are dedicated to producing robust software that exceeds the expectations of our customers. In order to achieve this level of quality, we should build a product with the following properties in mind:
Reliability
The program should be carefully planned, constructed and tested such that it behaves flawlessly for the end user. Bugs, including rendering problems, are unacceptable. In order to minimize these problems, all software will be carefully designed using UML diagrams and a Design to Test approach should be used for the Implementation Stage.
Availability
Customers may download and install the application for free.
Security
All security mechanisms will be addressed by future revisions
Extensibility
It is possible that more JavaScript/JSON widgets might be added to course sites in the future, so by providing an additional tab with suitable data and making changes to exporting methods, this should be considered during this deaign.
Portability
To start with, the app will target desktop Java applications.
Maintainability
Update mechanisms will be addressed by future revisions.
Organizing the specific requirements
Note that the application is simple enough that we need not worry about using an alternative arrangement of the content of this document. The specific requirements for this application already fit neatly into the sections listed in the IEEE’s recommended SRS format.
Additional comments
It is important to keep in mind that the plagiarism check results will be provided via a URL. The work done by that program is proprietary and not performed by this application.
Supporting Information
Note that this document should serve as a reference for the designers and coders in the future stages of the development process, so we’ll provide a table of contents to help quickly find important sections.
Table of contents
- Introduction
- Purpose
- Scope
- Definitions, acronyms, and abbreviations
- References
- Overview
- Overall description
- Product perspective
- Product functions
- User characteristics
- Constraints
- Assumptions and dependencies
- Specific requirements
- External interfaces
- Functions
- Performance requirements
- Logical database requirements
- Design constraints
- Software system attributes
- Organizing the specific requirements
- Additional comments
- Supporting Information
- Table of contents
- Appendixes
Appendixes
N/A