考试系统设计

考试系统设计

文章 

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

设计思路

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

流程

流程图

功能

考试体系

框架

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

出题

题目体系

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

领域规范

题型规范

考点规范

依据规范（标准等）

范围规范

有些题目可能不要了，因此须要标记题目是否有效

审题

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

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

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

审题进度

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

单审的基本流程

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

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

• 审题：全部出题的人员，可能须要交叉进行审题，可是这个时候基本上是一个我的行为，也就是你们是各自为战的。这个时候主要是审核题目，固然也可能会关注其余人提的意见。
• 会审：你们坐在一块儿进行审题。这时候的侧重点是对你们提出的意见进行讨论，并造成最终的意见，也能够是采纳此环节中某我的造成的意见。固然也须要看题。
• 修改：则是针对在该流程中，根据会审造成的意见，或者是采纳的意见。进行题目的修改。
• 确认：根据修改的状况进行，修改状况的检查。

审题的进度应该由管理员来，统一管理，即如今属于哪个进度是一个整体进度，而不该该让用户本身去选择。这样你们在添加的意见的时候，经不用本身去选择是在哪个审题的进度。
可是还有一个问题，就是第一批审完了，可能还须要添加新题目的时候，又须要进行一轮审核。这一批的审核状态和第一批的审核状态是不同的。因此这里最好仍是，让用户本身去选择比较好。

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

聚焦

领域索引

考点索引

题型索引

审题意见

单题审题界面

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

实际效果图：

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

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

新增意见

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

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

审题意见处理进度

会审

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

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

 

会审界面图

 

需完成的两个工做：

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

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

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

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

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

修改

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

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

 

修改界面效果图

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

 

界面完成

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

• 题目的版本控制：题目在建立的时候，会根据时间造成自复制，在修改时候，造成新的自复制，而后在以前的版本上增长一个版本。也就是说历代的版本都会存在，若是该题目被删除，实际在数据库中，仍然存在，只是标记为删除，这样万一在须要启用的时候，能够快速启用。
• 在采纳的审题意见中，也会有一个和版本控制相关的分析和因此，也就是说这里并非去记录题目的版本，而是记录一个题目修改过程分析的结果。模板：用户:xx，于 xxxx年xx月xx日一、对 题干进行了修改：修改以前为：""，修改以后为:""；二、对选项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

下面要完成的是便捷性

便捷性

想作点好玩的

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

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

上面自己其实也是改良后的，且不深究，通常的过程如何，不过在出题申请这个场景，出于一些便捷须要，应该进一步改良（这些须要：主要是应对使用场景中的实际操做及流程，由于即使理论上是好的，可是在实际实现过程当中，便利化老是逐步实现的，因此若是实际操做很是繁琐，工做量大的话，并不利于系统的使用）
实际过程为

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

固然这个实现比较简单，可是咱的特点是啥呢？是作教程的管理和控制，提升出题人和管理人员的效率。坚定不作须要人肉运维的系统。

 

 

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