Electronic Grader v1



System Design Document

May 12, 2001

Team A

Table of Contents

Introduction 3

Introduction:Purpose 3

Introduction:Scope 3

Introduction:References 3

Introduction:Overview 3

Introduction:Constraints 3

System Overview 3

System Architecture 4

System Architecture:Architectural Description 4

System Architecture:Component Decomposition Description 6

System Architecture:Architectural Alternatives 11

System Architecture:Design Rationale 11

Data Design 11

Data Design:Database Description 11

Data Design:Global Data Structures 12

Data Dictionary 13

Human Interface Design 28

Human Interface Design:Overview of the User Interface 28

Human Interface Design:Screen Images 28

Human Interface Design:Screen Objects and Actions 39

Human Interface Design:Report Formats 40

Requirements Matrix 42

Resource Estimates 43

Definitions, Acronyms and Abbreviations 43

1. Introduction

1.1 Purpose

The purpose of this document is to define the design of the Electronic Grader v1.0 system with respect to the needs of both the developers and the customers. In terms of developer needs, the goal of this document is to define the system in such a way as to make the actual coding of the system as efficient as possible. By clearly defining the system, we will define how each customer requirement will be met and provide the developer with sufficient information on how to meet those requirements. With respect to customer needs, the goal of this document will be to define how the system works by completely defining all components, as well as the user interface.

1.2 Scope

The system will act as a grade book in which the user may keep track of student information, assignment information and student grades for the assignments. The system will provide a unique logon for each class file created, and will supply a secure logon method, using basic encryption techniques, for opening a class file. The system will allow for the dynamic addition, deletion and modification of both students and assignments. The system will also allow for the generation of student reports and assignment reports, as well as class reports. Class reports will be able to be saved in either text or html format.

1.3 References

“Requirements Specification Document”, 03/30/2001

1.4 Overview

This document contains the definition of the major components of the Electronic Grader v1.0 system. Psuedocode is provided to assist the developers in their coding efforts. Screenshots of the system prototype are provided to help the customer understand how the system works. Variable definitions and an overview of the system architecture and database are provided for a greater understanding for all parties involved.

1.5 Constraints

For the purpose of this project, the Electronic Grader v1.0 system will be developed using Java, however there is no reason why another language could not be used. That language must provide a method for creating data structures, file input and output and basic user interface capabilities.

2. System Overview

Electronic Grader v1.0 is an automated grades keeping system designed for use by a university-level instructor. The system is designed based on the requirements set forth by Professor Gary Burt (see the “Requirements Specification Document”). Professor Burt and his Teaching Assistant (TA) will use the system. His TA changes each semester and it is possible for Professor Burt to have more that one TA each semester. Electronic Grader v1.0 is designed to have a single, consistent main window from which all actions are spawned. In other words, the system model is that of an event driven system. The system sits idle until the user performs an action. This main window contains a menu bar, a toolbar and a tabbed pane.

Following is a context diagram for the system:

[pic]

figure 2.1

3. System Architecture

3.1 Architectural Description

Our design is based on an event driven model, in which the system sits idle until the user performs an action. Following is a basic diagram that depicts the general model that we have used:

Main Window: The main frame from which the user performs actions.

Action Listeners: Listens for the user to perform an action. Passes control to an event handler when an action occurs.

Event Handlers: Handle actions performed by users. Calls level 1 procedures and check for failures.

Level 1 Procedures: Perform the significant amount of work to be done. Calls level 2 procedures for lesser needs.

Level 2 Procedures: Handles significant, but lesser, work that needs to be done.

Following is a diagram of the relationships between system components:

[pic]

figure 3.6

3.2 Component Decomposition Description

Following is a data flow diagram, depicting the flow of data and decision making for the system:

[pic]

figure 3.1

[pic]

figure 3.2

Following are block diagrams that decompose the procedural nature of the system. Event handlers are invoked by user actions. Event handlers call Level 1 procedures and Level 1 procedures call Level 2 procedures. In few instances, Level 1 procedures are called by other Level 1 procedures. In these cases, a dashed box represents the procedure.

Following are the event handlers:

[pic]

figure 3.3

Following are the Level 1 procedures:

[pic]

figure 3.4

Following are the Level 2 procedures:

[pic]

figure 3.5

3.3 Architectural Alternatives

Our constraints limit us to Java, due to lack of GUI programming experience with any other language. Our team has little experience with using Java. Therefore, we have made an effort to decrease the learning curve by not implementing possible alternatives, such as using an actual SQL database to hold the data, or taking an object-oriented approach.

3.4 Design Rationale

The system has a functional design in which procedures are invoked when the user performs an action within the main window (such as clicking a button). Many classes are used, but not in a way which facilitates an object-oriented design. For example, each dialog box is a class, including the main window. However, the classes are used within procedures and not by other objects. Another example is that of the student and assignment records. They are both classes, but neither performas a single operation on the other. Instead, an Assignment array is maintained in parallel with the array of grade values (of class double) in each Student.

4. Data Design

Our data design is based on the idea that students and assignments are treated as separate entities. An array of assignment records is maintained in parallel with an array of double values that is maintained within each student record. These double arrays represent the student's respective grades for the assignments that are kept in parallel.

4.1 Database Description

The data for a class is saved in an ASCII text file which has the following format:

--begin file--

--end file--

The file components are defined as follows:

: a string where each character's ASCII value is three more than the unencrypted characters's value, represents the encrypted version of the username for the class file

: a string where each character's ASCII value is three more than the unencrypted characters's value, represents the encrypted version of the password for the class file

: a string whose value is "--Grade Scale--"

: a double value, value represents the lowest percentage possible to recieve an A in the class or on an assignment

: a double value, value represents the lowest percentage possible to recieve a B in the class or on an assignment

: a double value, value represents the lowest percentage possible to recieve a C in the class or on an assignment

: a double value, value represents the lowest percentage possible to recieve a D in the class or on an assignment

: a string whose value is "--Assignments--"

: an integer value, represents the number of assignment records below

: a number of assignment records equal to , assignment records have the following format:

: a string, value is unique, represents the title of the assignment

: a string, represents any notes the professor has about the assignment

: a double, represents the total point value of the assignment

: a string with the value ";"

: a string whose value is "--Students--"

: an integer value, represents the number of student records below

: a number of student records equal to ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download