關於辦公自動化系統的設計與實現

辦公自動化系統就是使用計算機系統執行一系列辦公操作。下面YJBYS小編為大家搜索整理了關於辦公自動化系統的設計與實現，歡迎參考閲讀，希望對大家有所幫助!想了解更多相關信息請持續關注我們應屆畢業生培訓網!

利用網絡通訊基礎及先進的網絡應用平台，建設一個安全、可靠、開放、高效的信息網絡和辦公自動化、信息管理電子化系統，為管理部門提供現代化的日常辦公條件及豐富的綜合信息服務，實現檔案管理自動化和辦公事務處理自動化，以提高辦公效率和管理水平，實現企業各部門日常業務工作的規範化、電子化、標準化，增強檔案部門文書檔案、人事檔案、科技檔案、 財務檔案等檔案的可管理性，實現信息的在線查詢、借閲，最終實現“無紙”辦公。

　　1需求分析

　　1.1功能需求

本系統是為某校辦公自動化的需要而開發的，該學校需要解決如下問題：創造一個集成化的辦公環境;支持信息傳遞;提供具有工作流性質的處理過程和監督功能;提供集成處理與發佈信息的工作平台;實現文檔管理的自動化;提供與其它管理信息系統( MIS )的信息交流。

　　1.2功能介紹

辦公自動化系統功能介紹

　　1.3 流程圖

公文流轉系統分為三個功能模塊。

(1)發文管理模塊：發文管理即各個部門提交報文，文件不指定路線，由發文的個人制定流程，報文以附件方式傳送，每個用户只需要選擇“轉呈”下拉菜單中的下一轉呈人，該公文就會自動流轉到下一個處理人手中，由每個客户端成員查看文件，履行相應動作，並繼續流轉。管理員進行最後的處理。

(2)收文管理模塊：收文管理模塊顯示了所有需要簽收的公文記錄，處理人只要點擊查看，並進行相應的動作，公文就會按照流轉路線向下一個處理人傳遞。

(3)公文跟蹤模塊：公文跟蹤管理功能提供對單位內部所有在流轉公文狀態的跟蹤、查詢，根據工作的實際需要可以對這些功能進行催辦、刪除和改變流程負責人等功能。

　　2辦公自動化系統設計

　　2.1系統設計目標

系統的總體設計目標是：基於計算機網絡，提供一個安全可靠的、方便實用的辦公平台，在這個平台上，該學校用户可以高效地處理各種公文。根據前文的用户需求和總體設計目標，我們將某校的辦公自動化系統的具體目標歸納為：(1) 切實可行的公文處理能力;(2) 穩定性、健壯性和安全性;(3) 可定製的流程控制;(4) 可監控的辦文痕跡;(5)良好的集成功能;(6) 快速的開發過程。

　　2.2系統框架及功能劃分

　　2.2.1系統框架

初步決定將系統劃分為五個部分：

(1)公文處理，包括髮言、行文、通告、會議紀要;

(2)個人工作台，包括個人郵箱、日程安排、修改密碼;

(3)公文監控，包括來文監控、查閲監控、公文痕跡;

(4)系統管理，包括編號管理、流程安排、權限管理;

(5)系統集成，包括與Word和Excel在集成。

　　2.2.2系統功能劃分

(1)公文處理模塊。公文處理模塊負責處理各類公文的辦理，各類公文從起草、審核到發佈等這些過程都是在這個模塊完成的，在這個模塊裏要為各種公文設置不同的外觀，每種公文的界面裏有調用WORD和導出WORD的功能。

(2)個人工作台。個人工作台用於對本人各項工作進行統一管理。個人郵箱存放着屬於自己的各類公文，別的用户無法進入，郵箱有提示功能，突出顯示未辦或未閲公文，郵箱裏的草稿公文是由於是自己創建的，可以刪除，已經閲讀過的成文公文也可以刪除，待辦公文不能刪除;日程安排用來安排本人的日程和活動，起到提醒的作用;修改密碼用來更改用户個人的密碼;公文查詢用來搜索查看自己有權限的公文。

(3)公文監控。公文監控提供公文從草稿到成文的辦文痕跡，記錄什麼人什麼時間對該公文做了什麼事情。

(4)系統管理。系統管理員負責辦公自動化系統的公文字號管理，用户權限管理和流程走向管理。

(5)信息集成。信息集成模塊負責向該學校門户網站發送通知公告類的公文。在學校的網絡中已經實現了與門口網站的連接。

　　2.3系統詳細設計

　　2.3.1 公共模板的設計

柔性工作流着重強調系統的可重構性、可重用性和可擴展性，系統框架圖裏公文處理模塊裏面包括了多種公文處理子模塊，但這些公文處理子模塊其實有很多過程是相似的，如果我們把這些功能相似的部分做成可重用的模塊，即可以達到快速開發的目的又能使系統增加一定的柔性，再者，如果要修改各公文處理子模塊代碼時，只需更改模板的代碼，而由模板生成的`其他子模塊則能夠自動更新。在本文中，我們把這個模塊稱為“公共模板”。

　　2.3.2 流程部分設計

在設計流轉機制時，本系統在處理時將所有待處理的公文進行分類，然後針對每一類公文和處理該公文的對象來確定相應的流轉規則，並在系統建模階段將該規則寫入數據庫中。

假設現有部門A、部門B和部門C，同時有公文a、公文b和公文c。針對這三個部門和三類公文，我們可以設計一個簡單的流轉規則。對於公文a，只能由部門C起草，部門 B和部門C可以接收、發送，而部門A只能回覆;對於公文b ，部門B和部門C都能起草，但只有部門C能接收和發送，其它部門只能回覆;對於公文c，所有部門都能起草、發送和接收。該規則可以用相應的狀態

　　2.3.3 權限管理的設計

一個OA系統中有很多參與者，而且一般也有多種公文;每一類公文針對不同的參與者又有不同的權限。為了解決這個問題，可以引入RBAC(Role-Based Access Control)技術，先將用户按部門和職責分組，再根據需要定義一些角色(比如起草、審核、回覆、簽發、發佈等) ，然後將相應的組分配相應的角色。實現時要將角色設置遊離出業務邏輯，設計可配置的單獨模塊，獨立於業務邏輯;而業務邏輯裏判斷的只是角色，不涉及到具體用户。這樣設計後，人員變動、權限更改就不會影響整個系統的應用邏輯。 　　3辦公自動化系統實現

　　3.1公共模板實現

(1)所有文檔：顯示所有文檔;

(2)草稿文檔：顯示起草後未提交審核但保存了的文檔;

(3)刪除的草稿文檔：從草稿文檔視圖內刪除了的文檔;

(4)已發佈公文：已經成文並經過校辦公室發佈成功的文檔;

(5)已回收公文：由於起草錯誤或發送錯誤而傳遞到用户郵件數據庫裏的已成為公文可以被回收，所有回收的公文被放入該視圖;

(6)預歸檔文檔：在前文已經介紹，歸檔部分要與該學校的另一個系統銜接，所以本系統裏的歸檔只是預歸檔，僅僅將公文的狀態設置為歸檔;

(7)在審核文檔：所有起草完畢並已提交審核但未成文文檔。

　　3.2表單

我們採用了三種表單：草稿表單、審核表單和成文表單。

(1)輸入文本：公文草稿，當用户起草時，使用該表單，它有“本部門審核”、 “校辦公室審核”、“校對”等操作，

(2)處理文本：審核公文表單，整個審核期間的文檔都用此表單，它有“獲取編號”、“提交部門領導審核”、“提交校領導審核”、“保存”、“回覆”操作等。

(3)成文表單，當公文完成上述流程後，公文接收者看見的文檔就是以Doc表單打開的，它含有“關閉”和“打印”操作，除了這兩個操作外，還為祕書設計了錯發而設計的“收回”操作和因為漏發而設計的“補發”操作以及公文歸檔設計的。

　　3.3郵件模板的實現

　　3.3.1 代理

為了自動或後台運行一些任務，我們為郵件數據庫定義了一些代理，其中有個使用最頻繁的代理mailprocess，此代理的觸發條件設置為“郵件到達之前”，主要的功能是將收到的文檔按狀態分類，供不同的視圖使用。

　　3.3.2 應用與郵件的集成

在工作流的應用開發中，郵件和應用程序將集成在一起。當需要時，可以通過開發的應用程序向上級部門發送一個郵件，在郵件中將申請以及連接文檔以郵件的形式發送給相關領導。

　　3.4數據庫實現

本系統採用用户-角色-模塊的三層安全模式，第一層為用户，第二層為角色，第三層為系統模塊。用户和角色之間建立關係，角色和模塊權限之間建立關係，而用户和模塊權限之間沒有直接的關係。此模型將系統的模塊權限和用户分開，使用角色作為一箇中間層。用户訪問模塊時，通過其所在的角色對模塊的訪問權限來獲得訪問該模塊的權限，通過這種分層的管理模式可以實現有效的權限管理。

　　3.5權限管理實現

Domino在實現時可以用ACL來完成，Domino是帶有RBAC技術的羣件開發工具，它的Domino Admin可以進行用户設置和羣組劃分，它的Domino Designer除了可以進行正常的程序開發之外，還可以針對某個數據庫文件定義角色，並可以通過該數據庫文件的ACL將角色分配給相應的用户組和用户。具體實現時可以在某類公文數據庫的ACL裏定義一些角色。

　　3.6監控數據庫的實現

監控數據庫在實現時主要是創建了三張表單和若干個視圖和一個代理。三張表單，每張表單對應一類監控信息。在表單的上半部顯示公文的基本信息，下半部顯示公文痕跡信息，在下半部的這個帶附籤的表格裏，第一項標籤有“收文單位”、所有應接收人員、補發收文情況、流轉序列四項;代理用來將辦公痕跡寫到文檔裏。