軟件工程碩士論文某企業(yè)質量管理信息系統的設計與實現【畢業(yè)論文（設計）】好

《軟件工程碩士論文某企業(yè)質量管理信息系統的設計與實現【畢業(yè)論文（設計）】好》由會員分享，可在線閱讀，更多相關《軟件工程碩士論文某企業(yè)質量管理信息系統的設計與實現【畢業(yè)論文（設計）】好（62頁珍藏版）》請在裝配圖網上搜索。

1、軟件工程碩士論文_某企業(yè)質量管理信息系統的設計與實現【畢業(yè)論文（設計）】-好 專業(yè)碩士學位論文 摘 要 關鍵詞： Abstract Quality management systems are an integral part of enterprises, enterprises in ensuring product quality, improve their quality, to win the mar

2、ket competition is playing an increasingly important role. With the economic globalization is accelerating, the market increasingly competitive, the quality of the product needs of the increasing complexity at the same time, showing expansion of enterprise scale, many groups, many plants work togeth

3、er more and more. M a manufacturing enterprise engaged in development and production of products, in the information age of today realize the quality of management information requirements become more and more urgent. In this paper, the target enterprise needs analysis, research of the multi-tier

4、architecture design, component-oriented development techniques, the client automatically download updated technology, and heterogeneous systems integration technology, using the B / S and C / S mixed structure development, to meet the target enterprise application implementation Express, post-mainte

5、nance and flexible expansion requirements. Targeted enterprises and military enterprises belong to the system requirements of high security features, the system put forward a comprehensive security solution, using a strict authentication, rights management, the separation of powers and system audit

6、data to ensure system security. Automatically download the updates and take advantage of technology to solve the C / S client update problem, using a variety of data integration technology to solve the system with a number of external system data integration problem. After a period of operation, t

7、o prove that the system can complete a good quality management of enterprise-wide business deal, with good stability and security, has become the enterprise quality management platform, improve the quality of the target enterprise management level, reached a intended objectives. Key words: quality

8、 management, hybrid structure, automatic download, XML, integration, J2EE 目 錄 緒 論 1 1.1 研究背景與課題來源 1 1.2 國外質量管理軟件的發(fā)展現狀 1 1.3 國內質量管理軟件的發(fā)展現狀 2 1.4 國內外對比分析 2 1.5 研究目標、內容 3 研究目標 3 研究內容 4 1.6 論文的組織結構 4 第二章 需求分析 6 2.1 需求背景 6 2.2 任務概述 7 2.3 功能需求 7 研試質量管理 8 制造質量管理 9 產品質量數據分析 10

9、 質量策劃管理 11 質量保障活動管理 11 質量體系管理 12 系統維護 12 2.4 與已有遺留系統的接口要求 12 基礎資源中心系統 12 售后服務系統 13 MRPII系統 13 數據報送 13 2.5 非功能性要求 13 安全性 13 先進性 13 通用性 13 易用性 14 可靠性 14 網絡功能與自助服務 14 系統性能 14 進度要求 14 2.6 需要解決的主要問題 14 系統開發(fā)方案 14 系統的安全性 15 操作界面友好性 15 2.7 小結 15 第三章 解決方案與關鍵技術 16 3.

10、1 系統結構的選擇 16 C/S結構 16 B/S結構 16 結論 16 3.2 開發(fā)方案選擇 18 C/S結構的開發(fā)方案選擇 18 B/S結構的開發(fā)方案選擇 20 3.3 安全解決方案 23 身份認證 23 權限管理 23 三權分立 23 系統審計 23 3.4 用戶友好性解決方案 24 操作一致性 24 健壯性 25 3.4 關鍵技術 26 自動下載更新技術 26 基于XML的數據交換技術 28 3.4 小結 30 第四章 設計與實現 31 4.1 系統設計原則和運行環(huán)境說明 31 系統的功能設計目標 31 系統運行環(huán)

11、境說明 31 4.2 系統總體設計 32 系統的體系結構設計 32 系統功能模塊設計 33 4.3系統功能設計 33 研試質量管理子系統設計 33 制造質量管理子系統設計 38 產品質量數據分析子系統設計 48 4.4 數據庫設計 51 數據庫設計的內容 51 數據庫的設計目的 52 數據庫設計的原則 52 數據庫的概念與邏輯設計 54 數據庫的物理設計 55 4.5 系統集成設計 57 成的需求分析 57 成分析 58 系統集成的設計與實現 62 4.6 小結 64 第五章 測試 66 5.1 單元測試 66 單元測試的意義

12、66 單元測試的優(yōu)點 66 本系統的單元測試 67 5.2 集成測試 68 5.3 功能測試 68 5.4 性能測試 70 5.5 測試結果評估 71 5.6 小結 71 第六章 總結 72 6.1 本人承擔的具體工作內容 72 技術方面 72 管理方面 72 6.2 使用效果 72 6.3系統待完善之處 73 6.4 下一步工作 73 6.5小結 73 主要參考文獻 74 致 謝 76 圖 清 單 圖 1 系統總體用例圖 8 圖 2 研試質量管理用例圖 8 圖 3 制造質量管理用例圖 9 圖 4 封裝了各種基本操作的基礎表單對

13、象 24 圖 5 數據異?；謴驮韴D 26 圖 6 客戶端自動下載更新程序的體系結構 27 圖 7 數據交換格式的總體設計思路 28 圖 8 用UML活動圖建立的業(yè)務模型 29 圖 9 數據報送的信息模型 30 圖 10 系統拓撲結構圖 32 圖 11 系統功能結構圖 33 圖 12 研試質量子系統功能結構圖 33 圖 13 研試質量管理包封裝 34 圖 14 質量問題歸零封裝包 35 圖 15 質量問題歸零處理流程 35 圖 16 質量問題歸零信息錄入頁面 36 圖 17 質量評審工作流設計 36 圖 18 質量評審信息查看頁面 37

14、 圖 19 試驗信息處理工作流設計 37 圖 20 制造質量管理子系統功能結構圖 38 圖 21 制造質量管理子系統包封裝 38 圖 22 產品總裝功能結構 40 圖 23 產品總裝邏輯關系類圖 41 圖 24 總裝進度查詢 43 圖 25 測試項目與產品的類圖 44 圖 26 測試過程信息記錄 44 圖 27 測試進度查詢 44 圖 28 總裝和測試完成情況統計 45 圖 29 產品配套信息維護及根據配套進行的應用 46 圖 30 外協產品驗收業(yè)務流程圖 46 圖 31 外協產品各階段質量信息跟蹤示意圖 47 圖 32 產品質量數據分析包

15、封裝 48 圖 33 質量周報生成流程設計 49 圖 34 質量周報生成時序圖 50 圖 35 質量信息分析界面 51 圖 36 總裝測試E-R 圖 55 圖 37 部件質量跟蹤E-R圖 55 圖 38 系統集成原理 59 圖 39 數據上報時序圖 64 圖 40 活動用戶量分析圖 70 表 清 單 表 1 國內外質量管理軟件對比分析 3 表 2 C/S結構B/S結構優(yōu)缺點比較 17 表 3 幾種主流的C/S結構開發(fā)工具比較 19 表 4 周報主界面 48 表 5 主要的數據庫表清單 56 表 6 單元測試用例模板 67 表 7

16、產品軟件配套匯總單元測試用例 67 表 8 產品測試過程通電時間計算測試用例 68 表 9 測試用例表 69 表 10 測試一覽表 70 第一章 緒 論 1.1 研究 “某企業(yè)質量管理信息系統”是某企業(yè)為提高質量管理效率和水平而開發(fā)的一套適合企業(yè)自身管理特點的信息系統。 目標企業(yè)的質量管理已經有健全的規(guī)章制度，有比較完善規(guī)范的流程，但所依賴的管理手段仍然是效率比較低下的作業(yè)方式，主要以紙質單據、Excel、Word等方式進行質量信息記錄，以郵件、紙介質等方式進行質量信息的傳遞，在生產過程中產生的大量質量信息缺少數據積累平臺，缺乏對數據的統計加工再利用的基礎。 目標企業(yè)

17、主要從事M產品的設計與生產，目前面臨繁重的設計與生產任務，質量管理工作的重要性進一步凸現出來。仍然依靠原有的工作方式，要處理越來越繁重的任務，顯得力不從心。企業(yè)的質量管理工作不僅僅需要從方法上尋找改進，還需要從手段上進行改進。因此需要建立起一個可以加快質量信息有效傳遞、規(guī)范處理流程、能夠實時跟蹤處理過程，并能夠進行大量質量數據積累、對數據進行分析的信息化系統。這也正是本課題產生的緣由。 該質量管理信息系統研制的目的是實現企業(yè)質量管理信息的網上流轉和和及時處理，實現質量問題處理的動態(tài)跟蹤和閉環(huán)控制，并方便的實現信息統計和分析功能，最終為領導決策提供支持。 1.2 國外現狀 1.3 國現狀

18、 Enterprise Resource Planning，ERP）系統中質量模塊往往是功能最弱的部分，無法滿足企業(yè)整體管理的需要。國內外質量管理軟件對比分析如表1： 表 11.6 論文的組織結構 本論文分章，具體安排內容如下： 緒論 介紹課題的研究背景、來源、國內外軟件的現狀以及本文的研究內容及意義。 需求分析 對現有的進行詳細的分析，闡述系統的主要需求，以及系統為了實現這些需求而必須解決的主要問題。 解決方案 闡述系統的，系統 第四章 設計與實現 對系統的設計原則、運行環(huán)境進行說明，在介紹系統總體設計體系結構的基礎上，按照子系統分別闡述各自的主要功能及使用的關鍵技術，并

19、對數據庫設計和集成設計進行了介紹。 第五章 測試 對系統中采用的測試方法和具體的測試工作進行了說明。 第六章 總結 總結本人在項目中完成的具體工作內容，并對系統的實施效果進行簡要的說明。第二章 需求分析在軟件生命周期中，需求分析是最重要的一個階段。軟件需求分析的質量對軟件開發(fā)的影響是深遠的、全局性的，高質量需求對軟件開發(fā)往往起到事半功倍的效果。在后續(xù)階段改正需求分析階段產生的錯誤將付出高昂的代價。圖 12 研試質量管理用例圖 問題歸零 產品在設計、試驗中發(fā)生重要質量問題后，需要對問題的現象進行如實記錄，對發(fā)生原因進行分析，根據原因制定相應的解決措施，并對解決措施進行落實。根據

20、問題原因，對其它產品是否存在同樣的問題進行舉一反三，實現問題的“歸零”。由問題“歸零”各環(huán)節(jié)負責人員進行信息的填寫。 質量評審 產品在設計完成后、或者試驗之前，以及質量問題的“歸零”完成后，都需要組織專家進行評審。要對評審中的專家的意見、評審結論進行如實記錄，并對評審中提出的問題的后續(xù)處理落實情況進行跟蹤管理。由被評審的產品主管人員負責信息的記錄和填寫。 試驗管理 由試驗隊長負責記錄參加試驗的產品的基本信息，試驗的安排情況，試驗內容，試驗中發(fā)生的問題情況以及對問題的處理情況。 制造質量管理 制造質量管理對產品在加工生產過程中的檢驗信息記錄，對廢品、不合格品的處理信息進行管理；對大

21、型產品的裝配過程進行測試，記錄各個步驟的測試信息，對出現的質量問題進行記錄和處理；對外協產品的驗收和返修信息、元器件與原材料的驗收信息進行管理。用例圖如圖3： 圖 3Manufacturing Resource Planning II）系統主要管理企業(yè)的采購、到貨、庫存、生產計劃等內容。 在質量系統中，在進行外協驗收時，需要提取MRPII中的到貨信息，并且在驗收完成后需要將驗收結果返回給MRPII中的到貨信息。 元器件、原材料的驗收信息記錄在MRPII中，要求在質量系統中能夠進行查詢。 數據報送 向集團公司質量管理系統主要是上報問題歸零信息，問題發(fā)生后需要及時上報，隨著問題歸零情況

22、的進展，對進展情況也需要及時上報。 2.5 非功能性要求 系統在非功能性方面需要滿足以下幾個方面的要求： 安全性 系統需要符合企業(yè)安全保密規(guī)定，滿足國家保密局對涉密信息系統的安全保密要求。 先進性 系統應在管理流程中體現出先進的質量管理理念。應始終遵循全面質量管理的思想來部署系統的功能。 通用性 系統需要能夠運行于流行的技術環(huán)境中，如windows 2000,windows XP，Linux等，能夠在主流數據庫如Oracle、Sql Server上應用。 易用性 界面友好簡潔，直觀體現質量管理的主要工作內容，采用可視化功能界面，引導用戶按照優(yōu)化的質量管理流程進行每一

23、步操作。 可靠性 采用模塊化的松散耦合技術，開發(fā)全過程嚴格遵循軟件工程的方法，功能模塊采用統一的設計風格、高度集成統一的用戶界面。 網絡功能與自助服務 支持企業(yè)職工在基于Web的企業(yè)局域網內的應用。提供系統使用幫助功能。 系統性能 （1）系統響應時間 查詢時間：200個用戶并發(fā)響應時間應在5秒之內。一些大數據量的特殊功能的響應時間，例如近萬條記錄的、大數據量的報表打開時間應在15秒左右。 更新處理時間：一般數據增加、刪除、修改后提交，響應時間不超過5秒。一些大數據量的特殊功能的相應時間，如批量數據導入、5M以內的二進制數據插入數據庫的響應時間在20秒左右。 （2）系統用

24、戶數量 系統用戶數指標反映了不同情況下使用系統的用戶規(guī)模。本系統應保障多用戶并發(fā)訪問環(huán)境下的合理響應速度和數據穩(wěn)定性。應滿足峰值在線用戶數500人，平均在線用戶數100人的要求。 進度要求 用戶特別要求，系統在兩個月內具備部分模塊上線運行的條件。 2.6 需要解決的主要問題 通過對以上需求的分析，我們認為系統在設計上除了需要遵循一般系統開發(fā)原則和系統總體框架外，還需要重點解決以下問題： 系統開發(fā)方案 本系統要求有靈活的功能實現，同時要求能與現有的遺留系統能有效集成，如何選擇適合的開發(fā)方案是會直接影響到這些要求能否正常實現。 用戶對進度提出的特殊要求，部分模塊在盡可能短的時間

25、內上線，也直接影響到開方案的選擇。 系統的安全性 目標企業(yè)要求本系統符合國家保密局對涉密信息系統的保密要求。如何滿足一系列保密要求，是系統需要重點考慮的一個方面。 操作界面友好性 系統部分業(yè)務模塊的數據量大，每天需要由基層用戶完成大量的數據錄入編輯工作。因此提供友好的數據處理界面對于系統的成功應用至關重要。由于不同開發(fā)工具在界面功能的實現上特點、效率不同，因此選擇合適的開發(fā)工具也是本系統要著重考慮的問題。 綜上所述，要建設好這個系統需要多方面知識，需要多方面的技術專家進行商討論證、精心設計，解決上面提出的關鍵問題，并需要一個技術過硬、管理完善的團隊才能完成系統實施。 2.7 小

26、結 本章首先對系統的需求進行了總體介紹，包括需求背景、任務概述，以及系統的功能需求、非功能需求、集成需求等，然后根據提出的需求進行了系統的需求分析，最后對系統中需要重點解決的主要問題進行了描述。 第三章 解決方案3.1 系統結構的選擇 目前系統的結構分為C/S和B/S兩種結構。本系統需要根據兩種結構的特點以及系統本身的因素做出選擇。 C/S結構 C/S結構，即Client/Server 客戶機/服務器 結構，是大家熟知的軟件系統體系結構，通過將任務合理分配到Client端和Server端，降低了系統的通訊開銷，可以充分利用兩端硬件環(huán)境的優(yōu)勢。早期的軟件系統多以此作為首選設計標準

27、。服務器通常采用高性能的PC、工作站或小型機，并采用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server?？蛻舳诵枰惭b專用的客戶端軟件。B/S結構/S結構即Browser/Server 瀏覽器/服務器 結構，是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Ｗeb Server 同數據庫進行數據交互。用戶界

28、面完全通過瀏覽器實現，一部分事務邏輯在前端實現，但是主要事務邏輯在服務器端實現，形成所謂3-tier結構。B/S結構，主要是利用了不斷成熟的瀏覽器技術，結合瀏覽器的多種Script語言 VBScript、JavaScript… 和ActiveX技術，用通用瀏覽器就實現了原來需要復雜專用軟件才能實現的強大功能，并節(jié)約了開發(fā)成本，是一種全新的軟件系統構造技術。表 2 客戶操作界面設計個性化，具有直觀、簡單、方便的特點，可以滿足客戶個性化的操作要求。同時由于開發(fā)是針對性的，因此，操作界面漂亮、形式多樣，可以充分滿足客戶自身的個性化要求。 由于是針對性開發(fā)，因此缺少通用性的特點，業(yè)務變更或改變不夠靈

29、活，需要重新設計和開發(fā)，增加了維護和管理的難度，進一步的業(yè)務拓展困難較多。 需要專門的客戶端安裝程序，分布功能弱，不能夠實現快速部署安裝和配置。 兼容性差，對于不同的開發(fā)工具，相互之間很難兼容，具有較大的局限性。若采用不同工具，需要重新改寫程序。 開發(fā)成本較高，需要具有一定專業(yè)水準的技術人員才能完成。 B/S 具有分布性特點，可以隨時隨地進行業(yè)務處理。 業(yè)務擴展簡單方便，通過增加網頁即可增加服務器功能。 維護簡單方便，只需要改變網頁，即可實現所有用戶的同步更新。開發(fā)簡單，共享性強。 個性化特點明顯降低，無法實現具有個性化的設計要求。 操作的習慣性是以鼠標為最基本的操作方式，無法滿

30、足快速操作的要求。 頁面動態(tài)刷新，響應速度明顯降低。 專用性打印輸出難以實現，尤其對票據等打印，難以實現套打輸出。 無法實現分頁顯示，給數據庫訪問造成較大的壓力。 功能弱化，難以實現傳統模式下的特殊功能要求。 本系統在選擇系統結構時，重點需要考慮系統的開發(fā)效率、界面?zhèn)€性化、系統兼容性、系統的易維護性。根據本系統的需求，其制造質量管理部分對界面?zhèn)€性化的要求高，并且是用戶最急于應用的模塊。隨著系統各個部分的逐漸應用，后期的擴展和維護工作將會比較大。為了滿足系統的這種需求，我們決定采用C/S+B/S的混合結構。采用C/S結構先期實現用戶急于應用、并且界面?zhèn)€性化要求高的制造質量管理部分，采用

31、B/S結構實現系統其余部分，以提高系統整體的可擴展性和易維護性。 3.2 開發(fā)方案選擇 由于本系統采用了C/S+B/S的混合結構，因此需要為這兩種結構分別選擇開發(fā)方案。 C/S結構的開發(fā)方案選擇 .1 VB方案（，）是微軟公司開發(fā) .2 PB方案Delphi是著名的Borland（現在已和Inprise合并）公司開發(fā)的可視化軟件開發(fā)工具?！　elphi具有以下的特性：基于窗體和面向對象的方法，高速的編譯器，強大的數據庫支持，與Windows編程緊密結合，強大而成熟的組件技術。但最重要的還是Object Pascal語言，它是在Pascal語言的基礎上發(fā)展起來的，簡單易學。Delp

32、hi提供了各種開發(fā)工具，包括集成環(huán)境、圖像編輯（Image Editor），以及各種開發(fā)數據庫的應用程序，如DesktopDataBase Expert等。除此之外，還允許用戶掛接其它的應用程序開發(fā)工具，如Borland公司的資源編輯器（Resourse Workshop）。表 3Delphi 開發(fā)效率較高COM,ActiveX COM,JavaBean,Jaguar, ActiveX COM, ActiveX CORBA（本身自帶CORBA中間件VisiBroker，有豐富向導）DAO,ADO,RDO功能相仿Transaction,DwControl，可綁定任何SQL語句和存儲過程，數據訪

33、問具有無與比擬的靈活性具有包括DataSource,Table,Query,Midas,ADO在內的二十多個組件和類完成數據訪問DBGriD，與數據庫相關的數據表現控件只有此一種，只能表現簡單表格數據表現手段單一DataWindow對象功能異常強大，其資源描述語句構成類似6>HTML的另外一種語言，可在其中插入任何對象，具有包括DBGrid在內的數百種數據表現方法具有包括DBGrid,DBNavigator,DBEdit, DBLookupListBox在內的15個數據感知組件，DecisionCube, DecisionQuery在內的6個數據倉庫組件和包括QRChart, QRExpr在內

34、的20多個報表組建，可靈活表現數據語句執(zhí)行方式將一句SQL串綁定到一個命令對象中，結果返回到ResultSet對象中自行拆取是一種真正的4GL語言，可隨意直接嵌套SQL語句返回值被賦值到語句的變量中，支持語句級游標，存儲過程和數據庫函數使用數據庫組件或類完成SQL語句串的執(zhí)行和提交開發(fā)模式控件開發(fā)模式（OCX）組件開發(fā)模式 User Object 源代碼組件開發(fā)模式 VCL 面向對象特性差較好很好代碼執(zhí)行效率 一般較高很高 .NET 是 Microsoft 的用以創(chuàng)建 XML Web 服務（下一代軟件）平臺，該平臺將信息、設備和人以一種統一的、個性化的方式聯系起來。 借助于 .NET 平臺

35、，可以創(chuàng)建和使用基于 XML 的應用程序、進程和 Web 站點以及服務，它們之間可以按設計、在任何平臺或智能設備上共享和組合信息與功能，以向單位和個人提供定制好的解決方案。 .3比較與結論 （1）對分布式技術的支持 通過Web Services，任何應用程序可以在網絡上順利地整合在一起。Web Services的基本原理是利用標準的網絡協議 例如:HTTP 來傳送XML消息。這是一種非常輕便的溝通機制，因此可以讓任何程序語言、中間層組件或平臺很輕易地整合進來。一般工業(yè)上或企業(yè)內部會接受成熟且廣為廠商采用的業(yè)界標準，尤其是已經受過市場考驗行之有年的標準。 要構建Web Services必

36、須得采用業(yè)界通用的Web Services技術。Web Services是一種新一代的分布式服務，在這之前，有CORBA、DCOM、COM+、RMI，都是用來實作分布式架構的技術，而且也被證明運作的非常順利;而新一代的分布式服務，采用的是XML技術，如XML-RPC和SOAP就是最佳的例子，新一代的分布式技術可以用已有的通訊協議做基礎 如SMTP、FTP等 ，但是目前最受歡迎的方式仍然是將XML基植于HTTP這個廣受歡迎，但是效能并非最佳的通訊協議上。 J2EE支持了較為廣泛應用于現有企業(yè)系統的分布式運算服務，而.NET平臺支持延伸自COM與DCOM的COM+，其技術前身MTS COM+比E

37、nterprise JavaBeans技術早了三年，我們可以推斷J2EE提供的分布式服務比.NET的技術領先三年。 使用J2EE者可以選用XML-RPC或是SOAP技術，Sun Microsystems更提供了 Java Web Service Developer Pack供開發(fā)者開發(fā)Web Services。反觀.NET技術，只提供對于SOAP的支持。在對于既有分布式技術支援不足的情況下，對新一代分布式技術的支持又無法提供彈性的選擇，風險之大，是可以預估的。 總而言之，我們就平臺的穩(wěn)定性，服務器的穩(wěn)定性，以及產品的多樣性這三方面來考量，J2EE似乎優(yōu)于.NET技術。 （2）開發(fā)工具的可

38、選擇性 J2EE 以及 .NET 是現有用來開發(fā)服務器端企業(yè)級應用程序的技術延伸。這些技術的早期版本并非專門用來開發(fā)Web Services用。J2EE 以及 .NET的共通愿景就是希望能達成開發(fā)Web Services的基礎工程，例如：跨平臺的XML溝通、負載平衡以及交易。 但是，當開發(fā)到一定規(guī)模的應用程序時，會產生一定的復雜度，這個時候就必須有開發(fā)工具的輔助，如果您選用了其中一種平臺，那么您可以選用的工具如下所示： J2EE平臺的工具有： 普元EOS（普元） Eclipse Open Source JBuilder Borland Forte for Java Sun

39、 WebLogic Workshop BEA JDeveloper Oracle Rational Application Development IBM Visual Cafe WebGain .NET平臺： Visual Studio.NET （3）中間件產品的可選擇性 JAVA2平臺，企業(yè)版（J2EE）是為單一的復雜問題，如有關部門發(fā)展，人員配置，項目管理等多級企業(yè)解決方案而設計的。J2EE是一個由SUN微系統公司提出的工業(yè)標準。J2EE是一個標準，而不是一個產品，只要雙方都服從J2EE的約定，其應用程序就能在各種各樣的程序包環(huán)境下運行。 J2EE的目

40、的是使所有用戶有權自己去選擇他們要的產品和工具，這樣也鼓勵了產品間的競爭。這一目的實現的前提是J2EE已成為工業(yè)標準。為了使用戶放心的買入，SUN公司同其他的EBusiness平臺開發(fā)商（像BEA，IBM和Oracle）合作定義J2EE。SUN還發(fā)起了JAVA民間組織以汲取新的方案來不斷完善J2EE。 Microsoft .NET是一組能使你建立良好的，企業(yè)級的web services的產品。注意，它們有一個重要的不同：.NET是一個產品策略，然而J2EE是一個任何產品都要用到的標準。 .NET大量的改寫了Microsoft早期開發(fā)平臺的底層代碼和組件，其中包括了許多現在正廣范用到的技術，

41、也包括MTS和COM＋，消息隊列（MSMQ），和Microsoft SQL server數據庫。新的.NET結構取代了這些技術，并且包括了一個web services層來提高語言的支持能力。 因此在構建基于Web Services的企業(yè)分布式應用時，J2EE平臺有非常多的中間件產品可供選擇，而.NET唯一的選擇就是Microsoft的自己的產品。 從以上的比較可以看出，在構建基于Web Services的分布式企業(yè)應用上，J2EE平臺和.NET平臺相比，具有明顯的優(yōu)勢， 通過兩種方案的對比，可以看出基于J2EE平臺構建分布式企業(yè)應用具有非常明顯的優(yōu)勢。同時，由于本系統還需要與用戶已有的遺

42、留系統保持良好的接口，因此采用基于J2EE平臺的開發(fā)方案是最好的選擇。 本系統最終使用了普元EOS平臺完成系統開發(fā)，Web容器使用Jboss，數據庫采用了Oracle。 3.3 安全解決方案 本系統在機密增強的網絡環(huán)境下運行，對系統所處理的數據具有高度的保密要求。系統需要有完整的安全解決方案。 身份認證 系統遵循嚴格身份認證和有限授權原則、全面確認原則和安全跟蹤原則。所有用戶進入系統必須通過服務器上的身份認證。 身份認證采用集成第三方基于PKI 體系的USB 智能卡系統，這種類型的系統利用標準的加密算法技術，實現了網絡安全方案中數字簽名、身份認證和密鑰安全管理以及分發(fā)傳遞等功能。

43、 權限管理 根據用戶對權限管理要求的嚴格程度，提供了分級的權限管理機制，系統支持自頂向下的逐級分配權限的管理模式，系統權限包含功能權限、數據權限，其中數據權限包括數據對象權限、字段權限和字段范圍權限。 （1）功能權限：根據功能的劃分來為操作員設置權限。功能權限不僅能夠設置到最末一級菜單功能，而且能夠設置到每個功能中的各個按鈕。由于可以將權限明細到功能按鈕級，保證了功能權限的最明細化。 （2）數據權限：在功能權限的基礎上，針對具體的業(yè)務對象或者數據內容提供更進一步的權限設置。 三權分立 按照三權分立的要求：系統操作人員嚴格區(qū)分為管理員和業(yè)務操作員兩個類別，同時管理員分為系統管理員

44、、系統安全員、系統審計員，三者的權限互相制約： 系統管理員負責管理和維護系統所有人員信息； 系統安全員負責系統內所有人員業(yè)務權限和角色信息的維護； 系統審計員負責系統所有安全日志和業(yè)務日志的備份、清理、保存的工作。 系統審計 系統提供系統日志審計功能，可以在線查詢、監(jiān)控每一個訪問用戶的操作，可以自動記錄每一個用戶的應用節(jié)點、應用時間、功能操作，可以隨時查詢、審計。從另外一個層面保障非法操作的實時監(jiān)控和響應并做到可跟蹤和追溯。 3.4 用戶友好性解決方案 隨著重用需求和重用技術的發(fā)展，開發(fā)可重用軟件成了軟件工程的重要課題，而用戶友好性是可重用軟件的重要屬性之一。換言之，是否具有用

45、戶友好性已不僅僅是界面上的問題，而是結構上的問題；不僅僅是具體實現技術上的問題，而是設計思想方法上的問題。 圖 4 封裝了各種基本操作的基礎表單對象 利用該種設計，使得各業(yè)務模塊的基本功能操作一致，甚至基本對象的布局都是一致的，很好的遵守最小驚奇原則在整個系統中有一主要輸入模型，系統所做的一切都嚴格遵守這一模型都使用同一種語言，語法規(guī)則相同，用戶菜單和輸入/輸出屏幕始終都有相同的格式、一致的風格。一致性可以轉換成可預見的一致性，減少用戶的認知負擔，給用戶以自學的可能。只要掌握了一個屏幕上的操作，其它通過聯想就可舉一反三。健壯性是防御用戶錯誤和用戶破壞的能力需要對用戶輸入的正確性和完整性進

46、行全面檢查；分別處理和響應正確與不正確的輸入；出錯時無論是由用戶輸入直接或間接引起的能給出有意義的信息，解釋錯誤地方和如何糾錯；在設計時就應預見用戶容易出錯的地方，并做出避免出錯的預防性設計；必要時對不正確的輸入如密碼輸入錯誤進行審計處理。 圖 5 數據異?；謴驮韴D 3.4 關鍵技術 自動下載更新技術 系統中部分業(yè)務模塊采用了C/S結構。C/S結構的客戶端程序更新一直是客戶維護的主要工作之一，傳統的方法是人工訪問某個中心資源目錄或者人工進行程序客戶端更新，這樣做不安全且更新效率低。本系統設計時充分考慮了這一點，設計開發(fā)了客戶端程序下載更新組件。 該組件總的設計思想是：在后臺利用

47、數據庫，存儲需要更新的模塊文件，通過客戶端組件自動搜索比較，并決定是否需要下載更新。 （1）運行體系結構如圖6： 圖 6TOP-DOWN）的方法進行，這一方法主要包括四個階段：業(yè)務流程梳理、數據元和聚合數據元提取和標準化、組合數據元和聚合數據元形成獨立于語法的數據交換格式模型和把由數據元和聚合數據元組成的數據交換格式模型映射為 XML模式，如圖7所示。 圖 7UML模型）描述業(yè)務流程，形成業(yè)務模型和信息模型。業(yè)務模型明確了業(yè)務活動中的參與角色、要交換的數據交換格式和交換順序以及組成數據交換格式的業(yè)務數據。信息模型將業(yè)務模型中組成數據交換格式的業(yè)務數據歸為若干個具有相互關系的類，這些類及類

48、之間的關系構成了信息模型。 數據元和聚合數據元提取和標準化階段：在上述信息模型基礎上，進行數據元提取與分析，進行數據元標準化，形成符合規(guī)范化要求的通用數據元，進行分類與編碼。 組合數據元和聚合數據元形成獨立于語法的數據交換格式模型階段：在上述信息模型基礎上，用經過標準化處理的數據元和相關代碼規(guī)范該信息模型，形成由數據元組成的、具有層次結構的、獨立于語法的數據交換格式，該數據交換格式與任何一種語法綁定后，就形成了可在同構或異構系統間交換、用特定語法描述的數據交換格式。 把由數據元和聚合數據元組成的數據交換格式模型映射為 XML模式階段：將形成的由數據元組成的、具有層次結構的、獨立于語法的

49、數據交換格式，映射形成符合W3C XML語法要求、可在同構或異構系統間交換的XML Schema。 （2）業(yè)務數據共享的業(yè)務模型設計 業(yè)務數據共享的業(yè)務流程是由一系列在2個或多個角色間發(fā)生的業(yè)務活動組成，推薦使用UML的活動圖來描述業(yè)務流程。圖8給出用UML活動圖進行業(yè)務數據共享業(yè)務流程梳理的方法，建立了業(yè)務模型。 圖 8 圖 9設計與實現分析是問題抽象 做什么 ，設計是問題求解 怎么做 ，實現是問題的解 結果 。.1 系統設計原則和說明 從的業(yè)務模式和的要求來看，整個系統的設計首先是保證功能實現能夠滿足業(yè)務的需要，同時在技術上保持先進性、開放性、可擴展性等特征。在詳細描述各個

50、系統的設計之前，我們有必要討論在設計工作中所遵循的設計原則。 .1.1 系統的功能設計目標 .1.2 系統運行環(huán)境 本系統 按照我們的系統設計目標，其運行環(huán)境推薦如下： 客戶端：M以上內存，Windows 或以上版本操作系統，IE .0以上瀏覽器，屏幕顯示分辨率建議024*768以上。 WEB服務器端：Windows 或以上版本操作系統，IE .0以上瀏覽器，屏幕顯示分辨率建議024*768以上，內存最低為。Windows 2003 Server或以上版本操作系統，內存最低為。.2 系統總體設計 圖 系統功能設計 圖 .1 研試質量管理子系統設計 M產品系列的研制周期多則十

51、幾年，少則幾年，在研制過程會進行各種試驗，可能產生各種質量問題，針對各種研制活動會組織大量評審。研試質量子系統將對研試過程中的問題處理、質量評審、試驗情況信息進行維護管理。 圖 12 圖 13 圖 1415 質量問題歸零處理流程 由于質量問題信息所包含的內容很多，在頁面設計時采用了對信息進行分類，對每一類可以單獨收縮或展開的處理，以方便信息的錄入。如產品（設備）信息、故障信息、原因信息、糾正措施信息等。在信息的錄入過程中，為了方便信息的修改，不同流程環(huán)節(jié)的錄入人可以修改其他流程環(huán)節(jié)錄入的信息（審核環(huán)節(jié)信息除外）。問題歸零的數據錄入頁面實現如圖16： 圖 16 圖 17 圖 18

52、圖 制造質量管理子系統設計 制造質量同研試質量一同構成本系統的核心部分。制造質量對企業(yè)加工生產的過程質量進行管理，并對采購產品、采購原材料、外協加工生產的產品進行嚴格的質量把關。要保證企業(yè)最終生產出的產品質量合格，對來料把關和生產過程的嚴格控制是關鍵。制造質量子系統分為兩大部分：加工質控和外協外購管理。 圖 20 圖 .2 不合格處理 在產品加工生產過程中，由檢驗員對每道工序進行檢驗。若檢驗時發(fā)現產品問題，可根據問題情況判定為廢品或是判定為不合格品。若判定為廢品，則進行廢品處理。判定為不合格品，則進行不合格品審理。 不合格審理信息包括：產品信息（名稱、數量、工序、交檢數、不合格數等

53、）、故障現象、原因分析、不合格審理意見（工藝師系統意見、質量師系統意見、不合格審理委員會意見）、設計意見、相關單位會簽信息等。 以前企業(yè)的不合格審理是由檢驗員開具紙質的不合格審理單，將該紙質的審理單在各相關環(huán)節(jié)進行簽署流轉。該種處理模式效率低，而且十分不利于產品的質量跟蹤和后期的數據分析。在運用本系統后，按照設定的業(yè)務流程進行審理信息的流轉，能夠跟蹤到每一個環(huán)節(jié)的處理情況，也能方便的進行數據的統計與分析。 .3 報廢處理 在產品的檢驗過程中，當檢驗員發(fā)現廢品后，需要開具廢品通知單。廢品通知單中包括產品信息、責任單位信息、廢品原因及特征、工藝說明、工時損失、材料損失等信息。工時損失、材料損

54、失信息是由定額員核算完成。在數據分析時可以計算出不同責任單位的各類損失情況，以及統計出某指定單位在不同時期損失的變化趨勢。 .4 產品總裝 M產品的總裝是個復雜的過程，要將各個部段總裝成一套完整的產品，需要經過至少十幾個步驟，而每個步驟之間的先后順序并不象單一產品的加工工序那樣嚴格。為了控制每一個裝配步驟的質量，需要對裝配的每個步驟進行嚴格的測試和記錄。裝配完成之后，需要對整套系統進行系列測試。 不同型號產品的總裝步驟和需要測試的項目不同。即使是同型號的產品，由于不同批次的批次其用途不同，其裝配步驟和測試項目也可能會不同。因此對產品的總裝項目和測試項目需要具有可配置性。 在產品的裝配過

55、程中，部分環(huán)節(jié)需要進行較為復雜的數據記錄，由于不同型號產品的數據格式差異很大，難以用統一的表格化處理，因此系統中采用了使用Excel文件的形式進行數據記錄，可以在系統中在線進行excel中的數據編輯。 產品總裝模塊的功能結構如圖22： 圖 22 圖 23testTmpt：產品測試模板類，封裝了對產品測試模板的操作。 CasmbTmpt：產品總裝模板類，封裝了對產品總裝模板的操作。 CTmpt：模板基類，封裝了對模板的基本操作。 CasmbInfo：總裝過程信息類，封裝了對總裝過程信息處理的操作。 CtestInfo：測試過程信息類，封裝了產品測試過程信息處理的操作。 產品總裝

56、 總裝項目模板：為不同型號產品的不同批次進行總裝步驟的靈活配置。 總裝過程信息：按照總裝項目模板，為每套產品生成總裝項目。在總裝過程中，記錄下每個步驟的檢查結果，檢查人，檢查日期等信息。若發(fā)現問題，記錄下問題現象。利用PB中可以動態(tài)執(zhí)行帶參數的SQL語句的技術，可以一次生成同一批次下所有產品的總裝項目。動態(tài)執(zhí)行的Sql語句如下： insert into procctr_assemble_checkinfo item_no, model_no, model_batch, order_no, test_item, need_note, has_file, f

57、ile_name, test_value select :is_curXHDm, model_no, :is_curPc, :s_mslNo[j], order_no, test_item, need_note, has_file, file_name, file_name from procctr_assemble_checkitem where item_no :is_curXhDm and model_batch :is_curPc; 在產品總裝過程中，需要利用Excel記錄各種數據。不同型號的產品預先制定不同的Exce

58、l模板。記錄了數據的Excel文件以Blob的形式存放在數據庫中。但在使用過程，存在對模板文件的修改情況，包括對其中的某個Sheet頁面的修改，或者新增Sheet頁面。本系統采用了Ole編程技術，實現對Excel文件的動態(tài)修改。以下是代碼片段： //拷貝新模板文件中指定頁面的內容 ole_excel.workbooks 1 .Activate ole_excel.workbooks 1 .sheets ls_sheetArray[i] .Select ole_excel.workbooks 1 .ActiveS ole_excel.workbooks 2 .Activate ole

59、_excel.workbooks 2 .sheets ls_sheetArray[i] .Select ole_excel.workbooks 2 .ActiveSheet.Range "A1" .PasteSpecial 總裝進度信息：根據總裝過程中記錄的信息，統計某套產品型號下整個批次的總裝進度。可以概覽整個批次的總裝完成情況，也可以查看某套產品的某個總裝項目的具體數據。 圖 24 圖 25 圖 26 圖 27 圖 28 圖 29 圖 30 圖 31 外協產品各階段質量信息跟蹤示意圖 .9 元器件原材料驗收 元器件原材料的驗收信息記錄在企業(yè)的MRPII系統中。但為

60、了達到用戶在一個系統中便可以掌握企業(yè)的所有質量信息的目的，在本系統中實現了對元器件原材料驗收信息的查詢。該部分功能簡單，主要是在數據庫層面實現了同MRPII系統的集成，有關集成的內容在“4.5系統集成設計”中進行說明。 產品質量數據分析子系統設計 產品數據分析針對研試質量子系統、制造質量子系統中所積累的產品質量信息進行統計與分析，主要含質量日報、質量周報、質量信息分析三個子模塊。包設計如圖32： 圖 32InfoQuery分別為日報、周報、質量信息分析三個包提供質量數據查詢服務。 .1 質量日報 質量日報為領導、質量主管人員自動按M產品的不同分類查詢出當天發(fā)生的各類質量問題，包括不

61、合格品信息、報廢信息、測試中出現的質量問題信息。 .2 質量周報 質量周報由質量主管部門生成并發(fā)布。質量周報內容包括上期質量周報中的問題落實情況、各分廠待處理問題（不合格品、廢品）、本期辦完不合格品審理單統計、本周辦完廢品單統計、總裝測試問題統計（遺留問題和本周發(fā)現問題）。即周報中應包括不合格品、廢品和質量問題三類信息，并按時間劃分為上期遺留信息，本期新發(fā)生信息。 周報主界面設計 表 4 年 期 起始日期 截止日期 發(fā)布日期 不合格品 廢品 總裝測試問題 處理完 待處理 新發(fā)生 處理完 待處理 新發(fā)生 處理完 待處理 新發(fā)生 在周報主界面，

62、可以直觀的了解近期企業(yè)總體質量狀況，具體到解決了多少問題、遺留多少問題、新出現了多少問題。 （2）功能設計 周報生成：由周報管理員按期生成周報。系統根據當前日期和上期周報截止日期，由各不合格品、廢品、總裝測試問題信息庫中查詢出新發(fā)生的問題，由上期周報中查詢出仍然遺留的問題和已處理的問題，將查詢出的信息存放入周報數據表中。具體處理流程設計如圖33： 圖 33圖 34 .2 質量信息分析 質量信息分析模塊為用戶提供產品各類質量信息的綜合統計分析功能，可以由用戶自定義分析分析的指標項，結合查詢功能，實現多維數據分析。功能設計如下： 圖形定制 由用戶選擇需要進行統計分析的業(yè)務表，定義統

63、計圖形的X軸、Y軸、Z軸，以及圖形類型、圖形標題、字體等界面設置信息，定義后信息作為圖形配置項保存在數據庫中。同一個業(yè)務表可以定義多個圖形。 圖形顯示 以樹形結構的形式將各業(yè)務表所定義的所有圖形標題組織顯示，當在樹上進行節(jié)點切換時，圖形顯示區(qū)自動進行相應切換，顯示出對應業(yè)務表的圖形。 數據回溯 根據圖形上選擇的某個部分，系統自動查詢出該部分所對應的原始數據，便于進一步的分析。 文檔生成 系統自動將圖形、統計表和原始數據生成Word格式的文檔。 圖 35.1 數據庫設計的內容 數據庫是信息系統的核心和基礎，把信息系統中大量的數據按一定的模型組織起來，提供存儲、維護、檢索數據的功能

64、，使信息系統可以方便、及時、準確地從數據庫中獲得所需的信息。 結構特性設計是指數據結構的設計，設計結果要得到一個合理的數據模型，這是數據庫設計的關鍵。數據模型是反映現實世界中事物及事物間的聯系，對現實世界模擬的精確程度越高，形成的數據模型就越能反映現實世界，在這基礎上生成的應用系統就能較好地滿足用戶對數據處理要求。按照現有質量管理模式及操作過程要求，建立用以支撐系統運行的基礎代碼表、系統配置表、權限管理表、各類業(yè)務數據表。所建立的數據表要求能充分滿足用戶存取信息需求，同時盡量減少重復信息，節(jié)約存儲空間，保持數據的一致性和完整性。 結構（靜態(tài)）特性設計應滿足以下幾點： （1）能正確反映現實

65、，滿足用戶要求； （2）減少和避免數據冗余； （3）維護數據的完整性。 行為（動態(tài)）特性設計是指應用程序設計。在分析用戶需要對哪些數據處理的基礎上，劃分各個功能模塊，問題歸零模塊、質量評審模塊、試驗管理模塊、報廢處理模塊等等。并根據業(yè)務數據處理需要，在數據庫中建立數據視圖、觸發(fā)器、存儲過程。 數據庫的設計目的 （1）良好性能：一個符合應用要求的數據庫系統，應具有良好的性能。數據庫性能包括數據庫的存取效率和存儲效率。數據庫的存取效率主要表現在對事務響應快，存取次數少。存儲效率是指存儲數據的空間利用率，即存儲用戶數據所占有實際存儲空間的大小。 （2）便于維護：考慮系統使用方便、便于維

66、護以及將來擴充的可能性，在進行系統設計時必須考慮系統數據的可讀性、數據庫應用系統的可擴展性，并具有較長的使用壽命。 （3）滿足功能要求：成功的數據庫系統應具有足夠功能滿足用戶使用要求。 綜上所述，根據質量管理業(yè)務管理系統的特性和功能要求，建立數據庫模型時應滿足各子系統對信息的存取需求，能夠快速存取各種實時信息，滿足實時采集、實時控制、在線分析的要求，能夠給各級管理人員提供詳盡的原始數據、分析數據、統計數據、管理數據。 數據庫設計的原則 （1）采用領域模型驅動的方式和自頂向下的思路進行數據庫設計，首先分析系統業(yè)務，根據職責定義對象。對象要符合封裝的特性，確保與職責相關的數據項被定義在一個對象之內，這些數據項能夠完整描述該職責，不會出現職責描述缺失。并且一個對象有且只有一項職責，如果一個對象要負責兩個或兩個以上的職責，應進行分拆。 不應針對整個系統進行數據庫設計，而應該根據系統架構中的組件劃分，針對每個組件所處理的業(yè)務進行組件單元的數據庫設計；不同組件間所對應的數據庫表之間的關聯應盡可能減少，確保組件對應的表之間的獨立性，為系統或表結構的重構提供可能性。根據建立的領域模型進行數據