李 瀟,魏長江

(青島大學(xué) 數(shù)據(jù)科學(xué)與軟件工程學(xué)院,青島 266071)

統(tǒng)一建模語言(Unified Modeling Language,簡稱UML)是一種用于對軟件系統(tǒng)的制品進行可視化、詳述、構(gòu)造和文檔化的圖形建模語言[1].傳統(tǒng)的基于UML 的面向?qū)ο蟮慕７椒ㄔ诓煌朁c下將建模過程劃分為從概念到實現(xiàn)的若干個階段[2],包括用例模型、靜態(tài)結(jié)構(gòu)模型、動態(tài)行為模型和物理結(jié)構(gòu)模型.

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

然而,在不同的軟件開發(fā)階段和不同的涉眾下建立的不同模型,視點的分散性導(dǎo)致了模型間缺乏統(tǒng)一.目前,在傳統(tǒng)的基于UML 的面向?qū)ο蠼７椒ㄖ?多視點下模型間關(guān)聯(lián)困難的原因主要表現(xiàn)在三個方面[5]：(1)四種視點下的UML 模型缺乏對軟件系統(tǒng)總體結(jié)構(gòu)上的考慮；(2)過早的專注軟件系統(tǒng)的細節(jié),缺乏對軟件系統(tǒng)整體的把握；(3)對于軟件系統(tǒng)的非功能需求的描述存在不足.這不僅導(dǎo)致了無法獲取完整的系統(tǒng)需求,還難以進行需求變更管理.

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

因此,本文一方面將面向目標(biāo)的I*模型和軟件體系結(jié)構(gòu)模型引入到傳統(tǒng)的基于UML (Unified Modeling Language)的面向?qū)ο蟮慕ｋA段中,旨在設(shè)計一個基于多視點的建模過程框架.一方面在三個不同視點下建立追蹤元模型,闡明新的建模過程框架如何實現(xiàn)系統(tǒng)需求在多視點元模型間的平穩(wěn)過渡.另一方面通過計算需求追蹤矩陣,在多視點元模型間建立起可追蹤關(guān)系,實現(xiàn)對系統(tǒng)需求的追蹤并驗證.

1 元模型的建立

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

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

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

1.2 建立I＊目標(biāo)模型的元模型

1.2.1 I*目標(biāo)建模技術(shù)簡介

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

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

1.2.2 I*目標(biāo)元模型的建模與分析

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

圖2 I*目標(biāo)模型的元模型

1.3 建立場景元模型

1.3.1 用例建模技術(shù)簡介

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

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

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

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

圖3 場景元模型

1.4 建立軟件體系結(jié)構(gòu)元模型

1.4.1 軟件體系結(jié)構(gòu)簡介

軟件體系結(jié)構(gòu)[19,20]提供了一個抽象的系統(tǒng)規(guī)范,主要包括描述系統(tǒng)功能的構(gòu)件、構(gòu)件之間的連接件、構(gòu)件與外界環(huán)境交互的接口以及配置的約束等.軟件體系結(jié)構(gòu)不僅給出了系統(tǒng)的總體結(jié)構(gòu),而且顯示了系統(tǒng)需求和構(gòu)成系統(tǒng)的構(gòu)件之間的對應(yīng)關(guān)系.

1.4.2 軟件體系結(jié)構(gòu)元模型的建模與分析

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

圖4 軟件體系結(jié)構(gòu)元模型

2 多視點元模型間的追蹤

2.1 建立追蹤元模型

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

通過分析不同層次元模型元素含義以及它們間的關(guān)聯(lián)關(guān)系,實現(xiàn)了系統(tǒng)需求在I*目標(biāo)元模型、場景元模型、軟件體系結(jié)構(gòu)元模型間的平穩(wěn)過渡.

圖5 追蹤元模型

2.2 需求傳播途徑

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

圖6 需求傳播途徑

2.3 需求追蹤矩陣

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

根據(jù)圖6需求傳播途徑,將元素間連線關(guān)系用具有一定語義的數(shù)值表示,其中“1”標(biāo)記元素間有關(guān)聯(lián),“0”表示元素間無關(guān)聯(lián),可分別定義場景-目標(biāo)追蹤矩陣Mg,動作-場景追蹤矩陣Ms,構(gòu)件-動作追蹤矩陣Ma 以及節(jié)點-構(gòu)件追蹤矩陣Mc.

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

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

還可以通過計算矩陣Mg-s-a 判斷“目標(biāo)”變化時影響哪些“構(gòu)件”,其中

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

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

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

3 實例分析

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

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

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

圖7 基于ATM 系統(tǒng)的追蹤元模型

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

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

接下來,根據(jù)基于ATM 系統(tǒng)的需求傳播途徑圖,得到場景-目標(biāo)追蹤矩陣Mg,動作-場景追蹤矩陣Ms,構(gòu)件-動作追蹤矩陣Ma 以及節(jié)點-構(gòu)件追蹤矩陣Mc 為：

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

根據(jù)以上矩陣運算結(jié)果,得到基于ATM 系統(tǒng)的目標(biāo)元模型與場景元模型間,以及目標(biāo)元模型與軟件體系結(jié)構(gòu)元模型間的追蹤關(guān)系如圖9和圖10所示.

圖8 基于ATM 系統(tǒng)的需求傳播途徑

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

圖9 ATM 系統(tǒng)中目標(biāo)層與場景層間追蹤關(guān)系

圖10 ATM 系統(tǒng)中目標(biāo)層與軟件體系結(jié)構(gòu)層間追蹤關(guān)系

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

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

4 總結(jié)與展望

本文主要研究了一種在多視點的元模型間進行需求追蹤的方法.一方面把面向目標(biāo)的I*模型和軟件體系結(jié)構(gòu)模型引入到傳統(tǒng)的基于UML (Unified Modeling Language)的面向?qū)ο蟮慕ｋA段中,旨在設(shè)計一個基于多視點的建模過程框架.合理的建?？蚣苁刮覀儗π枨蟮睦斫飧油暾?另一方面在多視點間建立了追蹤元模型,并且通過矩陣運算實現(xiàn)了多視點下元模型間的追蹤.這不僅解決了視點分散性問題,實現(xiàn)了多視點元模型間的統(tǒng)一,還有效解決了需求變更困難的問題.然而,本文在場景元模型和軟件體系結(jié)構(gòu)元模型間主要針對功能需求進行了追蹤并驗證,缺乏對非功能需求追蹤的研究.接下來的研究方向可從非功能需求在多視點元模型間的追蹤繼續(xù)展開.