軟件制品可追溯性的形式化建模與分析

李建清，蔣建民

(成都信息工程大學軟件工程學院，四川 成都 610000)

1102418305@qq.com;jjm@fjnu.edu.cn

1 引言(Introduction)

在軟件生命周期過程中，常常會產(chǎn)生基于文本的需求、需求模型、設計模型、源代碼、測試用例、各種附加文檔等復雜多樣的軟件制品。良好的軟件制品可追溯性的潛在好處是更集中于開發(fā)、更低的維護成本、更清晰的文檔和更精確的變更影響分析。針對軟件制品可追溯性已經(jīng)研究多年，然而在管理可追溯性時，從業(yè)者得到的科學文獻支持很少，有必要探索如何構(gòu)建更好的可追溯性模型。一個好的可追溯性模型不僅可以保證各類軟件制品之間的可追溯性關(guān)系以及這些軟件制品內(nèi)部元素之間的關(guān)系，而且還支持定制，并允許使用擴展性來定義新的可追溯性鏈接類型。我們研究的可追溯性模型完全具有這些性質(zhì)。

可追溯性是描述和跟蹤軟件制品生命周期的能力，通常存在兩種類型的軟件制品可追溯性模型，一種是非形式化的，而另一種是形式化的。我們專注于形式模型，并使用形式方法來探索可追溯性。目前已有一些研究使用形式化方法建模和分析可追溯性，但這些與我們的工作完全不同。傳統(tǒng)的形式化模型通常采用行為模型，例如Petri網(wǎng)、進程代數(shù)、遷移系統(tǒng)。根據(jù)統(tǒng)一建模語言UML(Unified Modeling Language)和系統(tǒng)建模語言SysML(Systems Modeling Language)，軟件系統(tǒng)模型分為行為模型和結(jié)構(gòu)模型。我們認為結(jié)構(gòu)模型足以對可追溯性進行建模和分析，因為可追溯性關(guān)系是一種結(jié)構(gòu)關(guān)系。此外，如果用行為模型描述可追溯性，必須使用復雜的可達性算法來分析可追溯性，需要考慮狀態(tài)爆炸問題，從而花費較大代價。在本文中，我們提出了一種形式化的可追溯性模型，稱為“結(jié)構(gòu)模型”，用于建模和可視化可追溯性，并基于該結(jié)構(gòu)模型討論了一些可追溯性的分析方法，比如變更影響、制品和版本分析，最后實現(xiàn)了基于結(jié)構(gòu)模型的支持工具并用實驗證明我們的新方法是有效的。

本文其余部分的結(jié)構(gòu)如下：第2部分是可追溯性模型；第3部分是可追溯模型的組合；第4部分定義了可追溯性；第5部分是可追溯性分析；第6部分是案例研究和我們的支持工具介紹；第7部分是相關(guān)工作；第8部分總結(jié)了論文。

2 可追溯性模型(Traceability model)

該示例表明，結(jié)構(gòu)模型可以指定軟件系統(tǒng)中各種制品之間的關(guān)系。它可以直接使用原來的關(guān)系來表示用例模型之間的內(nèi)部關(guān)系(比如include和extend)及類之間的關(guān)系(比如aggregation)。一旦結(jié)構(gòu)模型明確了系統(tǒng)生命周期過程中模型的模型元素之間的關(guān)系，我們就可以從其結(jié)構(gòu)的角度來分析該系統(tǒng)。

證明：這個命題直接可得。

顯然，在一個結(jié)構(gòu)模型中，關(guān)系鏈的數(shù)量大于等于依賴鏈的數(shù)量。

3 可追溯性模型的組合(Composition of traceability model)

復雜的軟件系統(tǒng)包含許多制品，并分為由不同團隊開發(fā)的多個子系統(tǒng)。每個團隊都需要構(gòu)建自己的軟件制品可追溯性系統(tǒng)。一旦整個系統(tǒng)完成，所有的制品必須放在一起，并組成完整的可追溯性系統(tǒng)。因此，有必要討論可追溯性的組合問題。

證明：這些命題直接可得。

這個命題表明，結(jié)構(gòu)模型的組合具有封閉性、交換性和結(jié)合性。

4 可追溯性的定義(Definition of traceability)

軟件制品的可追溯性已被認為是支持軟件開發(fā)和維護過程中各種活動的重要質(zhì)量因素。軟件生命周期過程通常包含順序階段：需求、設計、實現(xiàn)、測試和維護，每個階段都存在各種制品。一般認為，下一階段的制品(模型元素)依賴于前一階段的制品。文獻[11]和文獻[12]中的可追溯性思想側(cè)重于需求和代碼(實現(xiàn))階段之間的依賴關(guān)系。我們擴展了這些想法，并提出了以下橫向和縱向可追溯性的形式化定義，并進一步給出了可追溯性的定義。

這里，水平可追溯性考慮需求和維護階段之間的直接和間接依賴關(guān)系，而垂直可追溯性則側(cè)重于模型元素的版本變化，即模型元素的版本號大于或等于其依賴模型元素，如圖2所示。顯然，雖然依賴鏈是直接的，但它們可以基于有向圖反向遍歷。因此，向前可追溯性和向后可追溯性包含在此定義中。定義不僅考慮了模型內(nèi)部的可追溯性，還考慮了多個模型之間的可追溯性。

圖1 系統(tǒng)中的偏序關(guān)系Fig.1 The partial relationships in a system

圖2 水平方向和垂直方向的可追溯性Fig.2 Horizontal and vertical traceability

定理4.1表明可追溯性在一定條件下是可組合的。

5 可追溯性分析(Traceability analysis)

基于結(jié)構(gòu)模型，這里介紹了一些可追溯性分析方法。

5.1 變更影響(覆蓋)分析

在大型軟件項目中，變更影響分析和變更覆蓋分析在控制軟件演化方面起著重要作用。一旦創(chuàng)建、修改和刪除模型元素，因為可能存在許多與該模型元素直接或間接相關(guān)的模型元素，因此相關(guān)的模型元素也可能會發(fā)生變化。我們的方法提供了更精確的變更影響分析，支持變更替代識別、消除誤報和變更一致性檢查。

模型元素的影響集包含直接或間接依賴于該模型元素的元素。該定義給出了一種計算模型元素影響集的方法。由于結(jié)構(gòu)模型形成一個有向圖，其中模型元素是頂點，包含或依賴關(guān)系是邊，可以使用圖遍歷算法輕松計算任何模型元素的影響集，我們的工具已經(jīng)實現(xiàn)了這個功能(見第6部分)。

圖3 可追溯性管理Fig.3 Managing traceability

5.2 制品分析

在一個軟件產(chǎn)品線中，制品的多個版本共存并同時在多個產(chǎn)品中使用，需要跟蹤哪個產(chǎn)品使用哪個版本。顯然，存在一些用于構(gòu)建多個產(chǎn)品的制品。事實上，每一個新產(chǎn)品都對應一個新版本號，但其中也包含許多版本保持不變的制品(請注意，這樣的版本號對應于我們的可追溯性模型中的初始版本號，不是我們的可追溯性中的最終版本號)。

在我們的解決方案中，無論何時創(chuàng)建產(chǎn)品，都可以跟蹤任何產(chǎn)品的所有制品。當一個產(chǎn)品發(fā)布時，需要創(chuàng)建一個模型元素，其中包含代碼元素和相應版本號的各種文檔，以及一些未更改的舊版本制品。例如，如果某些需求不需要改變，而新產(chǎn)品滿足了這些需求，我們可以根據(jù)新產(chǎn)品中包含的舊模型元素的直接或間接依賴關(guān)系來追溯這些需求。由于版本號通常是遞增分配給新模型元素的，因此產(chǎn)品模型元素的版本號大于或等于產(chǎn)品中包含的制品的版本號。

證明：這個命題直接可得。

這個命題說明，在可追溯的管理系統(tǒng)中不存在孤立的軟件制品，即孤立的軟件制品是不可追溯的。

5.3 版本分析

作為可追溯性最重要的工作之一，版本控制就是管理代碼等制品的變更和版本，并解決合并沖突和相關(guān)異常。在本部分中，我們將分析軟件制品的版本可追溯性。

證明：根據(jù)定義4.1(2)，新模型元素必須依賴于舊模型元素，并且新模型元素的版本號大于或等于舊模型元素的版本號。此外，同時創(chuàng)建多個模型元素，這些模型元素具有相同的版本號。因此，結(jié)果顯然成立。

圖4 異常的依賴關(guān)系和版本號Fig.4 Abnormal dependencies and version numbers

為了構(gòu)建基于結(jié)構(gòu)模型的可追溯性管理系統(tǒng)，我們開發(fā)了一款Web端名為JLTool的工具。該工具主要由兩個完整的模塊組成，一個模塊是繪制UML圖等各種圖，創(chuàng)建模型元素之間的可追溯性關(guān)系(包括自動化或半自動化UML圖導入和可追溯性鏈接生成)；而另一個是執(zhí)行可追溯性分析，如變更影響(覆蓋)分析、制品分析和版本分析。該工具可以從以下地址使用：http：//219.151.152.164：3000/。我校軟件工程專業(yè)的學生正在使用該工具進行軟件開發(fā)實驗。

6 案例研究(Case study)

在本部分中，我們使用一個簡單的地址簿系統(tǒng)演示本文中的結(jié)果。本案例(http：//www.cs.gordon.edu/courses/cs211/AddressBookExample/)由美國Gordon學院計算機科學教授Russell C.Bjork開發(fā)。在初始版本中，簡單的地址簿系統(tǒng)包含以下制品：10 個需求項、15 個用例、11 個類、15 個序列圖和11 個代碼片段。每個制品都被視為一個模型元素。在我們的工具中，不同類型的模型元素可以包含不同的內(nèi)容主體。例如，我們的工具提供了一個需求項的對話框，該對話框用于輸入需求項的具體文本內(nèi)容。類似地，我們的工具可以從XMI格式的文件中手動繪制或完全導入UML圖作為模型元素，例如，每個序列圖都是一個模型元素(可以通過工具Help中的Case study導入該案例)。

圖5 變更影響分析Fig.5 Changing impact analysis

7 相關(guān)工作(Related work)

軟件追溯管理問題得到了廣泛研究，大多數(shù)研究使用非形式化方法來探索如何管理軟件生命周期過程中的可追溯性。我們的工作涉及形式化方法，該方法有助于為軟件制品可追溯性提供嚴格的語義，以便對可追溯性進行建模、設計和推理。因此，我們在這里只討論最相關(guān)的作品。WEN等人使用稱為行為樹的形式化模型來表示功能需求，以確保變更管理的完整性并自動獲取記錄設計變更歷史的進化設計文檔。在文獻[17]中，ERATA等人介紹了一種新方法及稱為Tarski的支持平臺，該方法以交互方式表示可追溯性的語義，并使用戶能夠根據(jù)項目特定需求嚴格配置系統(tǒng)。GOKNIL等人提出了需求元模型，包括具有在一階邏輯中指定的形式語義的關(guān)系類型。BROY區(qū)分了邏輯制品內(nèi)容、制品內(nèi)容表示及其物理表示，并定義了制品內(nèi)容塊的概念。在上面提到的工作中，其可追溯性語義很難處理軟件制品的多對多關(guān)系，而我們的方法沒有限制。

在文獻[19]中，GOKNIL等人提出了一種在工具支持下生成和驗證需求及架構(gòu)之間跟蹤的方法。DRIVALOS等人提出了一種可追溯性元建模語言(TML)，該語言用于在高抽象級別上構(gòu)建和維護嚴格的可追溯性元模型。PAIGE等人提出了一種在基于模型的工程中識別、定義和實現(xiàn)語義豐富的跟蹤鏈接的方法。DI等人提出了一種基于模糊邏輯自動生成需求可追溯性矩陣的方法，該方法用于處理那些可能對需求可追溯性的確定產(chǎn)生負面影響的不確定性。SCHWARZ等人介紹了基于圖的方法來形式化和實現(xiàn)軟件工程項目中的可追溯性信息，旨在實現(xiàn)基于需求的軟件重用。SEIBEL等人提出了一種綜合的可追溯性方法，該方法針對模型驅(qū)動的工程和全局模型的能力方法，以動態(tài)分層的大型模型的形式進行管理。HOLTMANN等人在基于模型的開發(fā)上下文中給出了可追溯性術(shù)語的定義，并開發(fā)了一組術(shù)語，使我們能夠描述如何使用可追溯性，以及跟蹤鏈接具有哪些屬性。這些研究與我們的工作完全不同。

8 結(jié)論(Conclusion)

我們展示了如何在各種管理操作下保證可追溯性的正確，并提出了使用形式化方法構(gòu)建、分析和可視化整個軟件生命周期過程中的可追溯性的新的解決方案。我們開發(fā)了一個支持工具，用于促進不同形式的自動化分析，例如變更影響、制品和版本分析。該工具還可以幫助工程師半自動地建立和維護可追溯性信息。在本文中，由于我們關(guān)注的是管理追溯性的正確性，因此沒有考慮如何建立一個存儲庫來存儲追溯信息，但是我們的工具采用了一些節(jié)省存儲空間的解決方案。在未來的工作中，我們將探索如何更有效地存儲軟件制品和可追溯性信息，并完善JLTool工具，希望使其成為真正的CASE工具。