试系统设计

基本思路是由总负责人规划领域
每个领域的负责人规划范围（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），要求其重新修改。

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

新增意见提醒

新增题目提醒

统计

工作量统计

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

出卷

便捷性

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

版本控制

先讨论下实现方案：

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

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

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