SMART系统-系统框架设计与开发论文

分类号：D C：007) 5992：公 开 编 号：2003032068成 都 信 息 工 程 学 院学 位 论 文统胡 州 明申请学位专业： 网 络 工 程申请学位类别： 工 学 学 士指导教师姓名（职称）：叶立轩（高级工程师）论文提交日期： 2007年06月 05 日统系统主要实现了学生在线考试与评估以及教师对学生在线考试信息的管理和维护。本文按照于建了一个具有良好的可扩展性、可维护性、可靠性的系统框架。整个系统的框架分为三层，分别为表现层、业务层和持久层。 本系统的表现层是基于合本系统的需求完成了自定义标签的封装，基本 业务层则是采用单例模式设计与 现了公共代理类的编写，各业务逻辑接口的封装。而在持久层的设计中则是采用基于现有持久层框架的实现模式，实现了对产生常用数据库操作的封装。这样设计减少了耦合性且避免了生成大量的临时对象。该系统框架能达到良好的可拓展性和维护性。它不仅仅适用这个系统的开发，可以应用于系统。关键词：设计模式；开源；领域建模；系统框架is a of do of In to a of is in to of is is We do in of on of to of In is a of oC so of is to of is on of of of As a it a of in be be in is to to ; 论文总页数：25页1 引言. 课题背景. 国内外研究现状. 本课题研究的意义.统需求分析. 可扩展性要求. 可维护性要求. 可伸缩性要求. 可靠性要求.统开发环境及实现关键技术. 硬件环境. 软件环境. 系统实现的关键技术.统总体框架设计. 总体结构说明. 总体结构设计与建模.统总体框架具体实现. 各层具体实现.试与分析. 测试环境. 测试结果. 结果分析. 页 共 25 页1 题背景随着计算机技术的发展及计算机的日益普及，基于别是在大兴数字化校园建立的今天，基于的优势不但体现在人力上也体现在物力上，基于分、成绩存档功能将有效地避免资源的浪费，有利于环保，减少人员投入，大大的提高了效率。相比传统的考试方式，基于要准备好足够大的题库，就可以按照要求自动生成各种试卷；另一方面，考试时间灵活，可以在规定的时间段内的任意时间参加考试；另外计算机化的考试的最大特点是阅卷快，系统可以在考试结束时当场给出客观题考试成绩，计算机阅卷给了考生最大的公平感。本文中研究了基于统框架设计与开发设计与实现，包括系统需求分析和系统框架功能设计与实现。内外研究现状网络考试系统极大地提高了教学的灵活性，现在在许多领域已经有了广泛的应用。在国外最有影响的案例就是 国教育考试中心）举办的 国研究生入学考试）的计算机化考试，它使考试由原来的每年只能有两次参加考试的机会变成了每个工作日都可以参加的考试，大大提高了工作的效率。在我国，经过这么多年在 的发展及经验的积累，虽然数字化教育已经蓬勃地发展起来，但是目前学校与社会上的各种考试大都采用传统的考试方式，在此方式下，组织一次考试至少要经过五个步骤，即人工出题、考生考试、人工阅卷、成绩评估和试卷分析。然而在这个过程中人工手动出题和试题的选择是最为复杂的，显然，随着考试类型的不断增加及考试要求的不断提高，教师的工作量将会越来越大，并且其工作将是一件十分烦琐和非常容易出错的事情，可以说传统的考试方式已经不能适应现代考试的需要。因此在国内也出现了比较适合自己本国特色的在线考试系统如：杰佛通用在线考试系统，新为在线考试系统等。课题研究的意义本系统主要用来缓解传统考试所需要的繁琐工作流程，组织试题、印刷试卷、组织考试、监考防作弊、收卷判分、统计结果等，通过本系统，可以将以上考试的全部流程，完全借助计算机系统来实现，从而减轻教师的工作负担及提高工作效率，与此同时也提高了考试的质量，使考试更趋于公证、客观、科学性进一步的激发了学生的学习兴趣。第 2 页 共 25 页2 系统需求分析统框架在实现上要求采用在 域中比较流行的 架组合方式，并结合系统自身的一些特点来实现适合于本系统框架设计，该系统的一些非功能性的需求如下：扩展性要求一般来说，软件的可扩展性决定着其适应变更能力的大小。事后我们总是可以很容易地评价某个程序是可扩展的还是不可扩展的，但是要想使这个系统在今后真正派上用场，我们必须事先就对它有个判断。一个系统一般都是要在不断升级的过程中去结合用户的需求来完善自身功能，因此该系统要求采用清晰的接口把对象的实现与它的交互分离开来，特定的实现就可以独立于应用的其他部分，各个实现也可以在将来很方便地修改、升级甚至彻底替换。这时的应用不再是一个单独的东西，而是一个系统中半独立的组件。多个开发者可以在相互不破坏彼此成果或者甚至在不了解全局场景的情况下协同开发。组件提供了特定的功能，允许独立地测试，也可以重用于多个应用中。如果组件之间工作分配及接口是很清晰的，这样的软件就很容易扩展。维护性要求系统在开发完成以后，后期的维护也是一个项目中重要的一环，包括为了满足用户的使用体验对代码所作的修改；对上线后长时间运行过程中所出现的是要求一个系统是具有可维护性的特性的。伸缩性要求可伸缩性和性能是紧密相关的，但是它们并不完全相同。可伸缩性可以广义地定义为应用在请求数目增长时维护性能的能力。在发数应在10000人以上。在本系统架构的中是采用分层的技术，这将可以很好的满足可扩展性与可维护性的要求，但是各层之间的通信又反过来制约了伸缩性。因此，就要求我们在架构设计的时候使用有成效的实践经验来连接这些层次。靠性要求可靠的软件在所有时刻都会按照预期的那样执行。与可伸缩性类似，一个可靠的系统取决于对其底层组件的可预测性。从一个用户的角度来看，可靠性是对整个系统的判断，包括硬件、软件和网络元素。如果一个单独的组件发生故障了，并且用户无法访问应用或者应用工作不正确了，那么整个系统就是不可靠的。在统中的需求中，可靠性是首当其冲的，特别体现在考试的过程中。如果在考试的过程中系统出问题了，或者在考试后的阅卷中系统算错分了，这都将是第 3 页 共 25 页灾难性的错误，从而导致严重的后果。因此，保证 件环境2500+内存：1 0 件环境操作系统：003显示设置：95000 + 术称为“异步 该技术并不是一种新的技术，实际上是多种技术的综合，包括 中使用 为标准化的呈现，使用用出之前，业界对于上述技术都只是单独的使用，没有综合使用，也是由于之前的技术需求所决定的。与传统的 用不同，用异步交互过程。用户与服务器之间引入一个中间媒介，从而消除了网络交互过程中的处理户的浏览器在执行任务时即装载了常藏在一个隐藏的框架中。它负责编译用户界面及与服务器之间的交互。擎允许用与应用软件之间的交互过程异步进行，独立于用户与网络服务器间的交流。现在，可以用 用 存中的数据编辑、页面导航、数据校验这些不需要重新载入整个页面的需求可以交给 4 页 共 25 页图 1 例模式单例模式作为设计模式中的创建模式类型中的一种，从其名字可以看出该模式确保了一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这类称为单例类。单例模式具有以下的特点：1. 单例类只可有一个实例。2. 单例类必须自己创建自己这惟一的实例。3. 单例类必须给所有其他对象提供这一实例。在单例模式一般有三种实现其分别为：饿汉式单例类；懒汉式单例类；登记式单例类。1. 饿汉式单例类：饿汉式单例类是在言里实现得最为简便的单例类，下面所示的类图描述了一个饿汉式单例类的典型实现。图 2 饿汉式单例类类图第 5 页 共 25 页从类图中可以看出，在这个类被加载时，静态变量被初始化，此时类的私有构造子会被调用。这时候，单例类的惟一实例就被创建出来了。而避免外界利用构造子直接创建出任意多的实例。值得指出的是，由于构造子是私有的，因此，此类不能被继承。2. 懒汉式单例类：与饿汉式单例类相同之处是，类的构造子是私有的。与饿汉式单例类不同的是，懒汉式单例类在第一次被引用时将自己实例化。如果加载器是静态的，那么在懒汉式单例类被加载时不会将自己实例化。如图3所示，类图中给出了一个典型的懒汉式单例类实现。图 3 懒汉式单例类类图3. 登记式单例类：登记式单例类是 了克服饿汉式单例类及懒汉式单例类均不可继承的缺点而设计的。在本例中把他们的例子翻译为言，并将它自己实例化的方式从懒汉式改为饿汉式。只是它的子类实例化的方式只能是懒汉式的，这是无法改变的。如图 4所示是登记式单例类的一个例子，图中的关系线表明，此类已将自己实例化。图 4登记式单例类第 6 页 共 25 式式又称赖注入），从们已经习惯一种思维编程方式：口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行：a = ;据需要实现，打个比喻：接口如同空的模型套，在必要时，需要向模型套注射石膏，这样才能成为一个模型实体，因此，将人为控制接口的实现成为“注射”。其实述于被调用者名称写入了调用者的代码中，这产生了一个接口实现的原罪：彼此联系，调用者和被调用者有紧密联系，在示。但是这种依赖在分离关注的思维下是不可忍耐的，必须切割，实现调用者和被调用者解耦，新的 式 式由此产生了，式是依赖注射的意思，也就是将依赖先剥离，然后在适当时候再注射进入。射机制“反射”是 序开发语言的特征之一，它允许运行中的 序对自身进行检查，或者说“自审”，并能直接操作程序的内部属性。反射机制是使其具有动态特性的非常关键的一种机制，这个机制允许程序在运行时透过得任何一个已知名称的 内部信息，包括其如 等)、如 实现之如 也包括 所有信息，并可于运行时改变 定义标签要在么要求必须实现一个相应的标签处理类及写该标签的 件，在 理类，是基于一个 型的类，该类里面伴随的 的属性。另外这个 还必须要实现 范中与 三个接口如下所示：1. 页 共 25 页3. 承了 承了 提供的两个类使开发自定义的标签变得容易，它们分别为现了 接口，而 了实现了那两个接口外还实现了口。图5展现了整个标签处理过程：图 5 标签处理的生命周期4 体结构说明图 6 系统总体框架示意图第 8 页 共 25 现层如图1所示,在整个单易用，该框架是基于模式将表达层分解为自包含的和可重用的几个部分，当用户通过浏览器发起框架将利用其由其对应 处理。基于 式的整个交互的序列图如图7所示：图 7 用再自己实现全套省了大量的开发时间。务层如图1所示，在表现层与业务层之间利用一个公共代理类来完成交互，该代理类采用单例模式设计开发，在整个框架中起到了如下几点作用：1. 减少耦合性2. 避免生成大量的临时对象在该代理类，实现一个对相应业务逻辑的处理方法，该方法的参数为一个封装好相应的页面数据对象、要调用的业务类的名称及该业务类中相应的处理方法名的类。在该层中利用了 架中的 式(英文全名为 该模式类似于著名的好莱坞原则：“we后被 名为 赖注射，也就是将类之间的关系通过第三方进行注射，不需要类自己去解决调用关系，实现第 9 页 共 25 页了调用者和被调用者之间的解耦分离。的实质在于只是将这种联系转移了。在 现中这关系被转移到相应的原理如图8所示：图 8 式在 久层在采用基于现有持久层框架的实现模式，在这种模式中，将最为繁琐的基于由第三方组件（本框架中采用开源的完成，这样就会在对数据访问对象进行编码时，大大的简化了一些繁琐而又复杂的编码工作，只需要利用持久化对象进行操作。在该持久层框架提供了优秀的性能优化机制，如内置的数据库连接池支持，据缓存等。这些优化机制的综合使用大大提升了系统的性能。在一些常用的添加、删除、更新数据库操作进行了抽象封装。并在 9基于现有持久层框架的实现模式第 10 页 共 25 共代理机制的设计在大部分采用B/户与系统的交互都是要涉及到相应的交互数据、业务逻辑，因此在本系统的框架设计中考虑到将这些交互中涉及到的因素全部封装到一个通过一个单例类来实现表现层与业务层的交互，这样用户操作时不用每次都去实现各功能模块中子程序之间的解耦。统接口设计序设计语言提供了两种机制，可以用来定义一个允许多个实现的类型：接口和抽象类。两种机制之间最明显的区别是，抽象类允许包含某些方法的实现，但是接口是不允许的。一个更为重要的不同之处在于，为了实现一个由抽象类定义的类型，它必须成为抽象类的一个子类。任何一个类，只要它定义了所有要求的方法，并且遵守通用约定，那么它就允许实现一个接口，不管这个类位于类层次的哪个地方。因为 以，抽象类作为类型定义受到了极大的限制。接口使得我们可以构造出非层次结构的类型框架。例如：假设有一个接口代表一个 唱家)，另一个接口代表一个 曲家)：s);在现实生活中，有些歌唱家本身也是作曲家。因为是使用接口而不抽象类来定义这些类型，所以对于一个类而言，它同时实现际上还可以定义第三个接口，它同时扩展了且加入一些适合于这种组合的新方法:;如果要满足这样的一种灵活性，抽象类是不可能完成的。虽然接口不允许包含方法的实现，但是，使用接口定义类型并不妨碍你为程序员提供实现上的帮助，在本系统的接口设计与实现中借鉴了 的将接口类与抽象类的优点结合起来，将期望导出的每一个重要接口，都提供一个抽第 11 页 共 25 页象类的骨架实现(。按照惯有编码命名习惯，将该骨架实现类命名为务)接口，据访问对象)接口。定义标签的设计在对系统的实现中，由于在表现层使用的是基于 框架中为了在表现层的面中不混合大量的 保持 己的一套标签，但是考虑到本系统的实际应用的功能实现。且这些功能实现又是 签没法满足要求的，因此在该系统框架中实现了自己的一套标签，主要有，。1. 标签：设计意图：在一般的基于B/页面上经常是会涉及到添加、编辑、删除几种常用的功能，在早期的一些开发编码中，相当一部分人是将这几种功能分为多个页面来实现，例如：面，除用一个 这些的页面的代码80%以上都基本上是一样的，只不过是上显示的按钮及在点击相应的提交给后台处理方法不一样。为了达到在一个页面上面实现添加、编辑、删除功能，并且要保持页面代码的清晰可读性，因此，在本系统框架中，封装了自定义的提交标签。表 1 标签属性列表属性名称 属性描述 备注标签元素的标签元素的名称。点击该标签所显示的内容后所提交的参数名称标签在页面上所显示的值，等同于签的性。否要对该标签的内容是否在页面上显示出来作控制。 只有两种值标签在页面显示的内容的背景图片。点击该标签所展现的内容后所触发的事件。第 12 页 共 25 页2. 标签:设计意图：在一般的基于B/页面上经常要用到下拉框，且在了在加载该页面时动态的、带条件的取其标签相应的键/值对，因此，在本系统框架中，封装了自定义的下拉菜单。 表 2 标签属性列表属性名称 属性描述 备注标签元素的名称。标签元素属性名称，与应于 标签属性为标签取值的业务代码。属性同属性同 签组中的 签的 性。属性同属性为在加载该标签相应的值时的条件。于结构的页面上经常会出现一个以上的功能按钮，而这些功能按钮基本上都是对应于后台的一个操作实现，由于在本系统中的表现层选用较为成熟 架，该框架中最为核心的部分要属控制器控制转发相应的中的一个方法的调用都基于配置文件中指定的一个特殊请求参数值，利用该参数值反向查询资源绑定，并将它与类中的一个方法进行匹配。从这些功能可以看出此，在对本系统进行架构设计的时候，考虑建立一个抽象的 类继承 现 中的方法中返回本系统中请求参数值与资源文件中参数值的键/值对。实现一些对于所有的 是有可能用到的公共方法，包括从页面上按钮是否显示的控制；检查用户权限；对第 13 页 共 25 页公共业务逻辑接口的调用等等。在涉及到系统的具体开发实现的时候，要求所有开发人员在写自己的 基于实现的，在了解到相关的本系统的框架中，从如下几个方面对其进行了进一步的封装。1. 对产生意这里 含义，它与传统意义上的 的 没有什么关系。当于持久化管理器核心，提供了众多持久化方法，如过这些方法即可透明地完成对象的增删改查(但是值得注意的是，设计是非线程安全的，也就是说，一个一个此在本框架中对通过行了线程安全性的处理，在实现的 新建一个 的每次产生 入该类中，这样就达到了线程安全性的效果了。当 产 生 创 建 例 时 ， 也 要 注 意 对为 时也负责维护当前的二级缓存和此可见，价高昂，而这也意味，在系统设计中要充分考虑到 重用策略。由于由多个线程并发调用，大多数情况下，一个应用中针对一个数据库共享一个. 对通常的数据库操作进行封装设计意图：在系统的设计架构中考虑到代码的重用性，因此对一些通用的数据库的操作都将其封装到一个公共类中，这样就减少了系统开发人员的代码编写工作量，也避免了同功能代码的重复编写。第 14 页 共 25 图图 10 公共数据传输类 图 11 公共代理类图 12 表现层基于 5 页 共 25 页图 13表现层的基本 14 持久化对象接口图 15表现层自定义标签相关实现类第 16 页 共 25 页图 16系统相关异常处理类图 17 异常处理工具类第 17 页 共 25 页图 18 数据访问对象、业务相关接口及其实现类、对数据库操作及日志类图 19日期工具类第 18 页 共 25 列图图 20 用户与系统交互的序列图5 现层在本系统中的表现层实现了一个抽象的 ，该类继承现 中的 方法中返回本系统中请求参数值与资源文件中参数值的键/值对。实现一些对于所有的分代码如下所示:() ; ; ;.( ; ( ;/隐藏页面按钮 ; 务层在本系统中的业务层实现了一个单例的统中所有的表现层与业务层的交互都要通过这个类来实现。该类结合了件进行了解析，详见下面的类中的 ; /返回唯一的实例 第 20 页 共 25 页= = ;( ; (); 久层本系统的持久层是基于开源的合供相应实现的部分代码如下所示： ;/打开一个新的 & != (;= = ; ;/将 入 ;第 21 页 共 25 页6 试环境本次测试的环境的硬件环境与系统