<nav id="w0g0m"><code id="w0g0m"></code></nav>
  • <xmp id="w0g0m">
    <xmp id="w0g0m"><nav id="w0g0m"></nav><menu id="w0g0m"><strong id="w0g0m"></strong></menu>
  • <xmp id="w0g0m">
  • <nav id="w0g0m"></nav>
    <menu id="w0g0m"><menu id="w0g0m"></menu></menu>
    1. 網站地圖
    2. 設為首頁
    3. 關于我們
    ?

    電子元器件信息管理與釆購決策系統的 研究與實現

    發布時間:2023-07-17 15:20
    目錄
    摘要 I
    ABSTRACT III
    插圖索引 V
    表格索引 VII
    縮略語對照表 IX
    第一章 緒論 1
    1.1研究背景及意義 1
    1.2國內外研究現狀 1
    1.3本人完成工作 2
    1.4論文章節安排 3
    第二章 系統需求分析 5
    2.1系統需求分析概述 5
    2.2信息管理子系統功能需求分析 7
    2.2.1系統管理 7
    2.2.2業務處理模塊 7
    2.2.3元器件檢驗管理 8
    2.2.4元器件入庫管理 9
    2.2.5信息傳遞功能 9
    2.2.6Excel 處理功能 10
    2.2.7待辦工作提醒功能 10
    2.3采購決策子系統功能需求分析 10
    2.3.1源數據提取 11
    2.3.2數據預處理 11
    2.3.3數據決策分析 11
    2.3.4結果呈現與總結 11
    2.4非功能需求分析 11
    2.4.1信息管理子系統非功能需求分析 11
    2.4.2采購決策子系統非功能需求分析 12
    2.5本章小結 12
    第三章 系統總體設計 13
    3.1系統架構設計 13
    3.1.1系統邏輯架構 13
    3.1.1系統網絡架構 14
    3.2系統功能模塊設計 15
    3.3系統數據庫設計 18
    3.3.1概念結構設計 18
    3.3.2邏輯結構設計 19
    3.4本章小結 25
    第四章 信息管理子系統詳細設計與實現 27
    4.1系統管理 27
    4.1.1權限管理 27
    4.1.2日志管理 28
    4.1.3數據庫管理 29
    4.2 業務處理模塊 30
    4.2.1功能說明 30
    4.2.2功能設計與實現 32
    4.3元器件檢驗管理 33
    4.3.1功能說明 33
    4.3.2功能設計與實現 35
    4.4元器件入庫管理 36
    4.4.1功能說明 36
    4.4.2功能設計與實現 37
    4.5信息傳遞功能 37
    4.5.1功能說明 37
    4.5.2功能設計與實現 39
    4.6Excel 處理功能 40
    4.6.1功能說明 40
    4.6.2功能設計與實現 41
    4.7待辦工作提醒功能 44
    4.7.1功能說明 44
    4.7.2功能設計與實現 45
    4.8本章小結 47
    第五章 采購決策子系統詳細設計與實現 49
    5.1決策功能描述 49
    5.2算法選擇與描述 50
    5.2.1算法選擇 50
    5.2.2決策樹算法過程 51
    5.2.3特征選擇原理 52
    5.3決策功能實現 53
    5.3.1數據集獲取 53
    5.3.2數據預處理 53
    5.3.3數據決策分析 56
    5.3.4結果分析總結 58
    5.4本章小結 59
    第六章 系統部署與測試 61
    6.1部署與測試環境 61
    6.2系統功能測試 61
    6.3系統性能測試 62
    6.4系統運行截圖 62
    6.5本章小結 65
    第七章 總結與展望 67
    7.1總結 67
    7.2展望 67
    參考文獻 69
    致謝 73
    作者簡介 75
    第一章 緒論
    1.1 研究背景及意義
    隨著中國電子產業升級的加速,無論在涉及民生的傳統市場還是關系國家實力的 軍工產業,電子元器件的需求空間都空前增長。如果電子元器件的管理工作仍停留在 人工處理的層次,必然制約電子元器件產業的發展,甚至是整個電子信息產業的發展。
    電子元器件管理工作涉及采購、檢驗、存儲、生產等多種業務環節,很難有高效 的組織方式。傳統的人工處理的辦法操作困難,出錯率高,并且很難對個人操作進行 記錄,甚至可能出現難以挽回的后果。因此實現電子元器件管理的信息化工作迫在眉 睫,通過電子元器件信息管理系統的建設,可以優化管理工作的組織形式,提升管理 人員的工作效率,并且做到操作有跡可查,從而改變電子元器件的管理方式,促進電 子信息產業的發展。
    在數據挖掘、機器學習蓬勃發展的今天,電子元器件管理工作智能化有了更高的 期望性和可能性。將數據挖掘技術應用到電子元器件的采購工作中來,可以實現對采 購流程的指導和優化。
    1.2 國內外研究現狀
    當前,信息化是時代發展的潮流,信息化建設與布局成為國家戰略層面的焦點之 一[1]。由于研究所在增強國家綜合國力的事業中有著不可替代的作用,將先進技術與 研究所的管理、生產相結合,加快祖國科研水平的進步與綜合國力的提升,已經變得 越來越緊迫。
    改革開放給我國內地發展電子產業帶來了機遇,電子元器件的生產規模和經濟總 量不斷擴大,也讓研究所的科研工作煥發出新的活力。但是由于研究所所處環境的獨 特性,電子元器件管理的工作方式并沒有實質性的提升。在國外,查看某些數據僅僅 需要幾秒鐘,但是在國內仍然存在類似查看文件這種低效的處理方式,會耗費大量的 人工和時間成本[2],是科研生產的瓶頸之一。
    近年來數據挖掘技術的發展,讓信息管理朝著智能化、敏捷化的方向發展。通過 數據挖掘技術,可以發現數據的內在聯系或隱藏屬性。目前研究所內采購過程中供應 商的選擇大多是憑借經驗和直覺進行,很難做到客觀、科學[3]。而每年研究所的元器 件采購信息記錄數據量客觀,滿足數據挖掘的條件。在符合研究所安全審計要求的前 提下,將數據挖掘技術應用起來,從中篩選出優質供應商,能夠形成一套可實施性方 案。
    綜上所述,目前我國研究所電子元器件管理工作存在信息化程度低的問題且亟待 解決。通過信息化建設可以將員工、元器件、生產緊密結合起來,有力提高科研生產, 加快綜合國力的進步,我國研究所的信息化建設刻不容緩。
    1.3 本人完成工作
    本文主要完成了針對研究所物資部的電子元器件的信息管理系統及采購決策系 統的研究與實現工作。電子元器件信息管理系統實現了物資部現有工作的信息化,采 購決策系統以電子元器件信息管理系統為源數據,采用數據挖掘方法實現元器件采購 過程中在供應商選擇的輔助決策。
    對于電子元器件信息管理系統主要工作如下:
    (1) 通過實地調研的方式,對物資部元器件管理工作進行調查,掌握系統開發 需求,完成了電子元器件信息管理系統的需求分析。
    (2) 通過UML建模,實現了系統架構設計及功能模塊劃分。同時依照數據庫 設計原則,對系統數據庫進行設計。
    (3) 使用 J2EE 平臺,結合 SSH 框架開發電子元器件信息管理系統。對系統的 各個功能模塊進行詳細設計與實現,降低了研究所的元器件處理工作的難度,提高了 工作效率。
    (4) 對系統進行測試,包括功能測試和性能測試,保證系統運行穩定。系統通 過了三個月的測試,目前已穩定運行一年時間,各個功能均能滿足實際工作需求。
    對于采購決策系統主要工作如下:
    (1) 根據研究所在元器件采購過程中遇到的實際問題,與研究所共同對采購決 策系統的需求進行分析。
    (2) 通過 ETL 及數據倉庫技術,完成電子元器件信息管理系統向采購決策系 統的數據提取、轉換及載入,從而完成數據集選取及數據清洗這部分工作。
    ( 3) 通過 C4.5 決策樹算法實現數據決策分析過程,通過真實數據實現決策樹 的構建及剪枝,實現對元器件供應商從元器件質量、型號、到貨時間、元器件價格等 角度進行評估。
    ( 4) 對決策結果分析總結,通過比對決策結果和真實結果對決策模型的準確率 進行驗證。
    1.4 論文章節安排
    第一章:緒論。本章節主要介紹了電子元器件信息管理與采購決策系統的研究背 景及意義,并且介紹了本人在系統開發過程中完成的工作。最后介紹了本篇論文的章 節安排。
    第二章:系統需求分析。本章對電子元器件信息管理系統及采購決策系統進行需 求分析,從功能需求和非功能需求兩個方面分別進行討論。
    第三章:系統總體設計。本章從架構、功能模塊、數據庫三個方面對電子元器件 信息管理與采購決策系統進行了總體設計,實現系統的功能模塊的劃分。
    第四章:電子元器件信息管理系統詳細設計與實現。本章對電子元器件信息管理 系統從功能、流程以及技術等方面對系統進行了詳細設計與實現。
    第五章:采購決策系統詳細設計與實現。本章首先對分類進行了描述和選擇,然 后依據數據挖掘流程實現采購決策系統的功能,完成對供應商的決策。
    第六章:系統部署與測試。本章完成了電子元器件信息管理系統的測試工作,測 試結果令人滿意,系統正常運行。
    第七章:總結與展望。本章對全文進行了總結,對電子元器件信息管理系統和采 購決策系統進行了簡單的評價,并對不足之處加以描述。
    第二章 系統需求分析
    面對復雜多樣的用戶需求,開發人員制定合理正確的軟件需求分析在開發過程中 至關重要[4]。需求分析的主要任務是明確系統的主要功能,從而對整個系統提出真實、 全面、精確的分析,繼而完成深入描述軟件功能和性能的要求[5]。功能需求[6]需要將 系統包含的功能完整描述,從而使系統達到業務實際要求,保證用戶正常使用。非功 能需求主要從系統的性能和技術兩方面來考慮[7],如易用性、可靠性和拓展性等。
    2.1系統需求分析概述
    本系統以某研究所物資部實際需求為背景,服務于軍工產業,應用于該研究所內 網環境中,依據功能可劃分為信息管理子系統及采購決策子系統。
    信息管理子系統將物資部現有的工作流程串聯,實現元器件管理工作的信息化。 信息管理子系統在建設時需要與現有的物資系統進行同步,以保證基礎的任務信息及 物料信息及時更新,系統數據庫應使用物資部現有 SQL Server 數據庫或更高版本。 在元器件檢驗及入庫過程中,元器件檢驗信息將會在物資部與外網檢驗部門之間進行 流轉,經過與物資部和檢驗部門的協商,系統在開發過程中提供了信息傳遞模塊,同 時在檢驗部門的系統中集成相應模塊,保證雙方物理隔絕的情況下能夠信息正常交互, 信息傳遞過程中要保證傳遞高效性和信息的安全性。
     
     
     
    檢驗部門外網
    圖 2.1 電子元器件信息管理與采購決策系統功能示意圖
    在信息管理子系統建設完成后,物資部工作將在一定程度上實現信息化,降低工 作壓力,提升工作效率。但是仍存在元器件采購供應商評價、選擇困難的問題。在目 前物資部的工作當中,在確定了元器件的購買需求后,需要通過傳統的招標形式來確 定最終的供應商。由于此研究所購買的元器件將用于軍工產品,所以對元器件有著極 高的要求。通過招標的形式,員工在采購時只能通過供貨方提供的資料和自己的經驗 進行判斷,需要花費大量的時間和精力。因此需要通過采購決策子系統的建設,實現 對元器件供應實現科學、智能的評價。為保證信息管理系統正常運行不受影響,需將 待挖掘數據轉移至采購決策系統服務器,進而根據數據挖掘流程進行分析處理。
    綜合以上信息,可以得出電子元器件信息管理與采購決策系統的基本功能框架圖, 如圖 2.1 所示。
    根據物資部現有工作流程和工作需要,信息管理子系統包含業務處理模塊、元器 件檢驗管理、元器件入庫管理、信息傳遞、Excel處理、待辦工作提醒等六個功能模 塊。信息管理系統還應具備系統管理功能,具體為權限管理、日志管理、數據庫管理。 上述業務處理由普通用戶完成,系統管理由管理員用戶完成。綜上,電子元器件信息 管理系統總體功能如圖 2.2 所示。
     
     
    采購決策子系統以信息管理子系統數據為基礎,通過利用數據挖掘方法對元器件 供貨單位進行評價,實現采購過程中的輔助決策。
    根據研究所實際的采購流程及訂單信息,采購決策系統的數據來源于電子元器件 信息管理系統,需要將數據轉換至采購決策系統服務器,進而依據數據挖掘基本流程, 實現對供應商的決策、評價,指導元器件采購過程。綜上所述,采購決策系統基本功 能如圖 2.3 所示。
    源數據提取 〉 數據預處理 〉數據決策分析 〉結果分析總結
    圖 2.3 采購決策子系統總體功能圖
    2.2信息管理子系統功能需求分析
    2.2.1系統管理
    系統管理主要是將非業務的一些功能整合起來,由系統管理員進行操作,包括用
    戶管理、日志管理、數據庫管理和數據同步。
    (1) 權限管理:實現了基本的用戶賬戶管理及權限分配功能。本系統的權限由 角色決定,不同的角色具備不同的資源訪問權限。
    (2) 日志管理:由于系統應用在研究所內部,對用戶操作有嚴格的審查要求, 因此用戶在系統中的操作需要被記錄。對于已記錄的操作需要能夠根據操作類型、用 戶名、操作時間進行查詢,并且可以導出到Excel文件當中。
    (3) 數據庫管理:數據庫管理用于處理系統的備份策略,系統應具備完善的備 份與恢復機制[8],實現系統的自動備份和手工備份管理,支持快速重新部署,數據快 速恢復還原。系統界面上應顯示已完成的備份,并且支持手動備份,手動刪除備份。
    (4) 數據同步功能用于與物資部現有數據進行同步,屬于數據庫管理的一部分。 研究所物資部內部目前正常運營著一個信息系統,電子元器件信息管理系統需要和該 系統進行數據同步,提高數據利用率,降低用戶工作量。
    2.2.2業務處理模塊
    業務處理模塊包括物資部現有工作的三個流程,分別是備料任務管理、任務缺料
    管理、元器件訂購管理,這三個流程邏輯相似,因此統一劃分到業務處理模塊,各個 模塊基本業務如下:
    ( 1) 備料任務管理主要實現根據所內生產任務實現元器件準備工作,保證生產。 涉及職位包括總計劃、調度員、質保員、庫管員、信管組五個職位。
    (2) 任務缺料管理主要用于對庫房缺少的元器件進行統計,同時登記缺少的元 器件準備進展。此模塊涉及職位包括調度員、采購員兩個職位。
    (3) 元器件訂購管理用于處理任務需求的元器件的采購流程,主要流程包括生 成采購計劃、招標/合同管理、到貨管理。此模塊涉及職位包括總計劃、采購員。
    在以上業務中,需要功能包括業務新增、業務審查、業務查看等基本功能,具體 需求如下:
    (1) 業務新增:在系統中新增一條業務記錄,需要填寫必要信息,并經過確認 保存;
    (2) 業務審查:上述業務流程中,在業務創建后均需要相應職位進行審查,補 全等工作,用戶可根據不同業務的不同要求進行審查,符合要求后,確認提交,當全 部審查工作完成時,這一條業務也就隨之完成。
    (3) 業務查看:在上述業務流程中,系統應當支持隨時查看業務進展,并且支 持條件組合查詢,以應對不同需求。
    結合以上需求,得出業務處理模塊功能用例圖如圖 2.4 所示。
     
     
    2.2.3元器件檢驗管理
    元器件檢驗管理用于將電子元器件送到檢驗部門進行檢驗,只有通過檢驗的元器 件才能上線生產。元器件檢驗根據元器件來源分為兩種形式,分別為送檢和復檢。送 檢針對采購到貨的全新的元器件,復檢針對庫存的元器件。
    這兩種檢驗流程相同,流程涉及數據有些許差別,涉及職位包括采購員/庫管員、 質保員。此模塊具體需求如下:
    (1) 由物資部員工發起檢驗流程,送檢由采購員發起,復檢由庫管員發起,填 寫元器件基本信息、檢驗數量及相關的任務信息;
    (2) 物資部質保員對采購員發起的檢驗單進行審核,主要包括元器件的檢驗條 件,DPA數量等信息;
    (3) 物資部員工在質保員認證完成后,將檢驗單導出并送至檢驗部門;
    (4) 檢驗部門接收送檢物資,進行內部檢驗。 結合以上需求,得出元器件檢驗模塊用例圖如圖2.5所示。
     
     
    2.2.4元器件入庫管理
    元器件入庫管理負責將檢驗部門的檢驗結果,將元器件存入物資部庫房,進而將 元器件送至生產單位。此模塊由庫管員完成,具體需求為庫管員根據檢驗部門提供的 合格證將對應批次的元器件進行入庫處理,對于不合格的元器件同樣登記,但不做入 庫處理。
    2.2.5信息傳遞功能
    根據需求分析中的需求,信息傳遞功能用于解決物資部與檢驗部門物理隔離無法 進行信息交互的問題。此功能應提供滿足雙方信息交互需求的信息傳遞格式,包括送 檢單/復檢單信息及檢驗系統的合格證/不合格證信息。由于信息由內網環境轉入外網 環境,因此要保證傳遞信息足夠安全,防止因信息丟失甚至盜取導致關鍵信息泄漏, 造成嚴重后果。
    另外,在以往的實際檢驗過程中,雙方員工無法跟蹤檢驗環節流轉過程,出現問 題時也很難查到根源,最終導致無法追責,審計部門無法開展工作。因此在信息傳遞 時,本系統應支持文件比對,在出現問題時便于追查。
    結合以上需求,得出本模塊功能具體需求如下:
    (1) 同雙方進行商議,設計能夠被雙方正確接收的通信協議;
    (2) 確定加密策略,將檢驗單信息進行加密處理,保證信息安全;
    (3) 根據實際情況,不同類別的元器件可能一次檢驗出現不同數目的檢驗單。 針對少量、大量元器件檢驗流程,分別設計不同的傳遞方式,以應對不同量級的需求;
    2.2.6Excel 處理功能
    在系統建設之前,物資部的工作主要使用線下Excel文件進行信息處理,并且在 日常會議、審查當中Excel文件會經常使用。另外,基于研究所的要求,此系統僅限 物資部可以訪問,因此在與生產部門進行交流時,用戶需要將數據導出到Excel文件 中。綜上,系統需要具備Excel處理功能,保證物資部現有日常工作不受影響。具體 需求如下:
    (1) 對于現有數據,系統應支持通過導入的形式將Excel數據導入到系統當中, 從而實現數據及時更新;
    (2) 為應對會議、審查等實際需求,系統應支持將數據導出到Excel文件當中; 針對不同需求支持導出不同形式的Excel文件;
    (3) 對于通過Excel導入系統和由系統導出的數據,系統要保證數據不會缺失、 不出錯、不會丟失精度。
    2.2.7待辦工作提醒功能
    信息管理系統將實現物資部工作信息化,因此實現多人協同辦公必不可少。待辦 工作提醒用于將同一個模塊的不同組成部分的流程串聯起來,使得分散得工作方式轉 變稱工作流的形式,從而提高工作效率,更好地幫助多個用戶協同辦公。在本系統中, 要通過消息提醒的方式提示用戶處理工作,具體需求如下:
    (1) 針對信息管理系統的各個模塊,制定完善、周全的任務流程。對于每一個 流程要確保各個環節不會遺漏,同一個任務也不允許多次提醒,不得越級提醒;
    (2) 用戶接收任務提醒時,要根據不同的模塊進行分類,方便用戶處理信息。
    2.3采購決策子系統功能需求分析
    通過信息管理子系統的需求分析,明確了物資部工作信息化的基本工作需求。在 物資部工作過程中,元器件訂購管理從來源上決定了元器件的質量,因此對于供應商 的選擇至關重要,以往人工評價供應商難以直觀,本文希望通過決策算法的科學評估 對供應商產生直觀、科學的評價,從而為采購過程中的供應商選擇提供指導。
    2.3.1源數據提取
    在系統進行設計實現之前,需要確定要挖掘的數據來源。采購決策系統進行挖掘 分析的來源于電子元器件信息管理系統。采購決策系統的建設是為了優化采購過程, 通過技術方法對供應商進行決策。因此采購決策系統的源數據是信息管理系統當中元 器件采購管理模塊及元器件檢驗管理、元器件入庫管理當中涉及到的相關信息。
    2.3.2數據預處理
    根據數據挖掘的基本流程,數據在使用前需要先進行預處理及數據清洗工作, 從 而保證待挖掘的數據均為有用數據。通過數據倉庫技術,可以將數據預處理工作交給 數據庫去實現,開發人員僅關注功能的具體實現即可。
    2.3.3數據決策分析
    數據挖掘一般是指從大量的數據中通過算法搜索隱藏于其中信息的過程,包含了 分類、聚類、預測、估計等多個方面,本系統要通過數據挖掘方法實現對元器件供應 商的評判結果,本質上是對供應商進行分類。因此在數據決策分析過程中,需要選擇 一個合適的數據挖掘分類算法,從而實現供應商的決策,指導采購過程。
    2.3.4結果呈現與總結
    本系統需要實現供應商的決策,輔助采購過程,因此在結果呈現上需要直觀并且 易于理解。在決策結果產生后需要對決策結果的正確性與性能進行驗證和討論。
    2.4 非功能需求分析
    2.4.1信息管理子系統非功能需求分析
    對于電子元器件信息管理系統,在業務邏輯和系統功能分析后,仍需要詳細討論 系統的非功能需求,詳細描述如下:
    (1) 實用性:系統的實用性要求系統要符合物資部現有工作流程,消除物資部 現有工作的弊端,例如信息處理速度慢、更改信息無法追查等。同時,系統的界面布 局應符合大多數用戶操作習慣,數據展示清楚明了。
    (2) 可靠性:系統應支撐多用戶并發操作;對于常見問題應具備異常處理功能; 對災難性崩潰應支持快速部署,數據快速恢復還原;系統正式上線運行一年后,不發 生系統響應性能下降、響應能力下降、資源占用顯著增加等現象[9]。
    (3) 可拓展性:系統應在符合研究所信息化的前提下,提供開發平臺,具備良 好的二次開發功能,支持功能擴展與裁剪。
    (4) 安全性:本系統應用在研究所,業務流程覆蓋多個業務崗位,系統的安全 性、保密性尤為重要,系統的安全性要求不得低于物資部現有的基礎保密安全要求; 系統與外網檢驗系統進行信息交互時要保證信息為加密信息;系統要能夠記錄各類操 作,滿足操作的可追溯要求,記錄內容可在線查看和導出。
    綜合以上性能需求分析,系統的性能需要保證用戶在使用系統時快速相應,并且 能夠承受業務爆發帶來的服務器壓力,具體參數及要求如表 2.1 所示。
    表 2.1 信息管理子系統性能需求
    性能 需求項 理想值
    系統響應效率 用戶登錄 < 2s
    頁面跳轉
    系統按鈕反映
    系統事務處理 < 3s
    Excel導入/導出 1000 條<5s
    系統并發請求數 最大用戶請求并發數 100
     
    2.4.2采購決策子系統非功能需求分析 對于采購決策子系統,需要處理的過程包括數據抽取、數據倉庫設計及決策過程。 性能方面主要集中在數據抽取過程,為了保證元器件信息管理系統正常運行,需要每 個月進行數據抽取,要保證數據準確、完整的同步。在決策過程中,算法的計算過程 應該在可以承受的時間。
    2.5 本章小結
    本章從研究所實際業務流程出發,對電子元器件信息管理系統和采購決策系統進 行了詳細的分析。對于信息管理子系統,通過對研究所物資部目前的工作流程進行分 析,結合研究所實際的網絡條件,在功能上對各個模塊進行了詳細地劃分,在性能上 進行了周全地分析,在安全策略上進行了嚴密地推斷。對于采購決策子系統,結合業 務需求和技術條件,依據數據挖掘基本流程,設計了完整地決策流程。
    第三章 系統總體設計
    本章將根據需求分析從系統架構、功能模塊及數據庫等方面對電子元器件信息管 理系統及采購決策系統進行總體設計,實現系統技術及服務器架構的設計。
    3.1 系統架構設計
    3.1.1系統邏輯架構
    信息管理子系統主要應實現物資部現有工作流程的信息化,實現多人在線處理, 保證信息完整、順利、高效流轉。因此,本文開發的元器件信息管理系統采用 B/S (Browser/Server)架構,降低系統升級和優化維護的成本凹,減少客戶端的壓力。系 統采用Java語言,基于J2EE[ii]平臺開發。系統使用Spring框架、SpringMVC框架和 Hibernate^]框架進行搭建與開發,具備良好的可拓展性和可維護性。為了使開發工作 明了清晰,系統分為三層架構,由表現層,業務邏輯層和數據訪問層構成[13]。表現層 負責接收前臺請求,利用 SpringMVC 實現頁面的跳轉和處理,業務邏輯層對請求的 數據進行邏輯處理[14],數據訪問層實現數據庫操作,借助Hibernate實現數據持久化。 Spring 負責系統的事務處理及對 SpringMVC 和 Hibernate 的管理。系統的日志功能, 使用Spring AOP[15]實現,與系統業務邏輯分離,降低耦合性。系統的資源訪問控制使 用Spring Security框架實現,保證不同用戶具有不同的系統資源訪問級別。系統使用 POI框架實現Excel文件處理,保證讀寫文件的靈活性。信息傳遞使用AES[16]加密算 法,通過對數據進行加密,保證信息不會泄漏。綜上,信息管理子系統軟件邏輯架構 如圖 3.1 所示。
     
     
    采購決策子系統將數據挖掘思想與數據倉庫相結合,得出了一種更加高級的決策 系統形式,通過源數據的提取、ETL過程將待挖掘數據存儲到數據倉庫中,然后通過 決策算法,將訓練模型進行測試與保存,方便后期系統調用,對供應商的優劣進行決 策。采購決策系統功能框架如圖 3.2 所示。
    抽取
    歷史信息
     
    圖 3.2 采購決策子系統邏輯架構圖
    3.1.1系統網絡架構
    系統目前雖然應用于研究所內網,用戶有限,單臺服務器已經能夠滿足正常系統 使用需求。但是為了防止業務集中爆發,方便后期業務拓展,同時為了保證系統功能 可拓展,電子元器件信息管理系統在服務器搭建時采用了負載均衡策略,采用 “Nginx+Tomcat+Redis+SQL Server"多重架構進行搭建,最大程度地減少數據庫服務 器的壓力,提升系統的性能與用戶體驗,系統網絡架構圖如圖 3.3 所示,請求過程在 圖中有文字說明。
    從圖中可以看出,用戶在向服務器提交請求時首先會到達Nginx服務器,此服務 器用戶存放靜態資源,如果用戶請求靜態資源直接返回,如果是動態資源將轉發請求 至應用服務器。請求轉發至應用服務器的過程由Nginx提供負載均衡策略實現,此處 通過輪詢算法,使得請求到達應用服務器,處理不同的請求。當需要數據持久化時, 首先會在Redis緩存服務器中進行查找,如果緩存中存在數據可直接返回,如果Redis
    中不存在,則會請求數據庫服務器,查詢SQL Server并將查詢結果返回。不同的數據 庫之間通過主從復制的形式實現數據一致性。
    對于采購決策子系統,將設置一臺數據倉庫服務器,通過ETL將決策過程需要 的數據加載到數據倉庫中來,以供我們進行分析挖掘。
     
    圖 3.3 電子元器件信息管理與采購決策系統網絡架構圖
    3.2系統功能模塊設計
    信息管理子系統依據J2EE實現思想,根據研究所物資部的實際需求對系統模塊 進行劃分,信息管理子系統功能框架如圖 3.4 所示。
     
     
     
    (1) 備料任務管理模塊:主要用于對尚未完成的任務進行統計,并對后續工作 進行安排、調度、補全等。此模塊包括生產任務下達、備料任務下達、質保票據審核、 質保質量審核、庫房審核、最終確認六個主要功能,同時支持任務進展查詢,任務信 息導出和任務撤銷功能。
    (2) 任務缺料管理模塊:主要用于統計任務缺少的物料信息及采購進展。此模 塊包括缺料任務下達,任務進展登記兩個功能,同時支持缺料進展查詢,缺料信息導 出,缺料狀態更改功能。
    (3) 元器件訂購管理模塊:主要用于產生、滿足生產任務的元器件采購需求, 實現從采購需求產生到物料入庫的完整流程。此模塊包括采購任務下達、標書/合同 管理、到貨管理三個功能。
    (4) 元器件檢驗管理模塊:主要用于對采購到貨的元器件或庫房庫存元器件進 行檢驗,保證元器件質量可以滿足生產需求。此模塊包括申請檢驗、檢驗單審核、檢 驗單導出三個功能。其中檢驗單導出支持兩種形式,一種為二維碼檢驗單,應對檢驗 元器件數目較少的情況,一種為導出到Excel文件的批量檢驗單,應對檢驗元器件數 目較多的情況。
    (5)元器件入庫管理模塊:主要用于將檢驗部門完成檢驗的元器件進行入庫操 作,需根據合格證、不合格證進行操作。檢驗部門送出的合格證/不合格證上均包含二 維碼,員工通過掃描二維碼進行入庫操作,如果二維碼損壞,支持手動輸入。
    (6)系統管理模塊:此模塊包括權限管理、日志管理、數據庫管理三個功能。 權限管理包括用戶信息維護及權限分配;日志管理包括日志記錄、查詢及導出;數據 庫管理包括數據庫備份、備份查詢、備份刪除及數據同步。
    (7)待辦工作提醒:此模塊主要用于通知用戶處理工作。通過將物資部各項工 作進行分析后,各個模塊均可產生若干工作流程,通過工作提醒,可以提高工作的時 效性及便利性。超時任務提醒,保證超時工作及時處理,把損失降到最低。
    (8)Excel 處理模塊:此模塊包括 Excel 導入和 Excel 導出兩個功能。其中 Excel 導入用于將現有數據導入到系統當中,對于部分量級較大的任務可實現一次性下達, 提高工作效率。Excel導出則針對不同模塊設置不同的Excel格式以滿足實際需求, 并支持選擇自定義的列導出。通過將物資部各項工作進行分析后,各個模塊均對此模 塊有實際需求。
    對于采購決策子系統,為了使用戶在使用過程中有直觀的結果顯示,方便的用戶 操作,系統功能模塊劃分如下,如圖 3.5 所示。
     
    圖 3.5 采購決策子系統功能模塊圖
     
    (1)數據集選取將明確電子元器件信息管理系統中用來進行決策分析的數據 表字段,具體為元器件訂購管理及元器件檢驗、入庫流程的數據。
    (2)數據預處理實現數據清洗,將電子元器件采購歷史數據中噪音數據、錯誤 數據排查,同時將空數據進行處理。
    (3)數據決策分析為系統的核心部分,通過歷史真實數據對決策樹進行訓練與 剪枝,從而生成決策模型。
    (4) 結果分析總結將通過樣例數據對決策模型的正確性與準確性進行測試,如 果決策結果合理,將保留決策模型,以對后續的供應商進行決策,為采購過程提供指 導。
    3.3 系統數據庫設計
    本節將對信息管理子系統的數據庫設計進行詳細討論。采購決策子系統的數據庫 表將根據信息管理子系統的數據庫的部分表的部分字段進行構建,此處不再贅述。
    3.3.1概念結構設計
    系統的數據庫設計要在對系統進行詳細的需求分析之后進行,從而將現實世界中 各個實體之間的關系映射到數據模型當中,即將現實中的實體以關系模型進行連接, 最后再將該關系模式抽象成數據庫中一個個對應的的二維表[17]。通過概念結構設計, 可以將業務實體與數據庫模型建立聯系,從而明確各個業務節點之間的關聯關系與組 織形式,從而為邏輯結構設計打下基礎【I8】。元器件信息管理子系統的E-R圖如圖3.6 所示。
     
    圖 3.6信息管理子系統數據庫 E-R 圖
    3.3.2邏輯結構設計
    數據庫邏輯結構設計的主要目的是將 E-R 模型轉換成數據庫二維表,即根據概 念結構設計生成的 E-R 模型,將其轉換為特定數據庫的邏輯結構[19]。本文設計的信 息管理子系統使用SQL Server數據庫,為了方便系統開發和提升系統性能[20],合理 規劃了數據表的結構,創建了索引。系統數據庫表結構具體如下:
    (1) 任務信息表,主要內容包括了研究所生產任務的信息,任務信息表來源于 物資部舊物資系統的數據庫,任務編號作為表的主鍵,具體如表 3.1 所示。
    表 3.1 任務信息表
    屬性 描述 類型 是否允許為空 鍵類型
    taskSerialNumber 任務編號 varchar (20) 主鍵
    typeSerialNumber 型號編號 varchar (10)
    typeSerialName 型號名稱 varchar (30)
    productSerialNumber 產品編號 varchar (50)
    productName 產品名稱 varchar (20)
    developStage 研制階段 varchar (20)
    taskNumber 任務數量 int(10)
    taskAssignedTime 任務下達時間 dateTime
     
    (2) 物料信息表,物料信息主要是電子元器件的基本信息,比如行高規格,封 裝形式等,物料信息表同樣來自于物資部舊物資系統,需要定時同步,物料代碼將作 為主鍵,具體如表3.2所示。
    表 3.2 物料信息表
    屬性 描述 類型 是否允許為空 鍵類型
    envelop 封裝形式 varchar(50)
    excute 采用標準 varchar(50)
    manufacturer 生產廠家 varchar(50)
    material 物料代碼 varchar(50) 主鍵
    materialname 物料名稱 varchar(50)
    quality 質量等級 varchar(50)
    specsname 型號規格 varchar(50)
    unitcode 計量單位 int(10)
     
     
    (3) 備料任務表,存儲任務信息、備料任務信息及備料任務各個環節審核,數 據原本屬于同一個Excel表格,為提高開發效率,將備料任務表拆分為如下。
    a) 備料任務信息表,包含了任務編號,作為外鍵關聯生產任務信息,備料任務 序號作為主鍵,串聯整個備料任務,以及各部門進展信息,具體如表3.3所示。
    表 3.3 備料任務表
    屬性 描述 類型 是否允許為空 鍵類型
    prepSerialNumber 備料任務序號 varchar (20) 主鍵
    preparationNumber 備料臺套數 int(10)
    taskSerialNumber 任務編號 varchar (20) 外鍵
    responsiblePerson 負責人 varchar (20)
    AuditorCompleteTime 稽核審核時間 dateTime
    ScreenCompleteTime 質保審核時間 dateTime
    PreparationCompleteTime 庫房審核時間 dateTime
    ManageCompleteTime 信管審核時間 dateTime
     
    b)票據審核,由質保部門的特殊員工完成備料任務的票據審核,以自增長id作 為主鍵,備料任務序號作為外鍵關聯備料任務信息,具體如表3.4所示。
    表 3.4 票據審核表
    屬性 描述 類型 是否允許為空 鍵類型
    id 邏輯Id int(10) 主鍵
    prepSerialNumber 備料任務序號 varchar (20) 外鍵
    preAuditor 備料負責人 varchar (20)
    ticketTime 電子備料完成,出票時間 dateTime
    isOutStore 是否完成出庫 varchar (10)
    auditorNote 備注說明 varchar (50)
     
    c) 質保審核,由質保處質量審核員工完成備料任務的備料任務評審,以自增長 id作為主鍵,備料任務序號作為外鍵關聯備料任務信息,具體如表3.5所示。
     
    表 3.5 質保審核表
    屬性 描述 類型 是否允許為空 鍵類型
    id 邏輯id int(10) 主鍵
    prepSerialNumber 備料任務序號 varchar (20) 外鍵
    warranty 質保處 varchar (20)
    sxTime 篩選處理時間 dateTime
    preRevComTime 備料評審完成時間 varchar (20)
    warrantyNote 備注說明 varchar (50)
     
    d)庫房審核,由庫房完成備料任務涉及到的元器件的復驗、發料,以自增長id 作為主鍵,備料任務序號作為外鍵關聯備料任務信息, 具體如表3.6所示。
    表 3.6 庫房審核表
    屬性 描述 類型 是否允許為空 鍵類型
    id 邏輯id int(10) 主鍵
    prepSerialNumber 備料任務序號 varchar (20) 外鍵
    treasurer 庫管員 varchar (20)
    reviewTime 復查時間 dateTime
    preComTime 備料完成時間 dateTime
    treasurerNote 備注說明 varchar (50)
     
    e)最終確認,由信管組登記各個部門對備料任務的額外補充,以自增長id作 為主鍵,備料任務序號作為外鍵關聯備料任務信息,具體如表3.7所示。
    表 3.7 最終確認表
    屬性 描述 類型 是否允許為空 鍵類型
    id 邏輯id int(10) 主鍵
    prepSerialNumber 備料任務序號 varchar (20) 外鍵
    divisionlnfo 事業部信息 varchar (20)
    marketDepartInfo 市場部信息 varchar (20)
    outStoreMoney 出庫金額(元) float
    purchaseMoney 申購金額(估算) float
     
     
    (4) 任務缺料表,用于處理在備料過程中缺少的元器件信息, lackSerialNumber 作為主鍵,追蹤缺料進展, taskSerialNumber 作為外鍵,關聯任務信息, material 作為 外鍵,關聯元器件信息, 具體如表 3.8 所示。
    表 3.8 任務缺料統計表
    屬性 描述 類型 是否允許為空 鍵類型
    lackSerialNumber 任務缺料序號 varchar (20) 主鍵
    taskSerialNumber 備料任務序號 varchar (20) 外鍵
    material 物料代碼 varchar (20) 外鍵
    requireNum 需求量 int(10)
    preparationNum 己備數量 int(10)
    lackNum 缺料數量 int(10)
    purchaseListNumber 申購單號 varchar (20)
    confirmMaterialTime 確保發料時間 dateTime
    purTime 訂購時間 dateTime
    purNum 訂購數量 int(10)
    produceUnit 供貨單位 varchar (20)
    purcharseCycle 訂貨周期(周) int(10)
    causeOfNotArrive 貨期延誤原因 varchar (50)
    progressNow 目前進度 varchar (128)
    solution 解決措施 varchar (128)
    planScheduling 計劃調度員 varchar (20)
    buyer 采購員 varchar (20)
    problemClass 問題類別 int(10)
     
    (5) 元器件訂購信息表,用來存儲元器件訂購信息,申購物料序號作為主鍵, 串聯起整個元器件采購流程。 taskSerialNumber 作為外鍵,關聯任務信息, material 作 為外鍵,關聯元器件信息, 具體如表 3.9 所示。
     
    表 3.9 元器件訂購信息表
    屬性 描述 類型 是否允許為空 鍵類型
    purMaterialSeriNum 申購物料序號 varchar (20) 主鍵
    taskSerialNumber 備料任務序號 varchar (20) 外鍵
    material 物料代碼 varchar (20) 外鍵
    purchaseNum 申購數量 int(10)
    intoStockNum 利庫數量 int(10)
    unit 計量單位 varchar (10)
    buyNum 采購數量 int(10)
    buyer 采購員 varchar (20)
    askBatch 要求批次 varchar (20)
    orderTime 訂購時間 dateTime
    orderNumber 訂購數量 int(10)
    supplyUnit 供貨單位 varchar (20)
    orderCycle 訂貨周期(周) int(10)
    agreedToArriveTime 約定到貨時間 dateTime
    unitPrice 單價 float
    totalMoney 金額 float
    contractNumber 合同編號 varchar (20)
    contractSignTime 合同簽訂時間 dateTime
    orderSupply 訂貨貨源 varchar (20)
    isElecSensiDevice 是否靜電敏感器件 varchar (20)
    arriveTime 到貨時間 dateTime
    exceedAgreedTime 超過約定時間(天) int(10)
    exceedAgreedReason 超約定貨期原因 varchar (50)
    arriveModel 到貨型號 varchar (20)
    arriveNumber 到貨數量 int(10)
    batch 批次 varchar (20)
    differenceFromOrder 與訂購不相符情況 varchar (50)
     
    (6) 元器件送檢表,用于存儲元器件送檢單信息,送檢編號作為主鍵,串聯整 個流程,申購物料序號作為外鍵,關聯訂購的元器件信息,此表格物料代碼、任務編
    號并不做外鍵,而是用于檢驗流程。元器件送檢表包括了送檢流程和入庫流程涉及到 的數據庫表, 具體如表 3.10 所示。
    表 3.10 元器件檢驗表
    屬性 描述 類型 是否允許為空 鍵類型
    checkSerialNumber 送檢編號 varchar (20) 主鍵
    purMaterialSeriNum 申購物料序號 varchar (20) 外鍵
    material 物料代碼 varchar (20)
    checkNum 送檢數量 int(10)
    dpaNum DPA數量 int(10)
    screenNum 篩選數量 int(10)
    taskSerialNumbers 任務編號 varchar (20)
    taskName 任務名稱 varchar (20)
    produceUnit 供貨單位 varchar (20)
    useUnit 使用部門 varchar (20)
    askFinishTime 計劃完成時間 dateTime
    screenCondition 篩選條件 varchar (20)
    qualifiedNum 合格數 int(10)
    notQuali行edNum 不合格數 int(10)
    intoStoreTime 入庫日期 dateTime
    intoStoreNum 入庫數量 int(10)
    Acceptor 接收人 varchar (20)
    isIntoStore 是否完成入庫 int(10)
    (7) 元器件復檢表,用于存儲元器件復檢單信息,復檢編號作為主鍵,串聯整 個流程,備料任務序號作為外鍵,關聯備料任務信息。此表格物料代碼、任務編號并 不做外鍵,而是用于復檢流程。元器件復檢表包括了復檢流程和入庫流程涉及到的數 據庫表, 具體如表 3.11 所示。
     
    表 3.11 元器件復檢表
    屬性 描述 類型 是否允許為空 鍵類型
    reviewSerialNumber 復檢編號 varchar (20) 主鍵
    PrepserialNumber 備料任務序號 varchar (20) 外鍵
    material 物料代碼 varchar (20)
    checkNum 復檢數量 int(10)
    dpaNum DPA數量 int(10)
    screenNum 篩選數量 int(10)
    taskSerialNumbers 任務編號 varchar (20)
    taskName 任務名稱 varchar (20)
    produceUnit 供貨單位 varchar (20)
    useUnit 使用部門 varchar (20)
    askFinishTime 計劃完成時間 dateTime
    screenCondition 篩選條件 varchar (20)
    quali行edNum 合格數 int(10)
    notQualifiedNum 不合格數 int(10)
    intoStoreTime 入庫日期 dateTime
    intoStoreNum 入庫數量 int(10)
    Acceptor 接收人 varchar (20)
    isIntoStore 是否完成入庫 int(10)
     
    3.4本章小結
    本章根據用戶需求劃分了電子元器件信息管理系統和采購決策系統的各個功能 模塊,并從架構上實現了系統的總體設計。本章著重對電子元器件信息管理子系統的 數據庫從概念結構和邏輯結構結構上進行了設計與實現。
     
     
    第四章 信息管理子系統詳細設計與實現
    通過前文的需求分析與總體設計,信息管理子系統的基本框架與思路已經確定, 本章將介紹信息管理子系統的設計思路與實現方法,對于重點功能將通過文字說明與 流程圖的形式進行詳細描述與討論。
    4.1系統管理
    4.1.1權限管理
    權限管理包含權限分配及用戶信息維護。用戶信息維護限于篇幅不再贅述,下面 重點介紹權限分配。系統的權限分配通過資源訪問控制,避免員工越級訪問,越權操 作。在創建用戶時,系統會賦予相應的角色,角色用來控制用戶是否具備進行操作的 條件,例如創建業務,修改業務,刪除業務,Excel導入等等。權限分配通過Spring Security實現,Spring Security利用Spring框架體系的重要特性AOP[21],降低權限管 理與系統業務的耦合性,便于后期維護。
    權限分配可分為用戶登錄認證及用戶請求認證,下面將分別介紹。
     
    UsernamePasswordAuth Provider DaoAuthentication UserDetails
    enticationFilter Manager Provider Service
    圖 4.1 用戶登錄認證授權時序圖
    從圖4.1中可以看出,依據Spring Security的登錄認證流程,用戶在登錄系統時, 會進入UsernamePasswordAuthenticationFilter類中去獲取用戶名和密碼,由于該類繼
    承了 AbstractAuthenticationProcessingFilter 類,所以請求會先進入父類的 doFilter 方 法,進而調用 attemptAuthentication 方法,然后再調用 AuthenticationManager 類的 authenticate 方法去驗證,最終會到達自 定義的 UserDetailsService 的 loadUserByUsername方法,返回用戶的及其權限信息,認證通過后將會登錄成功跳轉 到系統主頁。
    用戶登錄系統后進行功能操作時, SpringSecurity 同樣會對操作進行攔截。當用 戶進行請求時,請求會被 FilterSecurityInterceptor 攔截器攔截,這是一個方法級的過 濾器,在調用內部的 invoke 方法后,將會調用其父類的 AbstractSecurityInterceptor 提 供的beforeInvocation方法作為鑒別權限的入口,然后經由AccessDecisionManager到 達AccessDecisionVoter,對請求是否合法進行投票,通過時返回“1”,否則返回“-1”, 從而決定后續的業務功能是否執行。用戶請求時序圖如圖4.2所示。
     
     
     
    屮Voke
    ——beforelnvocation-^
    根據返回結果判斷
    是否繼續執行
    圖 4.2 用戶請求時序圖
    4.1.2日志管理 日志管理主要負責記錄、查看用戶在系統當中進行的各種操作,比如修改數據, 導入導出等等。本系統日志管理具體記錄了用戶賬號、用戶職位、操作內容、操作時 間。通過日志管理功能的建設,使得用戶操作有跡可查,方便研究所在審查時信息搜 集及出現重大問題時的責任追究。日志管理同樣支持將用戶操作記錄導出到Excel文 件當中。
    日志管理功能主要依據SpringAOP實現,其核心思想為代理模式,默認使用JDK 動態代理。如果將日志管理功能融合業務流程無疑會降低系統的耦合性,使系統的難 以維護。在實現過程中上,通過@Aspect注解和配置文件中相關的Advice聲明實現 AOP 模式的啟用。通過自定義注解實現將日志記錄的操作植入業務方法,增加了日 志記錄的靈活性。使用@AfterReturning注解讓日志記錄功能在用戶業務請求方法完 成后進行,保證日志記錄精準到位。
    4.1.3數據庫管理
    數據庫管理包括數據庫備份、查看備份文件、刪除備份文件和數據同步功能。本 系統的數據庫管理各項操作通過代碼實現,用戶通過界面即可實現更改數據庫備份策 略、查看備份文件等操作,增加數據庫管理功能的靈活性,減少用戶操作服務器的可 能性。
    (1) 數據庫備份
     
     
    如圖 4.3 所示,數據庫備份在實現上支持兩種形式,具體如下:
    a) 管理員在界面上通過頁面點擊事件,后臺接收前臺請求進行備份;
    b) 通過設置定時器,按照實際的設置定時備份數據庫。對于定時備份,為了避免 備份功能會在服務器重啟后立即執行,程序會對時間進行判斷,如果服務器重啟時間 晚于備份執行時間,則備份功能會在第二天對應的時間執行。
    (2) 備份文件查看與刪除
    對于備份文件的查看和刪除,用戶可查看三個月內的備份文件,系統會自動刪除 過期的備份文件。
    (3) 數據同步
    數據同步功能的需求源自系統使用實際情況,物資部現另有一個物資管理系統, 負責維護任務信息和物料信息,信息管理系統的部分基礎數據來自物資管理系統。為 了降低工作成本,提高現有數據的利用率,系統開發了數據同步功能。
    物資管理系統服務器和信息管理系統的服務器屬于同一個局域網,數據同步可選 方法有數據庫作業和JDBC連接物資管理系統數據庫兩種方法。為了降低物資管理系 統服務器壓力,提高信息管理系統的易用性,數據同步采用SQL Server作業的形式 實現,SQL Server作業提供了發布訂閱功能,物資管理系統數據庫發布快照,信息管 理系統數據庫定時訂閱,從而實現同步。在同步過程中,需要在信息管理系統數據庫 中建立相對應的任務信息,物料信息數據庫表格。數據同步邏輯如圖 4.4 所示。
     
     
    4.2 業務處理模塊
    業務處理模塊主要統計物資部的備料任務進展、任務缺料情況以及元器件采購過 程,在系統中劃分為備料任務管理、任務缺料管理及元器件訂購管理,這三個模塊功 能、邏輯類似,在本節中將以備料任務管理為例進行詳細說明與設計,其余模塊不再 贅述。
    4.2.1功能說明
    備料任務管理主要用于登記研究所生產任務所需元器件的準備工作。當一個備料 任務下達到后,物資部各個部門需要對該備料任務進行逐級審核,審核全部通過之后 才能夠提交到生產部門。審核不通過的任務需要從系統中作廢。
     
    圖 4.5 備料任務管理流程圖
     
    如圖 4.5 所示,備料任務管理模塊具體包括如下環節:
    (1) 生產任務下達 生產任務下達由總計劃進行操作,根據研究所的生產任務,總計劃會在每年固定
    的時間批量下達任務,物資部后續工作的開展均由此決定。
    (2) 備料任務審核 備料任務審核由調度員進行操作,調度員需根據生產任務確定備料任務,并創建
    一個備料任務序號,因為每一項生產任務可能需要多個元器件,因此需要用任務序號 和備料任務編號聯合確定一條備料任務。
    (3) 票據審核 票據審核由質保處員工進行操作,主要核對任務的文件信息是否完整、正確,如
    出現錯誤或缺失,需要及時更正和補全。
    (4) 質量審核 質量審核由質保處員工進行操作,對于備料任務需求的各個元器件均需要經過篩
    選審核后才能最終提供到生產線上,此部分質保處需登記篩選審核的結果信息。
    (5) 庫房審核 庫房審核由庫管員進行操作,當元器件檢驗完成時庫房在本模塊登記信息。
    (6) 最終確認
    最終確認由信管組實現,在以上各個部門均確認完成后,由信管組與生產部門協 商,最終由生產部門確認簽字后,可以將元器件提交。
    4.2.2功能設計與實現
    在備料任務管理中,每一個環節都是用單獨的Controller接收和回應請求,以便 區分不同的環節。由于實體間存在關聯關系,因此業務層在進行邏輯處理時,再將各 個環節統一起來,并最終在數據訪問層實現持久化。用戶在進行操作時,只會提交屬 于自己環節的數據,減少了修改其他環節數據的可能性。并且后臺處理請求時,沒有 必要將整個表進行處理,簡化了開發過程,提升了代碼的可讀性與可拓展性。
    備料任務管理模塊類圖如圖4.6所示,為了保證類圖易讀性,各個環節操作均由 一種方法代替。依照 Controller-Service-DAO 三層設計思想,三級的實現類呈現逐級 依賴關系,后一層的實現類在前一層中以成員變量的方式存在,通過調用成員變量的 方法,實現數據向下傳輸。在Service和DAO層的實現上均采用接口實現的方式,保 證程序的可拓展性。用戶在處理備料任務流程時,會根據各個環節的請求分別請求至 AssurancesController、StorageController、ManageController 和 TaskController 中的某一 個,分別處理用戶請求。Controller處理完成后將傳遞至Service層的TaskServiceImpl 類中處理業務邏輯,比如根據條件查找、信息編輯、刪除等等。在邏輯處理各個環節 均存在新增,查看和修改功能,刪除功能。在邏輯處理完成后,傳遞至 DAO 層的 TaskDAOImpl,在DAO層中將和數據庫進行交互,實現數據的查詢或持久化操作。
    用戶在查詢業務時可使用組合的查詢條件,以備料任務管理為例,支持用戶使用 任務編號、備料序號、產品名稱、任務狀態等近十個條件進行查詢。在實現時采用面 向對象思想,將查詢條件封裝成 TaskSearchModel 對象進行傳遞,對象內部封裝了 set/get 方法以及 Sql 語句拼接方法,簡化了開發成本,同時也具備一定的可拓展性。
    為了最大程度的還原用戶的工作習慣,系統在頁面構建上仿照Excel布局,支持 用戶批量處理數據,用戶在全部處理完成后點擊保存提交即可。系統支持用戶自定義 顯示列,頁面通過Bootstrap-Table構建。用戶使用系統進行查詢時,如果設置了某些 列列的隱藏,系統會將用戶自定義的界面展示規則存儲到數據庫中,并且在加載時讀 取相應的信息,如此一來,便可以針對每一個用戶的不同習慣展示界面。
     
    StorageController
    ManageController
     
    圖 4.6 備料任務管理類圖
    4.3 元器件檢驗管理
    4.3.1功能說明
    元器件檢驗管理實現將采購到貨的元器件或庫存的元器件送至檢驗部門進行檢 驗的功能。流程包括檢驗發起,檢驗單審核,檢驗單導出等。
    元器件檢驗的流程具體如下:
    (1) 檢驗發起 檢驗發起根據元器件來源可分為送檢和復檢,送檢是將采購到貨的元器件進行檢 驗,由采購員發起;復檢是將庫房的元器件送至生產線前再次檢驗,由庫管員發起; 二者流程相同。采購員/庫管員發起檢驗時,需要填寫符合檢驗部門要求的檢驗編號, 該編號會在檢驗部門檢驗、庫房入庫時使用,跟隨整個元器件檢驗流程。以送檢流程 為例,采購員發起送檢流程時,填寫送檢編號、送檢數量、要求完成時間等關鍵信息 后,其余的元器件信息可由采購計劃編號關聯帶出,保存提交后即可由系統通知質保 員審核復,檢流程同理。通過數據庫表之間的關聯,將元器件采購、檢驗流程串聯起 來,極大地提高了員工的工作效率。
    (2) 檢驗單審核 在采購員/庫管員提起檢驗流程后,需要經過質保處審核后才可通過。質保處審
    核需檢查基本信息是否符合要求,填寫篩選條件和DPA數量,確認無誤后保存提交, 通知采購員導出、打印檢驗單。
    (3) 檢驗單導出
    在信息確認無誤后,由檢驗發起者導出檢驗單。檢驗單導出支持兩種形式,一種 是直接打印的含有二維碼的檢驗單,一種是需要刻錄光盤的Excel文件檢驗單。其中, 二維碼檢驗單可用在元器件檢驗數目較少的情況,每一條二維碼對應一條檢驗記錄; Excel 文件檢驗單可用在元器件檢驗數據較多的情況,方便檢驗部門接收。隨后員工 即可攜帶元器件與檢驗單送至檢驗部門。對于檢驗單導出的格式、信息內容、加密方 法會在本章第4.5節中具體介紹。
    元器件檢驗流程圖請看圖 4.7。
     
    圖 4.7 元器件檢驗管理流程圖
     
    4.3.2功能設計與實現 元器件檢驗管理的程序實現與前文類似,但存在一些特殊的方法以應對元器件加 驗的實際需求,因此類之間的依賴關系不再贅述,此處僅敘述關鍵方法, 以元器件送 檢為例,類圖如圖 4.8 所示。
    sendCheck
    SendCheckController
    -sendCheckService:sendCheckService +saveOrUpdateSC(SendCheck sc):void +addSCFromPurchase(string buySerialNumber ) :sendCheck +isCompleted(SendCheck sc): bool +exportSendCheck(String sendCheckSerialNumber): void
    sendCheckServiceImpl £> <<interface>> sendCheckService
    -sendCheckDAO:sendCheckDAO
    +saveOrUpdateSC(SendCheck sc):void +addSCFromPurchase(string buySerialNumber ) :sendCheck +isCompleted(SendCheck sc): bool +exportSendCheck(String sendCheckSerialNumber): void +saveOrUpdateSC(SendCheck sc):void +addSCFromPurchase(string buySerialNumber ) :sendCheck +isCompleted(SendCheck sc): bool +exportSendCheck(String sendCheckSerialNumber): void
     
     
    \|/
    sendCheckDAOImpl <<interface>> sendCheckDAO
    +saveOrUpdateSC(SendCheck sc):void
    +addSCFromPurchase(string buySerialNumber ) :sendCheck +isCompleted(sendCheck sendCheck): bool £> +saveOrUpdateSC(SendCheck sc):void
    +isCompleted(sendCheck sendCheck): bool
    +addSCFromPurchase(string buySerialNumber ) :sendCheck
     
    圖 4.8 元器件檢驗管理類圖
    采購員在填寫送檢單時,需要從元器件訂購管理的表格中關聯數據,在界面上填 寫申購物料序號后,通過addSCFromPurchase()方法從元器件訂購管理的數據庫表中 選取相關信息,并且在頁面上自動填寫,從而提高數據的利用率,大大提高用戶使用 效率,具體包括物料代碼、供貨單位、使用部門、任務名稱、任務編號五個屬性的信 息。
    由于在以往的檢驗過程中,存在檢驗單信息填寫不足就送至檢驗部門的情況,導 致檢驗工作嚴重拖后,為去除這一情況,提高雙方工作效率,系統在用戶提交導出請 求時會通過isCompleted()方法對檢驗單的完整性進行判斷,只有填寫完整的送檢單才 允許導出打印,否則駁回導出請求。
    送檢單導出方法為exportQRSendCheck(),并二維碼送檢單和批量送檢單,導出 方法會在本章第4.6節中進行詳細討論。
    4.4 元器件入庫管理
    4.4.1功能說明
    元器件入庫管理實現將完成檢驗的元器件進行入庫的操作進行登記功能,由庫管 員進行操作。當物料出現缺損或丟失時,庫管員需要與檢驗部門和檢驗發起人進行核 對,追查物資去向。當物料與文件完整時,根據檢驗部門提供的合格證/不合格證進行 選擇入庫。當遇到合格證有缺損的情況時,系統支持手動錄入信息,保證工作正常流 轉。元器件入庫管理流程圖如圖 4.9 所示。
     
    圖 4.9 元器件入庫管理流程圖
    4.4.2功能設計與實現
    在此模塊,需要將元器件檢驗結果與之前的檢驗單實現相關聯,實現元器件檢驗 數據和元器件合格信息的閉環,入庫方法可選擇掃描二維碼或手動輸入兩種方式。
    二維碼掃描使用的是Symbol DS3508-SR二維碼掃描槍,此掃描槍采用USB接 口,支持熱插拔,方便用戶使用,降低了開發成本。在目前使用情況下,能夠實現二 維碼內容秒級別的讀取。
    以送檢過程合格證掃描入庫為例,用戶在掃描合格證上的二維碼時,前臺將會在 識別到密文標志位后,把掃描到的密文信息傳遞到后臺,后臺首先會運行解密方法, 解密完成后,系統會根據明文中的送檢編號篩選出對應的檢驗單信息,然后將明文信 息和檢驗單信息一起以 Json 的格式返回前臺,并在界面上正確顯示。庫管員在確認 信息無誤后保存,實現該條送檢單的更新,至此完成元器件檢驗、入庫完整流程。
    檢驗部門提供的二維碼同樣是經過加密的,具體解密過程將會在本章第4.5節中 進行詳細討論。上文提到的追查物料環節將會在本章第4.6中進行討論。
    4.5 信息傳遞功能
    4.5.1功能說明
    信息傳遞功能主要是為了應對物資部與檢驗部門網絡隔絕的情況。在信息傳遞的 過程中,既要保證信息高效、完整地在雙方之間傳輸,又需要保證信息安全,避免信 息泄漏。因此,信息傳遞功能需設計合適的明文傳輸協議,找到合適的二維碼生成方 法及實現可靠的信息加密算法。
    (1) 信息明文傳輸協議 為了保證物資部和檢驗部門雙方進行高效可靠的信息傳輸,經過雙方協商,每一 個檢驗單二維碼應包含如下內容(以送檢過程為例):
    表 4.1 信息傳遞內容
    檢 編 號
    務 編 號 任 務 名 稱 篩 選 條 件 物 料 名 稱
    規 格 生 產 廠 家 送 檢 數 量 D P A 數 量
    驗 數 量
    等 級 使 用 單 位
    為了對各個字段內容進行區分,本文對信息傳遞的格式進行了如下規定:字段使 用&字符進行分割,在明文信息經過加密后,密文開頭添加@字符,結尾添加&字符, 以防止由鍵盤誤觸或鼠標錯誤點擊產生的信息傳輸混亂的情況。
    (2) 信息加密算法 信息加密是信息傳遞功能的重要的環節,要保證加解密強度和加解密速度。結實
    際需求與各個算法的特性,本文選擇AES256加密算法進行加密。AES加密算法是目 前廣泛使用的對稱加密算法,具備足夠的安全性能。由于AES加密解密過程使用相 同的密鑰,因此通過用戶協商,密鑰在物資部與檢驗部門分別保存,減少密鑰傳輸過 程,避免出現問題。
    在加密之后,可能會產生不可識別字符,為了保證密文正確顯示,需要將密文進 行 Base64 轉碼。經過加密,轉換后的密文已足夠安全,難以破譯,檢驗部門在解密 時將程序執行逆操作即可。
    (3) 信息承載方式選擇 二維碼在現代社會有廣泛應用,利用掃描槍可以快速讀取二維碼內容,掃描槍支
    持USB熱插拔,無需二次開發,節省了開發成本。對于將密文信息生成二維碼的技 術,綜合考慮后,采用QRCode碼,它具有超高速識讀、信息容量大、可靠性高、可 表示漢字及圖像多種文字信息、保密防偽性強等優點[22]。通過設置不同的版本、糾錯 級別以及編碼模式,QRCode最多可容納近2000個漢字內容,完全滿足用戶需求。
    綜上,可以得出信息傳遞功能圖如圖4.10所示。
     
    圖 4.10 信息傳遞流程圖
    4.5.2功能設計與實現
    根據上文的功能說明,信息傳輸協議設計已經進行描述,本節需要實現信息加密、 解密算法及二維碼生成方法,具體如下:
    (1)信息加密、解密算法
    在 AES 加密算法中,算法可以分為兩個階段,分別是密鑰補全和加密過程,均 可通過JAVA相關類庫進行實現。密鑰補全過程通過按位運算,對輸入密鑰進行補全, 保證密鑰為32 字節。在密鑰補全完成后需要實現加密解密過程,加密解密過程通過 crypto 包下的 Cipher 類進行實現,類內部支持多種加密方式,需要經過初始化后才能 執行加密解密方法,方法輸入要求格式為字符數組,所以在傳入前需要將明文轉碼。 轉碼過程采用String自帶的getBytes("UTF-8")方法即可,括號內采用UTF-8編碼是 為了避免中文信息加密后解密出現亂碼的情況。加密解密流程圖如圖4.11所示。
     
    圖 4.11AES 加密解密過程
    在加密過程中,需要注意的就是對于整個流程的輸入、輸出,均要符合方法規范, 且要保證結果可讀。因此無論是密鑰選擇還是加密解密過程,都反復用到了 Base64 轉碼。JAVA JDK8對于此功能也有很好的支持,直接使用Sun.misc包內的 BASE64Encoder/BASE64Decoder 類即可實現。
    (2)信息承載 用戶在執行檢驗流程時,可以選擇以二維碼的形式導出檢驗單,用戶選擇某一條 送檢/復檢流程,點擊導出后,前臺會將這條信息封裝到模板類中,后臺接收后,經過 加密處理會將加密信息利用 QRCode 生成二維碼,二維碼生成具體實現邏輯如下:
    a)將密文作為參數傳遞到encoderQRCode()方法,該方法還需要填寫imgPath 輸出路徑、imgType圖片格式、size二維碼尺寸;
    b)encoderQRCode()方法內部調用qRCodeCommon()方法,核心組件為Qrcode, 可以實現設置二維碼排錯率,可選L(7%)、M(15%)、Q(25%)、H(30%),排錯率越高 可存儲的信息越少,但對二維碼清晰度的要求越小。設置二維碼尺寸,取值范圍1-40, 值越大尺寸越大,可存儲的信息越大。
    c)對于中間產生的計算結果,可以使用 BufferedImage 承載,二維碼繪制使用 Graphics2D組件讀取Bufferedlmage獲取數據。在繪制過程中,通過Qrcode.calQrcode() 方法計算出二維碼的二位布爾變量數組,從而確定圖像的每一個點是否有數據。最終 使用fillRect()方法對每一個像素進行填充。
    d)該工具還提供了 decoderQRCode()方法來讀取、解析二維碼,來源可以是文 件或字節流。
    綜合以上討論與介紹,在信息傳遞過程中通過信息加密與二維碼的形式實現了信 息高效、安全傳輸。在實際使用過程中,無論是物資部還是檢驗部門,對二維碼這一 承載形式非常滿意,大大地節約了工作成本。對二維碼的掃描和解密能夠達到秒級別, 極大地提高了雙方員工地工作效率,加快了檢驗流程地推進。
    4.6 Excel 處理功能
    4.6.1功能說明
    Excel 處理功能可以為系統用戶提供另一種處理信息的方式,研究所目前使用的
    Excel 版本均為 xlsx 格式的文件,因此兼容性不需要額外考慮。具體包括如下功能:
    (1)Excel 文件導入
    Excel 文件導入要實現將 Excel 每一行的內容導入到系統數據庫中,而不是實現 文件上傳。在實現方式上,對于每個模塊均為用戶設計好導入模板,用戶在使用時要 保證根據實現約定好的若干規則填寫數據,并通過界面導入按鈕,將Excel數據導入 系統。
    (2) Excel 導出
    Excel導出功能要實現將系統的數據寫入Excel文件中,并且依據需求來看,導 出格式要靈活。具體如下:
    a) 在大多數情況下,如果需要將數據導出到Excel,會將某一模塊的全部列導出。 在這種情況下,使用POI框架將對應模塊字段的順序與文件中列的順序相對應即可。 需要特殊注意的時,元器件檢驗模塊選擇導出帶有二維碼的檢驗單時,需要將二維碼 圖片寫入到 Excel 中;
    b) 在較少情況下,會需要在某一個模塊中選擇某些列導出。在這種情況下,需要 將用戶選擇導出的列傳到后臺,在寫入文件時根據前臺傳回的對應列寫入。
    (3) Excel 文件比對 前文提到,當元器件從檢驗部門送回物資部,庫管員發現元器件缺損時,將追查
    元器件去向,將會使用 Excel 文件比對功能,此功能通過讀取雙方提供檢驗單的 Excel 文件進行對比,對于出現問題的條目將會在界面上進行突出顯示,從而追責。
    4.6.2功能設計與實現
    在實現過程中,為了保證瀏覽器兼容性及功能的穩定性,選擇JAVA POI框架實 現。通過POI內置的組件,可以實現對Excel文件數據、樣式、排版多方面的控制。
    (1) Excel 導入功能
    在 Excel 導入時,為保證數據不會沖突,首先需要通過數據庫比對,判斷文件中 數據是否存在于系統數據庫,如果存在需要提醒用戶是否覆蓋數據,如果不存在直接 執行導入方法。在重復判斷后,通過讀取文件流的形式將Excel數據暫存到集合當中。 為提高開發效率,通過JAVA反射的方法將集合數據與實體類進行轉換,并且通過泛 型控制,可以對集合內部各個值的數據類型進行判斷,從而實現集合數據與實體類對 象的一一轉換,最終通過數據訪問層(DAO部分),實現數據實體類的持久化[23], Excel 導入流程圖如圖 4.12 所示。
     
     
     
    在導入過程中需要注意數據類型處理,尤其在元器件訂購管理中,存在單價、總 價等浮點類型字段,需要注意保留數據位數。通過使用POI的API實現了各種數據 類型的讀取,避免數據出現精度損失甚至是錯誤。當大量數據導入時,需要嚴謹的異 常處理方法,為了方便用戶處理,當數據出錯時將會為前臺返回出現錯誤的數據在 Excel 文件中的位置,方便用戶修改。另外,當用戶導入數據較多時,由于用戶的電 腦配置不同會出現導入緩慢的現象,為了讓用戶更直觀的查看導入過程進展,系統在 導入界面上添加了導入進度按鈕,以百分比的顯示導入進程,方便用戶掌控。
    (2)Excel 導出功能
    Excel 導出需要支持多種形式,具體有如下幾種選擇:
    a)跨頁選取導出
    這種導出形式可針對用戶在查詢后,根據實際工作情況,選擇需要的條目進行導 出。前臺通過 SessionStorage 實現數據跨頁選取,向后臺傳遞選中條目的主鍵信息, 這樣可以減少客戶端向后臺傳遞消息的數目,降低客戶端壓力。后臺接收到前臺傳遞 的信息后,通過篩選得出要導出的條目,寫入Excel。
    b)條件批量導出
    這種導出形式可針對需導出的信息較多的情況,如果跨頁選取仍然會產生較大的 工作量,可以使用條件批量導出功能。用戶在界面填寫相關條件后,點擊導出按鈕即 可。前臺會向后臺傳遞用戶填寫的條件,篩選完成后寫入Excel。
    c)自定義列導出 這種導出形式只存在與備料任務管理、任務缺料管理、元器件訂購管理中,并且 使用頻率較低。此功能后臺會根據每個表的列數進行二進制字符串編碼,當用戶選擇 自定義導出界面時,首先要選擇需導出的列,傳遞到后臺,后臺將選中的列置為 1, 并且根據字符串將Excel表頭寫好。然后根據主鍵信息,篩選出對應內容,寫入Excel。
    在寫入文件時,每一個Excel文件實例化一個XSSFWorkbook組件,POI支持操 作每一個Excel的sheet,每一行,每一列,通過結合JAVA反射與循環即可實現數據 寫入。為了在保證導出樣式的同時提高導出文件的易讀性,通過結合 POI 的 XSSFCellStyle組件,實現了 copyCellStyle()方法,保證寫文件完成后樣式不會改變, 例如頁邊距,對齊方式等。在二維碼檢驗單導出時,要將二維碼插入到合適的位置, POI提供了 XSSFDrawing組件提供圖像畫布功能,createPicture()方法通過參數控制 可以實現圖像來源選擇,圖像格式設置。XSSFClientAnchor組件可以控制圖像的位 置,分辨率等。另外,為了保證導出性能,在生成二維碼時,將二維碼的二位數組進 行暫存,而不是直接生成圖片文件,從而減少文件I/O,提高導出效率。
    Excel 導出流程圖如圖 4.13 所示。
     
     
    圖 4.13Excel 導出流程圖
     
    (3) Excel 文件比對
    Excel 比對功能將通過讀取 Excel 文件,將 Excel 內容暫存到數據集合當中,然后 比對兩個集合存在的數據,當數據出現不一致時,返回前臺,將出現問題的條目標紅 顯示。從而可以判斷數據異常出現在哪一方。
    通過上文的介紹與討論, Excel 處理功能實現了線上系統與線下文件的交互,并 且經過實際測試能夠達到最慢5秒內導入/導出1000條數據,滿足實際使用需求,優 化了用戶的工作。
    4.7待辦工作提醒功能
    4.7.1功能說明
    待辦工作提醒功能主要是為了增強系統辦公的協同性,做到業務處理的實時性。 通過對業務的分析不難發現,每一個模塊的每一條記錄都可以當作一個流程來看待, 當業務流程的發起者發布一個業務時即產生了一個流程,待最后一個職位的員工完成 任務時,這個流程也就隨之結束。因此,待辦工作提醒需要首先滿足各個模塊的業務 邏輯,同時支持待辦任務的查看與處理。另外,使用本系統的研究所內部的每一項任 務都有嚴格的時間節點,對于超期的工作需要提醒相關責任人進行處理。
    4.7.2功能設計與實現
    依據上文功能說明中提到的內容,具體實現如下:
    (1) 待辦工作提醒的業務邏輯
    針對每一個模塊的每一個工作環節,通過嚴謹、合理地分析以后,根據每一個職
    位的工作內容,指定待辦工作提醒的業務邏輯具體如表4.2所示。
    表 4.2 待完成工作提醒業務邏輯
    工作模塊 發起人 業務流程
    備料任務管理 總計劃 總計劃一調度員一質保員一庫管員一信管組
    任務缺料管理 調度員 調度員f采購員
    元器件訂購管理 總計劃 總計劃一合同管理員一采購員
    元器件檢驗管理 采購員/庫管員 采購員/庫管員一質保員一采購員/庫管員
    元器件入庫管理 庫管員 庫管員
     
    因為各個業務邏輯相似,故現以備料任務管理為例對下文的設計進行詳細描述。
    (2) 待辦工作提醒的實現
    在有了待辦提醒的業務流程之后,需要確定待辦提醒的具體實現。在待辦提醒中, 要實現待辦工作通知、查看待辦工作、處理待辦工作三個功能。具體如下:
    a) 待辦工作提醒邏輯處理
    通過分析物資部的日常工作,不難發現,工作以流的形式進行推進,逐級傳遞, 最終完成任務。對于每一個環節,均需要有明確的任務節點,倘若節點任務沒有完成, 是無法向下傳達的。因此,在實現上可以將整個流程根據任務節點的數目進行編碼, 每一個流程設置標志位,用二進制的 0和 1來表示工作是否完成。例如備料任務管理 模塊總共6 個環節,將整個流程用六位的字符串進行表示,默認情況下是“000000”, 某一個環節完成后標志為“1”,直至全部流程完成。
    b) 待辦工作通知
    待辦工作通知需要在上一個環節工作提交時立即通知下一個環節的用戶進行提 醒。通過均衡各種實現方式的利弊,選擇Ajax輪詢查詢的方式來實現待辦工作通知。 通過前臺設置定時器向后臺發送請求,請求內容包括登錄用戶的職位,查詢后臺數據 庫中對應職位的環節的編碼是否為“1”,如果不是,則將提醒信息傳遞至前臺,在界 面上給用戶提示。
    c)查看待辦工作 在查看待辦工作處,需設置合適的提醒信息,滿足用戶需求,但不可顯示內容過
    于冗雜。除了待辦工作實時通知外,用戶可查看全部待辦工作。以備料任務管理為例, 經過溝通交流后,待辦提醒包括任務編號、任務名稱、承制單位、產品名稱、任務狀 態、備料編號六個字段。
    d)處理待辦工作 處理待辦工作通過點擊跳轉實現,通過選中某一條記錄,點擊對應的提醒鏈接便
    可直接跳轉到對應的模塊進行編輯處理。這里使用 form 跳轉的方式實現,將待辦提 醒顯示的字段包含在跳轉地址中,從而通過關鍵字段定位到某一條工作記錄,進而用 戶對該記錄進行操作。本流程工作完成后,該條待辦提醒將從提醒列表中移除。在地 址跳轉過程中,將添加formType為區分各個模塊標志位,各個字段用&分割,為保證 中文不亂碼,傳遞信息需使用encodeURI進行轉義。
    依據上文描述,可以得出待辦任務提醒整體流程圖如圖 4.14所示。
     
     
    4.8本章小結
    本章通過Spring框架的相關技術實現了業務的基本操作,通過JAVA相關技術實 現了信息傳遞過程中涉及到的加密、解密,二維碼的生成以及Excel內容的讀入和寫 入,通過Ajax輪詢和form表單技術實現了系統的消息提醒,詳細設計與實現了系統 的功能。
    第五章 采購決策子系統詳細設計與實現
    前文通過信息管理子系統的構建,實現了研究所物資部現有工作流程的信息化, 將元器件備料、采購、檢驗、入庫等流程串聯,極大的提高了工作效率。本章將會在 信息管理子系統真實數據的基礎上,選擇合適的分類算法,按照數據挖掘的基本流程, 再結合數據倉庫技術,對采購決策子系統進行設計與實現。由于采購決策子系統數據 集來源于信息管理子系統的元器件采購、檢驗模塊,本章對于數據庫表將不再贅述, 將重點描述決策功能的實現過程。
    5.1 決策功能描述
    通過信息管理子系統的搭建,積累了可觀數目的元器件采購數據,為供應商評價 提供了數據基礎。依據數據挖掘過程,采購決策子系統需要經過數據集選取、數據預 處理、數據決策分析、結果分析總結等若干流程實現供應商的決策。采購決策子系統 流程圖如圖 5.1 所示。
     
     
    各個流程具體功能如下:
    (1)數據集選取
    采購決策系統的數據來源于電子元器件信息管理系統的元器件訂購管理、元器件 檢驗管理及元器件入庫管理。
    (2)數據預處理
    數據集內部的數據不一定是直接可以使用的,因此需要經過數據預處理將噪音數 據,缺失值甚至是錯誤數據去除。數據將由采購決策系統從信息管理系統數據庫中提 取、轉化、加載。
    (3) 數據決策分析
    此部分是采購決策系統的核心功能,本系統將通過供應商的供貨期限、元器件合 格率等情況對其生成一個“好”或“不好”的判斷,從而對供應商進行區別,分類, 使得物資部在以后的元器件采購過程中對供應商的選擇有據可循。實現此功能需要選 擇一個適合本系統的分類算法,算法選擇將會在本章第5.2節進行詳細討論。
    (4) 結果分析總結
    系統對供應商生成評價結果后,需要將評價結果進行直觀展示,供用戶確定該供 應商的最終評價信息。此外,在評價完成后,需要對決策結果進行正確性與準確性進 行判斷,從而對決策效果進行總結。
    5.2 算法選擇與描述
    5.2.1算法選擇
    在分析了采購決策系統的功能與流程后,可以得出采購決策系統主要功能是將元 器件供應商進行評判從而做出分類,核心功能是數據決策分析。在前文中提到,對供 應商進行判斷、決策本質是一個分類問題,因此需要找到合適的分類算法。下面將會 對各類分類算法進行總結比較,選擇出最合適的算法。常見的分類算法如下:
    (1)支持向量機(SVM)從本質上來說是一種二分類的方法[24],其決策邊界是 對學習樣本求解的最大邊距超平面。支持向量機對于核函數的確定至今沒有合適的方 法,并且需要大量的存儲空間。
    ( 2) 決策樹算法是一種分類算法,結果是一種樹狀結構,依據分類規則對決策 樹進行構建,每一條由根節點到葉節點的路徑均可作為一種分類規則,從而發現數據 內部蘊含的分類規則[24]。常用的算法有ID3[25]算法,C4.5算法[26], C5.O0]算法等。
    (3) 樸素貝葉斯算法的核心是計算樣本的先驗概率與后驗概率,并且認定后驗 概率的最大值對應的類即是該樣本被判定的類[28]。由于貝葉斯定理的假設條件在實 際應用中經常會出現偏差,因而其分類準確性就會下降[29]。
    (4) k 最近鄰算法[30] ,是一種機器學習算法, 既可以用于分類, 也可以用于回 歸[31]。該方法就是找出與未知樣本x距離最近的k個訓練樣本,看這k個樣本中多 數屬于哪一類,就把X歸為那一類[32]。
    (5) BP[33]神經網絡是能夠學習和儲存許多輸入-輸出模式映射關系,并且不需 要提早揭示描述此種映射關系的數學方程。 BP 神經網絡通過反向傳播來不斷調整網
    絡的權值、閾值,使網絡的誤差平方和達到最小[34]oBP神經網絡主要應用在函數逼近、 模式識別、函數壓縮等方面,突出的改進算法有FAGABPNN算法和IAPSOBPNN組 合訓練算法。
    通過前文需求分析過程可以發現采購決策系統數據維度較高,并且數據類型也相 對較多。考慮到算法的計算開銷、準確性和決策結果的可讀性,本文選用決策樹算法 對采購歷史數據進行決策,決策算法的原理將在下一小節進行敘述。
    5.2.2決策樹算法過程
    前文中我們對各種分類算法進行了比較,并依據實際情況選擇了決策樹算法進行 實現。決策樹是表示基于屬性對數據進行分類的樹形結構。依據特征選擇的方法,遞 歸的選擇最優劃分特征,將訓練數據進行分割,使得各子數據集有一個最好的分類的 過程[35]。它包括特征選擇、決策樹生成和決策樹剪枝三個流程。決策樹構建整體流程 如圖5.2所示。
     
    圖 5.2 決策樹構建流程圖
     
    決策樹的創建過程將會把訓練數據集分成兩部分,在這里將分別成為構建子集和 判斷子集。其中構建子集的數據將會被用來執行算法流程創建決策樹,判斷子集將會 對決策樹的正確性進行判斷。在判斷過程中,如果決策樹能夠對判斷子集的數據正確 分類,則完成決策樹創建流程;否則將會把該判斷數據加入到構建子集當中去,通過 新的數據集重建決策樹。上述過程將反復執行,直到構建的決策樹能夠正確對判斷子 集的數據進行分類。
    基于上述算法流程,J. Ross Quinlan最初提出了 ID3算法,該算法采用信息增益 大的特征優先建立決策樹節點[36],但是這種方法的缺點也很明顯,當條件相同時,屬 性值越多的特征越容易被選為特征,但是屬性的具體值是無法確定的,而且ID3算法 也無法支持連續變量。
     
    基于ID3算法的以上缺點,算法提出者對ID3進行了改進,提出了 C4.5算法。 該算法引入了信息增益比的概念。在進行屬性選擇時,在候選特征中找出信息增益高 于平均水平的特征,然后在這些特征中再選擇信息增益率最高的特征[37],通過這種方 法能夠使樹的層次和節點數最小。在連續變量的處理上,C4.5的思路是將連續的特征 排序后離散化,從而使決策樹支持對連續變量的決策。本文的決策算法將采用 C4.5 算法,避免特征選擇受樣本屬性值的影響。
    5.2.3特征選擇原理
    決策樹算法的關鍵就在于特征選擇,也就是分類規則。C4.5算法使用信息增益率 進行特征選擇,在數學上是基于信息論的方法,它克服了 ID3 算法用信息增益選擇屬 性時偏向于選擇取值多的屬性的不足[38],其計算原理如下:
    設T為數據集,類別集合為{Ci,C2 Ck},選擇一個屬性V把T分為多個子
    集。設V有互不重合的"個取值{Vi,V2 吟},則T被分為"個子集Ti,T2 G,
    這里E中的所有實例的取值均為可。
    令|T|為數據集T的例子數,|7)|為“=巧的例子數,|Ci|為G類的例子數,|Ci“|是 v=巧例子中具有G類別的例子數。
    則有如下:
    (1) 類別G發生的概率:pG) = |G|/|T|
    (2) 屬性u =巧發生的概率:p(vj) = 7)/|T|
    (3) 屬性u =巧的例子中覺有類別G的條件概率p(Ci|Vj) = |馳|/|7)|[39]
    類別Q的信息熵計算方法如公式5-1所示。
     
     
    按照屬性V把集合T分割,在Q類別中屬性V的條件信息熵如公式5-2所示。
    Entropy (C[V)=— p(Vj)^p(Ci|Vj)log2P(Ci|Vj))
    j i
    =-》罟》需也得
    丿 I
    n
    =infoCTi)
    1=1
    屬性V的信息增益(Gain丿如公式5-3所示。
    Gain(C,V) = Entropy(C) — Entropy(C|V)
     
     
    上面給出的就是信息增益率的推導過程,將信息增益率最大的屬性構建為樹節點, 保證特征選擇過程不受特征屬性的數據量的影響。
    5.3 決策功能實現
    本節將依據上文的功能描述、處理流程及算法原理實現采購決策系統,其中數據 集獲取和數據預處理功能通過etl[4°]與數據倉庫相結合進行實現,數據決策分析通 過使用 C4.5 算法對采購歷史數據進行訓練與剪枝,產生決策模型后,再通過真實數 據去檢驗該模型,分析決策結果與真實情況后,確定該決策模型的正確性與準確性。
    5.3.1數據集獲取
    為了保證電子元器件信息管理系統的正常運行不受影響,本文在進行系統架構設 計時為采購決策系統分配了單獨的服務器。決策數據集來源于物資部日常的采購數據。 數據集加載到采購決策系統數據庫的過程本文采用ETL技術實現。ETL是用來描述 將數據從來源端經過提取(Extract)、轉置(Transform)、加載(Load)至目的端的過 程[41]。在本文中,數據來源端是電子元器件信息管理系統數據庫,具體為元器件訂購 管理和元器件檢驗管理兩個模塊當中相關信息。目的端是采購決策系統數據倉庫。整 個ETL過程使用微軟提供的Microsoft SQL Server integration Servers幫助實現,工作 方式將采用SQL Server作業的形式。ETL將數據集選取與數據預處理同步進行,因 此數據集選取相關實現將在下文中將詳細介紹。
    5.3.2數據預處理
    數據集中的數據是無法直接使用的,需要進行數據預處理,以去除噪音數據,修 補缺失值等。ETL實現數據集選取與數據預處理具體流程如下。
    ( 1 ) 數據抽取
    數據抽取是從數據來源端中抽取數據的過程,針對實際情況,使用以下兩種抽取 策略:
    (1)在決策系統建設的初期,需要使用全量抽取將全部數據保存到數據倉庫中。 全量抽取,將數據源中表或視圖的數據原封不動的從數據庫中抽取出來,整體遷移到 目的數據庫中,在轉換過程中實現數據格式轉換;
    (2)在采購決策系統應用上線后,使用增量抽取定時更新。增量抽取只抽取自 上次抽取以來數據庫中要抽取的表中新增或修改的數據。為了保證數據的準確性并且 不會對信息管理系統的性能造成影響,抽取時間間隔為每月一次。
    數據抽取流程圖如圖5.3所示
     
     
    在本文中,信息管理系統和決策系統數據庫均為SQL Server,因此可以直接使用 數據庫鏈接的方式,實現采購決策系統數據庫與信息管理數據庫的鏈接,保證抽取作 業的完成。抽取方式按照數據的實時性可分為實時抽取和批量抽取。決策系統對于數 據的實時性要求并不高,因此為了減少源數據庫壓力并且減少對信息管理系統的干預, 選擇批量抽取的策略,具體抽取方法采用日志抽取的方式,雖然需要信息管理系統按 照業務生成日志,但卻可以最低程度的減少信息管理系統服務器的壓力。
    (2) 數據轉換
    經過數據抽取獲得的數據一般不能直接使用[42],可能存在數據格式的不一致、數 據輸入錯誤、數據不完整等[43][44]問題,因此需要對數據進行進一步加工。數據轉換的 過程有多種選擇,例如使用 ETL 引擎進行轉換建工、在數據庫中進行加工、使用編 程語言進行處理等等。為了簡化開發,清楚邏輯,在這里使用SQL語句的編寫實現 數據的過濾、映射等等。
    在轉換過程中需要注意的是,決策過程需要的數據是已經檢驗完成的元器件訂購 信息,在編寫SQL語句時需篩選合格數、不合格數不為空的條目。
    以目前的需求來看,在元器件訂購管理中需要關注的信息是供應商信息、訂單信 息及到貨信息。供貨單位信息主要在于供貨單位名稱、貨源來源(國內/國外)等;訂 單信息主要關注元器件單價、訂購數量、訂購型號、訂購時間、發貨時間、協議價、 采購價等信息;到貨信息主要關注到貨時間、到貨數量、到貨型號等信息;當訂購信 息和到貨信息存在出入時,在轉換的過程中需要先對某些屬性進行計算,例如約定到 貨時間和實際到貨時間如果不相同,將計算推遲或提前時間,使得到貨時間情況也作 為一個屬性對供應商進行分類。對于其他信息,可以采取同樣的方法進行處理。對于 元器件檢驗管理需要關注的屬性為元器件合格數、不合格數,計算出元器件合格率后, 對某一批次的元器件進行評估,從而實現對供應商從元器件質量的角度進行評估。
    (3) 數據加載
    當完成了數據抽取與數據轉換這兩項工作后,最后需要將數據加載到目的數據庫 庫中。在本系統中,ETL作業位于數據倉庫的服務器上,加載作業只需要使用INSERT 的方式將數據導入到對應的數據表即可。
    表 5.1 元器件供應商評價特征屬性
    評價標準 評價指標
    元器件質量 合格、不合格
    元器件貨期 按時、延期
    訂貨/到貨型號出入 低等級、正常等級
    協議價/采購價 提價、不提價
     
    綜合以上流程,我們可以得出電子元器件供貨商的評測指標,分別為元器件質量
    合格率、元器件貨期、訂貨/到貨型號出入、協議價/采購價,其中后三個指標根據物
    資部員工提供計算規則后得出,保證數據可讀性,可以得出元器件供應商的特征屬性 集合及評價標準如表5.1所示。本文中僅以“好”(Good)與“不好” (Bad)對進行 供應商評價。在構造決策樹的過程中,隨機選取240個經過處理后的不同供應商的歷 史采購數據進行決策樹的構建,其中可評估為“Good”的供應商為214個,可評估為
    “Bad”的供應商為26個,數據真實且完整,可用于決策樹的構建。
    5.3.3數據決策分析 在構建決策樹前,需要進行初始化工作,初始化工作包括初始化屬性集合、數據 集合以及決策樹的根節點 Root。
    在特征屬性中存在漢字的等級,需要對其進行數字化處理,處理方法見表5.2。 以對于元器件質量為例,根據檢驗結果進行計算,將合格元器件記為“0”,不合格記 為“1”。
    表 5.2 特征屬性值處理方法
    特征屬性 屬性值 計算值 屬性值 計算值
    元器件質量 合格 0 不合格 1
    訂購型號/到貨型號 正常等級 0 低等級 1
    協議價/采購價 不提價 0 提價 1
    訂貨貨期 按時 0 延期 1
     
    在初始化工作完成以后,就可以通過讀取訓練數據集對決策樹進行構建,構建過 程中特征選取的過程依據其數學原理與實際數據中各個屬性的個數進行代入計算即 可,決策樹構建流程圖如圖5.4所示。
    在決策樹的創建時,許多分枝反映的是訓練數據中的異常[45]。通過決策樹剪枝可 以去除這些異常,從而將決策樹修正或去掉無用的分枝。通剪枝一般分兩種方法:預 剪枝和后剪枝。
    預剪枝是在決策樹的生成過程中,事先評估每個結點的劃分,若當前結點的劃分 不能帶來決策樹泛化性能的提升[46],就停止劃分并將當前節點記為葉節點。比較常用 的方法有:
    (1) 每一個結點所包含的最小樣本數目,例如將最小樣本數目設置為10,則 該結點總樣本數小于10時,則不再分;
    (2) 指定樹的高度或者深度,例如樹的最大深度為4;
    (3) 指定結點的熵小于某個值,不再劃分。
    后剪枝在決策樹構造完成后,自底向上對非葉節點進行判斷,如將該非葉節點及 其子樹替換為葉節點,能夠帶來決策樹泛化性能的提升[47],則將該子樹替換為葉節點。
    圖 5.4 讀取樣本數據生成決策樹流程圖
    圖 5.5 決策樹剪枝流程圖
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    本系統采用通過預剪枝的設定樣本最小數目的方法來進行剪枝,當此節點的實例 個數小于某個閾值的時候就停止決策樹的構建,剪枝之后該節點將會有一個類分布的 描述,即該葉節點屬于某類的概率。決策樹剪枝過程如圖 5.5 所示。
    本節將決策樹的生成和剪枝過程進行了描述,對于決策樹的訓練結果和正確性測 試,將在下一節結果分析總結中進行描述。
    5.3.4結果分析總結
    上文中根據決策樹訓練、剪枝原理,將全部240 個訓練數據用于生成決策樹,并 最終生成了一個決策樹,如圖5.6所示,可以看出決策樹中包含了樣本中 4個特征屬 性,根節點為元器件質量。同時,不難發現決策樹的一大優點就是決策結果非常直觀, 可以根據由樹的根到葉子節點的路徑對決策模型進行選取,選取過程遵循“IF…ELSE” 原理。這 240 個訓練數據,其評價結果已知,均為物資部員工根據研究所內部科學的 評價標準進行計算得出,通過抽取40條記錄進行測試,根據測試數據結果與真實的 評價結果進行比對,即可得出此決策樹訓練模型的正確性。
    通過比對測試數據結果與真實情況,可以得出在40個測試數據樣本中,有35個 評價結果正確,可計算出此決策模型的正確率為87.5%,由此可見此決策模型可應用 在后期的供應商評價當中,從而指導采購過程。
     
    圖 5.6 決策樹訓練結果
    5.4本章小結
    本章主要對元器件采購決策系統從各個角度進行了詳細的介紹。首先通過比較數 據挖掘中各種分類算法,選擇了更適合系統實際情況的 C4.5 決策樹算法。然后結合 ETL及數據倉庫,完成了數據集選取及繁雜的數據預處理工作。最終通過C4.5算法 構建決策樹,對歷史采購數據進行分析,對供應商在質量、價格、貨期、型號上進行 分類,得出決策樹算法的決策結果具備正確性和實用性,可以對采購進行指導。
    第六章 系統部署與測試
    軟件測試對于軟件開發尤其重要,其存在于系統開發的整個過程,尤其是在軟件 系統開發完成以后,需要對軟件需求中的功能模塊進行系統全面的檢查,是軟件在正 式上線運行前對軟件的質量和性能進行檢驗的重要環節[48]。本章的主要介紹信息管 理子系統的部署及測試過程,采購決策子系統的測試過程在第五章第5.3.4 節中已經 有詳細說明,此處不再贅述。
    6.1 部署與測試環境
    系統測試分為模擬環境測試與真實環境測試。模擬環境測試為開發者在系統部署 上線前,仿照研究所實際的工作條件對系統進行測試,以檢查系統的功能及兼容性, 盡量減少實際測試過程中可能出現的問題。在模擬測試完成通過后,方可將系統部署 至研究所服務器內網環境。系統的測試環境主要分為客戶端、服務器和硬件設備三部 分,具體的測試環境參數如表 6.1 所示。
    表 6.1 系統測試環境及參數
    環境 配置
    客戶端 瀏覽器 Chrome/搜狗瀏覽器 /FireFox/IE
    操作系統 Windows7/WindowsXP/Windows10
    服務器 Web服務器 Nginx 1.16
    應用服務器 Tomcat 8.0.53
    緩存服務器 Redis 5.0.5
    操作系統 CentOS、
    Windows Server 2008 R2 或以上
    數據庫 SQL Server 2014 Enterprise
    硬件設備 二維碼掃描槍 Symbol DS3508-SR
     
    6.2 系統功能測試
    系統功能測試依據對系統功能模塊進行,測試數據將采用合法數據和非法數據, 從而測試系統在正常流程處理和異常處理所表現的性能。除了在模擬測試環境進行測 試外,在與研究所進行協商,協調好工作時間后,本人將信息管理子系統部署到該研
    究所的內網服務器上,用系統使用的用戶使用真實數據進行實際生產環境測試。電子 元器件信息管理系統測試過程共計三個月,經過不斷調試、修正系統功能,目前系統 的功能能夠滿足研究所對元器件管理工作信息化的要求,各個功能具備實用性、易用 性及魯棒性。
    6.3 系統性能測試
    系統的性能測試又稱為非功能性測試,是對軟件系統在性能表現方面進行測試[49]。 本系統通過使用 LoadRunner 工具,對不同級別的用戶請求量的系統事務處理及服務 器性能參數進行記錄,實現系統性能測試。另外對于 Excel 導入導出功能,針對不同 條目的導入導出時間分別進行測試。測試記錄結果如表6.3所示。
    表 6.2 電子元器件信息管理系統測試記錄
    性能需求項 理想值 低并發
    實際值
    (日常使用) 高并發
    實際值
    (100用戶)
    用戶登錄 < 2s 1.23s 1.74s
    頁面點擊及跳轉 1.235s 1.623s
    系統事務處理 < 3s 1.034s 1.669s
    CPU使用率 <75% 35.65% 51.79%
    內存使用率 <70% 34.75% 50.26%
    Excel導入 1000 條<5s 2.561s 4.213s
    Excel導出 1000 條<5s 1.739s 3.417s
     
    通過對系統不同用戶量請求的測試,結果顯示系統具備一定的穩定性及抗壓性, 能夠滿足研究所的實際使用。
    綜上,元器件信息管理系統無論在功能上還是性能上均滿足研究所的實際工作需 求。系統現已正式上線運行一年時間,目前運行穩定,各項功能均正常運行。
    6.4 系統運行截圖
    普通用戶登錄跳轉到系統的主頁,主頁上包含各項業務模塊,其中前三個模塊為 本文中提到的業務管理模塊,消息傳遞功能集成至元器件檢驗管理和元器件入庫管理
    當中,元器件檢驗管理可分為包括元器件送檢和元器件復檢,每個模塊均支持 Excel 處理、消息提醒。電子元器件信息管理系統主頁如圖 6.1 所示。
    各個業務邏輯模塊支持用戶新增、查找、編輯、刪除,頁面布局相似,此處以元 器件訂購管理進行描述。用戶業務處理界面如圖 6.2 所示,在第四章第 4.2 節曾經提 到界面和功能盡量貼近Excel,在圖中可以看出,在用戶可根據實際情況點擊需要編 輯的條目的數據,在編輯完成后點擊左側保存即可,具備一定的可用性。
     
    為提高用戶使用體驗,用戶編輯及查看界面均支持自定義顯示,下面將通過業務 查看界面進行描述,業務查看界面如圖 6.3 所示,查詢界面可實現用戶查詢或導出數 據等功能。頁面頂部為查詢條件,用戶可根據條件組合查詢。在界面的右側,有自定 義隱藏列的按鈕,用戶可根據實際情況查看或隱藏相應信息。
     
    本文第四章第4.6節提到系統支持用戶將數據導出到Excel中,查詢界面的右側 放置了自定義打印和用戶導出按鈕,用戶點擊自定義打印按鈕后可選擇待打印的列, 點擊確定提交即可,如圖6.4所示。
    選擇打印列
    Q申購物料底呂 Q物料代碼 0產品分類 Q采購計劃編呂
    0物料名稱 ©產品型號/盤號 0型號規格 0質星臬級
    0采用標準 □封裝形式 0生聲廠家 0申購數星
    Q利庫數雖 口備份 Q計星單位 口用戶
    ©采購數星 Q申購輪號/申購數星 0任務編號 ©住務名稱
    ©備注 0采購員 Q年度采購計劃編號/計劃編 制日期 Q協議價
    0采購價 0預算金飯 0標書底號 0標書編號
    ©開標時問 Q計劃要求到貨時問 0要求妣次 Q訂購時問
    Q訂購數量 ©供貨單位 0訂購周期(周) Q約走到貨時問
     
     
    對于元器件檢驗環節需要的信息傳遞功能,一條檢驗單經過發起、審核后,用戶 點擊導出檢驗單即可,圖 6.5 展示的是一條檢驗記錄形成的二維碼,二維碼對應的明 文為表 6.4 所示的送檢單信息,其中任務名稱為保持保密需求,做了匿名處理。
    表 6.3 樣例檢驗單明文信息
    送檢
    編號 任務編號 任 務 名 稱 篩 選 條 件 物 料 名 稱
    規 格 生 產 廠 家 送檢
    數量 D P A 數 量 檢驗
    數量
    等 級 使 用 單 位
    SJ-
    20180
    604 CZ3671021
    301
    A
    GJ
    B-
    101
    A-
    199
    8 188
    100 3 97 1
    8
    0
    6 CA
    ST-
    C
     
     
     
    圖 6.5 樣例送檢單加密二維碼
     
    6.5本章小結
    本章完成了電子元器件信息管理系統的部署與測試工作。測試過程經歷了三個月 的時間,測試結果顯示系統各個功能健全,符合用戶需求與用戶使用習慣,并且能夠 在業務爆發的場景下繼續運行。目前系統已運行一年時間,各項功能均保持穩定,能 夠滿足需求分析中物資部的各項需求。
    第七章 總結與展望
    7.1 總結
    本文從研究所實際工作背景出發,為了滿足研究所元器件信息處理工作信息化的 需求,在詳細分析設計后實現了電子元器件信息管理子系統。信息管理子系統的建設 主要解決了以下問題:
    (1) 系統通過在線處理信息的方式,解決了人工維護信息 Excel 表格的弊端, 提高了員工的工作效率,滿足研究所信息化建設需求;
    (2) 系統通過待辦工作提醒的方式,將原本相互分離的各個工作流程串聯起來, 優化了工作處理流程;
    (3) 通過加密二維碼的形式,實現了異網部門之間的高效、安全信息交互,提 高了部門之間的工作效率;
    (4) 系統通過權限分配及日志記錄的形式,對系統的用戶進行嚴格的操作、訪 問控制,從而滿足研究所保密要求,如出現問題可將責任定位到個人。
    本文從元器件采購遇到的實際問題出發,將數據挖掘技術應用到元器件供應商決 策上去,在分析、學習后實現了采購決策子系統。采購決策子系統的建設主要解決了 以下問題:
    (1) 以采購及檢驗歷史數據為數據源,通過數據挖掘方法,從元器件質量、價 格、型號等校對實現了對供應商評估,從而對元器件采購流程提供指導;
    (2) 充分利用研究所采購的歷史數據,在最大程度上對資源進行整合利用。
    7.2 展望
    對于電子元器件信息管理子系統,使用J2EE及SSH相關技術對系統進行搭建與 開發,現階段雖能滿足研究所的工作需求,但是在未來工作中可有如下優化:
    (1) 待完成工作提醒功能的實現上采用的是Ajax輪詢查找的方式,這種方式 雖實現簡單,但是會存在大量的無用請求,目前在產業上對于消息隊列已經有廣泛的 應用,因此可以將提醒設計成消息的形式,放到消息隊列中進行處理,從而更符合流 式處理工作的方式;
    (2) 信息傳遞過程中的二維碼檢驗單的設計仍然沒有將頁面最大化利用,導致 一張A4紙僅能夠容納2條附帶二維碼的檢驗單記錄,后期需要將檢驗單格式優化, 設計出更加節約資源的檢驗單格式。
    對于采購決策子系統,采用數據倉庫及決策樹算法,通過實際數據測試已能夠對 供應商進行決策,但在未來的工作中仍可有如下優化:
    (1) 本系統使用 C4.5 決策樹算法,雖然相較于 ID3 算法已進行優化,但是在 計算效率上仍有一定的短板,在未來系統建設中可采用更好的決策算法,從而提高計 算性能;
    (2) 對于決策過程的屬性選擇,目前僅僅從直觀的角度進行決策,例如元器件 的質量角度僅以“合格”、“不合格”進行決策分析,在后續的工作中,可以按照合格 率對元器件質量進行更多等級的劃分,從而對供應商有更細化的決策。
    (3) 本系統雖實現了對供應商的決策,但是系統可視化做的并不是很好,在后 期可分配一些精力將參數為用戶展示更加直觀,從而對決策結果進行讀取時更易于接 收。
    參考文獻
    [1]張柳.電子元器件制造企業產品信息管理系統的設計與實現[D].四川:電子科技大學,2013.
    [2]甘璐.基于數據挖掘技術的檔案館信息快速分析算法研究[J].現代電子技術,2019(04):32- 34.
    [3]杜芳芳.基于數據挖掘的采購決策系統設計[J].中國商貿,2012(02):90-91.
    [4]任忍.儲油罐參數管理分析系統設計與實現[D].陜西:西安電子科技大學,2017.
    [5]王映輝.軟件功能需求變化傳播機理分析[J].計算機學報,2007(11):2025-2032.
    [6]趙亞男.電子元器件信息管理與篩選傳遞系統設計與實現[D].陜西:西安電子科技大學, 2018.
    [7]熊偉,渡邊喜道.軟件需求定量分析及其映射的模糊層次分析法J].軟件學報, 2005(03):427-433.
    [8]冀博.任城區供電公司配電自動化研究[D].山東:山東大學,2008.
    [9]戴玉青.中意財險銷售人員業績管理系統設計與實現[D].山東:山東大學,2015.
    [10]高雪宇.基于Java EE的綜合考務管理系統設計與開發[D],陜西:西安電子科技大學,2017.
    [11]Mingfang C . Design and Implementation of ERP System Based on J2EE Trading Company[C]. International Conference on Measuring Technology & Mechatronics Automation. IEEE, 2017.
    [12]Yan L . Construction and Testing of Modern Distance Learning Platform System Based on Struts and Hibernate Framework[C]. International Conference on Intelligent Transportation. IEEE Computer Society, 2018.
    [13]王進.B/S模式下的三層架構模式[J].軟件導刊,2011, 10(03): 30-31.
    [14]葉加青.Spring框架技術的應用[J].計算機時代,2009(10):54-55.
    [15]Liang X , Xue B , Huang M , et al. Application of join points management mechanism in spring in AOP[C]. International Conference on Computer Science & Network Technology. IEEE, 2014.
    [16]Qiang D , Zi-Bin D , Wei L I . Highly Efficient Fault Detection Schemes for AES S-Box Based on Redundant GF Arithmetic[J]. Acta Electronica Sinica, 2018.
    [17]王青.基于Java-Web的員工績效考核系統的設計與實現[D].吉林:吉林大學,2017.
    [18]張運策.H省醫院協會協同OA辦公系統的設計與實現[D].四川:電子科技大學,2011.
    [19]余春亞.基于WEB高校考務管理系統淺談[J].電腦迷,2018(04): 197-199.
    [20]馮慧.準能公司人力資源管理信息系統的設計與實現[D].遼寧:大連理工大學,2015.
    [21]李瓊.基于Spring Security的企業級應用安全架構的研究與實現[D].北京:北京交通大學, 2012.
    [22]劉鶯迎,付正欣,王益偉.基于視覺密碼和QR碼的兩級信息管理方案J].計算機應用研究, 2016(01): 3460-3463.
    [23]陳畫.Web技術在豐滿發電廠檔案管理系統中的應用[J].電腦知識與技術(學術交流), 2007 (05): 741-742+797.
    [24]胡仙,胡潔,田畔等.基于精細復合多尺度熵與支持向量機的睡眠分期[J].上海交通大學 學報, 2019(03):321-326.
    [25]Yu H , Lu J , Zhang G . Learning a fuzzy decision tree from uncertain data[C]. International Conference on Intelligent Systems & Knowledge Engineering. IEEE, 2018.
    [26]張樹滑.基于ID3算法的大學生成績數據挖掘與體能分析系統設計J].現代電子技術, 2018(05): 104-106+110.
    [27]Ahmadi E , Weckman G R , Masel D T . Decision making model to predict presence of coronary artery disease using neural network and C5.0 decision tree[J]. Journal of Ambient Intelligence and Humanized Computing, 2017.
    [28]李瓊陽.一種改進的樸素貝葉斯算法在垃圾短信用戶識別中的應用[D].廣州:華南理工大 學, 2017.
    [29]舒夢.基于基因表達譜數據的腫瘤分類算法研[D].湖南:湖南大學,2016.
    [30]Zhang, Shichao, Li, et al. Efficient kNN Classification With Different Numbers of Nearest Neighbors[J]. IEEE TRANSACTIONS ON NEURAL NETWORKS AND LEARNING SYSTEMS, 2018, 5(29).
    [31]楊延新.基于KNN算法的公路施工風險判別[J].資源信息與工程,2010(02):137-138.
    [32]闞立峰.工具線形痕跡單點激光檢測特征自適應匹配技術研究[D].云南:昆明理工大 學,2018.
    [33]He F, Zhang L. Prediction model of end-point phosphorus content in BOF steelmaking process based on PCA and BP neural network[J]. Journal of Process Control, 2018, 66:51-58.
    [34]石丹.基于BP神經網絡的高校學費定價模型的建立[D].陜西:西安科技大學,2013.
    [35]莫贊,蓋彥蓉,樊冠龍.基于GAN-AdaBoost-DT不平衡分類算法的信用卡欺詐分類J].計 算機應用, 2018(10): 618-622.
    [36]唐智超.基于廣義信息熵的維吾爾文文本分類器的設計與實現[D].吉林:吉林大學,2017.
    [37]杜宇昆.基于鏈接特征的視頻廣告過濾技術[D].四川:電子科技大學,2018.
    [38]焦瑞,李祥生.基于決策樹的醫學碩士生存質量的優化[J].電腦開發與應用,2011(04): 4-6.
    [39]王曉東.數據挖掘在ERP集團解決方案中的研究與應用[D].北京:華北電力大學(北京), 2006.
    [40]Wojciechowski A . ETL workflow reparation by means of case-based reasoning[J]. Information Systems Frontiers, 2018, 20(1):21-43.
    [41]董福剛.國家電網業務流程監控平臺的設計與實現[D].北京:北京交通大學,2017.
    [42]楊國林,王飛,賀慧.基于數據挖掘的圖書館數據預處理方法研究J].煤炭技術, 2010(07):192-194.
    [43]郭偉斌.商業銀行OCRM系統數據處理與傳輸平臺的研究與應用[D].福建:廈門大學,2009.
    [44]楊冬菊,徐晨陽.大數據環境下基于元模型控制的數據質量保障技術研究J].計算機工程 與科學, 2019(02):197-206.
    [45]謝遠濤, 楊娟, 王穩. Logistic 與分類樹模型變量篩選的比較——基于信用卡郵寄業務響應 率分析[J].統計與信息論壇,2011(06): 96-101.
    [46]王若晨.隨機森林在制造業上市公司信用風險評價中的應用[D].廣東:暨南大學,2017.
    [47]蔣荻.基于機器學習的新型數據讀出方法研究[D].中國科學技術大學,2017.
    [48]郭文梁.軟件測試方法概述[J].科技與企業,2012(16): 125-125.
    [49]蔡立志,楊根興.軟件系統性能測試方法初探[J].信息技術與標準化,2005 (7): 44-50.
    【本文地址:http://www.bzhlmm.com//guanlilei/gongshangguanli/xixinguanli/8887.html

    上一篇:高校思想政治教育信息管理體系建設研究

    下一篇:沒有了

    相關標簽: