【正文】 求分析，然后結合面向對象的思想和基于UML的建模方法，完成系統(tǒng)的需求分析、設計和實現(xiàn)。尤其針對招投標流程管理，又包括了招標計劃和流程制定、資格審查報名流程、預審流程、投標開標流程、評標流程、定標流程和簽約流程等多項復雜流程。通過項目管理可以有效的定義控制其整體流程，并能夠有效的定義該次招投標業(yè)務中的相關企業(yè)、數(shù)據(jù)和招投標文件等，同時能夠很方便的對其進行查詢和統(tǒng)計。在接下來的招投標管理中，將所有相關于本次投標的信息通過項目管理的方式來進行維護，從而實現(xiàn)信息的有效組織和維護。權限管理是由管理員對系統(tǒng)用戶進行權限分配。企業(yè)信息庫維護和建立包括了企業(yè)申請、監(jiān)管單位審批和企業(yè)信息維護等相關功能。同時，對于其流程管理通過基于工作流引擎的思想進行設計和實現(xiàn)，同時能夠對其進行狀態(tài)跟蹤和查詢。同時，為了能夠實現(xiàn)招投標過程的公正性，在評標過程中專家通過隨機抽取的方式進行確定。數(shù)據(jù)分析模塊主要是針對某個時期內(nèi)所有的招投標文件進行統(tǒng)計分析，包括招標信息明細查詢、統(tǒng)計報表等。在系統(tǒng)的需求分析過程中，本文采用統(tǒng)一開發(fā)過程的思想進行軟件設計與開發(fā)，系統(tǒng)的功能性需求描述工具主要是用例模型 (UseCase)，即將系統(tǒng)的功能性需求分解到每一個需求分析用例中去。在統(tǒng)一開發(fā)過程的分析方法中，我們?yōu)榱四軌蚯逦拿枋鱿到y(tǒng)用例及其層次結果，本文通過包圖對業(yè)務需求的各個模塊進行分析處理。如圖2一1所示，從系統(tǒng)的總體功能性需求來看本文的招投標管理系統(tǒng)系統(tǒng)可以劃分為以下幾個包圖:用戶和權限管理、公共數(shù)據(jù)維護管理、數(shù)據(jù)報表管理、招標項目管理、企業(yè)信息審核維護管理、專家信息管理、項目資源管理、投標履約管理、招標流程管理、專家抽審管理、企業(yè)信用維護管理和信息統(tǒng)計分析管理等。本文接下來對系統(tǒng)需求的核心用例模塊包括企業(yè)信息申請和審核管理模塊、招標項目流程管理、專家信息管理維護、履約考核管理、信用檔案管理等模塊進行用例建模分析和描述。通過用例分析對系統(tǒng)功能進行分解處理，對于復雜的業(yè)務處理流程建立靜態(tài)模型和動態(tài)模型。最后，通過傳統(tǒng)的基于多層的JZEE模型對系統(tǒng)進行開發(fā)和實現(xiàn)。通過對于完成標的情況建立企業(yè)的信用等級，同時建立招投標企業(yè)的信息庫達到對于招標履行的可控性。因此，在業(yè)務系統(tǒng)的分析和架構設計過程中如何實現(xiàn)業(yè)務流程的定義和控制將關系到系統(tǒng)實現(xiàn)的成敗。針對招投標管理中的核心公正性問題，為了達到整體業(yè)務的處理公平和公開，系統(tǒng)設計實現(xiàn)過程中通過流程審核分配以及專家信用評估和隨機抽取審核專家的方式達到了招投標過程中的公正性。同時，針對不同的功能為其提供了優(yōu)秀的數(shù)據(jù)展現(xiàn)方式，從而達到為企業(yè)決策者進行服務的目的。本文接下來將對招投標管理信息系統(tǒng)中的企業(yè)信息申請和審核管理模塊、招標項目流程管理、專家信息管理維護、履約考核管理、信用檔案管理進行詳細的需求分析和描述。對于招投標信息管理來說，企業(yè)的信息管理包括了復雜的審核和審批流程，其中包括了企業(yè)的基本信息備案、監(jiān)管單位審核、企業(yè)首次填報、監(jiān)管單位首次填報審批、企業(yè)信息修改、修改信息審核等相關業(yè)務流程，其相關的業(yè)務處理流程和涉眾人群如圖2一2所示。通過對上述業(yè)務需求的分析，企業(yè)信息管理模塊主要包括了各類參標企業(yè)單位和相關監(jiān)管單位兩種角色。圖2一3企業(yè)信息管理用例圖FigureZ一 3SystemPaekagediagram對于招投標信息來說，企業(yè)的相關信息的維護關系著企業(yè)是否具備相應的資質(zhì)進行招投標操作，因此如何完成企業(yè)相關信息的填報和資質(zhì)審查是本文系統(tǒng)設計和實現(xiàn)的關鍵。企業(yè)維護人員在登錄招投標管理系統(tǒng)后，將依次對基本信息、資質(zhì)信息、人員構成信息、企業(yè)資產(chǎn)構成信息、設備信息和在建工程信息以及代表工程信息進行相應的維護。擴展事件流在企業(yè)的某個在建工程需要轉為相關企業(yè)的代表性工程時，將其轉化為代表性工程備注企業(yè)對于相關的信息進行修改時，需要進行相應的登記：在企業(yè)信息進行修改后需要通過審核以確保企業(yè)信息的真實性。將整體的業(yè)務看做從發(fā)起、初始化數(shù)據(jù)到投標報名、專家審核、簽定合同看作是項目的整體周期，通過工作流模型對其定義。通過對其業(yè)務的需求進行分析，其主要的涉眾角色包括了建設單位、投標單位和工程監(jiān)管單位，整體的業(yè)務流程包括了招標項目定義、標段信息定義、招標公告發(fā)布、項目申請開始、資格審查報名、資格預審、招標開標、評標管理、定標管理和簽訂合同。通過對招投標業(yè)務的需求分析，本文梳理得到招投標項目流程依次為項目信息創(chuàng)建和維護、標段信息創(chuàng)建和維護、招標公告發(fā)布、資格審查報名、資格預審階段、投標開標階段、評標階段、定標階段和簽約階段。尤其在“資格預審”和“評標”流程環(huán)節(jié)中，需要相關的專家組進行招標投票和打分評審。對于某個招投標項目來說，在資格預審和評標的處理階段，需要相關專家進行登錄評審。如表2一2，本文給出了專家條件設置和篩選用例的詳細說明:用例標識Model_WorkFlow_ExpertSelection用例名稱選擇評審專家創(chuàng)建時間2015111參與者建設管理單位用例描述管理員設定相關的專家篩選條件前置條件已經(jīng)對相關招標項目進行基本維護完成相關項目的標段維護后置條件通過篩選條件自動生成評審專家為相關專家生成登錄名和密碼基本事件流1. 管理員登錄系統(tǒng)2. 查看相關項目信息3. 設定評標和資格審查日期4. 新建抽簽5. 關聯(lián)相關的項目和標段，設定專家人數(shù)6. 選擇專家組類型7. 進行專家組抽簽8. 確定專家組抽簽，定簽擴展事件流在專家組確定以后，相關監(jiān)督單位可以對專家抽簽結果進行修改和取消備注專家組的選擇與相關專家的信息，屬性和專家的信用相關聯(lián)，整體采用動態(tài)淘汰制從而確保專家評審的公正性。因此，在招投標管理信息系統(tǒng)的設計和實現(xiàn)山東人學碩十學位論文過程中，需要建立相應的專家?guī)煨畔⒓捌渚S護模塊，通過該模塊支持整體的專家組篩選和確定，從而確保招投標業(yè)務的有效運轉而提高招投標項目的成功幾率。通過相應的建設進度跟蹤，能夠及時跟蹤和發(fā)現(xiàn)招標項目建設過程中存則的各種問題。因此，對于履約考核最主要的涉眾角色為相關建設單位，如圖2一7，給出了中標單位履約考核的相關主要用例及其分析和描述:圖2一7履約考核用例圖通過上述的招投標管理業(yè)務的分析，我們發(fā)現(xiàn)招標單位、單位核心成員和評審專家的信用將關系著招投標業(yè)務的公平性甚至影響到整個招標項目最終的成敗。其中，對招標單位來說，其相關的中標項目的評價將會自動轉入其信用檔案。對于信用檔案管理，主要包括了企業(yè)信用檔案維護、個人信用檔案維護、企業(yè)信用等級維護、專家信用檔案維護和相關的主要查詢統(tǒng)計功能，其主要的用例如下圖2一8所示:圖2一8信用檔案管理用例圖對于業(yè)務信息管理系統(tǒng)來說，除了業(yè)務功能相關需求以外還包括了系統(tǒng)運行、維護等相關方面的非功能性需求。如果事先缺乏很好的非功能性需求定義，結果往往是使產(chǎn)品在非功能性需求面前捉襟見肘，甚至淹沒功能性需求給用戶帶來的價值。適用性要求系統(tǒng)用戶學習和操作的簡單，根據(jù)要求可以延伸出這樣四點模糊的需求:l)指明為了使用戶能夠完成普通日常工作所需要的培訓時間，而且需要以那些從未接觸過計算機的新手以及普通用戶和高級用戶的術語來描述。對于新手用戶來講，系統(tǒng)應當滿足培訓時間小于等于半天，否則將是不可接受的。對于日常管理人員登錄系統(tǒng)，從系統(tǒng)供能界面輸入相關信息需要的時間，這當然會受到技術實現(xiàn)中性能問題的影響(網(wǎng)絡傳輸速度、網(wǎng)絡容量、RAM和CPU能力，它們共同決定了系統(tǒng)的響應時間)，但是任務性能時間也更加受到系統(tǒng)適用性的影響。需求中需要特別提到這些現(xiàn)象，顯示系統(tǒng)到底以哪種用戶能接收的程度運轉。系統(tǒng)對于一個使用時間的指定百分比必須是可用的。(2)平均故障間隔時間和平均修復時間(MTBF和MTTR)。(3)準確性(accuracy)。比如數(shù)以“萬”為單位，統(tǒng)計時精確到小數(shù)點后面幾位，才能讓學位報盤是不超過國家規(guī)定的字段長度。通常分為微小的錯誤、顯著的錯誤和關鍵的錯誤三類。，通常包括以下幾個方面:(l)事務的響應時間:平均值、最大值。(3)容量:系統(tǒng)可容納的客戶總數(shù)或事務數(shù)。這些都應量化地體現(xiàn)在系統(tǒng)需求文檔中。對某些應用領域，未來可能的升級是可預測的，因此需求可以規(guī)定維護小組的簡單升級以及復雜升級的“響應時間”。系統(tǒng)的概要設計階段將主要關注整體宏觀上和系統(tǒng)實現(xiàn)的技術框架設計。在概要設計的過程中，將采用由粗到細的原則，通過定性和定量的分析和分解，同時采用UML建模方法完成其設計。系統(tǒng)的軟件架構設計是指將軟件需求轉化為數(shù)據(jù)結構和軟件的系統(tǒng)結構以及劃分系統(tǒng)功能模塊設計。該階段注重宏觀上和框架上的設計，包括是否采用客戶端和服務器端分離的多層結構以及客戶端和服務器端所采用的技術等。客戶端技術采用瀏覽器進行實現(xiàn)，客戶端與服務器之間采用了HttP協(xié)議進行通信，同時為了能夠實現(xiàn)相應的客戶端與服務器端的異步通信，在具體的界面實現(xiàn)部分采用了Ajax技術進行實現(xiàn)。通過統(tǒng)一的接口設計實現(xiàn)了層與層之間的松藕合。 JZEE(Java2Platrorm，Ente印 riseEdition)是sUN公司推出的一種全新的概念模型，使用了一個多層分布式應用程序體系。對于JZEE的系統(tǒng)架構來說，主要包括基于EJB的重量型架構設計和“spring+struts+Hibemate”的開源輕量型架構設計。目前，相對于EJB來說，對于表現(xiàn)層逐步出現(xiàn)了struts等相關框架，業(yè)務邏輯控制和面向切面控制的框架為SPring，而數(shù)據(jù)持久層框架為Hibemate。因此，在本文招投標管理系統(tǒng)開發(fā)過程中，也使用了“spring+struts+Hibernate”的三駕馬車式的框架結構(如圖3一1所示)，通過輕量級的架構設計節(jié)省了學習和開發(fā)時間，同時滿足了分層架構設計的要求。使開發(fā)者不僅可以比以前更快的發(fā)表對市場的新的解決方案，而且其獨立于平臺、基于組件的JZEE解決方案不再受任何提供商的產(chǎn)品和應用程序編程界面的限制。通過采用基于JZEE的軟件平臺進行設計，整體系統(tǒng)的軟件結構采用了分層的思想，系統(tǒng)軟件結構的整體設計按照MVC(Model，View，Control)的架構設計思想，將招投標管理系統(tǒng)的整體軟件框架分為顯示層、控制層、業(yè)務邏輯層和數(shù)據(jù)持久層和數(shù)據(jù)庫層等多層進行設計。對于界面的描述和分析技術，在B/s端主要采用了JsP和基于struts的頁面標簽庫進行描述。該部分主要通過瀏覽器中內(nèi)置的XnllHrtp協(xié)議和對象進行異步的數(shù)據(jù)請求和數(shù)據(jù)獲取，在對頁面進行顯示的過程中結合JavaseriPt對相應的界面Html元素進行控制和顯示。模型主要是指報表界面中的各種顯示元素。業(yè)務數(shù)據(jù)接口是結合具體的業(yè)務數(shù)據(jù)處理獲取需要展示和存入報表的具體數(shù)據(jù)。2. 基于StrutS的控制層設計，該部分的核心功能是接受和控制從客戶端發(fā)送過來的各類不同的請求，并通過運行時獲取的具體的XML配置文件信息，將請求轉發(fā)到不同的業(yè)務邏輯處理類進行處理。，、實體對象類和SPring框架封裝類。同時，該框架采用了分層的架構設計，能夠合理的與MVC的架構進行整合。工作流引擎通過訪問流程數(shù)據(jù)庫獲得業(yè)務流程信息，控制業(yè)務邏輯的流轉。對于整個業(yè)務流程中訂單管理采用工作流引擎進行管理和分析，實現(xiàn)了整體業(yè)務流程的有效控制和跟蹤。同時，通過oR映射完成了業(yè)務數(shù)據(jù)與數(shù)據(jù)庫中的關系表的映射，使得整體設計脫離了對具體類型的數(shù)據(jù)庫(如oracle，Mysql，MSSQL)的依賴。本文中結合招投標管理系統(tǒng)的業(yè)務需求，采用了Mysql數(shù)據(jù)庫進行數(shù)據(jù)的具體存儲。因此，在系統(tǒng)的設計過程中，為了能夠確保訪問資源的有效控制，本文設計和實現(xiàn)了相應的基于用戶角色的訪問控制模型也就是 RoleBasedAeeessControl(RBAC)。根據(jù)用戶請求的URL判斷是否在該用戶的資源權限表中，若無權限則返回客戶端給用戶提示。操作名稱操作方法系統(tǒng)資源管理創(chuàng)建資源、維護資源、刪除資源用戶角色管理創(chuàng)建角色、維護角色、刪除角色、分配資源用戶組管理創(chuàng)建用戶組、維護用戶組用戶管理創(chuàng)建用戶、維護用戶、刪除用戶表3一1權限操作模式表相應的訪問控制組件中，資源的訪問權通過系統(tǒng)用戶角色來劃分，同時將角色和相應的用戶組關聯(lián)，確定不同用戶組所包含的角色。用戶(usERS)是對數(shù)據(jù)對象進行操作的主體，可以是人、機器設備、構成用戶組。用戶將不直接與角色 (ROLES)進行關聯(lián)，而是將用戶進行組包裝后，有組與角色進行關聯(lián)。角色將于權限(Permission)進行關聯(lián)，確定角色享有的權限。比如授予某個角色對計算機資源有讀的權限，則代表了一個許可的存在，這個許可表示角色獲取了對計算機資源的讀許可。用戶組分配 (UserAssignment)是用戶到組的映射，表示某一用戶所劃歸的組，用戶與組是多對多關系，即某一用戶可以劃歸一個或多個組，相同的某一組也可包含不同的用戶。角色權限分配 (PermissionAssignlne叫，角色權限分配是角色到權限的映射，表示一個角色所擁有的權限，角色與權限是多對多的關系，即一個角色可以擁有多個權限，同樣，一個權限也可以分配給不同的角色。根據(jù)資源、角色、用戶三級管理的機制，靈活的為用戶指定角色，為角色指定可訪問的資源，從而使用戶的權限成為可配置的。對于招投標管理來說，整體系統(tǒng)設計采用了基于瀏覽器和互聯(lián)網(wǎng)設計的B/S架構，應用服務器和相關數(shù)據(jù)庫服務器通過防火墻進行相應的安全控制。所謂分解就是將系統(tǒng)劃分為不同的業(yè)務功能模塊，各個模塊之間盡量減少其藕合性，同時在模塊內(nèi)部盡量實現(xiàn)高內(nèi)聚性。在系統(tǒng)開發(fā)的過程中，本文采用了上述分解劃分的業(yè)務分解方法，同時在整體的劃分過程中遵循以下相關原則:單個模塊內(nèi)部具有高內(nèi)聚性，同時具有相對獨立的功能。同時，各個模塊間盡量減少相應的藕合，從而較少了模塊間開發(fā)的相互影響。業(yè)務模塊之間數(shù)據(jù)的禍合性盡量要小。業(yè)務模塊的劃分同時應該盡量減少數(shù)據(jù)的冗余性。業(yè)務模塊的劃分同時應該考慮系統(tǒng)的分階段實現(xiàn)的影響。