基于j2ee架構的辦公自動化系統的設計與實現-資料下載頁

　　

【正文】 其中struts采用版本為struts2，spring采用的版本為spring2．0，hibernate采用的版本為hibernate3．2。具體的步驟如下：(1)將struts．2的jar包拷貝到webinf/lib目錄下。(2)在web．xml中添加對struts、spring、hibernate框架的支持。(3)框架配置完畢后，開始對web的功能模塊進行開發，由于spring對bean類進行托管以及對hibernate的事務支持，所以bean類的托管需要在applicationContext．xml中配置；；，最后表的映射文件也需要配置。下面具體說明框架的配置過程。 Spring框架配置，添加Spring監聽器。Spring提供了一個ContextLoaderListener類，可以作為Web應用的Listener使用。Web應用啟動時會根據該文件創建Spring容器。 struts配置，添加如下代碼：為了使Spring和Struts同時工作。 Hibernate配置，添加如下代碼： 系統構架設計本系統采用J2EE的B/S架構，J2EE是一個分層的架構體系，由四層組成：客戶端層、表示層、業務層和系統數據層。客戶端層：客戶端層通過瀏覽器訪問系統，在服務器端采用tomcat作為J2EE的服務器，表現層采用的是Struts架構。表示層：表示層采用Struts框架。Struts是一個基于模型視圖控制器（MVC）模型的開源框架，利JSP和Servlet構建Web應用。，負責管理用戶的請求，并做出響應。業務層：業務層由Spring框架來實現。該層負責應用程序的業務邏輯處理、業務驗證、管理業務層的對象間的依賴功能以及與其它層交互的接口。系統數據層：辦公自動化系統的數據庫。存放系統支持的數據及業務數據。本系統采用Oracle10g的數據庫管理系統。為了保證業務居和數據層的高連接，在系統中配置了一個持久層，持久層采用了Hibernate框架，對數據對象進行包裝，構建一個通用的數據處理模型，讓不同的項目無縫的連接。1．客戶機/服務器結構在Client/Server，即客戶機/服務器結構的數據庫系統中，數據的處理不是在單獨一端進行的，而是在客戶機和服務器間同時進行。數據的分布方案并不唯一，根據不同需求可以選取不同方案。客戶機負責處理應用程序，數據庫負責數據訪問是最常用的一種分布方案。這種工作方式根據客戶端和服務器的性能和作用，將數據分別分布在客戶端和服務器上，是一種高效的工作方式。不僅能夠充分利用網絡資源，實現了資源的合理分配和優化，更提高了系統的工作效率和穩定性。不過任何一種結構都有優勢和劣勢。這種系統的維護費用比較大，而且保密性還有待提高。2．Browser/Server結構Browser/Server結構是一種以網絡為中心形成的拓撲結構。這種結構維護簡單方便，數據庫和應用程序都集中在服務器方，克服了C/S模式維護費用大，修改麻煩的缺點。而且客戶方只需要安裝一個簡單的瀏覽器，使用起來十分方便。B/S模式基于三層體系結構，能充分發揮客戶端和服務器的優勢，均衡了系統負載，是一種安全、成熟的系統。Web Server是中間代理方，服務器在后臺管理數據，通過Web Server這個中介傳輸給客戶端。經過以上分析，Browser/Server結構是本系統的最優選擇。如圖41所示。企業用戶可以通過客戶端瀏覽器訪問Domino服務器。同時可以實現交互式的數據更新和信息發布，方便各部門與同總部進行溝通。WEB瀏覽器Web瀏覽器郵件服務器其他應用Notes Web PublishNotes APINotes 客戶端Notes 服務器Web與RDBMS的接口RDBMS用戶層應用層服務層圖41系統體系結構圖在項目的開發過程中，要遵循一定的順序，先開發處于結構底層的組織級構、權限管理等基礎模塊，常見一個大體框架，在此基礎上再開發流程管理、公文管理等附加功能模塊。開發的過程通常分為以下三個步驟：第一步：初始階段。是開發過程的基礎，主要完成需求分析，并根據需求創建模型和系統結構體系，生成系統大體架構。第二步：細化階段。在第一步的基礎上，設計并完成實現用例。第三步：實現呈現層。將前兩部設計出來的系統通過前段界面和后臺數據庫等工具實現出來。 組織機構管理經過調查發現，組織機構中的實體類有兩種：Organization類（機構）和Person類（人員）。Organization類包含三個屬性：機構編號、機構名稱和機構描述。Person類包含五個屬性：員工編號、姓名、性別、職務、電話。機構類和人員類的關系為：一個機構下可以有多個子機構；一個機構有多個人員。為了更好的組織和管理機構和人員信息，設置了組織機構管理模塊，主要實現機構信息的增、刪、改、查；人員管理模塊主要完成人員信息的增、刪、改、查。下面以機構管理模塊為例，說明機構管理模塊的詳細設計。系統設計一個機構管理類：OrgManager。OrgManager類包含如下五個函數：（1） SearchOrgs（int ParentID）函數。ParentID是控制結構模型的變量，返回值是一個分頁模型。當其值為0時，系統將搜索頂極機構列表。（2） ReadOrgs（int OrgID）函數。此函數讀取機構信息，返回值為一個Organization對象。（3） AddOrgs（Organization Orgs，int ParentID）函數。此函數用于添加機構信息。如果ParentID為0，則表示建添加一個頂機的機構。（4） UpdataOrgs（Organization Orgs，int ParentID）函數。這是一個更新函數，可以將機構信息及時更新。（5） DelOrgs（int OrgID）函數。這個一個刪除機構信息的函數。執行此函數前一定要確保此機構下沒有子機構和人員。人員管理模塊的實現方法和機構管理相似，這里就不在做過多的敘述。 權限管理辦公自動化系統有許多不同模塊構成，每個模塊需要設置訪問權限，以區別不同的用戶級別。模塊的授權是根據角色來分配的，以角色為主。設置權限之前，要先設置好權限，再根據不同用戶和角色進行權限分配。每個用戶必須有一個角色，而且可以同時擁有多個角色。在某些特殊的情況下，還要求能單獨對用戶進行授權。本系統使用授權控制列表來存儲授權信息。權限控制列表的屬性主要有：角色標識、ID、模塊ID和ACLSTAT。權限控制列表的屬性如圖42所示。圖42權限管理類圖模塊操作包括增、刪、改、查四種操作，針對這每一種操作，需要設置一個對應的“允許/禁止”標識。ACL類設計一個int類型的狀態位：ACLSTATS，后四位表示操作類型，從后到前的各位分別表示“增”、“刪”“改”和“查”。如果相應的位上為0，表示禁止；如果為1，表示允許。權限管理模塊的實體類有以下幾種：（1） User類。User類的屬性有：登陸賬號、密碼、創建時間和失效時間。（2） Roles類。Roles類有角色名稱這個屬性。（3） Module類。Module類用于描述各模塊的屬性，包括模塊名稱、入口地址、標識和排序號。（4） ACL類（權限控制列表類）。ACL包含的屬性有主體類型、標識、模塊標識及操作四個屬性。這些實體類之間的關系是：用戶和角色之間是多對多的關系，ACL和用戶之間是多對一的關系；ACL和角色之間為多對一的關系；模塊和ACL之間是一對一的關系，表示一個模塊對應權限列表中的一個記錄。權限管理模塊的用例圖如圖43所示。圖43 權限管理用例圖權限管理模塊主要實現權限管理的功能，功能包括：模塊、用戶和角色信息的創建和管理；用戶和角色的授權和自動分配；還有用戶登錄系統，提供用戶的注冊、注冊信息的驗證、獲取用戶授權列表等功能。授權功能主要通過授權樹來實現，根據圖中列出的模塊功能和關系，對不同用戶進行授權。授權和操作權是本模塊最主要的功能之一。不同用戶的權限不是相同的。根據不同的權限，用戶可以享受的功能和模塊也不同。用戶權限的判別主要通過授權列表來實現。 公文管理公文包括報銷單、請假單、收文和發文等書面材料，對企業辦公有不可替代的作用。公文的處理過程比較復雜，通常要經過許多中間環節，通過不同的人進行審批，才能實現最終目的。公文管理涉及到流程的概念，需要對流程進行管理。流程管理包括流程的分析、流程的定義、資源分配等。對于大多數企業來說，公文管理是企業管理的核心的核心內容。下面詳細說明公文管理的設計與實現過程。公文流轉類圖如圖44所示。圖44 公文流轉類圖圖45列出了查詢待審公文的流程圖。參與者首先提交查詢待審公文列表請求，通過DoucumentAction執行查詢操作，并由DoucumentManage得到查詢任務列表，通過JBMP得到任務實例表，然后將公文列表傳遞給DoucumentManage和DoucumentAction，并最終顯示給用戶。圖45查詢待審公文列表流程圖圖46列出了刪除公文的流程圖。首先，參與者提交刪除公文請求，通過DoucumentAction執行刪除公文的操作；最后，DoucumentManage開始工作，查找與公文相對應的流程實例，并將其刪除。 圖46 刪除公文流程圖公文流轉的難點在合理控制審批流程。業務審批的設計應當考慮的問題有如下幾點：業務的提交、審批和退回、相關手續的催辦和緩辦等。業務審批不是隨意進行的，必須遵循一定的順序和規定。自動審批流程無需再人工設置審批流程，由系統根據預先設定好的流程自動進行業務傳遞。并行審批和串行審批是最常用的兩種審批模式：串行審批模式流程如圖47所示。圖47 串行審批模式圖串行審批模式是以線性結構存在的審批流程，每一個審批步驟只需要一個人審批，審批人員同意該審批環節審批就通過，審批人員不同意該審批環節則退回。例如，在步驟1中，只需要一個人審批，審批人審批通過后，公文流轉到步驟2所需的審批人，審核未通過，則退回給審請人。并行審批模式如圖48所示。圖48 并行審批模式并行審批模式一步需要多個人審批，其中有一個人不同意就退回。例如步驟2中，需要三個人都審批通過，該審請才能流轉到步驟3的審批人，否則該申請退回。在實際的審批流程，完整的審批流程可以既包含串行審批模式，又包含并行審批模式，我們稱為混合審批模式。一項業務的完整審批流程，必須包括申請者和審批者這兩個參與角色。申請者具有申請、查看、編輯和刪除業務的權限，可以提交業務申請。審批者可以查看提交的業務申請和具體內容，具有同意、退回、催辦和緩辦等審批業務的權限。業務的審批是逐級進行的，不同的審批階段有不同的狀態，也處于不同的業務流中。業務有未提交、待批、審批中、通過審批這四種審批狀態，以及催辦、緩辦和退回這三種其他狀態。一．公文流轉的實體類首先定義以下幾個類：（1）Workfloat類Workfloat類有流程名稱和流程定義這兩個屬性。流程定義顧名思義記錄了流程的信息，以XML的文件形式保存。（2）Document類Document類包括標題、內容附件、描述、創建時間、狀態和流程實例ID這留個屬性，是描述公文信息的類。（3）ApproveInfo類Approvelnfo類包括審批時間和審批意見這兩個屬性，是一個管理類，用于管理用戶和公文之間關系。二．公文流轉的描述與實現本模塊的功能比較完善，普通用戶可以提交、下載、添加、更新和刪除公文，超級用戶可以審批公文；可以查詢提交、待審核和已審核的公文列表；對于公文的審批進度和審批內容也可以進行查詢。用戶添加公文頁面的流程如下：首先，DocumentAction會提交一個查詢流程列表給WorkflowManager，WorkflowManager經過處理后將流程列表返回給DocumentAction；然后，DocumentAction根據流程列表的內容展示頁面；最后，用戶提交流程標識，DoucumentManage根據流程標識查將表單返回給客戶，這樣就完成了添加公文頁面的功能。其中，DoucumentManage用于存儲公文，并將公文標識和公文名稱傳遞給JBPM。JBPM主要用于綁定公文標識并創建流程實例。每個類都有具體的職能，而且各類之間還有一定的內在聯系，互相配合協作才能實現完整的功能。公文的修改、刪除和更新等操作過程與此類似，只是傳遞的請求不同而已。請年假是公司里最常見的一項事務。一般情況下，首先需要填寫并提交請假單，然后需要審請人部門經理審批，還需要行政部門老總審批，最后向有業務關聯的同事告知此事。請假流程的角色分析：（1）部門員工：員工請假，有發起請假的權限，可以適當的提出請假申請。（2）部門經理：負責普通員工的休假審批工作，自身請假申請要提交給公司老板進行審批； （3）公司老板：只有經過公司老板的批準員工和經理才可以休假。分配好角色之后，接下來進行類的設計。類圖如圖49所示。圖49 請假任務分派類的類圖其中，BossDecideAssignmentHandler為角色類，它可以通過Userid，在數據庫中查找請假申請人；ChiefDecideAssignmentHandler類用來獲取部門經理，可以通過員工的Userid得到員工的部門經理是誰；WriteRequestAssignmentHandler類用來獲得發起申請的員工ID；在CancelRequestAssignmentHandler類中，申請人可以撤銷請假請求任務。系統中存在一個流程變量RequestStat，用來存儲申請狀態。用戶啟動請假流程，完成第一個填寫請假申請的任務實例后，此狀態置為REQUEST。在完成取消請求任務之后，狀態改為CANCEL。 測試方法由于采用面向對象的程序設計思想，在系統的迭代開發過程中，每次迭代都包含測試過程。構件測試和集成測試通常采用白盒法和黑盒法兩種方法相結合，以確保各部