考試系統設計

文章 

基本思路是由總負責人規划領域
每個領域的負責人規划范圍（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

下面要完成的是便捷性

便捷性

想做點好玩的

將培訓的一些想法做個實現：
例如 這個系統的使用做一個培訓：
出題資格的申請：

• 用戶需要進行培訓
• 培訓完以后進行考核
• 考核以后進行申請
• 對申請進行審批

上面本身其實也是改良后的，且不深究，一般的過程如何，不過在出題申請這個場景，出於一些便捷需要，應該進一步改良（這些需要：主要是應對使用場景中的實際操作及流程，因為即便理論上是好的，但是在實際實現過程中，便利化總是逐步實現的，所以如果實際操作非常繁瑣，工作量大的話，並不利於系統的使用）
實際過程為

• 用戶發起申請，系統（或人工）為申請人分配培訓教程
• 培訓（可以看，也可以不看，看的時候，系統會記錄看的時間等）
• 收看過程中，會根據視頻的內容，不斷跳出一些小測驗。並記錄答題情況。
• 所有教程看完后，進行考核，
• 發起權限申請（也可以是對通過的，系統自動發起申請，后台管理員給予審批）

當然這個實現比較簡單，但是咱的特色是啥呢？是做教程的管理和控制，提高出題人和管理人員的效率。堅決不做需要人肉運維的系統。

 

 

文章有點亂，因為一直還在寫，寫完以后再規范化一下。還要把這個過程中用到的東西，標准化以后加入到敏捷快發框架中。