stx col class width 一個人 ali cal tags 規則

試系統設計

文章

基本思路是由總負責人規劃領域
每個領域的負責人規劃範圍（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中的需要添加新的引用才能實現，為了不破壞原來的結構，覺得還是在外面來實現。

考試系統設計