代写一个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