招投標管理系統的設計與實現設計報告-文庫吧資料

　　

【正文】 以參與投標，因為備案的信息量很少，不能為企業的投標活動提供依據，因此企業需要詳細地填報自己的信息，包括資質、資信、代表工程等。每個企業只允許備案一個用戶。其中的核心是企業的備案注冊和首次填報。整個系統的功能結構分為框架層、公共服務層和業務處理層，其整體的功能結構設計如圖3一4所示。通過該方案為招投標信息管理的各個問題包括企業信息管理、業務流程管理、專家信息管理等提出了合理有效的解決方案。按業務處理順序劃分要依據業務流程分析的結果，這種劃分方式在一些時間和處理過程順序特別強的系統中常常采用。對于業務管理系統來說，業務模塊劃分的方法主要包括:功能劃分(按業務處理功能劃分)、順序劃分、數據擬和、過程劃分、時間劃分、環境劃分。在對系統業務功能進行模塊劃分的過程中，我們需要盡量多的考慮現有設備資源的搭配，使得各種設備資源和信息資源能夠合理分布和充分使用。對于大型的業務處理系統來說，系統的實現會被劃分到多個迭代過程來完成，因此在業務模塊劃分的過程中應盡量適應分時間實現的過程。也就是說，在系統業務的數據劃分總應盡量減少數據的重復性，應盡量使得對于相關業務的數據的處理在某個業務模塊中進行。在業務模塊的設計過程中，應該盡量采用接口的方式，從而減少各個業務模塊之間的數據依賴性，從而實現了系統的結構更加松藕合。從而，整體的開發有利于進行業務分工，同時保證了軟件產品的開發效率和代碼質量。業務模塊的劃分，必須使得單個模塊內的業務之間具有很好的內聚性。這樣，通過劃分模塊的方式，即有利于整體業務的分解開發，同時通過不同模塊之間的協調實現整體系統的業務需求。系統用戶通過Http協議對系統進行訪問、請求，系統整體的網絡拓撲結構設計如圖3一3所示:圖3一3系統網絡結構設計在業務信息軟件系統設計的過程中，開發人員在功能設計和開發過程中將會依據業務功能之間的關聯關系，通過分解協調的方法進行劃分模塊和功能子系統的方法進行軟件開發。針對招投標管理系統來說，主要的涉眾人員包括了招標單位內部相關管理人員、審核人員、投標的相關建設單位和工程監理單位等。本系統將RBAC模型中的權限集規定為對頁面資源的訪問權限。組角色分配 (GroupAssigliment)是組到角色的映射，表示一個組所具有的角色，組與角色也是多對多關系，即一個組可以具有一個或多個角色，相同的某一角色也可分配給不同組。針對操作來說，其描述的是許可和操作之間的一種關聯關系，而這層關系則表示了某一角色對某一操作所具有的權限及權限狀態。許可(Permissions)和權限(Permission)，許可描述了角色對計算機資源的訪問和操作所具有的權限，其反映的是授權的結果。角色 (ROLES)表示組織或部門中的工作或者職務。組(GROUP)是對用戶的包含結構，一類擁有相同權限的用戶，比如同一部門下的職工，或者同一類型的學生等。而用戶組是系統中相關人員和用戶的組合，按照一定的組織結構來進行分配。結合基于角色的權限控制模型，本文所述招投標信息管理系統的相關訪問控制管理模塊描述如表3一1所示。首先系統管理員通過“用戶一用戶組一角色一資源”多層模式來設置用戶權限，為每個角色維護其資源的訪問權限，而每個用戶組被指派一個或多個角色，這樣用戶既具有了所指派角色的資源權限。圖3一2系統軟件架構對于業務管理系統來說，如何實現用戶請求資源的有效控制和分配是其關鍵的業務功能，本文所述招投標管理系統所涉及的相關業務人員涉眾角色眾多。數據庫層，主要是具體的對數據進行存儲的數據關系關聯表，包括了不同實體數據的表格、各類業務關系的存儲表等。數據持久層，包括OR映射和數據庫操作兩層，通過基于 ORMaPPing框架的Hibemate，封裝對數據庫的持久化操作，提供可由業務層調用的接口，這也是Spring系列架構中 SPringORM所支持的。工作流引擎的引入將業務邏輯和流程邏輯分離，允許用戶靈活的設計與發布新的流程。考慮到其業務過程管理為一完整流程管理過程，為了能夠更好的進行訂單跟蹤和結果分析，我們在整體的架構設計中加入了基于JBPM的工作流引擎。其中，SPring為業務邏輯的有效開發提供了合理的封裝類，能夠實現面向切面的有效操作。同時，將處理獲取后的數據轉發給相應的顯示模塊進行顯示。在報表的顯示過程中，通過業務數據模塊獲取業務數據，由界面管理器結合數據和界面描述文件獲取最終繪制的數據報表和各類格式的圖表。界面管理器主要包括解析器、布局管理和事件處理三部分。在報表數據的顯示過程中，設計階段充分采用了基于模型驅動的開發技術，將報表的顯示劃分為模型描述、界面管理器和業務數據接口三部分組成。同時，為了能夠實現界面數據的異步請求和顯示，本文在某些模塊的數據顯示部分采用了基于Ajax的異步數據請求和顯示技術。以下對整體的分層結構圖如圖3一2所示，分別進行詳細的描述:1表現層，主要包括基于瀏覽器技術的B/S端的頁面顯示和基于 JasperReP0rt的各種不同樣式和類型的數據報表顯示部分。提供商和買主都可以選擇最合適于其商業應用和所需技術的產品和組件。圖3一l基于SSH的JZEE架構 JZEE平臺提供的這個多層結構的分布式應用程序模型具有重用組件的能力、基于擴展標記語言(XML)的數據交換、統一的安全模式和靈活的事物控制。然而，相對于其余的輕量級框架來說，“spring+Struts+Hibernate”已成為Java開發的主流框架體系。對于基于開源框架來說，目前己經逐漸成為研究和開發的熱點同時得到了很大的發展。應用程序的邏輯根據其實現的不同功能被封裝到組件中，組成JZEE應用程序的大量應用程序組件根據其所屬的層被安裝到不同的機器中。同時，鑒于系統采用分層松藕合的架構設計，使得系統框架的可擴展性得到增強系統容易實現對業務請求的擴展。在各個層中分別采用了成熟的開源框架，層與層中間采用統一的接口。針對招投標管理系統用戶角色多、部門多和分布地域廣泛的特點，整體招投標管理系統的架構設計本文選擇采用基于JZEE的多層架構設計，同時采用了B/S的整體軟件設計。系統的技術架構，其任務是以系統需求分析的結果為依據，充分考慮系統的特點及用戶的要求，為系統選擇合適的開發平臺，并且選擇合適的方式構建系統。因此，本章將針對系統的概要設計主要是系統的軟件架構設計、權限管理設計和基本的功能設計部分進行詳細的描述。概要設計主要完成系統的需求分析到設計的轉化，并且分階段設計實現系統的整體架構，使得系統架構能夠為系統的進一步開發和運行服務。第3章系統設計對于系統的研究開發，在完成整體的需求分析之后將進入系統的設計階段，基于RUP的軟件設計主要包括了系統概要設計和系統的詳細設計兩階段的工作。可支持性是指為了升級或修復，軟件被修改的能力。(4)退化模式:系統被降級時，可接受的運轉模式。(2)吞吐量:每秒事務數。如數據的完全丟失或者系統的關鍵性模塊不能使用。(4)每類錯誤。產生數字輸出的系統要求有多高的精確度。允許系統出故障后不運轉的時間，比如要求90%的系統故障要在5分鐘內修復，%的系統故障要在一小時內修復，這就要求在系統運行過程中需要穩定的技術支持團隊，達到故障修復周期的最小化。對于客房子系統來說，系統必須7*24小時正常使用，而餐飲子系統也必須在進餐的高峰時段確保穩定。(l)可用性(availability)。沒人喜歡錯誤、缺陷、系統故障和數據丟失，當系統出現故障和用戶出現錯誤的操作后是否支持恢復，當用戶在使用過程中遇到錯誤的時候是否可以立即定位問題，當業務場景和邏輯發生變化的時候系統是否支持，當網絡不穩定或使用中異常中斷的情況下系統是否都有相應的容錯措施，這些都包含于可靠性要求中。2)指明典型終端用戶可能的典型任務或事務的可度量任務時間。系統用戶涉及到相關部門的使用人員、公司項目管理人員、評審專家等，系統使用培訓對他們來說周期很短或者不需培訓，而日常管理人員大部分屬于計算機普通用戶甚至是新手，這里所說的培訓時間主要指針對這類用戶。對于招投標管理系統來說，本文的的非功能性需求主要包括:適用性要求，可靠性要求，性能要求，可支持性要求，下面分別對各項要求進行分析。相對一于功能性需求，非功能性需求不僅僅關乎軟件產品的使用和性能，同時還在某種程度上影響到軟件的功能性需求。單位核心成員的信用等級也與上述中標項目的履約結果相關，其中評審專家的信用等級由相關監管單位的維護人員審核確定后確定其相關的信用影響。因此，在系統業務分析、設計和實現過程中，需要增加對于以上三類主要成員的信用檔案維護和管理。該部分相關的主要涉眾角色包括了建設單位和中標單位，其中中標單位需要定期填寫簡報，而建設單位需要定期的對相關工作內容進行審核和評價，及時列出某個階段內評價不合格的單位。對于專家信息的維護涉眾角色為相關的監管單位來進行維護，相關的主要功能包括了專家基本信息維護、專家培訓信息維護、專家現場考核、專家日常考核、專家單位信息維護、專家信息統計等相關功能，其用例圖如圖2一6所示:圖2一6專家管理用例圖對于招投標管理系統來說，招投標業務流程管理中最關鍵的部分為跟蹤和確定某個階段內中標企業的履職情況，包括了完成進度、工作簡報和履約評級等相關內容。表2一2選擇評審專家用例說明通過以上的業務流程分析，本文得出相關專家信息的維護關系到招投標管理系統的成敗，尤其是針對招標項目流程中的資格審查和評標階段，專家選擇的公正性和權威性關系到招標最終的成敗。因此，在項目的創建和標段創建過程中，相關建設單位還需要設定相應的條件對專家組進行自動選取，從而避免人為選擇因素從而提高了整體招投標管理流程中的公正和公平性。因此，在業務系統的設計過程中還包括了相關專家等涉眾人群。其整體的業務流程為順序的關系，業務流程的處理過程包括了投標單位、建設單位和監管單位三個主要的涉眾人群。整體的流程如圖2一4所示:圖2一4招投標項目流程圖從上圖可以發現，在招標項目流程管理的整體業務流程中，所有的涉眾角色中建設單位是關鍵的業務核心角色，因此接下來的描述中將針對建設單位的用例進行建模分析和描述，其業務用例圖如圖2一5所示:圖2一5招投標用例圖通過對招投標業務流程的業務需求進行分析，對于招投標管理信息系統來說其最關鍵的業務處理為流程的需求的梳理和管理。在需求分析階段，需要對其相關的業務流程進行分析和定義。 表2一1企業人員進行企業信息維護用例說明通過對招投標管理系統業務流程的需求分析，本文在分析和設計過程中將某個業務的招投標過程看作一整體的項目來進行管理。用例標識Model_Enterprise_01用例名稱企業修改相關信息創建時間201165參與者企業維護人員用例描述維護企業信息前置條件企業維護人員登錄系統后置條件記錄信息修改的次數監管部門將對修改的信息進行相應審核基本事件流1. 管理員登錄系統2. 查看企業相應信息3. 添加、修改或刪除企業的相關信息，包括基本信息、人員信息、礦產信息等。同時，企業對于相關信息進行修改時，也需要相關部門進行審核，因此針對企業的信息維護和填報的用例描述如表2一1所示。如圖2一3所示，本文給出了該部分業務的核心用例圖和關鍵用例的用例描述。圖2一2企業信息管理業務流程圖FigureZ一 2SystemPaekagediagram通過對上述企業信息業務管理流程的分析，企業信息管理模塊中還包括了企業信息檢索和查詢以及報表生成打印等相關功能。在招投標業務分析和處理中，參標企業的信息維護是其中的核心業務模塊，因為參標企業的活動貫穿著招標活動的始末，企業的信用和資質將會影響其是否能夠通過初步的審核。招投標管理作為企事業單位的信息化管理核心模塊，關系著其運營和生產，良好的招投標管理將會促進企事業單位的高效運作和良好形象。針對招投標業務數據的統計分析和決策問題，為了達到企業招投標業務的統計和易查詢性，系統在設計過程中增加了各類不同的招投標業務查詢和統計功能。本文在系統的設計和實現過程中通過基于工作流引擎的流程處理模塊，實現對招投標業務的建模分析、狀態跟蹤和業務控制，從而達到有效的流程定義和業務處理。招投標的業務流程較為復雜，其中包括了項目審核、招標公告、格預審流程、招標開標流程、評標流程管理、定標流程管理和簽約流程管理等業務處理流程。針對招標企業的信用問題，系統在設計過程中增加了招標履約考核管理模塊，針對于標書中的不同階段的目的進行采用了可考核性指標進行評估和分析。在靜態模型的基礎上，對主要實體的數據庫進行設計。結合不同行業和企事業單位招投標業務的需求和分析，本文在設計和實現招投標管理系統的過程中需要達到以下幾方面的要求:招投標業務處理流程復雜，本文對以上復雜的招投標流程通過面向對象的思想和UML建模語言進行了建模分析和梳理。圖21 系統功能包圖通過面向對象的分析方法，結合基于統一建模語言(UML)的建模方法對不同系統模塊中的需求進行用例分析和建模。在系統的需求分析過程中，本文引入了包圖對不同業務的用例進行分模塊處理和分析。統一開發過程的最大優點是采用按照角色(A以or)對業務需求進行分析從而識別用例模型 (UseCase)中的方法，通過以上方法能夠直觀的建立起系統的需求分析模型，而且通過多次迭代處理避免需求分析過程中存在的漏項問題。在系統的管理過程中，除了以上業務處理模塊意外還需要包括報表打印模塊將各類不同的數據報表進行輸出，包括Excel輸出、表格輸出和統計報表輸出等。招投標文件歸檔管理是將每次招投標的相關文件進行歸檔存儲，包括了標書、招標公告和相關合同書等，將不同的資源進行分類歸檔。為了實現對企業的資信進行評估考核，系統中建立各個階段標的履約考核，通過考核結果對企業的信用等級進行評估，為招標過程提供決策參考。對于招標項