ＵＭＬ用例建模在《電子公文歸檔移交系統》需求分析中的應用

摘要：電子公文的歸檔工作是檔案管理工作和電子政務建設的重要內容之一，電子公文歸檔系統作為一個連接辦公自動化系統和數字檔案管理系統的橋梁，在文檔一體化管理體系中占據著重要位置。建設電子公文歸檔系統首先要從需求分析做起，確定系統“做什么”的問題。將UML（統一建模語言）的用例模型應用到電子公文歸檔系統的需求分析中可以更有效的獲取系統需求，并清晰描繪出系統需求。

關鍵詞：電子公文歸檔系統 ；用例圖 ；活動圖；需求分析

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)36-2658-04

Design Usecase Moodeling of E-document Transfer System in the Process of Requirement Analysing

JING Jing

(School of Information Managemet， Wuhan University， Wuhan 430072， China)

Abstract: The E-document transfer system is a important matter of the archive manage job and E-government constrcuting. It's a bridge which link the OA system and the Digital Archival Management System. The basic of building E-document transfer system is requirement analysis， making sure the problem of \"what to do\". With the Usecase， we can capture the system requirements in E-government constrcuting， and describe system requirement definitly.

Key words: e-document transfer system; usecase diagram; activity diagram; requirement analysis

1 UML中的Use Case及在需求分析中的應用

UML(unified modeling language，統一建模語言)是一個通用的可視化建模語言，用于對軟件進行描述、可視化處理、構造和建立軟件系統制品的文檔。使用UML建立模型的重要內容就是利用用例圖、靜態圖、行為圖、交互圖、實現圖來定義模型。建立用例圖（Use Case Diagram）則是開發軟件工程的第一步，以后的各項工作都是圍繞著如何實現這個Use Case模型展開。

需求分析是軟件工程開發中最為關鍵的一個過程，需求分析的質量決定著用戶的滿意程度、產品質量高低、系統開發的工期、功能的完整程度等。對系統需求進行建模時，要將需求分析首先轉化為用例，即用用例圖清楚、準確地表達系統功能需求，使系統投資者、項目開發人員和系統用戶達成一致的理解，并且用來指導項目開發人員的后續工作，以后的各項工作都以Use Case圖為中心去開展。可以說，用例圖驅動著其他模型的開發，是整個系統需求的核心。

所以，通過使用UML的Use Case用例模型從系統的功能結構和行為出發對將要開展的系統進行建模，能夠更好的了解到用戶需求，幫助系統開發人員了解到“誰來做”、“做什么”，同時也能夠避免因需求分析不清而導致的一系列問題，更徹底的了解用戶對整個系統需求。

2 電子公文與電子公文歸檔移交系統

電子公文歸檔系統所作用的對象是電子公文，電子公文是公共機構產生的、專用于處理公務活動、具有法律效力和規范格式的文本型電子文件。電子公文歸檔移交工作的流程是從電子公文的收集和積累開始，再對電子公文進行整理編目，交付檔案室進行歸檔，然后整理、登記、分類，之后存入檔案室庫房。檔案室保管以歸檔的電子檔案，并對本機構提供利用服務。檔案室中的檔案在本單位保存一定期限后，定期向檔案館移交有價值的檔案。根據電子公文的歸檔管理流程，可以看出，電子公文歸檔系統是一個能夠支持電子文件歸檔業務流全過程的自動化信息系統，它將辦公自動化系統和檔案館的管理信息系統連成一體，是介于辦公自動化系統與數字檔案館系統之間的自動化中間系統。

電子公文歸檔移交系統的核心功能是實現電子公文的順利歸檔和移交。歸檔是與辦公自動化系統的公文交換，而移交則是與數字檔案館系統的公文交換，電子公文從辦公自動化系統中接收過來，經過電子公文歸檔移交系統的整理、驗收，在完成待定期限的保管后實施相應的處置措施，并將具有永久保存價值的電子公文向數字檔案館移交。

3 使用用例圖描述需求

建立用例模型（Usecase diagram）首先需要進行角色(Actors)確定，Actors代表一個系統的使用者或外部通信的目標。用例是系統中的一個功能單元，可以被描述為參與者與系統之間的一次交互作用。用例模型的用途是列出系統中的用例和參與者，并顯示哪個是用例的執行。

3.1 確定參與者

參與者是系統的主體，表示提供或接收系統信息的人或系統，他們是與系統有交互作用的人或事物，通常代表了一個系統的使用者或外部通信目標。本系統的參與者有公文歸檔移交系統、文件負責人、檔案室、檔案館。

公文歸檔移交系統，是生成、存儲、傳遞文件的信息系統，也是為參與者提供輔助技術支持的輔助系統，由于它幫助參與了歸檔移交業務，其本身就可以看成歸檔移交業務的一個參與者。

文件負責人是在電子文公歸檔前，完成公文的收集、分類、整理、統計、數據修改維護的操作。在電子公文歸檔之后文件形成機構還能對電子公文進行查詢、檢索及目錄與數據信息打印。

檔案室完成在線接收各部門的電子文件（含文本文件、圖像文件和多媒體文件等）和電子檔案的業務。并與機關各部門實現網上信息交互傳遞，實現各部門電子檔案的規范管理，定期將電子檔案導入數字檔案館管理系統，通過數字檔案館政務網站和互聯網站為各級黨政機關和人民群眾提供及時的檔案信息服務。

檔案館通過政務網，完成對檔案中心目錄與原文數據的接收業務。遠程對機關檔案工作進行業務指導，幫助機關檔案工作人員解決工作中的具體問題，做到業務監督指導的“零距離”、“零延誤”。

圖1 公文分類業務用例圖

圖2 鑒定業務用例圖

3.2 使用用例圖描述需求

3.2.1 公文分類業務用例圖

電子環境中，系統首先判斷公文的類別，給公文以分類標記。此分類標記由系統提供選擇，可以與公文的登記號合一，也可不同。當不存在公文的類別時，需要創建公文集合，再將公文歸類到相應的公文集合類別中。檔案室的工作人員對文件集合的創建與文件歸類情況通過電子公文歸檔系統進行核查。（圖1所示）

1) 公文分類標記用例的需求說明：

在系統下拉菜單中選擇文件類別，選定后系統賦予文件以分類標記。

這個過程中要需要的需求有：①系統能支持類目兩種以上的命名方法，并保證可以同時在某一特定層級上使用。命名方法包括依據分類方案中的分類名進行命名和依據分類方案中的分類編號進行命名; ②保證分類標記在同一類目下的唯一性，允許在不同文件集合下文件分類標記有重復; ③自動賦予該公文的上位類標記信息。

2) 創建文件集合用例的需求說明：

①系統提供分類方案的查詢，機關公文負責人選定分類方案。

②系統將分類方案予以集成，建立文件集合，自動生成集合創建時間，授權用戶自定義文件集合名稱。

③當分類方案的設計和配置需要修改時，修改文件集合，并可將集合內公文重新分類。

④在創建文件集合過程中，禁止用戶在已存在的文件集合中創建子類，避免文件集合與文件在同一層級出現。

⑤創建同時給文件集合自動編號，自動生成創建時間。

⑥創建新文件集合的同時在新的文件集合中標識其上位類的信息。

圖3 歸檔業務用例圖

圖4 移交業務用例圖

圖5 電子公文系統用例圖

3) 公文歸類用例的需求說明：

①找到相應的文件集合，此文件集合必須是集合中的最低一級。

②向文件集合中添加電子公文，再確定完成電子公文添加之后，用戶可以鎖定文件集合使之狀態變為可讀。

③若發現有遺漏或需修改，則重新開放已鎖定的文件集合。

④在文件集合發生變化時，允許文件集合下的公文重新歸類。

⑤當電子公文歸類需要修改時，允許公文重新歸類。

⑥將此過程中的元數據進行著錄，如果元數據有繼承的，要與其上位類元數據進行動態鏈接。

3.2.2 鑒定業務用例圖

如圖2，機關公文負責人將要歸檔的公文數據提交到公文歸檔系統中，系統根據預定規則進行初步鑒定，識別此數據單元是否是公文。系統根據預定規則自動判斷某文件是否具有保存必要，根據文件的信息類別，即其記錄、支持的業務職能，參照《電子文件保存期限表》，自動判斷文件的保存期限。檔案館工作人員對文件的真實性、完整性、可讀性進行鑒別。

1) 確定電子公文保管期限用例需求說明：

①系統根據公文元數據信息，參照《電子文件保存期限表》作出相應的運算。

②若以月為單位，系統以1-11個月進行計算；若以年份為單位，系統以1-100年進行計算；若為年份和月份的結合單位，則結合以上兩種假設進行計算。計算后系統得出公文保管期限。

③若系統得出保管期限與《電子文件保存期限表》或人工判斷不符合，則進行人工修改。

2) 公文處置用例的需求說明，公文處置包含了三種措施分別是復審、遷移、銷毀。

①復審是對初次鑒定的一次過濾，決定了電子公文未來的命運。復審結果分為三種一種是具有電子公文永久保存價值待移交檔案館；一種是繼續保存在電子文件保管系統中有待本機構利用；還有一種是將電子公文銷毀。復審帶來一系列變化應記錄在系統日志中。

②若電子公文需要銷毀，在可擦寫介質上保存的公文，其類目、案卷、公文的數據從介質上被完全刪除，且不可恢復。在一次性介質上的公文，系統銷毀與此介質的所有鏈接，使此介質無法鏈接到本系統或操作系統。系統最后保存一部分已銷毀的元數據信息。

3.2.3 歸檔業務用例圖

當登記的對象為公文時，系統根據編號規則，對公文進行登記賦予公文的唯一標識，系統同時記錄文件的名稱、形成部門、創建時間等信息。當登記的對象為公文集合時，由檔案人員在系統中創建有關類目。系統根據文件鑒定結果，賦予文件以檔案身份，形成電子檔案的檔號。進入電子公文歸檔系統的電子檔案，進行按照移交檔案的標準進行再次分類，電子公文歸檔系統將公文的在其生命周期內的所有信息包括背景信息、內容信息以及文件系統信息的元數據。并對電子檔案進行維護。對于歸檔后的電子檔案及其目錄信息，機關負責人可以即使查詢。

1) 登記公文用例的需求說明：

①如果電子公文有多個版本，用戶可選擇將所有版本登記為一份公文，或僅登記其中一份版本，或將每一個版本登記為一個獨立文件。

②選定，瀏覽公文登記表。

圖6 電子公文歸檔用例活動圖

圖7 電子公文移交用例活動圖

③系統根據電子公文的元數據，進行一些項目的自動登記。

④根據電子公文的元數據，系統向用戶提供一些與項目所對應的公文元數據的可視化選擇，同時也可人工錄入登記項目。

⑤登記完成后，提交給系統。

⑦系統將登記的時間和日期作為元數據進行保存。

2) 歸檔用例的需求說明：

①將公文劃歸為一個或多個案卷。

②系統根據公文的元數據列出相關類目和案卷目錄。

③當同一份公文在同一個案卷中進行的登記時，系統給予提醒和阻止。

④接收公文，確定接收公文的所有內容，包括定義文件類型、文件格式、文件結構的相關信息，對公文的完整性、真實性、可讀性是否具備加以提示。

⑤接收公文的相關元數據，并保證與電子公文的關聯性。

⑥選擇歸檔方式，即時歸檔或定期歸檔，選擇即時歸檔則將選中公文狀態即時變更為“已歸檔”，若選擇定期歸檔則等到期時系統向用戶發出通知提醒，再對公文狀態進行更改。另外還可以選擇網絡歸檔和介質歸檔，選擇介質歸檔，系統直接鏈接輸出設備，將公文脫機保存于介質上。

⑦給公文賦予檔號，成為電子公文的唯一標識。

⑧歸檔后系統將公文生成一份以系統默認格式存在的原電子公文文件轉換本。

3.2.4 移交業務用例圖

按照國家法律規定，將有社會文化價值的電子文件移交給檔案館。現階段移交的情況有兩種：一是信息系統根據文件的保存期限自動判斷文件是否應該移交，并對應移交的文件通過安全網絡傳送到指導位置；二是檔案人員根據系統的判斷結果，將移交文件脫機保存在一定的介質上，將介質移交至檔案館。

公文移交資格判斷用例的需求說明。在系統的決策支持下人工判斷待移交的電子公文是否符合移交條件，移交條件主要有以下幾點：

①電子檔案是否是最后核定的定稿；

②電子檔案是否具有永久保存價值；

③電子檔案的真實性、完整性、有效性和可讀性；

④電子檔案包括的公文原件、相關元數據、歸檔時的日志文件、內容留痕和留真信息以及電子公文在本系統中的管理和使用日志。

⑤移交電子公文格式是否符合規定格式要求，專用軟件產生的格式需要轉換，無法轉換的隨文件一同進館。

⑥電子公文與元數據關聯完好，元數據格式符合要求。

3.2.5 電子公文系統用例圖

在電子環境的公文歸檔移交業務與傳統公文管理的區別就是著錄需要貫穿于文件的整個生命周期之中，它需要記錄文件形成、管理、利用的全過程。這樣著錄業務在內容和時間上都與傳統公文管理活動有所區別。為了保證著錄信息的準確性，在電子環境下著錄被提前到了公文形成之前，由電子公文著錄管理系統來完成對電子公文在整個生命周期活動的著錄。在公文的不同階段，所捕獲的元數據不同，元數據在系統中不斷被積累。跟蹤是電子公文系統根據事先的定義自動記錄電子文件生成、處理和保管過程。統計是根據預先定義自動生成有關的臨時性報表。公文每個不同的階段都在發生改變，在電子環境下文件系統也處于不穩定的狀態，應對公文進行實時備份。權限控制用于控制各類用戶的訪問權限。

4 使用活動圖描述關鍵用例

在需求分析中，需要用活動圖對復雜用例加以描述。活動圖實質上也是一種流程圖，表現的是一個活動到另一個活動的控制流。其基本圖形元素有動作狀態、動作流、泳道、對象等。

4.1 電子公文歸檔用例

如圖6歸檔公文驗收與公文整理過程之間是靠“歸檔申請單”和“驗收通知書”進行聯系的。檔案室首先接到來自機關公文責任人提交的“歸檔申請單”，根據申請單中所列目錄調閱對應的公文進行檢查驗收，驗收完成后，賦予公文以檔案身份。這個活動在系統中表現的結果為系統將公文的狀態變為已歸檔，自動生成電子檔案帳目，顯示檔案存放的邏輯地址。同時，系統向機關公文負責人發送驗收通過通知。如果驗收沒有通過，系統則向機關公文負責人發送返回修改通知，機關公文負責人可根據情況選擇重新申請或者退出歸檔。歸檔結束后公文傳送到機關檔案室，等待登記、整理、入庫。系統在此活動中著錄元數據。

4.2 電子公文移交用例

如圖7，電子公文的移交用例由檔案室和檔案館負責，其最終結果是將電子公文、公文目錄、元數據及其關聯信息由電子公文歸檔移交系統進入數字檔案館系統中。根據實際移交工作流程，可以看出系統至少要滿足兩種移交方式的需求。一是在線移交，檔案室向檔案館提交移交檔案目錄，檔案館調閱文樣進行驗收，符合移交條件的由檔案館負責選擇公文存放的邏輯地址，通過安全網絡進行在線移交，判斷公文、目錄信息元數據及其關聯信息在移交過程是否受到破壞，數據完好則著錄此過程產生的元數據，然后將公文、目錄信息、關聯信息及元數據一并進入數字檔案館管理系統中。二是脫機介質移交，移交公文符合移交條件，驗收合格之后，檔案室根據移交檔案目錄中的相關公文數據導出，一部分紙質檔案通過打印輸出，還有一部分文本文件、圖像文件和多媒體文件等數據脫機保存于一定介質中，一并移交到檔案館。

5 結束語

電子公文歸檔移交系統是建立在電子政務網和數字檔案館基礎之上的“虛擬”文件中心，為保證各部門形成的電子公文、電子檔案其信息的齊全、安全、有效和長期可讀，加強進館檔案的監控與移交，保證進館檔案質量提供了有效的保障。但是電子公文歸檔移交活動具有復雜性，系統參與的對象眾多，對電子公文歸檔移交建設前的系統需求獲取比較困難。運用面向對象的建模技術，特別引入對用例圖建模的技術，可以有效的解決這個困難。通過對電子公文歸檔移交系統用例的建模與對用例的分析，軟件開發者可以準確的了解用戶需求與系統功能，檔案工作人員也可對系統功能有更直觀的印象，從而參與軟件開發的專業指導之中。

當然，需求分析階段是一個迭代的過程，需要不斷的調查、分析和總結，只有不斷的實踐才可使獲取的系統需求更加完善合理。

參考文獻：

[1]Jacobson I.Object-Oriented Software Engineering:A UseCase Driven Approach[M].NewYork:Addison-WesleyPublishing Company，1992:16.

[2] 薛四新.檔案信息化應用系統建設[M].北京:機械工業出版社，2006:110-120.

[3] 國剛，周峰，孫更新.UML與Rational Rose 2003軟件工程統一建模原理與實踐教程[M].北京:電子工業版社，2007:96-111.

[4] 吳建，鄭潮，汪杰.UML基礎與Rose建模案例[M].北京:人民郵電出版社，2007:56-65.

[5] 謝海新.電子公文歸檔移交系統功能研究[D].天津:天津師范大學，2006.

[6] 劉麗， 夏友斌.Use Case建模在數字圖書館系統中的應用[J].圖書與情報.2002(2):58-61.

[7] 沈曉近.基于UML建模的圖書館信息管理系統的分析與設計[J].現代計算機，2007(26):108-110.

[8] 劉越男.建立新秩序——電子文件管理流程研究[M].北京:中國人民大學出版社，2005:185-273.

[9] 李力鋼.建立“電子文件歸檔系統”探析[J].蘭臺世界，2007(3):25.