多視點元模型間需求追蹤性方法①

李 瀟,魏長江

(青島大學 數據科學與軟件工程學院,青島 266071)

統一建模語言(Unified Modeling Language,簡稱UML)是一種用于對軟件系統的制品進行可視化、詳述、構造和文檔化的圖形建模語言[1].傳統的基于UML 的面向對象的建模方法在不同視點下將建模過程劃分為從概念到實現的若干個階段[2],包括用例模型、靜態結構模型、動態行為模型和物理結構模型.

引入多視點的需求建模方法[3,4],使得軟件開發人員能夠按照不同的視點將整體劃分成分散、獨立的若干部分,最大程度地捕獲待開發系統及系統相關人員的完整需求信息.此方法只關注視點內所感興趣的問題,降低了需求描述的復雜度,并且各個視點之間相互補充和配合,減少了需求的遺漏.

然而,在不同的軟件開發階段和不同的涉眾下建立的不同模型,視點的分散性導致了模型間缺乏統一.目前,在傳統的基于UML 的面向對象建模方法中,多視點下模型間關聯困難的原因主要表現在三個方面[5]：(1)四種視點下的UML 模型缺乏對軟件系統總體結構上的考慮；(2)過早的專注軟件系統的細節,缺乏對軟件系統整體的把握；(3)對于軟件系統的非功能需求的描述存在不足.這不僅導致了無法獲取完整的系統需求,還難以進行需求變更管理.

目前,針對需求變更困難問題的解決方法有很多種,但被需求工作者廣泛使用的是基于需求追蹤的方法.2013年,Cimatti A[6]等人提出一種綜合性方法來驗證系統的功能型需求,并且還實現了從非正式需求到正式、可追蹤、自動化、可擴展需求的轉換過程.2014年,Goknil A[7]等人分析并改進了需求中的變更影響,對需求的可追蹤性進行研究,并開發TRIC 工具對需求變更進行分類和驗證.2017年,Tekinerdogan B[8]等人對需求的可追蹤性提出了不同的要求,在需求的元模型基礎上分析并實現了需求的可追蹤性.除此之外,國內關于獲取一致性、易于變更且可追蹤的需求問題也有相關的研究.2005年,朱雪峰、金芝[9]提出了一種需求不一致性管理框架的需求建模方法,就需求的不一致性管理方面有代表性的工作進行了較為系統的分析.2006年,王映輝等[10]提出了一種用于處理需求變更問題的有效方法,通過在關系矩陣中記錄變化的系統需求,然后通過矩陣的運算實現變更過程中需求的追蹤.

因此,本文一方面將面向目標的I*模型和軟件體系結構模型引入到傳統的基于UML (Unified Modeling Language)的面向對象的建模階段中,旨在設計一個基于多視點的建模過程框架.一方面在三個不同視點下建立追蹤元模型,闡明新的建模過程框架如何實現系統需求在多視點元模型間的平穩過渡.另一方面通過計算需求追蹤矩陣,在多視點元模型間建立起可追蹤關系,實現對系統需求的追蹤并驗證.

1 元模型的建立

1.1 基于多視點的建模過程框架

在我們的研究領域中,為了有效解決多視點下模型間關聯困難的問題并獲取完整的系統需求,本文將建模過程劃分為I*[11]目標建模、用例建模以及軟件體系結構[12]建模三個階段,旨在設計一個新的基于多視點的建模過程框架如圖1所示.在新建的建模過程框架中,將面向目標的I*模型建模在用例模型之前,不僅能夠避免過早的專注軟件系統的細節,而且能夠有效描述系統的非功能需求；將軟件體系結構模型建模在用例模型之后,通過UML 構件圖和部署圖實現對軟件系統的總體結構的描述.

圖1 基于多視點的建模過程框架

1.2 建立I＊目標模型的元模型

1.2.1 I*目標建模技術簡介

GRL (Goal-oriented Requirements Language)[13-15]作為一種可視化建模語言,主要應用于面向目標建模和推理需求過程.基于I*框架的建模是一種面向目標的需求建模方法,I*模型中的元素由GRL 語言提供,并且支持對非功能需求的分析與建模.

I*目標建模框架是一種在早期階段需求工程中著重描述軟件環境中各參與者意圖的建模方法[16]：該框架使用策略依賴模型(Strategic Dependency model,簡稱SD 模型)建立參與者意圖間的依賴,推導出能夠使得意愿滿足的策略；另外使用策略原理模型(Strategic Rational Model,簡稱SR 模型)表示參與者的意圖.

1.2.2 I*目標元模型的建模與分析

圖2所示I*目標模型的元模型元素關系分析如下：(1) AND：表示元素間的AND 分解關系.他能夠分解一個目標為一系列子目標,表示父目標的實現依賴于全體子目標的共同實現；(2) OR：表示元素間的OR 分解關系,它與AND 分解關系類似,不同的是父目標的實現可以由任意一個子目標(子軟目標)的實現所代替；(3)貢獻：定義為當目標被實現時,該目標對軟目標的影響關系；(4)依賴：不同參與者之間在某種元素關系上的依賴關系,依賴的雙方為依賴者depender和被依賴者dependee.

圖2 I*目標模型的元模型

1.3 建立場景元模型

1.3.1 用例建模技術簡介

功能需求是指開發人員必須實現的軟件功能或軟件系統應具備的外部行為[17].目前,對系統進行需求獲取與分析最常用的技術是基于UML 的用例技術,雖然說用例不能對所有的系統需求進行可視化建模,但卻為功能需求提供了良好的支持并得到了廣泛的應用[18].

用例著重于系統功能需求,關注的是系統與外部參與者間的交互,用于描述可發生的所有動作序列,而場景則是特定的動作序列.所以,用例與場景的關系中,場景是用例的一個實例,用例則是對于主角與系統交互層面上的那些相關交互場景的集合的描述.

1.3.2 場景元模型的建模與分析

圖3所示的場景元模型元素關系分析如下：(1)場景根據滿足目標的不同分為正常場景和異常場景；(2)場景描述被描述為一個或多個動作的組合；(3)動作分為動作流和原子動作,動作流包括一組動作；(4)場景會有狀態的變化,狀態中的起始狀態和終止狀態分別標志著場景的開始與結束；(5)代理執行相關的原子動作,并對對象參數產生一定的影響.

圖3 場景元模型

1.4 建立軟件體系結構元模型

1.4.1 軟件體系結構簡介

軟件體系結構[19,20]提供了一個抽象的系統規范,主要包括描述系統功能的構件、構件之間的連接件、構件與外界環境交互的接口以及配置的約束等.軟件體系結構不僅給出了系統的總體結構,而且顯示了系統需求和構成系統的構件之間的對應關系.

1.4.2 軟件體系結構元模型的建模與分析

如圖4所示軟件體系結構元模型元素關系分析如下：(1)一組相互協作的構件(components)以及連接這些構件的連接器(connectors)定義了應用系統的軟件體系結構；(2)為了處理來自業務領域需求的不斷變化以及軟件技術的不斷進步所引起的系統變更,軟件體系結構可以通過預先定義的一些擴展點來組裝用戶新開發的構件；(3)從模型結構上看,構件和連接器形成了軟件體系結構,此外還包含了配置(configuration),配置給出了系統的物理結構的文本形式；(4)構件的接口由一組端口組成,端口是構件與外部系統進行交互的紐帶；(5)連接件的接口由一組角色組成.

圖4 軟件體系結構元模型

2 多視點元模型間的追蹤

2.1 建立追蹤元模型

本小節建立了追蹤元模型如圖5所示.它由三個不同的層次組成,包括目標層、場景層以及軟件體系結構層.對每個級別中的制品和追蹤關系進行建模：目標層涉及功能需求和非功能需求,分別建模為“目標”和“軟目標”；場景層中涉及到為完成某個特定的目標而進行的一系列特定的“動作”；因此,我們將目標元模型與場景元模型間的追蹤關系建模為“支持”,表示一系列場景能夠“支持”相應目標的實現；軟件體系結構元模型表示了系統需求和構成系統的“構件”間的對應關系,軟件構件技術是指通過軟件的構件化把需要實現的功能分解成一系列標準的原子構件,其中每個“構件”都具有特定的功能實現[21]；因此,我們將場景層與軟件體系結構層的追蹤關系建模為“實現”.

通過分析不同層次元模型元素含義以及它們間的關聯關系,實現了系統需求在I*目標元模型、場景元模型、軟件體系結構元模型間的平穩過渡.

圖5 追蹤元模型

2.2 需求傳播途徑

根據圖5建立的追蹤元模型可知,在使用場景描述需求時,根據需要完成的功能設置相關的目標,為了實現這個目標就需要多個場景的支持,而場景是由若干個動作組成的,同時每個構件都具有特定的功能實現,最后每個構件都被部署在不同的硬件節點上.因此,在追蹤元模型中,目標、場景、動作、構件中任何一個元素發生改變,都可以根據目標g (goal)→場景s(scenario)→動作a (action)→構件c (component)→節點n (node)的傳播途徑進行追蹤.為了更清晰的表達追蹤元模型各元素間關系,得到如圖6所示的需求傳播途徑.

圖6 需求傳播途徑

2.3 需求追蹤矩陣

需求追蹤矩陣是一種主要管理需求變更和驗證需求是否得到實現的有效工具,可以跟蹤每個需求的狀態[22,23].

根據圖6需求傳播途徑,將元素間連線關系用具有一定語義的數值表示,其中“1”標記元素間有關聯,“0”表示元素間無關聯,可分別定義場景-目標追蹤矩陣Mg,動作-場景追蹤矩陣Ms,構件-動作追蹤矩陣Ma 以及節點-構件追蹤矩陣Mc.

建立以上四個追蹤矩陣可有效管理需求變更,當需求中的某個元素改變時,可以根據追蹤矩陣找到并更改這個元素所影響的其他元素.通過Mg 可以判斷“目標”改變時會影響到的“場景”；通過Ms 可以判斷“場景”改變時影響到的“動作”；通過Ma 判斷“動作”改變時影響到的“構件”；通過Mc 判斷“構件”改變時影響到的“節點”.

除了對系統需求在元模型間進行逐層的追蹤,還可以跨層追蹤,例如當“目標”發生變化時,可通過計算矩陣Mg-s 直接追蹤到相關的“動作”,其中

還可以通過計算矩陣Mg-s-a 判斷“目標”變化時影響哪些“構件”,其中

通過計算矩陣Mg-s-a-c 判斷“目標”變化時會影響哪些構件的部署,其中

所以,通過跨層追蹤得到矩陣Mg-s、Mg-s-a、Mg-s-a-c.

通過分析矩陣運算結果可追蹤到相關的需求變化關系,從而有效管理需求變更,例如矩陣中第i行第j列中的非零數字即表示兩個元素之間具有可追蹤關系,改變其中一個元素便會對另一個元素產生影響.

3 實例分析

本小節以自動取款機(ATM)系統為例,對以上方法進行可行性分析與研究.

首先建立基于ATM 系統的可追蹤元模型如圖7所示.第一層表示功能需求和非功能需求的目標元模型級別；第二層表示場景元模型的級別,描述了為支持某個目標而進行的一系列活動；第三層表示軟件體系結構元模型級別,描述了功能分配以及構件的部署.

在目標元模型層和場景元模型層間：“成功取款”、“查詢賬戶信息”以及“基本操作”屬于ATM 系統的功能需求,即目標.一個目標的完成需要一系列的動作支持,而動作的執行都是由目標所驅動,例如“成功取款”目標由“取款”場景支持,而此場景又包括“輸入取款金額”、“驗證取款金額”、“數據傳輸”以及“取出現金”這一系列動作.又比如：“基本操作”目標由“發起會話”和“傳輸數據”場景支持,“插卡”和“驗證密碼”則是“發起會話”場景所包含的一系列動作.對非功能需求而言,“ATM 設備安全”以及“ATM 系統安全”是從“ATM安全”的目標中分解出來的非功能需求,即軟目標,并且“ATM 系統安全”軟目標可以通過“安裝防病毒系統”和“及時升級測試”這兩個動態操作來滿足.

圖7 基于ATM 系統的追蹤元模型

在場景元模型層和軟件體系結構元模型層間：將ATM 系統功能劃分并分布到特定構件,并且將特定功能的構件部署在節點上來展示系統的架構.例如,“插卡”、“輸入取款金額”以及“取走現金”的動作都在“ATM 客戶端”界面上操作,接著將“ATM 客戶端”這一構件部署到“ATM 機”節點上.同理,將與“取款”功能相關的的“賬戶管理”構件部署在“銀行數據庫服務器”節點.同時,“ATM 機”、“ATM 服務器”以及“銀行數據庫服務器”之間又通過特定的網絡連接.

然后,通過分析基于ATM 系統部分功能的追蹤元模型,得到ATM 系統部分需求的傳播途徑如圖8所示.

接下來,根據基于ATM 系統的需求傳播途徑圖,得到場景-目標追蹤矩陣Mg,動作-場景追蹤矩陣Ms,構件-動作追蹤矩陣Ma 以及節點-構件追蹤矩陣Mc 為：

然后根據矩陣運算式(1)、式(2)、式(3)實現元模型的跨層追蹤.例如,通過式(1)計算矩陣Mg-s 建立ATM 系統目標與動作間的追蹤關系,計算Ms-a 建立ATM 系統場景與構件間的追蹤關系；通過式(2)計算Ma-c 建立ATM 系統動作與構件間的追蹤關系；通過式(3)計算矩陣Mg-s-a-c 實現ATM 系統目標與節點的追蹤,最終實現不同視點下元模型的統一.得到矩陣Mg-s、Ms-a、Ma-c、Mg-s-a-c 分別如式(4)-式(7).

根據以上矩陣運算結果,得到基于ATM 系統的目標元模型與場景元模型間,以及目標元模型與軟件體系結構元模型間的追蹤關系如圖9和圖10所示.

圖8 基于ATM 系統的需求傳播途徑

以“成功取款”目標為例,驗證基于ATM 系統的目標元模型層和場景元模型層間,目標元素與動作元素追蹤關系的準確性.根據圖8可知,“成功取款”目標更改影響到的動作是與“取款”場景相關的動作一致.其中,“取款”場景由一系列“數據傳輸”、“輸入取款金額”、“驗證取款密碼”、“取走現金”系統或人為的動作來完成.這意味著g2 與a3、a4、a5、a6 間具有關聯關系.顯然,這與圖9的第二列一致.同理,可知圖9的其他列也是正確的.

圖9 ATM 系統中目標層與場景層間追蹤關系

圖10 ATM 系統中目標層與軟件體系結構層間追蹤關系

再以“成功取款”目標為例,驗證基于ATM 系統的目標元模型層和軟件體系結構元模型層間,目標元素和節點元素追蹤關系的準確性.根據圖8可知,“成功取款”目標的更改影響到的構件是與“數據傳輸”、“輸入取款金額”、“驗證取款密碼”以及“取走現金”動作相關的構件一致,其中“數據傳輸”和“驗證取款密碼”與“賬戶管理”構件關聯,“輸入取款金額”和“取走現金”則與“ATM 客戶端”構件關聯,而這兩個構件又分別部署在“ATM 服務器”和“ATM 機”節點上.這意味著g2 與n1、n2 間具有關聯關系.顯然,這與圖10的第二列一致.同理,可知圖10的其他列也是正確的.

因此,通過矩陣運算,在ATM 系統多視點元模型間建立了可追蹤關系,一方面實現了在不同視點下元模型的統一,另一方面可有效管理需求變更.

4 總結與展望

本文主要研究了一種在多視點的元模型間進行需求追蹤的方法.一方面把面向目標的I*模型和軟件體系結構模型引入到傳統的基于UML (Unified Modeling Language)的面向對象的建模階段中,旨在設計一個基于多視點的建模過程框架.合理的建模框架使我們對需求的理解更加完整.另一方面在多視點間建立了追蹤元模型,并且通過矩陣運算實現了多視點下元模型間的追蹤.這不僅解決了視點分散性問題,實現了多視點元模型間的統一,還有效解決了需求變更困難的問題.然而,本文在場景元模型和軟件體系結構元模型間主要針對功能需求進行了追蹤并驗證,缺乏對非功能需求追蹤的研究.接下來的研究方向可從非功能需求在多視點元模型間的追蹤繼續展開.