考試系統設計

考試系統設計

文章 

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

下面要完成的是便捷性

便捷性

想作點好玩的

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

• 用戶須要進行培訓
• 培訓完之後進行考覈
• 考覈之後進行申請
• 對申請進行審批

上面自己其實也是改良後的，且不深究，通常的過程如何，不過在出題申請這個場景，出於一些便捷須要，應該進一步改良（這些須要：主要是應對使用場景中的實際操做及流程，由於即使理論上是好的，可是在實際實現過程當中，便利化老是逐步實現的，因此若是實際操做很是繁瑣，工做量大的話，並不利於系統的使用）
實際過程爲

• 用戶發起申請，系統（或人工）爲申請人分配培訓教程
• 培訓（能夠看，也能夠不看，看的時候，系統會記錄看的時間等）
• 收看過程當中，會根據視頻的內容，不斷跳出一些小測驗。並記錄答題狀況。
• 全部教程看完後，進行考覈，
• 發起權限申請（也能夠是對經過的，系統自動發起申請，後臺管理員給予審批）

固然這個實現比較簡單，可是咱的特點是啥呢？是作教程的管理和控制，提升出題人和管理人員的效率。堅定不作須要人肉運維的系統。

 

 

文章有點亂，由於一直還在寫，寫完之後再規範化一下。還要把這個過程當中用到的東西，標準化之後加入到敏捷快發框架中。