軟件演化過程的資源優化配置

摘要：在支持標準化的可配置、可重用且支持軟件演化過程建模方法——第二代SDDM建模方法基礎上，提出了軟件演化過程性能分析與資源優化的方法，有效地支持了軟件演化過程的改進。

關鍵詞：軟件演化； 軟件過程優化與改進； Petri網； 系統動態開發模型

中圖分類號：TP311．5文獻標志碼：A

文章編號：1001－3695(2007)07－0071－04

0引言

如今，軟件的提交形態已從產品形態轉換為服務形態，軟件需要根據用戶的需求和技術變化不斷改變。這種改變的頻率越來越高，推動軟件從低級走向高級、從幼稚走向成熟。此時，人們用演化（Evolution）來描述這種不斷的改變[1，2]；可以將演化看成是經常的、持續不斷的軟件再工程[1]。

軟件演化具有極強的個性化特征：迭代性、并發性、持續；間斷的改變是交錯進行的；反饋驅動系統；其模型的體系結構必須是多層的。需要建立基于過程模式的、滿足具體項目需要的過程優化技術，以支持個性化軟件過程的建立。軟件在不斷演化，支持演化的過程也需要不斷優化，以提供對軟件演化的有效支持。

隨著越來越多的成功軟件系統變成了遺產系統（Legacy System），軟件演化的重要性和普及性越來越強。一方面，軟件演化已成為軟件生存周期中最重要的形態之一；另一方面，軟件過程在提高軟件演化的效率和質量方面也發揮著重要作用。正是如此，軟件過程和軟件演化的多學科交叉成為軟件工程中的一個關鍵領域。一個良好的軟件過程能夠有效地促進軟件演化的成功實施；反之，將導致軟件演化的失敗。

1軟件演化過程的優化方案

筆者將過程優化分為兩個層次，即結構級優化和資源級優化。結構級優化主要是基于過程模型自身結構的優化，而資源級優化主要是基于過程模型實例的優化，涉及資源的分配調度和軟件過程運作的性能分析等問題。

首先在結構級對過程模型進行并行性挖掘和并行性延拓[3]，得到一個合理的并行化過程模型，它不涉及具體運作中的其他約束條件。因此在不出現結構性變更的情況下，其性能就是它的所有過程模型實例理論上的最佳性能。根據資源的匹配程度、活動間的并行度、資源的工作量平衡度等因素對資源進行合理的分配和調度。在資源級優化階段，主要是通過對軟件過程實例進行仿真和性能分析來預測資源的爭用和等待情況，對資源的分配進行調整，從而對并行的軟件過程進行柔性的動態改進和優化。本文將重點介紹軟件演化過程的資源級優化。

2用帶資源約束的活動網絡圖進行軟件過程性能分析

要在軟件過程中實現資源的優化分配，首先就應該對軟件過程的性能進行仿真分析，找出影響性能的地方，為資源的優化分配提供信息支持。

在第二代SDDM建模方法中，把活動看做是任務序列、活動、過程三者的統一體。活動使用的時間屬性主要有使能時間、點火時間、資源等待時長、執行時長、等待提交時間、正式提交時間、最遲點火時間。

（1）資源等待時長＝點火時間－使能時間；

（2）執行時長＝等待提交時間－點火時間；

（3）因后繼條件中有Token而等待的時長＝正式提交時間－等待提交時間；

（4）若點火時間＝最遲點火時間，則該活動是關鍵路徑上的活動。

要對軟件過程的性能進行分析，關鍵路徑是研究的一個重要方面。通過Petri網的仿真執行可以得到活動的使能時間、點火時間、等待提交時間和正式提交時間。求關鍵路徑的關鍵就是求出每個活動的最遲點火時間和最遲提交時間，然后判斷哪些活動的點火時間等于最遲點火時間。從Petri網軟件過程模型的仿真路線，可以得到一個活動的網絡圖，但該網絡圖中只能反映活動之間的控制關系。而軟件過程是穿插有資源約束的，因此直接用活動的網絡圖無法得到正確的關鍵路徑。

如圖1所示，方框內為活動的執行時間；實線箭頭表示活動之間的執行控制關系；角色活動A2和A3之間存在資源爭用關系，在圖中用虛線表示；箭頭方向表示A3等待A2釋放資源。在執行過程中，A2、A3、A4的使能時間都是3，假設活動A2比A3的優先級高，A2先點火，因此A3必須等待A2提交后才能點火，點火時間為6。從圖中可以看到，關鍵路徑應該是A1、A2、A3、A5。如果僅按傳統活動網絡圖就無法找到這條正確的關鍵路徑。

因此，應該在傳統的活動網絡圖中加入虛線表示的資源約束關系，然后利用這種帶資源約束的活動網絡圖來計算活動的最遲點火時間和最遲提交時間，從而獲得過程的關鍵路徑。

根據帶資源約束的活動網絡圖，不僅可以得到關鍵路徑的信息，還可以獲得每個活動的緩沖時間信息，如：

（1）活動的總緩沖時長＝最遲點火時間－點火時間；

（2）活動的安全緩沖時長＝后續活動最早點火時間－該活動的提交時間；

（3）干預緩沖時長＝總緩沖時長－安全緩沖時長。

總緩沖時長反映的實際上是活動所在串行路徑上公共的緩沖時長，一個活動如果占用了該串行路徑的所有總緩沖時長，則其他活動就沒有緩沖時長了。

安全緩沖時長反映的是可以使用的不影響任何后續活動的緩沖時長；它是一個比較安全的緩沖時長。

干預緩沖時長反映的是該活動在突破空閑緩沖時間后，延遲后續活動開始，但不延遲整個過程結束時間的緩沖時長。

這些過程度量數據都可以為資源優化和過程改進提供有用的信息。

3資源配置前的準備

在資源分配中，應該盡可能為并行活動分配不同的資源。另外考慮到分配的資源主要是人力資源，在資源分配中應該盡量保持人員工作量平衡；為了使軟件過程的流程盡可能是無縫的，應該盡量減少產品在資源間的交接次數。例如，“取款”用況中的用況描述人員將會獲得許多有關“賬戶”類職責的知識，應該作為“賬戶”類構件工程師邏輯上的候選者。為此，應該在角色模型的基礎上再引入分配單元的概念。

第二代SDDM建模方法模型是以角色為中心的，一個角色對應一個活動，默認情況下，應該一個角色作為一個分配單元。但為了盡量減少產品在資源間的交接次數，可以指定某幾個角色為一個分配單元，必須由同一個人完成。每個參加分配的活動都應該對應一個執行者，執行者是活動與具體人員之間的關聯，用它記錄執行活動、執行人員、執行優先級以及執行延遲時間等信息。執行者列表也就是資源分配的結果，它是資源分配過程中動態產生的，并且可以動態修改。

如圖2所示，每個人員進行分配前都應該轉換為工作人員，也就是確定他們能夠從事什么樣的工作，如架構設計師、構件工程師或集成測試人員等。另外，每個角色也應該指定需要什么類型的工作人員來完成、他們的優先順序怎樣等。然后就可以以工作人員為紐帶進行人員的合理分配。一個人員可以擔任多個工作人員的工作，一個角色也可能可以由多種類型的工作人員充當。

接下來還要解決兩個問題：為活動找到可以勝任的人員；為活動選擇最合適的人員。

4資源的定量描述

安全緩沖時間是不影響任何后續活動的點火的緩沖時間，可以把它考慮到并行度的計算中去。具體做法是，先獲得活動i與j的四個并行度：①兩個活動都沒有緩沖的并行度；②活動i的點火時間和提交時間都加上安全緩沖時長后與活動j的并行度；③活動i與按安全緩沖時長平移后的活動j的并行度；④活動i和j都按各自的安全緩沖時長平移后的并行度。因為它們都有按安全緩沖時長調整的余地，所以四個并行度中的最小值可以更合理地代表活動i與j的并行度，最終的并行度就是這四個并行度中的最小值。

上面介紹了活動與活動的并行度，因為一個分配單元可能含有多個活動，還應該討論以下分配單元與分配單元的并行度問題。

在把一個分配單元分配給具體人員時，該分配單元與該人員已有分配單元集的并行度越大，則分配給該人員的可能性越小。在實際的資源分配中，還應兼顧人員工作量的平衡問題。本文用工作量平衡度來進行衡量。

定義4工作量平衡度。對于一個分配單元而言，其候選人員的工作量平衡度等于該人員已有分配單元的總資源占用時間比上所有候選人員已有分配單元的總的資源占用時間與待分配單元的資源占用時間的和。

5資源的優化配置方法

(1)首先對未分配資源的軟件過程模型進行仿真運行。此時獲得的是沒有資源約束情況下軟件過程模型的性能數據，它反映了所有活動邏輯上的并行性和軟件過程的最佳進度。

(2)選定進行分配的分配單元和供它們選擇的資源，基于第（1）步獲得的軟件過程性能數據，對分配單元進行排序。候選人數越少應該越先分配資源，包含有關鍵路徑上的活動分配單元應該先分配資源，角色層次高的也應該先分配資源，安全緩沖時間越大的越后分配資源。

(4)第一輪資源分配完成后，因為資源的調整必然導致資源約束的變化，也會導致軟件過程性能數據的變化。為此，應該對資源分配后的軟件過程重新進行仿真，獲取新的性能數據。與沒有資源約束時的關鍵路徑不同，現在關鍵路徑上必然有活動存在資源等待，要提高軟件過程的性能就應該減少關鍵路徑上活動的資源等待時間。筆者取出關鍵路徑上存在資源等待的分配單元進行重新分配，為它們重新分配比原來資源等待時間更少的資源。

(5)資源調整后，再次對軟件過程進行仿真分析，找出需要重新調整資源分配的分配單元，修改點火時間和提交時間后進行重新分配，然后再仿真。如此反復，直到資源分配相對穩定或者可以接受為止。

6結束語

本文主要介紹軟件演化過程的資源級優化，先討論了軟件過程的性能分析方法，介紹了如何通過過程模型的仿真數據來獲得帶資源約束的活動網絡圖，從而獲得關鍵路徑、緩沖時間等性能信息。接著又討論了資源的匹配方法，以模糊集理論來描述人員的能力。為了從數學的角度對該問題進行求解，給出了五個矩陣來獲得分配單元與具體人員的匹配程度信息。然后討論了資源的優化方法，給出了并行度及人員工作量平衡度的計算方法。最后給出了通過軟件過程的仿真來進行過程優化的方法。在未來的研究中，將進一步探討在層次化過程模型中提取帶資源約束活動網絡圖的方法。

參考文獻：

[1]YANG H， WARD M. Successful evolution of software system[M].[S.l.]:Artech House， 2003.

[2]BIANCHI A， CAIVANO D， MARENGO V， et al. Iterative reengineering of legacy systems[J]. IEEE Transactions on Software Engineering， 2003，29(3):225－241.

[3]李彤，孔兵，金釗，等. 軟件并行開發過程[M]. 北京:科學出版社，2003:33－46.

[4]馮冬青，謝宋和. 模糊智能控制[M]. 北京:化學工業出版社， 1998.

[5]李彤，王黎霞.一個支持軟件并行工程的過程建模語言[J].計算機應用與軟件，2000，17(4):26－33.

[6]王黎霞，李彤.一個支持軟件并行工程的過程模型[J].計算機工程，1999，25(11):10－11，46.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”