一種基於熵的構件可信度量方法
2023-10-04 08:34:54 1
專利名稱：一種基於熵的構件可信度量方法
技術領域：
本發明涉及可信度量領域，特別是涉及一種基於熵的構件可信度量方法。
背景技術：
軟體可信性概念，或者說「可信」這一概念，來源於可信計算，而隨著「可信」需求從硬體到軟體的擴展，業界對「可信」的理解也在不斷延伸。TCG認為「如果系統的行為與結果總是預期和可控的，那麼系統是可信的」，容錯專家提出並倡導的強調可靠性、可用性的可信計算D印endable computing是指計算機提供的服務是可以論證其是可以信賴的，而且這種可信賴是可論證的；國內武漢大學張煥國等人提出可信就是可靠、可用和安全。構件技術是重要的軟體復用手段，旨在提高軟體生產效率和質量。但是構件的共享和復用建立在構件使用者信任構件能實現預期功能的基礎上，由於構件本身層次多樣 (有通用基本構件、領域共性構件、應用專用構件等)，涉及業務種類繁多，構件本身的可信性度量至今在業界沒有成熟的方法和技術。但是這不代表在某一具體領域我們不能尋求到構件的可信性度量方法。由此看出，可信性並沒有一個公認的通用的定義，我們認為可信軟體是具有領域需求的可信屬性的軟體。對於構件來說，因為更具備領域特性，因此構件的可信性除了一些通用的可信屬性，如可用性(Availability)，可靠性(Reliability)，安全性(Security), 實時性(Real Time)，可維護性(Maintainability)和可生存性(Survivability)外，還應擴展一些領域相關的屬性。因此，目前需要本領域技術人員迫切解決的一個技術問題就是如何能夠創新地提出一種有效的構件可信度量方法，用以度量構件的可信性，提高軟體生產效率和質量。
發明內容
本發明所要解決的技術問題是提供一種有效的構件可信度量方法，用以度量構件的可信性，提高軟體生產效率和質量；通過創建構件可信性度量框架，對構件的可信屬性進行分析與度量，從而獲得量化的構件可信性度量結果。為了解決上述問題，本發明公開了一種基於熵的構件可信度量方法，所述方法包括分解出構件的主要功能點；記錄每個功能點在需求階段、設計階段、編碼階段、測試階段的可信證據；根據記錄的可信證據計算功能點中每個階段的可信評估值Pi ；計算各個功能點的熵；計算構件的熵，判斷構件可信性。優選的，所述構件的可信性作為構件投入使用的標準，構件不可信，重新修改構件開發過程，度量可信性。優選的，所述需求階段的可信證據包括過程能力資質、計劃工作量、實際工作量、計劃進度、實際進度、需求人員能力、需求變更數、需求評審結論、評審缺陷密度、缺陷清除效率。優選的，所述設計階段的可信證據包括計劃工作量、實際工作量、計劃進度、實際進度、設計人員能力、需求變更數、設計評審結論、評審缺陷密度、缺陷清除率。優選的，所述編碼階段的可信證據包括計劃工作量、實際工作量、計劃進度、實際進度、編碼人員能力、需求變更數、單元測試強度、代碼規模、代碼可維護性。優選的，所述測試階段的可信證據包括計劃工作量、實際工作量、計劃進度、實際進度、測試人員能力、測試工具支持、測試缺陷趨勢。優選的，所述可信評估值Pi為該階段偏離上一步製品的意圖的程度。優選的，根據構件可信性度量方法畫出可信性樹。優選的，所述構件的熵與可信性為負相關的關係，構件的熵越大，可信性越低。優選的，所述構件的熵為各個功能點的熵的平均值。與現有技術相比，本發明具有以下優點本發明中，可信性的度量側重於過程證據。因為構件可信質量內建於開發過程，測試只能事後檢驗且帶有片面性。假設一個軟體的過程證據得分很低，但是測試結果很好，根據二者在可信度量時的權重差異，總體可信性仍然會很低。所以通過過程證據，量化可信性指標，用信息熵作為可信性度量標準是非常恰當的。
圖1是本發明一種基於熵的構件可信度量方法的可信度量流程圖。圖2是本發明一種基於熵的構件可信度量方法的可信度量框架。圖3是本發明一種基於熵的構件可信度量方法的可信樹。
具體實施例方式為使本發明的上述目的、特徵和優點能夠更加明顯易懂，下面結合附圖和具體實施方式
對本發明作進一步詳細的說明。參照圖1，示出了本發明的一種基於熵的構件可信度量方法的可信度量步驟，所述方法具體包括步驟SlOl，建立可信性度量框架；優選的，所述方法還包括通過過程證據度量可信性。更為優選的，通過測量偏離上一步製品的意圖的程度度量各階段的可信性。參照圖2，示出了本發明的一種基於熵的構件可信度量方法的可信度量框架圖。在實際應用中，構件開發過程中需要記錄的可信證據包括過程證據和測試證據。 前者是開發過程中記錄下的證據，後者是在測試環境中記錄下的證據。只有二者都達到可信要求，才能確保構件的可信從而可以提交入庫投入使用。在整個過程中，有四個重要環節需要提供可信證據需求階段過程能力資質、計劃工作量、實際工作量、計劃進度、實際進度、需求人員能力、需求變更數、需求評審結論、評審缺陷密度、缺陷清除效率。設計階段計劃工作量、實際工作量、計劃進度、實際進度、設計人員能力、需求變更數、設計評審結論、評審缺陷密度、缺陷清除率。編碼階段計劃工作量、實際工作量、計劃進度、實際進度、編碼人員能力、需求變更數、單元測試強度、代碼規模、代碼可維護性。測試階段計劃工作量、實際工作量、計劃進度、實際進度、測試人員能力、測試工具支持、測試缺陷趨勢。在應用中，我們使用「debug管理」軟體進行過程證據的記錄，使用構件測試工具進行測試證據的記錄，證據的記錄嚴格遵守可信證據框架的模板。構件可信評估人員如何根據上述證據來量化各個階段的可信性呢？因為軟體開發是一個逐步演化的過程，每一步都力圖實現上一步的意圖但不可避免有所偏差，我們要用概率表示出每一步有多大程度的偏差。如需求分析階段，需求分析人員與構件的客戶是否進行了有效的溝通，消除了歧義，本階段的需求分析說明書多大程度地反映了客戶的意圖；設計階段系統分析人員是否完全領會了需求分析說明書，設計方案能否實現前者的功能；編碼階段程式設計師是否理解設計方案並有能力去實現該方案等。構件開發過程中每一步軟體製品只能反映上一步製品的意圖，我們也只能測量它偏離上一步製品的意圖的程度。 因為構件可信質量內建於開發過程，測試只能事後檢驗且帶有片面性。所以度量可信性時我們側重過程證據。假設一個軟體的過程證據得分很低，但是測試結果很好，根據二者在可信度量時的權重差異，總體可信性仍然會很低。步驟S102，確定可信性量化指標；一個系統由多種要素組成，每個要素都有一定的不確定性，所以系統整體的不確定性就是各要素不確定性的加權平均。優選的，用信息熵作為可信性度量標準。信息熵概念來源於申農的資訊理論，表徵系統整體的混亂程度或不確定度。公式表示為Entropy =Σ pi log pi (1)它的值代表系統不確定性的平均信息量。通過深入研究信任的本質，我們發現用信息熵作為可信性度量標準是非常恰當的。根據可信的定義，如果系統的行為與結果總是預期和可控的，那麼系統是可信的。 因此信任度就是客體的運行結果和主體的期望的吻合程度。因為構件乃至整個計算機系統相當於一個函數，確定的輸入必定有確定的輸出，所以按運行結果的期望的吻合程度，可以轉化為對運行系統的了解程度。例如我完全信任你，實質代表我對你情況完全了解。我對你還有多大程度的不了解，決定我對你有多大程度的不信任。反之，主體對客體越了解，對其不確定性消除越多，就越信任客體。客體的運行結果和主體的期望就會越吻合。如若能用程序證明理論分析軟體程序的源碼，並證明它是正確的，則可信性為1，即對該軟體完全了解自然也就完全信任；若一個軟體內部結構和開發過程細節都不提供，黑盒測試結果也與標榜的有很大差別，則可信性為0，表示對該軟體完全不了解，它下次運行結果我們完全不可預期和控制。其他類型的軟體，依據過程和測試證據打分情況，可信性會介於二者之間。我們考察構件使用者對構件開發和測試過程的了解情況，並用概率表示不了解程度。對這些概率求其加權平均即是對整個構件的熵。熵與可信性是負相關的關係，即構件的熵越大，可信性越低。根據構件的熵我們可以對構件的可信性劃分等級。步驟S103，度量構件可信性；
5
優選的，用信息熵作為可信性度量標準。更為優選的，根據可信性度量方法畫出可信性樹。如圖3所示本發明所述的一種基於熵的構件可信度量方法的可信樹。面向數據處理的構件一般是基於一個數據處理算法，過程性強，實現的功能點清晰明確。因此度量構件可信性時，我們分解出主要功能點(根據需要確定功能點的粒度)， 然後畫出可信樹。首先分析功能點1，在需求階段，專家通過分析客戶的需求以及可信性度量框架中記錄的可信證據，給定該階段的可信評估值Pi ；設計階段根據該階段記錄的可信證據測量它偏離需求階段的意圖的程度，給定P2;編碼階段，程式設計師是否理解設計方案並有能力去實現該方案，根據編碼階段記錄的可信證據計算出該階段的可信評估值P3 ；測試階段，對實現的構件從功能、性能、安全性等各個角度進行測試，根據記錄的可信證據得出該階段的可信評估值P4。在得出PI、P2、P3、P4之後，根據熵的計算公式⑴計算出功能點1的熵值。功能點2以及其餘的功能點都按照功能點1的分析過程進行分析，然後計算出每個功能點的熵值。所有的功能點分析完之後，計算所有功能點的熵值的平均值，該值即為構件的熵。由於所有的構件可信性都用該方法計算，所以熵值可以相對地比較出各個構件的可信性高低。熵與可信性是負相關的關係，構件的熵值越大，可信性越低。經過對可信性的度量，如果得出構件是可信的，則該構件可以提交入庫投入使用；如果構件是不可信的，則要分析是哪個階段出現了問題，然後對其進行修改，使構件達到可信度要求。下面以某金融領域匯率取得構件的開發為例，介紹上述可信性度量方法的運用實例。在實際開發過程中，我們根據可信證據和開發記錄依次分析每一階段軟體製品針對上一步的可信度。第一階段客戶需求陳述。客戶需求是構件生命期的起始，它與客戶真實意圖的微小偏離將會在後續階段放大。所以我們務必保證客戶需求儘量明確，為此我們要求客戶有書面需求陳述。該陳述也是可信證據的一部分。專家將對照該陳述和需求分析文檔來給定 pi。第二階段構件設計階段。包括構件的接口設計、接口描述和類設計三部分(本文略過)。構件接口設計在面向數據處理的軟體生產線平臺中，構件與構件之間的調用主要通過XML進行數據交互，因此構件所提供的方法的輸入和輸出參數，不僅支持普通的 JAVA類型參數，同時都提供了 XML支持。構件接口描述主要包括兩部分內容構件功能描述和構件接口調用描述。其中構件功能描述主要用於構件的檢索及查看，構件接口調用描述主要用於構件與構件之間的自動組裝。前者包括構件的類型、分類、功能描述、約束、可信度描述(測試用例)等，後者主要描述構件是如何被調用的，主要涉及到構件的類名、構件的方法名、構件的輸入參數和輸出參數等等。第三階段代碼實現根據設計進行代碼實現，對完成的代碼進行嚴格的版本管理。第四階段測試對實現的構件從功能、性能、安全性等各個角度進行測試。因為我們每一步都有詳細的證據和文檔，所以評審專家能根據這些資料評估每一步軟體製品相對上一步的偏離程度Pi，從而可以熵的計算公式(1)計算出信息熵當作可信度的度量。因為信息熵值沒有絕對的含義。因此構件的過程證據信息應按統一的標準和工具記錄和測定，在算出各構件的信息熵後我們可以根據需要劃分構件的可信度等級了。本說明書中的各個實施例均採用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。以上對本發明所提供的一種基於熵的構件可信度量方法進行了詳細介紹，本文中應用了具體個例對本發明的原理及實施方式進行了闡述，以上實施例的說明只是用於幫助理解本發明的方法及其核心思想；同時，對於本領域的一般技術人員，依據本發明的思想， 在具體實施方式
及應用範圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本發明的限制。
權利要求
1.一種基於熵的構件可信度量方法，其特徵在於，所述方法包括 分解出構件的主要功能點；記錄每個功能點在需求階段、設計階段、編碼階段、測試階段的可信證據； 根據記錄的可信證據計算功能點中每個階段的可信評估值Pi ； 計算各個功能點的熵； 計算構件的熵，判斷構件可信性。
2.根據權利要求1所述的方法，其特徵在於，所述構件的可信性作為構件投入使用的標準，構件不可信，重新修改構件開發過程，度量可信性。
3.根據權利要求1所述的方法，其特徵在於，所述需求階段的可信證據包括過程能力資質、計劃工作量、實際工作量、計劃進度、實際進度、需求人員能力、需求變更數、需求評審結論、評審缺陷密度、缺陷清除效率。
4.根據權利要求1所述的方法，其特徵在於，所述設計階段的可信證據包括計劃工作量、實際工作量、計劃進度、實際進度、設計人員能力、需求變更數、設計評審結論、評審缺陷密度、缺陷清除率。
5.根據權利要求1所述的方法，其特徵在於，所述編碼階段的可信證據包括計劃工作量、實際工作量、計劃進度、實際進度、編碼人員能力、需求變更數、單元測試強度、代碼規模、代碼可維護性。
6.根據權利要求1所述的方法，其特徵在於，所述測試階段的可信證據包括計劃工作量、實際工作量、計劃進度、實際進度、測試人員能力、測試工具支持、測試缺陷趨勢。
7.根據權利要求1所述的方法，其特徵在於，所述可信評估值Pi為該階段偏離上一步製品的意圖的程度。
8.根據權利要求1所述的方法，其特徵在於， 根據構件可信性度量方法畫出可信性樹。
9.根據權利要求1所述的方法，其特徵在於，所述構件的熵與可信性為負相關的關係，構件的熵越大，可信性越低。
10.根據權利要求1所述的方法，其特徵在於， 所述構件的熵為各個功能點的熵的平均值。
全文摘要
本發明提供了一種基於熵的構件可信度量方法，所述方法包括分解出構件的主要功能點；記錄每個功能點在需求階段、設計階段、編碼階段、測試階段的可信證據；根據記錄的可信證據計算功能點中每個階段的可信評估值Pi；計算各個功能點的熵；計算構件的熵，判斷構件可信性。發明中可信性的度量側重於過程證據，通過過程證據，量化可信性指標，用信息熵作為可信性度量標準，更有效地度量構件的可信性。
文檔編號G06F11/36GK102279793SQ20111022389
公開日2011年12月14日 申請日期2011年8月5日 優先權日2011年8月5日
發明者吳海燕, 張新鈺, 許斌, 賈寧, 鄭莉 申請人:清華大學