招投標管理系統的設計與實現設計報告(編輯修改稿)

　

【文章內容簡介】 在使用過程中遇到錯誤的時候是否可以立即定位問題，當業務場景和邏輯發生變化的時候系統是否支持，當網絡不穩定或使用中異常中斷的情況下系統是否都有相應的容錯措施，這些都包含于可靠性要求中。需求中需要特別提到這些現象，顯示系統到底以哪種用戶能接收的程度運轉。(l)可用性(availability)。系統對于一個使用時間的指定百分比必須是可用的。對于客房子系統來說，系統必須7*24小時正常使用，而餐飲子系統也必須在進餐的高峰時段確保穩定。(2)平均故障間隔時間和平均修復時間(MTBF和MTTR)。允許系統出故障后不運轉的時間，比如要求90%的系統故障要在5分鐘內修復，%的系統故障要在一小時內修復，這就要求在系統運行過程中需要穩定的技術支持團隊，達到故障修復周期的最小化。(3)準確性(accuracy)。產生數字輸出的系統要求有多高的精確度。比如數以“萬”為單位，統計時精確到小數點后面幾位，才能讓學位報盤是不超過國家規定的字段長度。(4)每類錯誤。通常分為微小的錯誤、顯著的錯誤和關鍵的錯誤三類。如數據的完全丟失或者系統的關鍵性模塊不能使用。，通常包括以下幾個方面:(l)事務的響應時間:平均值、最大值。(2)吞吐量:每秒事務數。(3)容量:系統可容納的客戶總數或事務數。(4)退化模式:系統被降級時，可接受的運轉模式。這些都應量化地體現在系統需求文檔中。可支持性是指為了升級或修復，軟件被修改的能力。對某些應用領域，未來可能的升級是可預測的，因此需求可以規定維護小組的簡單升級以及復雜升級的“響應時間”。第3章系統設計對于系統的研究開發，在完成整體的需求分析之后將進入系統的設計階段，基于RUP的軟件設計主要包括了系統概要設計和系統的詳細設計兩階段的工作。系統的概要設計階段將主要關注整體宏觀上和系統實現的技術框架設計。概要設計主要完成系統的需求分析到設計的轉化，并且分階段設計實現系統的整體架構，使得系統架構能夠為系統的進一步開發和運行服務。在概要設計的過程中，將采用由粗到細的原則，通過定性和定量的分析和分解，同時采用UML建模方法完成其設計。因此，本章將針對系統的概要設計主要是系統的軟件架構設計、權限管理設計和基本的功能設計部分進行詳細的描述。系統的軟件架構設計是指將軟件需求轉化為數據結構和軟件的系統結構以及劃分系統功能模塊設計。系統的技術架構，其任務是以系統需求分析的結果為依據，充分考慮系統的特點及用戶的要求，為系統選擇合適的開發平臺，并且選擇合適的方式構建系統。該階段注重宏觀上和框架上的設計，包括是否采用客戶端和服務器端分離的多層結構以及客戶端和服務器端所采用的技術等。針對招投標管理系統用戶角色多、部門多和分布地域廣泛的特點，整體招投標管理系統的架構設計本文選擇采用基于JZEE的多層架構設計，同時采用了B/S的整體軟件設計。客戶端技術采用瀏覽器進行實現，客戶端與服務器之間采用了HttP協議進行通信，同時為了能夠實現相應的客戶端與服務器端的異步通信，在具體的界面實現部分采用了Ajax技術進行實現。在各個層中分別采用了成熟的開源框架，層與層中間采用統一的接口。通過統一的接口設計實現了層與層之間的松藕合。同時，鑒于系統采用分層松藕合的架構設計，使得系統框架的可擴展性得到增強系統容易實現對業務請求的擴展。 JZEE(Java2Platrorm，Ente印 riseEdition)是sUN公司推出的一種全新的概念模型，使用了一個多層分布式應用程序體系。應用程序的邏輯根據其實現的不同功能被封裝到組件中，組成JZEE應用程序的大量應用程序組件根據其所屬的層被安裝到不同的機器中。對于JZEE的系統架構來說，主要包括基于EJB的重量型架構設計和“spring+struts+Hibemate”的開源輕量型架構設計。對于基于開源框架來說，目前己經逐漸成為研究和開發的熱點同時得到了很大的發展。目前，相對于EJB來說，對于表現層逐步出現了struts等相關框架，業務邏輯控制和面向切面控制的框架為SPring，而數據持久層框架為Hibemate。然而，相對于其余的輕量級框架來說，“spring+Struts+Hibernate”已成為Java開發的主流框架體系。因此，在本文招投標管理系統開發過程中，也使用了“spring+struts+Hibernate”的三駕馬車式的框架結構(如圖3一1所示)，通過輕量級的架構設計節省了學習和開發時間，同時滿足了分層架構設計的要求。圖3一l基于SSH的JZEE架構 JZEE平臺提供的這個多層結構的分布式應用程序模型具有重用組件的能力、基于擴展標記語言(XML)的數據交換、統一的安全模式和靈活的事物控制。使開發者不僅可以比以前更快的發表對市場的新的解決方案，而且其獨立于平臺、基于組件的JZEE解決方案不再受任何提供商的產品和應用程序編程界面的限制。提供商和買主都可以選擇最合適于其商業應用和所需技術的產品和組件。通過采用基于JZEE的軟件平臺進行設計，整體系統的軟件結構采用了分層的思想，系統軟件結構的整體設計按照MVC(Model，View，Control)的架構設計思想，將招投標管理系統的整體軟件框架分為顯示層、控制層、業務邏輯層和數據持久層和數據庫層等多層進行設計。以下對整體的分層結構圖如圖3一2所示，分別進行詳細的描述:1表現層，主要包括基于瀏覽器技術的B/S端的頁面顯示和基于 JasperReP0rt的各種不同樣式和類型的數據報表顯示部分。對于界面的描述和分析技術，在B/s端主要采用了JsP和基于struts的頁面標簽庫進行描述。同時，為了能夠實現界面數據的異步請求和顯示，本文在某些模塊的數據顯示部分采用了基于Ajax的異步數據請求和顯示技術。該部分主要通過瀏覽器中內置的XnllHrtp協議和對象進行異步的數據請求和數據獲取，在對頁面進行顯示的過程中結合JavaseriPt對相應的界面Html元素進行控制和顯示。在報表數據的顯示過程中，設計階段充分采用了基于模型驅動的開發技術，將報表的顯示劃分為模型描述、界面管理器和業務數據接口三部分組成。模型主要是指報表界面中的各種顯示元素。界面管理器主要包括解析器、布局管理和事件處理三部分。業務數據接口是結合具體的業務數據處理獲取需要展示和存入報表的具體數據。在報表的顯示過程中，通過業務數據模塊獲取業務數據，由界面管理器結合數據和界面描述文件獲取最終繪制的數據報表和各類格式的圖表。2. 基于StrutS的控制層設計，該部分的核心功能是接受和控制從客戶端發送過來的各類不同的請求，并通過運行時獲取的具體的XML配置文件信息，將請求轉發到不同的業務邏輯處理類進行處理。同時，將處理獲取后的數據轉發給相應的顯示模塊進行顯示。，、實體對象類和SPring框架封裝類。其中，SPring為業務邏輯的有效開發提供了合理的封裝類，能夠實現面向切面的有效操作。同時，該框架采用了分層的架構設計，能夠合理的與MVC的架構進行整合。考慮到其業務過程管理為一完整流程管理過程，為了能夠更好的進行訂單跟蹤和結果分析，我們在整體的架構設計中加入了基于JBPM的工作流引擎。工作流引擎通過訪問流程數據庫獲得業務流程信息，控制業務邏輯的流轉。工作流引擎的引入將業務邏輯和流程邏輯分離，允許用戶靈活的設計與發布新的流程。對于整個業務流程中訂單管理采用工作流引擎進行管理和分析，實現了整體業務流程的有效控制和跟蹤。數據持久層，包括OR映射和數據庫操作兩層，通過基于 ORMaPPing框架的Hibemate，封裝對數據庫的持久化操作，提供可由業務層調用的接口，這也是Spring系列架構中 SPringORM所支持的。同時，通過oR映射完成了業務數據與數據庫中的關系表的映射，使得整體設計脫離了對具體類型的數據庫(如oracle，Mysql，MSSQL)的依賴。數據庫層，主要是具體的對數據進行存儲的數據關系關聯表，包括了不同實體數據的表格、各類業務關系的存儲表等。本文中結合招投標管理系統的業務需求，采用了Mysql數據庫進行數據的具體存儲。圖3一2系統軟件架構對于業務管理系統來說，如何實現用戶請求資源的有效控制和分配是其關鍵的業務功能，本文所述招投標管理系統所涉及的相關業務人員涉眾角色眾多。因此，在系統的設計過程中，為了能夠確保訪問資源的有效控制，本文設計和實現了相應的基于用戶角色的訪問控制模型也就是 RoleBasedAeeessControl(RBAC)。首先系統管理員通過“用戶一用戶組一角色一資源”多層模式來設置用戶權限，為每個角色維護其資源的訪問權限，而每個用戶組被指派一個或多個角色，這樣用戶既具有了所指派角色的資源權限。根據用戶請求的URL判斷是否在該用戶的資源權限表中，若無權限則返回客戶端給用戶提示。結合基于角色的權限控制模型，本文所述招投標信息管理系統的相關訪問控制管理模塊描述如表3一1所示。操作名稱操作方法系統資源管理創建資源、維護資源、刪除資源用戶角色管理創建角色、維護角色、刪除角色、分配資源用戶組管理創建用戶組、維護用戶組用戶管理創建用戶、維護用戶、刪除用戶表3一1權限操作模式表相應的訪問控制組件中，資源的訪問權通過系統用戶角色來劃分，同時將角色和相應的用戶組關聯，確定不同用戶組所包含的角色。而用戶組是系統中相關人員和用戶的組合，按照一定的組織結構來進行分配。用戶(usERS)是對數據對象進行操作的主體，可以是人、機器設備、構成用戶組。組(GROUP)是對用戶的包含結構，一類擁有相同權限的用戶，比如同一部門下的職工，或者同一類型的學生等。用戶將不直接與角色 (ROLES)進行關聯，而是將用戶進行組包裝后，有組與角色進行關聯。角色 (ROLES)表示組織或部門中的工作或者職務。角色將于權限(Permission)進行關聯，確定角色享有的權限。許可(Permissions)和權限(Permission)，許可描述了角色對計算機資源的訪問和操作所具有的權限，其反映的是授權的結果。比如授予某個角色對計算機資源有讀的權限，則代表了一個許可的存在，這個許可表示角色獲取了對計算機資源的讀許可。針對操作來說，其描述的是許可和操作之間的一種關聯關系，而這層關系則表示了某一角色對某一操作所具有的權限及權限狀態。用戶組分配 (UserAssignment)是用戶到組的映射，表示某一用戶所劃歸的組，用戶與組是多對多關系，即某一用戶可以劃歸一個或多個組，相同的某一組也可包含不同的用戶。組角色分配 (GroupAssigliment)是組到角色的映射，表示一個組所具有的角色，組與角色也是多對多關系，即一個組可以具有一個或多個角色，相同的某一角色也可分配給不同組。角色權限分配 (PermissionAssignlne叫，角色權限分配是角色到權限的映射，表示一個角色所擁有的權限，角色與權限是多對多的關系，即一個角色可以擁有多個權限，同樣，一個權限也可以分配給不同的角色。本系統將RBAC模型中的權限集規定為對頁面資源的訪問權限。根據資源、角色、用戶三級管理的機制，靈活的為用戶指定角色，為角色指定可訪問的資源，從而使用戶的權限成為可配置的。針對招投標管理系統來說，主要的涉眾人員包括了招標單位內部相關管理人員、審核人員、投標的相關建設單位和工程監理單位等。對于招投標管理來說，整體系統設計采用了基于瀏覽器和互聯網設計的B/S架構，應用服務器和相關數據庫服務器通過防火墻進行相應的安全控制。系統用戶通過Http協議對系統進行訪問、請求，系統整體的網絡拓撲結構設計如圖3一3所示:圖3一3系統網絡結構設計在業務信息軟件系統設計的過程中，開發人員在功能設計和開發過程中將會依據業務功能之間的關聯關系，通過分解協調的方法進行劃分模塊和功能子系統的方法進行軟件開發。所謂分解就是將系統劃分為不同的業務功能模塊，各個模塊之間盡量減少其藕合性，同時在模塊內部盡量實現高內聚性。這樣，通過劃分模塊的方式，即有利于整體業務的分解開發，同時通過不同模塊之間的協調實現整體系統的業務需求。在系統開發的過程中，本文采用了上述分解劃分的業務分解方法，同時在整體的劃分過程中遵循以下相關原則:單個模塊內部具有高內聚性，同時具有相對獨立的功能。業務模塊的劃分，必須使得單個模塊內的業務之間具有很好的內聚性。同時，各個模塊間盡量減少相應的藕合，從而較少了模塊間開發的相互影響。從而，整體的開發有利于進行業務分工，同時保證了軟件產品的開發效率和代碼質量。業務模塊之間數據的禍合性盡量要小。在業務模塊的設計過程中，應該盡量采用接口的方式，從而減少各個業務模塊之間的數據依賴性，從而實現了系統的結構更加松藕合。業務模塊的劃分同時應該盡量減少數據的冗余性。也就是說，在系統業務的數據劃分總應盡量減少數據的重復性，應盡量使得對于相關業務的數據的處理在某個業務模塊中進行。業務模塊的劃分同時應該考慮系統的分階段實現的影響。對于大型的業務處理系統來說，系統的實現會被劃分到多個迭代過程來完成，因此在業務模塊劃分的過程中應盡量適應分時間實現的過程。業務模塊的劃分應該同時考慮的各種系統資源的充分使用，包括各種網絡和硬件資源。在對系統業務功能進行模塊劃分的過程中，我們需要盡量多的考慮現有設備資源的搭配，使得各種設備資源和信息資源能夠合理分布和充分使用。通過合理應用，從而減少了系統對網絡資源的過分依賴，同時又能夠減少數據的輸入和輸出以及數據通信所帶來的通信設備壓力。對于業務管理系統來說，業務模塊劃分的方法主要包括:功能劃分(按業務處理功能劃分)、順序劃分、數據擬和、過程劃分、時間劃分、環境劃分。按功能劃分是目前最常用的一種劃分方法。按業務處理順序劃分要依據業務流程分析的結果，這種劃分方式在一些時間和處理過程順序特別強的系統中常常采用。對于招投標管理信息系統來說，本文提供了結合現有中間件包括struts、SPring在內的基于功能組件和業務組件相結合的集成化的信息管理系統解決方