基于bs的在线考试系统的分析与实现

基于bs的在线考试系统的分析与实现内容摘要：

定的试卷建立试卷，学生通过浏览器登陆考试，考试结束后客观题自动得到答案，主观题教师可以上线评阅，系统自动给出成绩单。 对比传统考试可以发现，这种方式可以大大减轻教务部门和教师的工作负担。 系统 设计 目的 本设计的主要目的是为作者所在院校建立一套在线的考试系统。 教师可以登录系统录入题库，并组建考试。 学生可以登录系统进行日常的随机练习、对做错的题目进行反复练习、进行模拟考试和正式考试。 系统需能给出学生的成绩和统计分析结果。 论文结构 基于 B/S 的在线考试系统的设计与实现 3 2 相关技术与框架 C/S 架构与 B/S架构 C/S 即 Client/Server，由服务器和客户端组成。 服务器通常采用高性能的 PC、工作站，并采用大型数 据库系统如 Oracle、 SQLServer。 客户端需要专门安装客户端软件 [1]。 B/S 架构（ Browser/Server，浏览器 /服务器）是 Web 技术发展的产物。 Web浏览器是一个常用操作系统安装率 100%的软件，所有主流操作系统均装有浏览器。 B/S 架构以浏览器作为统一的客户端，免去了为每个用户安装客户端的麻烦。 B/S 架构将真个系统的核心部分集中到服务器上实现，简化了客户端的操作，减少了对客户端的要求。 服务器一般安装有数据库系统和 Web 应用服务器（如 Apache， Tomcat， IIS）。 用户通过浏览器与 Web 应用服务器交互， Web应用服务器通过与数据库交互获取并处理数据。 C/S 架构和 B/S 架构有各自的优点和缺点。 [2] 从处理能力看， C/S 架构的优势在于它能充分雷勇客户端机器的处理能力，很多工作可以先处理完再交给服务器。 从响应速度看， C/S 架构客户端响应速度较 B/S 结构快，且能完成一些 B/S架构无法完成的功能。 如教务系统中的排课功能，就是在客户端完成。 从网络看，传统的 C/S 架构通常只能适用于局域网，一旦放入广域网中其响应速度（远程访问数据库）就会变得很难，导致假死等情况发生。 改进的 C/S 架构不直接使 用 Client 访问服务器上的数据库，而是通过自定义应用层协议的方式与服务器通讯，如ＱＱ，它使用腾讯公司自定义的通讯协议。 这种架构的软件，设计和开发的工作量较大，且难以修改和维护。 从安装部署看， C/S 架构需要在每个用户的机器上安装特定的客户端。 客户端对操作系统有一定要求，如开发与 Windows 平台的应用不能在Ｌｉｎｕｘ下使用。 有的客户端还需要安装如 . Framework 等支持性类库。 从安全性看， C/S 架构面向固定的用户群，对信息安全的控制力较强，如果系统有保密性要求，则优先选择 C/S 结构。 B/S 结构 因为不需要固定的客户端，且基于互联网，所以保密性相对较差。 基于 B/S 的在线考试系统的设计与实现 4 从重用性看， C/S 架构的重用性较 B/S 架构差。 B/S 基于动态网站技术，一般采用多重架构，很多功能都可以重用。 从系统维护看 ,在软件生命周期中，系统维护占有重要比例，开销也很大。 C/S 架构由于整体性，必须整体考查，处理出现问题困难，且需要所有用户更新客户端才能完成一次升级。 B/S 架构因为大多数功能集中于服务器，软件的更新只需要更新服务器即可，可以实现系统的无缝升级。 系统维护开销最小。 用户客户端无需做任何改变。 从表现力来看， C/S 程序基于平台的空间库 ，一般表现比较固定。 而 B/S架构可以使用Ｄｉｖ＋ＣＳＳ技术做出非常绚丽的效果，其表现形式丰富。 从开发难度看，传统的 C/S 架构开发难度不高，但性能存在问题。 改进的C/S（包含了自定义的应用层协议）性能优越，但开发难度很高。 B/S 架构则在众多动态网站设计语言如ＰＨＰ，ＡＳＰ，ＡＳＰ．Ｎｅｔ，ＪＳＰ的支持下，变得非常简单便利。 从服务器的稳定性上看， B/S 架构基于千锤百炼的 Web 应用服务器，使用HTTP 协议交互，服务器稳定性高，负载能力强。 改进的 C/S 架构基于自己编写的应用服务器，稳定性差，基于 TCP 协议，负载 能力不如无连接的 HTTP 协议。 综上所述，对于一般应用而言， B/S 优于 C/S 架构。 对于一些对有特殊要求的应用，则可选用 C/S 架构。 本文给出的系统采用 B/S 架构。 MVC 架构 与 Spring MVC MVC 即模型（ Model） 视图（ View） 控制器（ Controller）是 Xerox PARC在二十世纪八十年代为编程语言 Smalltalk－ 80 发明的一种软件设计模式，后来被推荐为 Oracle 旗下 Sun 公司 Java EE 平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP 的开发者 的欢迎。 现已广泛被用于各个软件科目。 MVC 是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。 MVC 被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。 [3] MVC 最开始存在于桌面应用中。 模型代表数据存储，视图代表用户界面，控制器负责将模型和视图关联起来。 MVC 实现了数据和视图的分离，从而是同 基于 B/S 的在线考试系统的设计与实现 5 一种数据可以具备不同的表现形式。 如一批统计数据可以分别表示为柱状图和饼状图。 控制器则负责绑定模型和视图。 当模型改变后，视图应相应改变。 图 MVC结构图 在软件中，模型负责保存应用程序的数据，包含用户输入的数据、中间结果和最终结果。 模型的这种角色使得它天然具备了数据持久化的责任。 数据持久化可以采用文件的形式，但更多的是采用数据库形式。 模型至少应具备从数据库表格中的一个字段自动转换为模型类对象的功能。 这个可以由成熟的组件 Hibernate 来实现。 数据模型不依赖于控制器和视图，也就是说它不关心如何被显示，或如何被操作。 但模型中数据的变化会通过一种刷新机制被视图 获取到，进而刷新页面。 视图能将数据按照某种格式显示，当然有些视图也可以不依赖于任何数据显示，比如注册用户页面，它因为不需要根据数组作出不同的显示，故而不依赖数据。 在设计视图的时候，一般不要放入数据的处理逻辑等代码内容，让视图只做数据显示。 在桌面应用中，视图一般需要监视它所显示的模型，可以使用“观察者模式 1“实现这种功能。 在 Web 应用开发中一般不需要监视。 因为 Web 应用的页面并非一个持续运行的程序，而是重复”请求 相应，请求 相应“这样一个循环。 所以一般 Web 应用中的 MVC，都是先用控制器调用模型获取数 据，将获取到的数据传递给视图并显示。 控制器一般起一个组织作用，即调用何时的模式和视图完成特定功能。 它是事件相应的负责者。 对于 Web 应用，只有一个事件 ,那就是请求事件。 Web 应 1 ： // 基于 B/S 的在线考试系统的设计与实现 6 用的控制器一般都会有一个 URL映射的功能。 我们知道，用户通过访问某个 URL，或者提交数据访问 Web 应用的功能。 那么 URL 和控制器如何对应，就需要一个约定，这个约定一般通过一个配置文件来实现。 理论的介绍往往很难理解，但它不可或缺。 人们往往从大量的软件开发实践中发现了一些共有的问题，并针对这些问题提出了一些解决问题的思路和想法，然后才是 如何用代码去实现它。 MVC 从根本上讲，还是借鉴了管理学的方法，将复杂问题分解各个模块，让每个模块各司其职协同工作，这样避免了混乱，带来了秩序，减少了工作量，提高了效率。 而分解的一句就是：低耦合，高内聚。 所谓低耦合就是在模块之间要尽量关联少，在模块内部要加强合作。 由于 Web 应用的复杂程度的日益增加，功能也日益庞大，表示层与数据层的分离也显得日益重要。 于是 MVC 这种架构模式被移植到 WEB 开发中来也是很自然的事情，然而， Web 程序和 Desktop 程序是有很大区别的， HTTP 协议是无连接的，当用户从服务器拿 到一个页面之后，整个交互过程也就完成了，用户无法知道服务器端状态的更新，除非用户再次发送请求。 而且，在 Web 程序中，是没有事件模型支持的，用户的每个动作都必须转化为对服务器请求。 以往的经验，我们经常把视图和控制器组合起来，一个页面既包含程序的业务逻辑，又包含页面的显示信息。 然而，视图是经常变化的，业务逻辑确实相对比较稳定的。 为了解决这个问题，比较流行的做法是让控制器执行业务逻辑，从数据层（模型）中抓取显示相关的数据，而视图仅仅是一段显示代码，没有业务逻辑。 由于请求多种多样，而且在控制器到视图的数据转发部分含 有很多相同的逻辑，而且为了方便扩展和管理，于是就有人提出了前端控制器的概念，也就是请求分发器。 分发器的作用主要工作就是将一个 request 分发到一个合适的处理器上，并将处理返回的包含特定信息的视图返回给客户端。 下图展现了现在常用的 Web MVC 的标准模型。 基于 B/S 的在线考试系统的设计与实现 7 图 Web中的简单 MVC结构图 然而，这不是唯一的模 型，在 中，有一种叫做页面控制器的模型。 在这种 MVC 中，并不是令分发器去寻找一个控制器并执行之，而是直接到达视图并且在继续生成视图之前调用相应的控制器。 与传统的 MVC 模式中的前端控制器对应，这种模式称为页面控制器。 页面控制器和前端控制器实现实现之间的区别在于页面控制器描述的往往是同一个页面中（如类似于控制面板那样的页面）的处理逻辑，不能用于跨多个页面对处理过程进行控制或协调。 它是一种 Poll 的模型。 基于 B/S 的在线考试系统的设计与实现 8 图 中的 MVC结构图 Spring MVC 框架是有一个 MVC 框架，通过实现 ModelViewController 模式来很好地将数据、业务与展现进行分离。 从这样一个角度来说， Spring MVC和 Struts、 Struts2 非常类似。 Spring MVC 的设计是围绕 DispatcherServlet展开的， DispatcherServlet 负责将请求派发到特定的 handler。 通过可配置的handler mappings、 view resolution、 locale 以及 theme resolution 来处理请求并且转到对应的视图。 Spring MVC 请求处理的整体流程如图。 1. 用 户向 服务 器发 送请 求， 请求 被 Spring 前端 控制 Servelt DispatcherServlet 捕获； 2. DispatcherServlet 对请求 URL 进行解析，得到请求资源标识符（ URI）。 然后根据该 URI，调用 HandlerMapping 获得该 Handler 配置的所有相关的对象（包 括 Handler 对 象以 及 Handler 对象 对 应 的拦 截 器 ） ，最 后 以HandlerExecutionChain 对象的形式返回； 3. DispatcherServlet 根据获得的 Handler ，选择一个合适的HandlerAdapter。 （附注：如果成功获得 HandlerAdapter 后，此时将开始执行拦截器的 preHandler（ ...）方法） 4. 提取 Request 中的模型数据，填充 Handler 入参，开始执行 Handler（ Controller）。 在填充 Handler 的入参过程中，根据你的配置， Spring 将 基于 B/S 的在线考试系统的设计与实现 9 帮你做一些额外的工作： HttpMessageConveter： 将请求消息（如 Json、 xml 等数据）转换成一个对象，将对象转换为指定的响应信息 数据转换：对请求消息进行数据转换。 如 String 转换成 Integer、 Double等 数据根式化：对请求消息进行数据格式化。 如将字符串转换成格式化数字或格式化日期等 数据验证： 验证数据的有效性（长度、格式等），验证结果存储到BindingResult 或 Error 中 5. Handler 执行完成后，向 DispatcherServlet 返回一个 ModelAndView对象； 6. 根据返回的 ModelAndView，选择一个适合的 ViewResolver（必须是已经注册到 Spring 容器中的 ViewResolver）返回给 DispatcherServlet ； 7. ViewResolver 结合 Model 和 View，来渲染视图 8. 将渲染结果返回给客户端。 图 Spring MVC 的请求处理流程 Spring3 MVC 的优点： 基于 B/S 的在线。