Mathematics Placement System 2.0

Software Design Description

Dr. Dennis S. Martin

March 3, 1999

Submitted in partial fulfillment

Of the requirements of a

Sabbatical Project

<<Annotated Edition>>

<<Please note that all comments in double diamond brackets (such as these) are comments about the paper and are not part of the paper. They are intended to help clarify how this report meets the requirements of the documentation standards. Also note that double-spacing has been suppressed for better viewing on the screen.

<< The project described here is an actual project produced by the author in the time frame stated in the proposal. These documents are faithful to the spirit of the project but were created to help clarify the application of the standards that they accompany. They have been edited to enhance their usefulness as models for documentation at the expense of being useful documents for the project. In fact, this set of documents does not fully or accurately describe the project. Several critical features of that project protecting security and any data that might identify individual students have been changed. In addition, the project has evolved since it was created and several of the items discussed here no longer apply.

<<The reader is further warned that the author takes the stipulation Fall 2001 Version very seriously. This is always a work in progress. As problems are pointed out in either these documents or the standards that they exemplify, changes will be made immediately and, possibly, without notice. On the other hand, this is an opportunity for students to edit a faculty work to improve it. Turnabout is fair play in this instance! Comments such as “I read the section on … and it still does not make sense.” are actually useful at this stage. >>

Index to Page:

1.5 Overview of Document 4

2. Deployment Diagram.. 4

3. Architectural Design. 5

3.1. Academic Mainframe Level Architecture. 5

Name: Remote File System Interface. 5

Name: File Utility. 6

3.2. Mathematics Placement System Level Architecture. 7

Name: Local File System.. 14

4. Data Structure Design. 15

Placement Database. 16

Archive Database. 19

5. Use Case Realizations. 19

Use Case: Archive. 20

Use Case: Initialize. 20

Use Case: Modify Persistent Data. 21

Use Case: Load CRN Data. 21

Use Case: Load Student Data. 22

Use Case: Load Test Data. 23

Use Case: Enter Student 24

Use Case: Enter Test Data. 24

Use Case: Create Student List 25

Use Case: Report Session. 26

Use Case: Create Custom Report 26

Use Case: Create Master Report 26

Use Case: Create Upload List 26

6. User Interface Design. 26

7. Help System Design. 30

Index. 30

Table of Figures

Figure 1 - Deployment Diagram.. 4

Figure 2 - Academic Mainframe Level Architecture. 5

Figure 3 - MPS Architectural Design. 7

1. Introduction

1.1. Purpose

This document contains the complete design description of the Mathematics Placement System, Version 2.0. This includes the architectural features of the system down through details of what operations each code module will perform and the database layout. It also shows how the use cases promised in the SRS will be implemented in the system using this design.

The primary audience of this document is the software developer. A secondary audience consists of students and faculty wishing to see a model for software development documentation.

<<Note the purpose of this document and the intended audiences. Normally, this document would have a single audience. >>

1.2. Scope

This Software Design Document provides a complete description of the design of the Mathematics Placement System, Version 2 (MPS), developed for the University of Scranton. The dominant design methodology is an object-oriented design using a Visual interface to a database management system.

This document describes two levels of the system. The larger system accepts data files from the University database and a test scanner. These are stored on the academic mainframe (Tiger). The test scanner files are modified on the academic mainframe. The MPS Administrator uses ftp to move these files to the PC on which the program and its database reside. The core system then processes these files and store report files on this PC. After report files are produced, the larger system is used to print the files locally or remotely. Remote printing requires a program on the academic mainframe for formatting the reports.

The core MPS architecture is a standard database design. The Administrator accesses this system through forms. These forms interact with code modules to provide the bulk of the services. In turn these code modules interact with the underlying database.

The Administrator will work on the larger system using standard utilities such as telnet and ftp. S/he will use a word processor for local printing.

The Administrator will do most normal maintenance of the persistent data in the database using database utilities. These include adding new faculty members, adding new mathematics courses, and adding new academic majors and their recommendation schemes.

<< We have stated the dominant design methodology, a brief overview of the architecture of the product and the external systems with which this system must interface. >>

1.3. Glossary

Administrator	Faculty member in charge of Mathematics Placement System
Archive Database	Students from past years stored for reference
CRN	Course Registration Number — primary key used by the University to identify courses; unique within one academic year
CRN Info File	File with information about mathematics sections offered
Current Database	Active students (incoming freshman)
Current Students	Current grouping of students in one session.
DAT	Diagnostic Algebra Test – used for placement into General Education Quantitative Reasoning courses
Functional Requirements	A detailed list of all the services provided by the system. Information about what the system does not do is also in this category.
Local File System	Files available on PC on which the Placement System resides
Major	Code for academic major/program
MPS	Mathematics Placement System — this system
Non-Functional Requirements	Constraints on product (e.g., performance or memory restrictions) and process (e.g., development paradigm or documentation standards)
Persistent Data	Certain tables retained from one year to another; can be modified; see Supplemental Requirements
Placement System	Mathematics Placement System or MPS
PT	Placement Test – used for placement into the calculus sequence
Recommendation	Analysis of student test result with reference to student's academic major with suggested course placement
Remote File System	Files available on the academic mainframe
Session	Group of students tested at one time
Student	Information about a student including all tests taken
Student Data File	File with information about incoming freshmen from University Database
Student ID	Primary key identifying student
Student Name	Field in last name, first name order
System Databases	Contain all data for current year and archives of previous years
Test	Consists of version number and answer key; at least two versions must be supported; versions are stable during one administration year
Test Data File	File with information from test scan sheets from one session
Test Results	Score on test and all subtests and/or indicated areas of weakness
Transient Data	Information for one academic year

<<This contains all the technical words that are used in this document. >>

1.4. References

Martin, Dennis S. Mathematics Placement System 2.0, Software Requirements Specification. University of Scranton, 1999.
Martin, Dennis S. Mathematics Placement System 2.0, Test Design. University of Scranton, 1999.

1.5 Overview of Document

The following chapters and their contents are

Chapter 2 is a Deployment Diagram that shows the physical nodes on which the system resides. This allows a clear explanation of where each design entity will reside. No design unit may straddle two nodes but must have components on each, which collaborate to accomplish the service.
Chapter 3 is the Architectural Design. This is the heart of the document. It specifies the design entities that collaborate to perform the functionality of the system. Each of these entities has an Abstract Specification and an Interface that expresses the services that it provides to the rest of the system. In turn each design entity is expanded into a set of lower-level design units that collaborate to perform its services.
Chapter 4 is the basic Data Structure Design, which for this project is a relational database. While it is separated out here for emphasis, it is really the lowest level of the Architectural Design.
Chapter 5 exhibits the Use Case Realizations. The implementation of each use case identified in the SRS is shown using the services provided by the design objects.
<<Note that this is a single user system so there is no Real Time Design needed. That is, there are no timing constraints between users that have to be described and designed. >>
Chapter 6 is on User Interface Design and discusses the methodology chosen, why it was chosen and why it is expected to be effective.
Chapter 7 describes the structure of the Help System.

<<Note that this is not a Table of Contents but a “guide to better reading.” >>

2. Deployment Diagram

The deployment shows the physical layout of the system. Each component of the system must lie on exactly one node. An operation that spans two nodes must have communicating components on each node to implement it.

Figure 1 - Deployment Diagram

The University Database and the Test Scanner are external to this system.

The Academic Mainframe contains two code modules needed by the system.

The Administrator’s PC contains data and report files, the code file, and the database for the MPS.

<<Diagrams are always accompanied by explanatory text. We have used the Create/Deployment Diagram option in ArgoUML for this diagram. >>

3. Architectural Design

Not pictured here are the off-line request from the Administrator to the University Database to send CRN and student files to the Academic Mainframe (Remote File System). Not pictured is the transferal of test scan files to the Academic Mainframe (Remote File System). It is assumed that these files are already present in the Remote File System. It is also assumed that the Print command to the system printer is available in the Remote File System. It is anticipated that the usage of the Remote File System will be removed from this project at some time in the future.

3.1. Academic Mainframe Level Architecture

Figure 2 - Academic Mainframe Level Architecture

<<This is a very unique feature for this project. You normally would start with the next section as the top-level architectural diagram. Remember that each project will have unique features that require you to reinterpret the rules. >>

Name: Remote File System Interface

Type: System with executable code modules

Description:

The Administrator will log into the Academic Mainframe to execute each of these file operations.

Operations:

Modify

No arguments (opens a file whose name is provided by the user)

No return value (writes a file)

Pre-condition: Test scan data file is in a file on Academic mainframe in a predefined format, which, if transferred directly to the local file system, is corrupted.

Post-condition: The input file has been rewritten to and stored in a standard text file.

Exception: If input file name is wrong, the program crashes.

Flow of Events:

The Administrator runs the program Modify on the Academic mainframe.
The System requests the name of the input file.
The Administrator provides the name of file to be converted.
The System opens the file for reading.
The System creates a name for the output file (by appending “_MOD” to the input file name) and opens this file for writing.
The System reads four lines of the input file.
The System writes two lines of the output file (see SRS file formats for details).
The System repeats steps 6 and 7 until the end of the input file.
The System closes both files.
The System reports the name of the output file to the Administrator.

<<Is this enough information so that you could write this program? If not, the description is insufficient. >>

See also Code Module: Modify.PAS <<Explicit cross-reference into code >>

See also Test Design, Unit Test: Modify <<Explicit cross-reference into the Test Design document >>

<<These cross-references are added as they are available. It is a good idea to leave a placeholder until the reference is available. >>

Expand

No arguments (opens a file whose name is provided by the user)

No return value (writes a file)

Pre-condition: Report file is on Academic mainframe with the text “<FF>” where a form feed is needed.

Post-condition: The input file has been rewritten to a file with form feeds replacing all lines starting with “<FF>”.

Exception: If input file name is wrong, program crashes.

Flow of Events:

1. The Administrator runs the program Expand on the Academic mainframe.

2. The System requests the name of the input file.

3. The Administrator provides the name of file to be converted.

4. The System opens the file for reading.

5. The System creates a name for the output file (by replacing extension by “.NEW”) and opens the file for writing.

6. The System reads one line of the input file.

7. If the first four characters are “<FF>” then the System writes a carriage return to the output file, otherwise it writes the line from the input file.

8. The System repeats steps 6 and 7 until the end of the input file.

9. The System closes both files.

10. The System reports the name of the output file to the Administrator.

<<Again, is this enough detail to write the program? >>

Name: File Utility

Type: system software

Description:

This provides the standard ftp program

Operations:

ftp

No arguments

No return value

Pre-condition: File is in resource account.

Post-condition: Copy of file is in object account.

Exception: none

Flow of Events:

The Administrator choose ftp from the operating system of his/her PC and follows the instructions.

This is standard system software and has not been rewritten for this project.

No test in Test design document. <<Be complete >>

Name: Local File System

(see next section)

3.2. Mathematics Placement System Level Architecture

<<This section is intentionally not complete. The system is very complex and we are including enough detail to show how the document can be written but we leave out most of the large report generator for convenience. Missing parts are indicated. >>

All tables referred to in this section can be found in Data Structure Design section below.

Figure 3 - MPS Architectural Design

<<I like to have the stick figures on class diagrams but ArgoUML does not support this directly. I have copied the stick figures from a use case and I have added their connecting lines with the drawing tool. This diagram must form the basis of the collaboration or sequence diagrams in the user case realizations. >>

There are four main subsystems to the architectural design.

The Initializer subsystem is used whenever the system opens or performs a major operation.

The Archiver subsystem is used at the start of a testing year to store the previous year’s data.

The LoadMgr subsystem loads all data into the MPS whether from files or manually.

The ReportMgr subsystem produces all reports but one.

Name: MainMenu

Type: form frmMain.frm

Description: This is the interface for the Administrator. It initializes the system when loading and allows menu selection of the desired activity.

Operations:

Load (implicit)

No arguments.

No return value.

Pre-condition: None.

Post-condition: System is ready for use.

Exception: None.

Flow of Events:

1. The Administrator run the executable file.

2. The Splash screen appears on the screen for several seconds.

3. The form calls the operation Initialize in the Initializer package.

4. The system awaits a menu choice or an exit command.

See also Test Design, Unit Test: Load Main Menu

Select (implicit)

No arguments.

No return value.

Pre-condition: The system is initialized.

Post-condition: Control returns to main menu when called operation is finished.

Exception: None.

Flow of Events:

1. User selects a pull-down menu.

2. User selects a menu choice.

3. System branches to appropriate operation.

See also Test Design, Unit Test: Select from Main Menu

Name: Initializer

Type: Code Module modVariables.bas <<This is the explicit cross-reference into code. >>

<<Code module names are added as the modules are created in implementation. >>

Description: Initializes MPS for each use and reads global data into variables.

Operations:

Initialize <<Use name exactly as found in code module. If the language is case-sensitive, this name must also be. >>

This module is used to initialize the MPS for each usage.

No arguments.

No return value.

Pre-condition: MPS is initialized for some academic year.

Post-condition: The System is ready to be used.

Exception:

Flow of Events:

1. Values are transferred from database to global variables. Basically all values in Default and SysDef tables are moved into variables for easier access.

2. Call Update operation.

See also Test Design, Unit Test: Initialize <<These names must be unique enough to correctly identify the specific test plan in the test design document. >>

Update

No arguments.

No return value.

Pre-condition: System is initialized.

Post-condition: Menu choices are properly enabled. Screen message is accurate.

Exception: None.

Flow of Events:

1. If AcadYear = 0, disable all menu choices except New, Help and Exit, else

2. if CRNTable empty, disable all menu choices except Load CRN, Help and Exit, else

3. if NumberStu = 0, disable all menu choices except Load CRN, Load Student, Help and Exit, else enable menu choices.

4. Display number of students in database to screen.

Load Package

Name: LoadMgr

Type: Code Module modReadData.bas

Description: This module loads the various data files into the MPS. See SRS for external file specifications.

Operations:

ReadCRNFile

No arguments.

No return value.

Pre-condition: System is initialized

Post-condition: MPS has at least one CRN data set.

Exception: If the file has the wrong format, the user will be warned and allow user to stop the operation.

Flow of Events:

1. Prompt for file name using ActiveX form and store name.

2. Open file. Read first record.

3. Close file.

4. Check for correct format (nine digits followed by a non-upper case letter).

5. If format wrong, notify user by a form and allow user to stop operation.

6. Open file.

7. loop until EOF

1. Read data line (CRN, course number, section number, faculty name)

2. Check match for CRN in CRNTable

3. If no match on CRN, check for match on course number in Course table.

4. If no match for course number, replace with 999 and report to screen.

5. (If no match on CRN,) add record to CRN Table, else update record

6. end loop

7. Close file.

8. Call Update in Initializer package.

9. Report number of unmatched course numbers to user.

See also Test Design, Unit Test: Read CRN File

ReadDatafile

No arguments.

No return value.

Pre-condition: At least one CRN data set is in the MPS.

Post-condition: At least one student data set is in the MPS.

Exception: If the file has the wrong format, the user will be warned and allowed to stop the operation.

Flow of Events:

1. Prompt for file name using ActiveX form and store name.

2. Open file. Read first record.

3. Close file.

4. Check for correct format (nine digits followed by an upper case letter).

5. If format wrong, notify user by a form and allow user to stop operation.

6. Open file.

7. loop until EOF

8. Read data line (name, ID, CRN, major, school)

9. Check major for match in Major table, if no match, change to default for unknown.

10. Check CRN for match in CRNTable, if no match, change to default for unknown.

11. Check for match on student ID in Students table, if no match, count and add new record, else update record.

12. end loop

13. Close file.

14. NumberStu field in SysDef table is updated.

15. Call Update in Initializer package.

16. Report unknown CRN and major data to user with a form.

See also Test Design, Unit Test: Read Student Data File

ReadTestFile

No arguments.

No return value.

Pre-condition: At least one student data set is in MPS.

Post-condition: At least one student data set is updated with test information.

Exception: If the file has the wrong format, the user will be warned and allowed to stop the operation.

Flow of Events:

1. Prompt for file name using ActiveX form and store file name.

2. Check for correct format for file name (“_MOD” at end).

3. If format wrong, notify user by a form and allow user to stop operation.

4. Initialize counts for tests graded, DAT tests graded and PT tests graded

5. Create alphabetical list of all student names in Students table.

6. Load test versions and answer keys from TestTable.

7. Place form FindStu on screen with list box with names of students processed and recovery information. (See details below.)

8. Open file.

9. loop until EOF

10. Read two data lines (name, ID, test version, test data)

11. Check ID for match in Students table.

12. if not matched, switch control to screen form FindStu (recovery subsystem).

13. Check student record in Students table.

14. If no entry for this test version, update the record by adding the (new) test version and data, else update the record by replacing the current information.

15. Add student name to list of processed students on screen form.

16. end loop

17. Close file.

18. If any student not identified, add to ProbTable.

19. Update NumberStu and Probs fields in Sysdef table.

20. Call Update in Initializer package.

21. Loop through database of all students in this testing session who have only one test version recorded to see if either (a) the wrong test version as taken for that major or (b) the test score indicates that the other version should be taken. List all such students to a form on the screen and to a text file with the test version that each should take.

See also Test Design, Unit Test: Read Test Data File

EnterStudent

No arguments.

No return value.

Pre-condition: System is initialized. At least one CRN is in system.

Post-condition: New student record is added to the Placement database.

Exception: If ID matches one already in database, operation is stopped.

Flow of Events:

1. Form frmNewStu is placed on screen.

2. User enters student ID. If ID is in database, operation stops.

3. User enters Name, Major, School, and CRN. Default “unknown” values available for all but Name.

4. User chooses enter or cancel.

See also Test Design, Unit Test: Enter Student

EnterTestData

No arguments.

No return value.

Pre-condition: System is initialized. At least one CRN is in system.

Post-condition: Test data for student has been added to student record.

Exception: None.

Flow of Events:

1. Form frmTestData is placed on screen.

2. User enters student ID.

3. if ID is not in database, EnterStudent is called.

4. User enters test data and test version, when prompted.

5. User chooses enter or cancel.

See also Test Design, Unit Test: Enter Test Data

Name: FindStu

Type: form frmFindStu.frm

Description: Used to find a student from a test scan sheet whose ID number does not match any in the database. See example screen in User Interface section of this document.

Operation:

No arguments.

No return value.

Pre-condition: LoadTestData is in progress and an ID cannot be matched. A list of students already processed in order is on the screen.

Post-condition: Student is identified or a false identity is created.

Exception: None.

Flow of Events:

1. Display ID and student name from data file to form

2. Fill a list box with “close” ID numbers, that is, compare each ID in the Student Table to see if it matches at least as many digits as the preset number. If so place the ID and the student name in the list box.

3. The form has a combo box with an alphabetical list of student names. As the characters are added to the text box part of the combo box, the list scrolls to all names lexigraphically greater than or equal to the characters entered.

4. The form has a text box on the screen to enter a corrected ID number.

5. The form has a button to add a New Student. The NewStu form appears to accept the data and create a record.

6. The form has a button to create a “problem” entry (create a student record with a fake ID; record information in problem student list).

7. The user selects a student through one of these options.

8. This ID is returned to the ReadTestData operation.

See also Test Design, Unit Test: Find Student

Report Package

Name: ReportMgr

Type: Code Module

<< The code for this section had not been written when this version of the SDD was written. Therefore, the code section may not yet have a name. If it had a tentative name, we would have put it in. This is where this document starts to be incomplete. Although we are simulating this code module not having been started, the design at this point should be fully expanded, not abbreviated as it is here. This document better represents an earlier time before the SDD is ready to be submitted. As a partial document, it represents the approach of iterative development with always the possibility that sections may have to be reworked for compatibility with newer sections not yet written. While, ideally, design decisions are permanent, we cannot predict when an earlier decision causes unacceptable risk later on. Developing a real world project is never as simple as the examples in the text! >>

Description: This module produces all of the reports generated by the MPS except the “Should Take Other Test” report generated during LoadTestData.

A significant part of the complexity of this module is that the user wanted all printing to be done on the remote file system. The printer on the remote file system was well understood for printing programs and text files but had not been used extensively for printing formatted reports. When the original system was developed in 1988, all headers and footers including pagination and page length were controlled directly by the Ada code. While the remote file system printer in 1999 supported various mark-up languages for formatting text documents, these were not incorporated in the project to reduce risk. That is, the system developer was not familiar with them on the machine and had too short a deadline before the system had to be in use to learn them. During beta testing, the users decided that all but the voluminous last report would be better printed locally. Currently, the text files are brought into a word processor to be printed. The next version of the system will do most of the printing from Access.

Operations:

CreateStudentList

No arguments.

No return value.

Pre-condition: At least one student is in the database.

Post-condition: An alphabetical list of students with ID numbers is generated and stored in a pre-named file.

Exception: None.

Flow of Events:

1. The System accesses the Students table in the database.

2. The table is arranged alphabetically (by the student Name field).

3. An output file is opened.

4. The System iterates through the table copying each student name and ID number to a line in a file.

5. The file is closed.

6. The user is notified of the file name.

Note: Since only the latest version of this list should be available, the file name is always the same so that new lists will replace old ones in storage.

See also Test Design, Unit Test: Create Student List

ReportSession

No arguments.

No return value.

Pre-condition: At least one student has been tested in the session.

Post-condition: Several reports are created and stored in uniquely named files.

Exception: None.

Flow of Events:

1. The System accesses the Students table in the database.

2. The table is arranged alphabetically (by the student name field).

3. Several output files are opened <<start of missing details >>

4. The System iterates through the table as needed, identifying students whose TestSession field matches the CurrStu field in the SysDef table. Each such student is graded, the recommendation based on major and test results is calculated and written to appropriate files. <<This represents many missing steps. >>

5. The output files are closed.

6. The CurrStu field in the SysDef table is incremented.

7. The user is notified that the process is complete. (One file has a list of all output files produced.)

Note: For all reports, other than the Student List above, produced by the MPS, each report needs to be available for reference. Therefore, each report has a name that is unique during the academic year.

See also Test Design, Unit Test: Report Session

CreateCustomReport

No arguments.

No return value.

Pre-condition: At least one student is in the database.

Post-condition: An output file is created with the requested information.

Exception: None.

Flow of Events:

1. The System places the form frmFilter on the screen. See example form in User Interface section.

2. The user selects the options that s/he wishes for the report.

3. The System accesses the Students table in the database.

4. The table is arranged alphabetically (by student name field).

5. An output file with a unique name is created.

6. The System iterates through the table, identifying students who meet the filter criteria, processing their records as appropriate and writing results to the output file.

7. The output file is closed.

8. The user is informed of the output file name.

See also Test Design, Unit Test: Create Custom Report

CreateMasterReport

No arguments.

No return value.

Pre-condition: Normally run at the end of the testing season just before the fall semester.

Post-condition: Many standard reports are produced.

Exception: None.

Flow of Events:

1. Just like the above.

See also Test Design, Unit Test: Create Master Report

CreateUploadList

No arguments.

No return value.

Pre-condition: CreateMasterReports has been run.

Post-condition: One text file is produced.

Exception: None.

Flow of Events:

1. Just like the above but much simpler.

See also Test Design, Unit Test: Create Upload List

Name: Archiver

Type: Code Module modArchive.bas

Description: Removes and transfers graded students from active database to a backup database. Students who have not been tested are just removed.

Operations:

Store

No arguments.

No return value.

Pre-condition: At least one student is in Placement database.

Post-condition: All graded students have been transferred to Archive database. Placement database has no students.

Exception: If no students in Placement database, user is notified and operations stops.

Flow of Events:

1. If number of entries in Students table in Placement database is zero, user is notified and operation stops.

2. Year value is moved from global variable and added to Year table in Archive database.

3. loop from first to last record of Student table in Placement database:

4. Move current record from Student database into memory.

5. If Test1 field is not zero, add student record (student name, id, year, test1, answer1, test2, answer2) to archive database.

6. Delete student record from Placement database.

7. end loop

8. Empty CRNTable in Placement database.

9. Empty ProbTable in Placement database.

10. Set CurrYear and Probs fields in Placement database to 0..

11. Call Update operation in Initializer.

Name: Local File System

Type: Computer System with executable code modules

Description:

The user will use the operating system utilities for file manipulation.

Operations:

Select

No arguments.

Return value. File name

Pre-condition: None.

Post-condition: None.

Exception: No file selected.

Flow of Events:

The system presents an ActiveX form for file browsing and selecting. This operation interfaces with the File Manager. This form returns the name of the file to the program.

This is standard system software so there is no test in test design document.

Open

No arguments.

No return value.

Pre-condition: File is selected or a name is selected.

Post-condition: File is opened for reading or created and opened for writing.

Exception: None

Flow of Events:

Called from within system. This operation interfaces with the File Manager.

This is standard system software so there is no test in test design document.

Close

No arguments.

No return value.

Pre-condition: None.

Post-condition: None.

Exception: None.

Flow of Events:

Called from within system. This operation interfaces with the File Manager.

This is standard system software so there is no test in test design document.

4. Data Structure Design

There are two databases at the foundation of this system. The active database is called the Placement Database and the inactive database is called the Archive Database. The Placement database handles all the current students. The Archive database contains records from previous years. Currently the Archive database is used only for storage. If, at some future time, a longitudinal study of the effectiveness of the system is desired, the data will be available.

These databases have all the functionality usually associated with relational databases and these operations are used extensively and implicitly in this document.

Placement Database

The Placement database has twelve tables organized as follows:

Persistent Data:

Courses

DATRecs

Defaults

Majors

PTRecs

Recommendations

Schools

TestTable

Transient Data

CRNTable

ProbTable

Students

SysDef

Courses:

Field	Type	Description
Number	Integer	Course Number
Name	Text	Course Name

This table associates the name of a course with its number, e.g., number 142 is associated with Discrete Structures. Number is the primary key.

DATRecs:

Field	Type	Description
Numb	Integer	Question Number
Topic	Text	Algebra topic

This table allows the student to receive a list of algebra topics that s/he should study. Each missed question causes one topic to print. This table must reflect the question order on the DAT.

Defaults:

Field	Type	Description
NearSSNumb	Integer	Defines a “close” ID number
LevelTop	Integer
DATCuts	Integer
PTCuts	Integer
PgLen	Integer	Length of an output page

This Table establishes defaults that the Administrator may wish to change such as the cut-offs for levels on the tests.

Majors:

Field	Type	Description
Major	Integer	Numeric code for major
MajorName	Text	Name of major
MajorAbbr	Text	Literal code for major
RecType	Text	Code for type of recommendation.

This table allows the system to turn a major code into a full major name. (The University switched from a two-digit numeric code to a literal code as the system was being prepared. The numeric code is no longer used.) The recommendation for a student’s placement depends on the requirements of a student’s major. As several departments could have the same mathematics requirements, we use a code for the recommendation type for a group of departments.

PTRecs

Field	Type	Description
Numb	Integer	Ordinal key
Category	Text	Topic group
Mask	Text	Identifies questions
Minimum	Integer	Pass level
ErrorMsg	Text	If less than minimum
GoodMsg	Text	If minimum or better

The PT is graded in sections with a pass level for each section. This allows custom messages for each section. Sections may overlap. This table must reflect the question order on the test.

Recommendations:

Field	Type	Description
MajorType	Text	RecType from Majors
Level	Integer	Achievement Level (0-3)
ShouldTake	Character	Test version that should have been taken
DATRec	Text	Course recommendation by level
PTRec	Text	Course recommendation by level

This table controls the printing of recommendations based on a student’s type of major and score on each test take.

Schools:

Field	Type	Description
School	Character	Code for school
School Name	Text	Name of School

This table allows printing out the school (college) name rather than the one-character code.

TestTable:

Field	Type	Description
Version	Integer	Version number
Name	Text	Name of Test
NumbQues	Integer	Number of questions on test
AnswerKey	Text	Answer key to test
Abbreviation	Text	Short form of name

This has all the information about the tests. Changes in the tests need to be reflected here.

CRNTable

Field	Type	Description
CRN	Text	Section Designation
FacName	Text	Instructor
Course	Integer	Course Number
Section	Integer	Section Number

This table allows reports to be printed for each section containing the instructor’s name.

ProbTable

Field	Type	Description
TempIDCode	Text	9 character code
Name	Text	From scan sheet
ID	Text	From scan sheet

When a student cannot be identified, a new distinct ID is created for data storage and the fact logged here. It is unlikely that such a student will ever be identified but this preserves the data.

Students:

Field	Type	Description
Name	Text	From University Database
ID	Text	Student ID Number
Major	Text	Major abbreviation
School	Character	School (college) enrolled in
Test1	Integer	Version of test
Answer1	Text	Responses on Test1
Test2	Integer	Version of test
Answer2	Text	Responses on Test2
CRN	Text	Math course, 0000 if none
TestSession	Integer	When tested

This table is the heart of the system. It holds all the information about one student.

SysDef:

Field	Type	Description
CurrYear	Integer	Allows current year to be printed.
CurrStu	Integer	Number of current testing session.
NumberStu	Integer	Number of students currently in database
Probs	Integer	Number of unidentified students
RptNumb	Integer	Number of current report; used to create unique report names.

This is information relevant to the current year but should not be changed by the Administrator.

Relations

The primary key in the Student Table is the student ID number. Although the University will sometimes assign a temporary number to an incoming student until the student obtains a Social Security number, this is usually for a new foreign graduate student but rare for an incoming freshman. For such a student, a manual change of the primary key is the only possible remedy.

The Student Table field Major relates to the MajorAbbr field in the Major Table to allow printing full names of major.

The Student Table field School relates to the School field in the School Table to allow printing of full names of schools.

The Student Table field CRN relates to the CRN field in the CRNTable allowing printing of instructor, course and section information (through the relation between the Course field in CRNTable and the Number field in the Courses Table.

Archive Database

The Archive database has two tables with the fields:

Year:

Field	Type	Description
Data	Integer	Testing year

This field is used to record the year for which information is stored.

Data:

Field	Type	Description
Name	Text	From University Database
ID	Text	Student ID Number
Year	Integer	Year tested
Test1	Integer	Version of test
Answer1	Text	Responses on Test1
Test2	Integer	Version of test
Answer2	Text	Responses on Test2

This stores all relevant information about tested students in the archive.

5. Use Case Realizations

For each use case in the Requirements Specification, there is a use case realization here. That is, the design objects in the above architecture perform a sequence of events realizing each of the operations promised in the SRS. We are using Collaboration Diagrams to show these realizations.

For each use case, we assume that the Administrator has started the program running and that we are at the main menu. Further, we assume that the preconditions on each use case have been met.

<<It is essential that these use case realizations only use relationships and methods, which have been specified in the Architectural Design above. Each diagram was created by starting with the Architectural Diagram above, removing unneeded parts and labeling the sequence of operations. (I also had to go back and add some missing features to the original Architectural Diagram. That is not unusual in design.)

<<Cross-references: The relationship between use case specification and use case realization must be bi-directional (referenced from SRS to here and from here to SRS) and explicit.

<<Cross-references: Each use case realization must be cross-referenced to the use case test in the test design. This relationship between use case specifications and use case test must be bi-directional and explicit. >>

Use Case: Archive

Diagram:

1. Select Archive from File Menu

2. Store()

3. Set pointer to start of Students table in Placement database

4. Read one record

5. If tested, add modified record to Data table in Archive database.

5.1. Repeat 4 and 5 until end of data in Students table.

6. Update ()

See also SRS 3.2. Functional Requirement, Use Case: Archive

Use Case: Initialize

Diagram:

1. Select New from File menu

2. doNew()

3. Modify fields in Placement database.

See also SRS 3.2. Functional Requirement, Use Case: Initialize (System)

See also Test Design Test Case: Initialize

Use Case: Modify Persistent Data

This is done outside of the MPS using Access features directly. Above design entities are not involved except the database.

See also SRS 3.2. Functional Requirement, Use Case: Modify Persistent Data

No Test Design Test Case:

Use Case: Load CRN Data

Diagram:

1. Select Load CRN Data from File menu

2. readCRNFile()

3. Select File

4. Open File

5. Read Record

6. Close File

7. if wrong format, allow user to stop operation.

8. Open File

9. Read Record

10. Check CRNTable for match; if match retrieve record and update else create record

11. Update/Add record

11.1. Repeat 9, 10, 11 until end of file

12. Close File

13. Update()

See also SRS 3.2. Functional Requirement, Use Case: Load CRN Data

See also Test Design Test Case: Load CRN Data

Use Case: Load Student Data

Diagram:

1. Select Load Student Data from File menu

2. readDataFile()

3. Select File

4. Open File

5. Read Record

6. Close File

7. if wrong format, allow user to stop operation.

8. Open File

9. Read Record

10. Check Students table for match; if match retrieve record and update else create record

11. Update/Add record

11.1. Repeat 9, 10, 11 until end of file

12. Close File

13. Update()

See also SRS 3.2. Functional Requirement, Use Case: Load Student Data

See also Test Design Test Case: Load Student Data

Use Case: Load Test Data

Diagram:

1. Select Load Test Data from File menu

2. readTestFile()

3. Select File

4. if name has wrong format, allow user to stop operation.

5. Open File

6. Read Two Records

7. Check Students table for match; if match retrieve record and update

8. if no match, call frnFindStu to find or create student record and update

9. Update/Add record

9.1. Repeat 6, 7, 8 until end of file

10. Close File

11. Update()

See also SRS 3.2. Functional Requirement, Use Case: Load Test Data

See also Test Design Test Case: Load Test Data

Use Case: Enter Student

Diagram:

1. Select Add New Student from Edit menu.

2. addStu()

3. Check Students table for match.

4. If no match, create new record and add to database.

See also SRS 3.2. Functional Requirement, Use Case: Enter Student

See also Test Design Test Case: Enter Student

Use Case: Enter Test Data

Diagram:

1. Select Add Test Grades from Edit menu.

2. addStuTest()

3. Check Students table for match.

4. If no match, call addStu()

5. Update record.

See also SRS 3.2. Functional Requirement, Use Case: Enter Test Data

See also Test Design Test Case: Enter Test Data

Use Case: Create Student List

Diagram:

1. Select Student List from Report menu.

2. createStudentList()

3. Organize Students table alphabetically by Name field.

4. Open File

5. Read Record

6. Write to file.

6.1. Repeat 5 and 6 until end of table.

7. Close File

See also SRS 3.2. Functional Requirement, Use Case: Create Student List

See also Test Design Test Case: Create Student List

Use Case: Report Session

Diagram:

<<Somewhat similar to above. Details missing. >>

See also SRS 3.2. Functional Requirement, Use Case: Report Session

See also Test Design Test Case: Report Session

Use Case: Create Custom Report

Diagram:

<<Somewhat similar to above. Details missing. >>

See also SRS 3.2. Functional Requirement, Use Case: Create Custom Report

See also Test Design Test Case: Create Custom Report

Use Case: Create Master Report

Diagram:

<<Somewhat similar to above. Details missing. >>

See also SRS 3.2. Functional Requirement, Use Case: Create Master Report

See also Test Design Test Case: Create Master Report

Use Case: Create Upload List

Diagram:

<<Somewhat similar to above. Details missing. >>

See also SRS 3.2. Functional Requirement, Use Case: Create Upload List

See also Test Design Test Case: Create Upload List

6. User Interface Design

See also the SRS, which discusses the basic design of the User Interface Design and the reasons why we feel that it will be effective. We supplement that material here with a finer level of detail.

This is frmPanicData used when the format for an input file is wrong. Since the greatest risk to corrupting the system comes from reading an input file incorrectly, the File Okay, Continue option is dangerous. A rare event that may occur when reading a student data file is that the first ID number starts with an “@”. This symbol is used by the University to flag an ID number as temporary.

This is frmFindStu referred to in the LoadMagr package. It is on the screen during the LoadTestFile operation. Normally only the bottom right list is active (lstTested). This records each student successfully processed from the test data file.

When an ID number is not matched, the name and ID from the student sheet is printed at the top in the indicated spaces. Note that either or both could be blank if the student did not fill in the circles on this part of the scan sheet. At the same time, “close” ID numbers are displayed in the upper left box (lstIDTry). The NearSSNumb field in the Defaults table determines “close.” An ID is selected by clicking its entry in this list box. If the scan sheet ID field is blank, nothing can be displayed here. It does, however, handle missing digits and two-character switches well.

The combo box to its right (with the label Select by Name) is always present. It allows scrolling an alphabetical list. This works well if the student has filled in the name bubbles but not the ID number bubbles. Rather than attempt to write code to try to match names, the user is utilized. An ID is selected by clicking an entry in the list box part of the combo box.

As the order of the scan file is the same as the order of the physical test papers possessed by the user, the list box at the lower right (lstTested) can be used to find a student who may not have filled in bubbles for either name nor ID number. The ID number can be typed in the appropriate text box and the Try Me button below it pressed.

Finally, a new student record can be created, either a real record or a temporary record with a created ID.

Note that the user is expected to be windows comfortable as well as knowledgeable about the process being undertaken. This interface was designed with the characteristics of the users—fulltime members of the mathematics faculty—in mind.

This is an example of a report form at the end of a load operation. In addition to numerical information, it contains two important lists for the user. Unknown majors and CRN values will prevent the proper reporting of information. They are displayed here to prompt for correction.

This screen (also displayed in the SRS) shows the type of input screen planned. The ID and Name are text boxes as that information cannot be acquired any other way. The major is selected from a list so that only valid majors can be selected (from Major table in Placement database). Undeclared is an option for an unknown major. A similar list box is used for school. The CRN is not a list box and is defaulted to 00000 (none or unknown) as this will rarely be known. Finally, the option to Save or Quit allows the user full control.

This screen (also displayed in the SRS) shows the various options available for a custom report. Registrar Upload is available here but was also added to the Main Menu for convenience.

This is the Splash screen for this project.

7. Help System Design

The Help System will be very simple in nature. When chosen, it will present a copy of the User Manual.

The access mechanisms will be a Table of Contents/Index with entries linked to the appropriate section.

The Help System is not context sensitive, that is, it does not differ depending on the state of the system.

Index

<<Place here. >>

Branch to the Project Documentation Standards Homepage

Branch to Martin’s Homepage