附录B 外文原文

Exam Generator

Abstract

The UW-La Crosse Exam Generator is an online web application that was created to aid faculty members of educational institutions with creating and maintaining exams. With the Exam Generator faculty members can create and maintain a repository of questions. Questions within the system can be used by faculty members to manually or automatically generate exams. The Exam Generator also provides students of these education institutions the opportunity to prepare for a course by taking online practice exams using exams and questions that have been shared with the student.This manuscript describes the development of the UW-La Crosse Exam Generator as well as the challenges and issues that arose during its development.

1. Background Information

Each year teachers and faculty members at education institutions across the world are searching for ways to properly evaluate their students understanding of course content. A proven method for doing this is to test a studentrsquo;s knowledge through the use of multiple choice quizzes or exams. The use of multiple choice exams as a way of evaluating knowledge comes with the risk of a student cheating. This certainly becomes the case when there is a high volume of students taking the same exam in one area. This scenario creates the possibility of a student looking at a neighboring studentrsquo;s exam sheet to copy answers.

One popular method for discouraging cheating on an examination is to create multiple versions and distribute them so students sitting near each other complete different exam forms. Multiple exam versions makes it difficult for students to copy answers but puts strain on the faculty members since multiple versions of the same exam must be created and graded.

The Exam Generator is an application that has been created to aid faculty members in creating exams as well as to aid students in preparing for exams. The Exam Generator provides the tools for a faculty member to create and categorize questions. Questions created with the system can then be included in exams. Exams can be randomized and printed, along with their answer sheets. This functionality allows faculty members to focus on the content of the exam instead of the layout. Exams can then be shared with other faculty members or with students. Students have the ability to log into the application and take a shared exam.

2. Life cycle model

Many development models exist for developing software, each containing their own advantages and disadvantages. The development model chosen for the Exam Generator was an iterative development model. A synopsis of this model is described below.

The iterative development model defines a process of developing an application in a cyclical fashion. Such an engineering cycle starts with the developer gathering a subset of the user requirements from the customer. The requirement subset is then designed, coded, and tested. After testing is complete for an iteration, the developer starts the next iteration. This process continues until the project has been fully developed. Following this approach allows the developer to spot potential design and coding weaknesses earlier.

If the application being developed is GUI intensive, the iterative development model may be extended to include a demo. Within the demo, a prototype of the application is shown to the customer. Providing a demo allows the customer to see progress of the application and allows the customer request changes in the GUI design or functionality in earlier stages of development.

One concern for the iterative development model is that the developer does not have a complete understanding of all requirements before starting the design. Major design decisions made in an earlier iteration may not be valid in future iterations, causing modification to design and code. To offset this concern, the developer modified the iterative development model to include gathering all requirements for the application within the first stage of the development process. Gathering all of the requirements before beginning the development iterations allowed the developer to gain oversight on all that would be required in the application. This encompassing view would help the developer make appropriate design decisions and lower any risk of design and code rewrites.

3. Requirements Phase

The gathering requirements phase consisted of the customer and the developer discussing the functionality of the Exam Generator. The customer for the Exam Generator was an UW-L Faculty Member named Dr. Kenny Hunt. Discussions of the requirements were performed through email and face-to-face meetings between the customer and the developer. This occurred throughout the Spring of 2008. A total of thirteen face-to-face meetings were held which lasted thirty minutes to an hour each meeting. A total twenty emails that were exchanged.

3.1.Requirements Document

A segment of the requirements document can be seen within Figure 2. Each functional requirement is defined with the following fields.

an index ( a unique code for the functional requirement)  
a descriptive name  
a purpose (a short description of the requirement)  
input parameters  
output parameters  
actions ( a set of tasks or activities that must be performed in order to  satisfy this requirement)  
exceptions (set of conditions that indicate a situation in which the function will stop)  
remarks that explain more about the functionality  
cross-references to other functional requirements that are related to the current function

The completed requirements document contains a total of thirty-nine requirements that follow the same format as shown in Figure 2. Thirty-four requirements define the functionality of the application, while the

剩余内容已隐藏，支付完成后下载完整资料

附录A 译文

试卷生成系统

摘要

UW-La Crosse试卷生成器是一个在线网络应用程序，旨在帮助教学机构的教员创建和维护考试。试卷生成系统里的教员可以创建和维护题库。系统中的题目可由教师手动或自动生成试卷。试卷生成器还为这些教育机构的学生提供了通过使用与学生分享的考试和题目的在线练习考试来准备课程的机会。这篇论文描述了UW-La Crosse试卷生成器的开发以及开发过程中出现的挑战和问题。

开发背景

每年全球教育机构的教师和教师正在寻找适当评估学生对课程内容的理解的方法。一个成功的方法是通过使用多项选择测验或考试来测试学生的知识。使用多项选择考试作为评估知识的一种方式带来学生作弊的风险。当有一大批同学参加同一考试时，肯定会出现这种情况。这种情况造成学生看旁边学生试卷抄袭答案的可能性。

劝阻作弊的一个流行方法是创建多个版本并进行分发，使彼此坐在一起的学生完成不同的考试形式。多个考试版本使得学生难以复制答案，但对教师造成压力，因为同一考试的多个版本必须被创建和分级。

试卷生成器是一个应用程序，旨在帮助教师创建考试，并帮助学生准备考试。试卷生成器为教师提供了创建和分类问题的工具。随后系统创建的问题可以包含在考试中。考试可以随机和打印，以及他们的答卷。此功能使教师能够专注于考试的内容而不是布局。然后可以与其他教师或学生分享考试。学生有能力登录申请并参加共同考试。

生命周期模型

现代存在开发软件的许多开发模式，每个都包含自己的优点和缺点。为试卷生成器选择的开发模式是一个迭代的开发模式。以下描述该模型的概要。迭代开发模型定义了以循环方式开发应用程序的过程。这样的工程循环从开发人员开始收集客户的用户需求的一部分。然后对需求子集进行设计，编码和测试。测试完成后，开发人员开始下一次迭代。这个过程一直持续到项目得到充分发展。按照这种方法，开发人员可以更早地发现潜在的设计和编码缺陷。

如果正在开发的应用程序是GUI密集型的，则可以将迭代开发模型扩展到包括演示。在演示中，向客户显示应用程序的原型。提供演示允许客户查看应用程序的进度，并允许客户在开发的早期阶段对GUI设计或功能进行更改。

迭代开发模式的一个问题是开发人员在开始设计之前并没有完全了解所有需求。在以前的迭代中做出的主要设计决策可能在以后的迭代中可能无效，导致设计和代码的修改。为了抵消这一担忧，开发人员修改了迭代开发模型，包括在开发过程的第一阶段收集应用程序的所有要求。在开始开发迭代之前收集所有要求，允许开发人员对应用程序中所需的所有要求进行监督。这种涵盖的视图将有助于开发人员做出适当的设计决策，并降低设计和代码重写的风险。

需求分析

需求分析阶段由客户和开发人员讨论试卷生成器的功能。试卷生成器的客户是UW-L教授，名叫肯尼·亨特博士。通过电子邮件和客户与开发人员的面对面会议来讨论这些要求。这发生在2008年春季。共举行了十三次面对面会议，每次会议持续了三十分钟到一个小时。共有二十封电子邮件被交换。

需求文档

每个功能需求都用以下字段定义。

索引（功能要求的唯一代码）
描述性名称
目的（简要说明要求）
输入参数
输出参数
动作（必须执行的一组任务或活动满足此要求）
异常（指定功能的情况的一组条件）会停止）
关于功能的更多说明
与其相关的其他功能要求的交叉引用当前功能

表现形式

完成的需求文件包含总共三十九个要求，遵循如图2所示的相同格式。三十四个要求定义了应用程序的功能，而剩下的四个要求定义了非功能性要求。需求文件中包含三个用例图，以增加要求。

要求文件中的非功能性要求不符合任何具体格式。要求文件中讨论的四个非功能性要求是性能，安全性，安全性和软件质量。下面列出了每个部分的一些项目符号。

应用程序必须始终保持良好状态。
对于所有交易，响应时间在应用程序内必须保持不到一分钟。
存储在应用程序中的数据将每周进行备份，以防止数据丢失。
不具有访问内容权限的用户不能查看该内容。
应用程序必须编码，以防任何用户遇到任何类型的攻击（SQL注入，XSS攻击等）。
应该设计应用程序，以促进易于维护。
设计必须易于理解，并允许轻松修改。

用户组

试卷生成器的要求依赖于三种类型的用户组。下面描述了三个用户组，其要求的简短说明和用例图。

3.3.1 教师

教师有能力管理系统中的类别，参考，问题和考试。以下是考试生成器中部分功能的列表。

登录和退出系统。
创建/编辑/删除类别。
将零个或多个类别分配给多个参考，问题或考试。
创建/编辑/删除引用。
可以向问题添加图像或文本引用
建/编辑/删除多项选择和真假问题。
使用应用程序中存储的问题创建/编辑/删除考试。
使用用户可访问的问题自动生成考试。
随机抽出考试的问题。
以PDF格式生成考试和考试答卷。

3.3.2 学生

学生用户的功能仅限于搜索考试，随机生成考试和在线考试作为考试。以下列出了一些学生的功能。

登录和退出系统。
搜索与学生分享的考试。
使用学生可访问的试卷生成考试。
可以参加在线练习考试。学生收到一个总结
完成在线考试; 显示考试成绩，并确定哪些问题已被正确和错误地回答。

3.3.3 管理员

管理员管理所有用户帐户。以下是管理员功能的列表。

登录和退出系统。
创建/编辑/删除/搜索系统用户。

开发阶段

开发工具

在开始设计之前，已经对用于构建Web应用程序的工具和包进行了研究。熟悉Java编程语言导致开发人员用Java构建应用程序。这样做允许开发人员专注于应用程序本身，而不是学习新的编程语言。易于维护是Java的另一个好处。

根据客户要求，Exam Generator被设计为能够托管在Tomcat Web服务器上的基于Web的应用程序。在本文时，许多应用框架存在于Java中开发Web应用程序，所有这些框架都有优缺点。其中一个Web应用程序是由JBoss团队开发的Seam Framework。 Seam Framework具有帮助开发人员创建试卷生成器的功能。以下是开发人员为此项目选择Seam的一些功能。

Seam框架包含被配置为相互协调工作的库。包含iText PDF生成库对于生成PDF格式的考试非常有用。包含JPA和Hibernate是一个数据库。 RichFaces库提供了应用程序前端使用的许多GUI组件。
Seam框架包含许多自定义类，可以减少开发基于Web的应用程序时通常需要的冗余代码。一些包括：
EntityHome类用于使用持久性管理器在数据库中发现的实体进行CRUD操作。
提供JPEG和GIF图像的压缩和调整大小的类，用于在GUI中存储和显示图像引用以及生成的PDF。
提供用于加密存储在数据库中的用户密码的数据加密的类。
Seam Framework应用程序包括用于认证的工具。
JBoss团队为Eclipse IDE开发了一套易于插件的插件
使用Seam Framework创建和编辑应用程序。最有用的是Seam Generator，它生成一个包含基本Seam Framework Web应用程序所需的所有文件和配置的Eclipse项目。
Seam框架支持将应用程序部署到任何Java应用程序Web服务器。
“Seam框架”包含许多示例，说明如何正确使用该框架。
Seam框架的家庭网页包括一个管理论坛，开发人员可以发布关于框架的问题，并获得框架的创建者和强大用户的支持。

设计文档

在每次开发迭代开始时，开发人员创建并更新了Exam Generator的设计文档。设计文档包含面向对象的设计，用于在以前的迭代中实现的内容，以及在后续迭代中要实现的内容。设计文档包括实体和会话设计（描述为类图和类定义）和数据库设计（描述为实体关系图）。本设计的这些图和关键特征将在本文的以下部分进行讨论。

除了实体和会话图之外，使用类定义的集合描述了每个设计。类定义描述了一个类的结构和行为属性。在试卷生成器的最终开发迭代中，设计文档总共包含四十六个类定义。

图5包含了Authenticator类的类定义。类定义包含一个类框和方法列表。该框包含类名称，属性，目的和任何其他有助于开发人员的注释。在类框之后是类中包含的方法（减去类属性的通用setter和getter方法）的列表。为了确保数字符合一页，只有Authenticator类才会显示验证方法。

核心设计

试卷生成器的设计可以分为三部分：实体层设计，数据库设计和会话层设计。 4.3.1至4.3.3节描述了每个设计中包含的内容以及每个设计的主要特性。

EntityLayerDesign

实体层类是提供考试生成器中所有对象的结构的Java类。图7显示了Exam Generator的实体类图。本节描述了开发人员在创建实体层类的结构时作出的一些决定。

在图7中，可以看出类问题，选择和参考不是与考试直接相关的。 Question，QuestionChoice和Reference与Class ExamQuestion，ExamChoice和ExamQuestionReference相关联。 ExamQuestion，ExamQuestionChoice和ExamQuestionReference然后直接与考试相关联。以这种方式创建类关联允许Exam对象包含问题，选择和引用对象的副本。由于Exam对象只保留了Question，Choice和Reference对象的副本，所以所有者可以对其进行更改，而不会在考试中反映更改。如果考试的所有者想要一个ExamQuestion来反映新的更改，用户必须手动更新考试。

客户提出的要求之一是，当用户查看考试时，可以根据参考资料将问题分组在一起。创建了ExamQuestionGroup类以满足此要求。使用此设计，Exam可以包含ExamQuestionGroups列表。每个ExamQuestionGroup都包含所有ExamQuestions引用的ExamReference以及属于该组的ExamQuestions列表。如果ExamQuestion没有引用ExamReference，那么ExamQuestion将是该组中唯一的ExamQuestion。这个解决方案使得分组问题的复杂性比较简单。此外，该解决方案适用于Seam使用RichFaces将内容显示在网页上，无需创建用于向用户显示数据的自定义视图。

开发应用程序时，开发人员发现，保存创建和更新日期有助于应用程序维护，并在未来的应用程序增强中提供更多高级搜索查询。名为Auditable和BaseEntity的两个抽象类的创建为所有实体提供了这些字段。可审计类包含两个日期字段 - 一个用于何时创建实体，一个用于更新实体。 BaseEntity被创建为所有实体类的父项。 BaseEntity扩展了Auditable，提供了扩展BaseEntity日期字段的所有实体类。这种方法还提供了在将来的迭代中向所有实体添加字段的方法。

DatabaseDesign

数据库设计用于考试生成器中的数据。图8显示了使用实体关系（ER）图的Exam Generator的数据库设计。

如果读者将图8与图7中的类图进行比较，可以看出每个实体类（减去枚举和抽象类）在数据库中都包含自己的表。图8中显示的表中没有下划线的表可以直接映射到实体层

来自图7.“映射”一词表示实体类中的每个值都可以作为数据库表中的列找到。例如，图7中的考试类可以映射到图8中的考试表。

图8中显示的在其名称中具有下划线的表格表示实体之间的一对多或多对多关系。例如，在实体层类图中，Question类包含Category类的列表。问题类别表表示数据库中的这种关联。 question_category表包含存在的每个问题类别关联的一行。如果一个Category对象被添加到一个Question对象的类别列表中，那么一个新的行将被添加到具有关系的类别id和问题id的question_category表中。类似地，如果从列表中删除该类别，则会删除question_category表中的该行。

设计数据库使其类似于Entity类结构有两个主要优点。第一个好处是使“实体层”和“数据库”层包含彼此之间的关系映射。图7中的类都有一个Hibernate或JPA注释，将它们映射到适当的数据库表。该关系映射然后由实体管理器在考试生成器的会话层内使用。本文的会话层设计部分介绍了实体管理器的使用方式。

设计数据库以使其类似于Entity类结构的第二个好处就是使数据库保持正常化。数据库内的规范化意味着从数据库中删除冗余数据，并确保数据中的依赖关系是有