基于變更場景的體系結構元素的識別

彭釗

摘要：需求的變更影響分析對于軟件系統的正確實現有著重要的意義。當前的需求變更影響分析研究方法主要集中于需求間以及需求到代碼間，缺乏需求到體系結構元素之間的研究方法。其次傳統的需求變更影響分析方法，在變更維護過程中，體系結構工程師需要對于變更源相關的每個體系結構元素（Architectural elements，AE）都要做出分析，這很容易造成變更影響狀態爆炸。本文基于一階邏輯相關理論以及一階邏輯在需求間變更影響分析的應用，提出一種基于變更場景的需求變更到體系結構元素的識別，并通過一個案例來分析該方法。

關鍵詞：需求變更影響分析;一階邏輯;變更場景體系結構元素

中圖分類號：TP311 文獻標識碼：A 文章編號：1007-9416（2020）05-0197-03

0引言

據調查，軟件系統開發的預算中有85%到90%被用于軟件系統的管理和維護，而這其中有50%被用于軟件系統的變更管理。Ebert等人在文獻[2J和文獻[3]中通過調查得到一個結論：一個周期為一年的軟件開發項目，就會有多于40%的需求發生了變更。為了盡可能的減少軟件開發成本，需要盡早在軟件開發周期中對變更進行管理。需求變更影響分析主要分為需求問、需求到AE以及需求到代碼的變更影響分析三類。傳統的方法對需求到AE之間的研究比較少，且傳統的方法很容易造成變更影響狀態爆炸。

需求到AE的變更影響狀態爆炸：由于缺乏需求到體系結構追蹤關系的語義，需求變更分析會產生大量的有關受影響的體系結構元素的誤報。體系結構工程師需要對體系結構中的每—個元素進行分析，因此會造成變更影響爆炸從而忽略真正受影響的體系結構元素。

在絕大多數軟件，尤其是安全關鍵的嵌入式軟件中，需求變更影響分析有著重要的意義。很多重大的事故都是由于在軟件系統的開發過程中，受變更影響的AE無法被正確識別所導致的。

綜上所述，保證受影響得AE正確識別是軟件開發過程中必不可少的。本文提出一種基于一階邏輯的需求變更影響分析方法，基于一階邏輯相關理論以及一階邏輯在需求間變更影響分析中的應用，給出了一種基于變更場景的受影響AE的識別方法。

具體章節安排如下：第1節介紹了需求到體系結構變更影響分析的國內外研究現狀;第2節介紹相關理論;第3節給出具體的方法說明;第4節用一個簡單的案例說明文中方法的可行性。

1研究現狀

目前，學術界對需求變更影響分析做了大量的研究。文獻[6]中，通過sysML需求圖描述系統的需求，通過sysML活動圖、塊圖、內部塊圖和狀態圖描述系統的體系結構，利用一個靜態切片算法，從而達到需求變更影響分析的目的。Sunny Wong等人在文獻[7]中提供一種基于UML關系邏輯模型的需求變更影響分析方法。陳光穎等人在文獻[8]中基于謂詞邏輯和模型驅動方法，提供一種常見的需求間關系和需求到體系結構的追蹤關系的形式化語義。Briand等人在文獻[9]中提供了一種基于UML用例圖的需求變更影響分析方法。

2相關理論

2.1基于一個需求描述定義的需求變更類型

本文用到的一個需求描述模型，基于該描述模型，本文把需求描述為一個由屬性和約束條件構成的二元組，其中每個需求必定有1個或以上的屬性，每個屬性必定有0個或以上的約束條件。根據這個描述模型，本文把變更分為如下幾種類型：增加需求、刪除需求、增加需求關系、刪除需求關系、更新需求關系、更新需求。

其中前面5種變更類型是顯而易見，最后一種最為復雜，可分為如下表所示的6個子類型：刪除/增加“一個屬性”;刪除/增加一個“約束條件”;“更新”屬性/約束條件。

2.2基于變更場景的變更影響規則

定義：變更場景（change senafio）：對于任意兩個需求之間，如果存在某種需求關系RLo對于這兩個需求中的任意—個需求引入任意一種變更類型CT，此時二元組構成一種需求場景，一個確定的變更場景，必然會導致確定的變更影響。

基于2.1中的變更類型以及它們在一階邏輯下的形式化語可以得出如表1所示的變更影響規則。

3基于變更場景的受影響AE方法

3.1重構與領域變更

本文基于變更的原理將需求變更分為重構（refactoring）和領域變更（domain change），其中語義保留變更與重構對應，語義修改變更與領域變更對應。需求的重構是指僅僅改善需求模型而不會改變整個系統的屬性;需求的領域變更是指需求變更會改變系統的屬性并且通常會改變滿足這條需求的體系結構元素。例如：把一個需求R簡單的分解為R1，R2……Rn，這種變更即為重構，因為這種變更并沒有改變整個系統的屬性，例如為需求R添加一個屬性pt。

3.2基于變更類型的受影響AE識別

基于第2節中的變更類型，可以把受影響的AE是識別分為四大類：

（1）對于變更類型為“增加需求關系”“刪除需求關系”“更新需求關系”的受影響AE的識別：如果變更類型為上述三種，那么滿足變更需求的AE不會受到影響，因為這三種類型的需求變更屬于重構，不會改變需求模型中的屬性。

（2）對于變更類型為“為需求增加一個屬性”的受影響AE的識別：如果添加的屬性是新的系統屬性，即之前的需求模型中不存在的屬性，那么滿足變更需求的AE必然會受到影響;如果添加的屬性不是一個新的系統屬性，那么滿足變更需求的AE不會受到影響，因為對需求的描述中并沒有對已存在的屬性和添加的屬性之間的顯式依賴關系的描述，所以很多情況無法自動識別添加的屬性是否是一個新的屬性，此時就不能確定滿足變更需求的AE是否受到影響，這種情況需要通過體系結構工程師來分析。

（3）對于變更類型為“增加需求”的受影響AE的識別：如果添加的需求中引入了新的系統屬性，那么滿足變更需求的AE必然會受到影響。如果添加的需求中沒有引入新的系統屬性，那么滿足變更需求的AE不會受到影響。

（4）除上述（1）（2）（3）中的需求變更，其他需求變更類型“刪除需求”“更新需求（不包括為需求增加一個屬性）”會更新需求模型中的屬性，因此滿足更新的屬性的體系結構元素會受到影響，變更的需求中某些屬性有可能未更新，因此滿足未更新的屬性的體系結構元素不會受到影響，可以通過在需求模型中遍歷變更的傳播路徑來確定是否有未受影響的屬性集，如果有，確定受影響的屬性的最小集。然后在確定受影響的體系結構元素。

3_3基于變更類型的受影響AE識別算法

對于受影響的AE的識別，本文給出一個算法來實現該函數。如圖1為算法概述。

如圖2為算法流程圖。

判定條件1：變更類型為“增加需求關系”“刪除需求關系”“更新需求關系”;

判定條件2：變更類型為“新增需求”;

判定條件3：已有需求和新增需求之間存在“refines”“partially refines”“contains”關系;

判定條件4：新增需求和已有需求之間存在“requires”“required”“refines”“partially refines”關系;

判定條件5：變更類型為“為已有需求增加一個屬性”;

判定條件6：增加的屬性是一個全新的，之前不存在的系統屬性。

對于該算法，如果變更類型不屬于判定條件1，2，5中的任意一種，則基于圖3中的遍歷規則調用算法1中的traverse PmpagalionPath函數，得到受影響的AE。

算法1：受影響的AE識別算法，如圖3。

4案例分析

我們通過RPM（遠程病患監護系統）中的兩個需求來說明本文方法的可行陛：

有以下需求R1和R2：

R1：系統應該通過傳感器把測量到的患者的血壓存儲到系統的存儲器中。

R2：系統應該通過傳感器把測量到的患者的中心靜脈壓存儲到系統的存儲器中。

對于上述關系，存在R2 refines R1，現在引入需求變更：除了測量中心靜脈壓之外，還需測量肺動脈壓。添加需求R3：

R3：系統應該通過傳感器把測量到的患者的肺動脈壓存儲到系統的存儲器中。

對于上述關系，存在R3 refines R1，則需求R3必定對滿足R1的AE產生影響，證明如圖4所示。

5總結與展望

本文基于一階邏輯相關理論以及一階邏輯在需求問變更影響分析中的應用，定義了變更場景，并基于需求問變更影響分析規則，提供了一種對影響的AE識別分類方法，給出了相應的算法。

但本文依然存在很多不足，首先本文的方法僅支持識別受變更影響的體系結構元素模型，不支持變更在體系結構中的傳播，即本文的方法只能是被受影響的體系結構元素，無法通過體系結構中引入變更并傳播變更來對體系結構進行更改以解決體系結構元素不滿足變更后的需求的問題。另一方面，在某些特定的情況下，本文的方法存在局限性，例如當變更類型為“增加一個需求”時，系統原有的需求中必須要有與新增需求有關系的需求，否則變更影響分析算法無法執行，即無法對該變更場景進行變更影響分析。