考试系统设计

考试系统设计

文章 

基本思路是由总负责人规划领域
每个领域的负责人规划范围（Exteindex1）,及其他
每个出题人规划考点。

设计思路

• 1 控制性
  • 1.1 质量控制
  • 1.2 过程控制
  • 1.3 版本控制
• 2 协同性
• 3 便捷性

流程

流程图

功能

考试体系

框架

采用原系统中的字典管理，数据库中的表不变，但是在control加一个过滤的函数动作，和一个view ，另外还需要添加一些逐级获取子类的函数。
因为涉及到索引，所以这里还是我先来建立一个基本的框架，然后制定一个根据这个框架的基本的维护规则。再由用户自己来维护。
但是依然需要给普通的出题用户一个增加考点的的维护界面，所以还是需要有一个维护的dataitem的界面。
上面的这个维护还是不是很好，决定自己写一个体系维护模块。先来完成出题的两个界面。主要是传值和保存。

出题

题目体系

• 领域
• 依据（标准法规？）
• 章
• 节
• 考点

领域规范

题型规范

考点规范

依据规范（标准等）

范围规范

有些题目可能不要了，所以需要标记题目是否有效

审题

审题目前是有两个场景，一个是在每一各阶段（指一审，二审。。），由审题的人进行意见的添加。这个阶段主要是单个人提出意见。另外一个场景就是大家坐在一起进行会审。集中起来对意见进行确认，并形成最终的修改意见。并且需要有一个修改后的集中查看，以便反馈修改的是否符合要求。

也就是说在每一个阶段，其实包含了四个子阶段

• 大家提出意见
• 对意见进行会审，形成最终的修改意见
• 按照最终的修改意见进行修改。
• 形成修改结果报告或者汇总，以便审核修改的情况。

审题进度

• 一审
• 二审
• 三审
• 四审
• 终审

单审的基本流程

• 审题
• 会审
• 修改
• 确认

每个审题进度的环节内都需要这样的一个流程。虽然都是审题，但是在不同的环节内，侧重点是不一样的，并且可能是完成的主体也是不一样的，

• 审题：所有出题的人员，可能需要交叉进行审题，但是这个时候基本上是一个个人行为，也就是大家是各自为战的。这个时候主要是审核题目，当然也可能会关注其他人提的意见。
• 会审：大家坐在一起进行审题。这时候的侧重点是对大家提出的意见进行讨论，并形成最终的意见，也可以是采纳此环节中某个人形成的意见。当然也需要看题。
• 修改：则是针对在该流程中，根据会审形成的意见，或者是采纳的意见。进行题目的修改。
• 确认：根据修改的情况进行，修改情况的检查。

审题的进度应该由管理员来，统一管理，即现在属于哪一个进度是一个总体进度，而不应该让用户自己去选择。这样大家在添加的意见的时候，经不用自己去选择是在哪一个审题的进度。
但是还有一个问题，就是第一批审完了，可能还需要添加新题目的时候，又需要进行一轮审核。这一批的审核状态和第一批的审核状态是不一样的。所以这里最好还是，让用户自己去选择比较好。

每一个审题进度都是需要重新捋一遍，即每一个题目都需要重新审核，

聚焦

领域索引

考点索引

题型索引

审题意见

单题审题界面

左侧是题目，有修改题目按钮。
右侧是添加的意见。右侧上方是一个grid，有新增意见按钮。意见的表格对应状态按钮，可以只显示目前未处理的意见。
原型图：

实际效果图：

中间需要主意的几个地方：

• 不打开信息窗口，只是在当前页面中进入下一题（当前界面的题目审完后提示，翻页）
• 新增加的意见，只是更新了左上方的表，并不更新整个界面，用户体验会好很多

新增意见

因为如果是在一个新的页面中新增的话，对于复制，查看描述等都不方便，因此还是在一个页面中显示，因为每次都是新增，所以对于获取的话不成问题。只是获取两个意见，记录是哪一个流程的即可。只获取三个信息，也就不需要getWebcontrol了。
现在的问题就是页面的左右布局了。

• 意见会对应几个状态：
  • 哪个进度中的状态（一审、二审、三审、四审、...，终审）
  • 是否被处理
  • 是否被采用
  • 如被采用，还需要有一个采用后处理进度（未被采用的，可以在不采用的时候，就在采用后处理用添加）
• 意见内容
  • 意见内容，不当之处
  • 建议修改的意见

审题意见处理进度

会审

此阶段的对象，还是审题，但是侧重点是对提出的意见进行核实，要产出该阶段的采纳意见或者是新提出意见。然后采纳。总之这个阶段就是确定采纳意见。，给出两个界面：

• 题目的逐一会审
• 聚焦审题意见的界面。

 

会审界面图

 

需完成的两个工作：

• 点击意见列表时，在下方显示相应的意见
• 在意见中增加一个按钮，标记为采纳该意见
• 修改原来新增意见，增加一个参数，标识该意见为会审意见。

不单独增加状态呢栏标识是会审意见了。只是标记为采纳，就作为会审意见了。
会审的单页面完成。
题目应该加一个状态，标识题目处在什么状态（以便标识题目是否已经审核了，万一有没审的呢）

也就是说这里还有一个工作：

• 添加一个按钮，没有问题的话，例如没有意见，就通过当前审核了。（但是题目感觉真的不应该添加类似于审题进度的条目），但是这里有这样一个问题需要解决：一天审不完，审到一个地方，第二天假设没有记住这个号，怎么找到昨天审到哪里了。所以这里还是应该有一个标记，在这一轮审核过了，但是审核结果可能有同，所以题目也应该有两个状态，一个是审核阶段（一审，二审，终审），一个是在审核阶段内的阶段状态（审核、会审、修改、确认，通过）。那这样，在审题和会审中，其实还都是应该根据题目来进行索引。这样的话，就可以有一个看似工作流的流程，没有通过一审的题目，在二审中看不到。一次类推。在会审阶段，看不到没有审核过的题目，只要有一个人审了，这个题目就可以进入会审阶段。不过难道到了会审阶段，就不需要再审了吗？不是，因为一个人审完，别人还是要审的，所以，在审核阶段，还是索引全部题目。，但是可以建一个单独的索引，查找没有任何人审核过的题目。
• 但是这里如果卡死流程的话，如果有一个流程没过，后面的流程就实现不了了，对于批量的情况，会影响整个进度：

先完成第一个功能：逐一会审：
这个界面和审题的界面会很像，只需要加一个区域，这个区域在点击意见表时候，会显示该意见，并有一个按钮：采纳，点击以后，作为修改的依据。（所以看起来比较好处理），还有一个折叠起来的区域，这个区域用来添加新的意见（万一在会审阶段发现新的问题，以便添加新的意见。）

修改

此界面的index，列出了该审题阶段（一审、二审。。。）最终采纳的意见，修改人员选择条目展开以后，左侧采纳的审题意见，右侧是题目，还有一个折叠全部审题意见。方便进行其他意见的查看。修改的时候会记录修改的历史版本。以方便在确认阶段进行核查。

再来完成修改的页面。
修改的逻辑是，在index页面中聚焦该阶段（一审、二审、终审），然后显示采纳的意见，
单击以后，大致仍然是原来的界面，只不过现在是左侧是意见，右侧是修改题目。并且修改题目需要增加版本控制的概念。最好是再在意见中反馈修改的情况。也就是说会有一个小小的信息冗余，在题目

 

修改界面效果图

左侧是采纳的修改意见，右侧是修改的题目

 

界面完成

下面是需要完成版本控制，和信息冗余存储：

• 题目的版本控制：题目在创建的时候，会根据时间形成自复制，在修改时候，形成新的自复制，然后在之前的版本上增加一个版本。也就是说历代的版本都会存在，如果该题目被删除，实际在数据库中，仍然存在，只是标记为删除，这样万一在需要启用的时候，可以快速启用。
• 在采纳的审题意见中，也会有一个和版本控制相关的分析和所以，也就是说这里并不是去记录题目的版本，而是记录一个题目修改过程分析的结果。模板：用户:xx，于 xxxx年xx月xx日1、对 题干进行了修改：修改之前为：""，修改之后为:""；2、对选项A进行了修改，修改之前为:""，修改之后为:"".
• 如果在确认步骤中发现，对修改的效果不满意，那么返回以后确认意见，需要用户重新修改。这个时候就会有多条的修改过程，而且应该特别标注对修改结果添加的意见，这个时候可以用一个隐藏的textrear，当这个值为空时候，隐藏，当不为空时显示，可能会有多条，所以这个，应该，要不然，这里不用这么麻烦，当发现修改的不符合的时候，即提出新的会审意见即可。也就是说，在会审意见、修改和确认（也有一个添加会审意见的接口，还有一个通过的接口，如果通过，则标注这个题目的该阶段审核完成，并且该意见的修改完成，如果修改不满意，则新加一个会审意见，重新修改，OK，这样就不需要再去增加相应的字段和环节了，在自身内部就解决问题了）之间形成一个循环。

确认

在index界面其实还是索引的采纳的修改意见。用颜色标记修改人员对采纳的修改意见的执行情况（控制论的反馈机制？，不看那半部控制论基础的基础书籍，估计后面的这几个模块可能会没有了，至少不会这么流畅。所以有空还是系统的学习下控制论和信息论的只是），不过话说回来，其实这些还都是一些状态的标注，也就是说实现了设计上的流，但是IT中的工作流技术还是没有加入进来，或许采用了工作流的技术以后，实现的会更好？这是不是说说，我又做了一些工作流的底层工作，不过也好，自己造一下轮子，也还是可以。

采纳意见的几种修改状态：

• 待修改（此时可以是空，为空，同时又标记为采纳是，标识此为待修改）
• 修改完毕
• 确认完毕
• 重新修改，需要添加备注，对不满意的修改，添加说明（remarks），要求其重新修改。

当确认完成后，说明此条意见修改完。

新增意见提醒

新增题目提醒

统计

工作量统计

• 添加的题目数
• 审核的题目数
• 编辑的字数
• 编辑的图片数。

出卷

便捷性

将危化、打火机、烟花爆竹放在一个系统里，整合完成。

出题的便捷性

设置一个可选的前置，让用户不用每次出题都去选择进行考试、领域、考点、子节点等的选择（不要让你设计的知识体系，或者新加的设计去增加用户的负担），解决方案就是在在index界面做一个折叠的前置选项区域（可以和后面的便捷性搜索进行整合，这些前置可以作为搜索条件，不过这个可以需要在搜索方面做一天整体设计，搜索是增删改查的中的查，只有查的到，才能改的到，删的到，所以查非常重要。这个需要做一个好的搜索的设计，这个也是后面的快捷框架的一个非常重要的部分。）

版本控制

先讨论下实现方案：

• 形成新的entity？
• 在题目中 通过json保存历史版本？
  • 那么删除的怎么办？：通过标记无效来选择如何？

版本控制决定采用json的方式来实现，具体实现过程如下：

• 将题目的一个字段长度变为max，承接相应的版本控制数据，初步定为:ExtIndex3
• 本来想在entity中实现自复制和自增长，但是entity中的需要添加新的引用才能实现，为了不破坏原来的结构，觉得还是在外面来实现。

进度

基本问题都已经解决，还差几个方面

• 图片的上传和管理
• 下拉菜单，选择控件，自动填充等
• 表单的验证和校验，主要是对用户填写表单的检验，主要是一些约束。
• 体系建设

初步来算，这个周就完成了。另外还需要加入培训的内容

培训部分，主要需要解决几个问题

• 培训课件的存储和保护
• 课件的播放和控制
• 页面的美化
• 测试
• 交互
• 培训效果的检验。

图片的操作

• 上传
• 显示

上传

参见另一篇文章，或者是等会发布一下，给一个连接

显示

判断一下 图片地址是否为空，不为空，就让预设

体系建设的完成

在原来的item及itemdetails的基础上进行设计，其实主要是协同，然后建立一个引用的规则，涉及到后面在引用的时候的多级引用的函数等等。其中还包括对建立者的友好和对引用者的友好。这里的主要作用是出于对控制的需要，还有就是便利性的需要。

• 建立
  • 在建立字典类别的时候，同时建立相应的details，类似于一种自关联和自繁殖。也就是相当于，在创建自己的时候，把自己放到家族的族谱中，以便可以添加下一代。这里需要研究一下lr中的设计。最好能抽象出来一个体系建设的模式。

具体实现：在创建itemdetails的时候，同时创建item，或者是在创建item的时候，创建itemderails

• 考试的添加（例如危化，打火机,烟花爆竹等，可以拓展到其他考试）
• 领域的添加
• 考点的添加
  原则上是设置为五个级别，但是并不强制。体系，用户自己来建立，越精致致，后面越省事。因为这里的便捷性主要是为了后面出题的时候方便。
  • 依据（例如法规，标准，作业指导书）
  • 章
  • 节
  • 段
  • 点
    不强制用户，按照这个层次建立，用户哪怕可以只建立一级的目录。只不过是后面想出题的时候省事的话，会比较麻烦。题外话，为了培训期间，其实应该添加课程类别的。不过这里本身依据课程区分的话，也难以做到知识点和培训之间的拼装，多加一个课程，相当于定死了课程和知识体系之前的联系，但是实际情况是知识点或领域可以分属多个课程，所以这里还是不多增加这个所谓的课程的标签索引了。

作为改良版本，暂时只加领域和考点的维护。

因为这里是嵌套的增加，所以应该做好删除的更新的装备，例如我创建的时候，可以传递，但是更新或删除的时候，如何做好更新。

基本路线：

• 先实现同时创建
• 分好目录
• 做好更新和删除
• 做好引用的设计

再加上后面的选项设置。这样就只剩下表单的验证（这一部分貌似不是必须强制做好的，可以在后面不断的优化，因为预设值一些验证，验证通不过，不能进行下一步，可能设置的验证上有一些无法）

领域维护

方式选用，从item创建，包含itemdetails创建，原因是，从ui对用户的友好度上考虑。

 

领域维护

让左侧只显示当前领域的领域。左侧显示该领域下的节点树。如果不选择领域，则显示全部的全部领域的节点树。

 

让左侧只显示领域
筛选的encode，即可，在control中写一个新函数即可。
左侧的显示，只希望显示相应的培训的领域。也就是说是一个二级目录，并且一级目录只有1个。

• 通过request 获得encode，然后通过action获得相应的数据，在action中进行筛选。

知识体系维护做完了。
只是体系不需要details，虽然最好是加，但是因为涉及到增删改查。本身item需要判断是否有子孙才能删除就已经很麻烦了，为了减少bug，还是不加的比较好。

另外，题型等，需要加。不过这些可以用isnav进行区分，或是在description进行区分。，利用description进行特定的删选。

为了增加用户友好度，在新增体系处增加默认值，也就是说，点击左侧以后，会给一个默认的领域。parent

下面要完成的是便捷性

便捷性

想做点好玩的

将培训的一些想法做个实现：
例如 这个系统的使用做一个培训：
出题资格的申请：

• 用户需要进行培训
• 培训完以后进行考核
• 考核以后进行申请
• 对申请进行审批

上面本身其实也是改良后的，且不深究，一般的过程如何，不过在出题申请这个场景，出于一些便捷需要，应该进一步改良（这些需要：主要是应对使用场景中的实际操作及流程，因为即便理论上是好的，但是在实际实现过程中，便利化总是逐步实现的，所以如果实际操作非常繁琐，工作量大的话，并不利于系统的使用）
实际过程为

• 用户发起申请，系统（或人工）为申请人分配培训教程
• 培训（可以看，也可以不看，看的时候，系统会记录看的时间等）
• 收看过程中，会根据视频的内容，不断跳出一些小测验。并记录答题情况。
• 所有教程看完后，进行考核，
• 发起权限申请（也可以是对通过的，系统自动发起申请，后台管理员给予审批）

当然这个实现比较简单，但是咱的特色是啥呢？是做教程的管理和控制，提高出题人和管理人员的效率。坚决不做需要人肉运维的系统。

 

 

文章有点乱，因为一直还在写，写完以后再规范化一下。还要把这个过程中用到的东西，标准化以后加入到敏捷快发框架中。