擴展SysML支持需求追蹤模型的自動生成*

鄧劉夢，沈國華,2+，黃志球,2，王 飛，葛曉瑜

1.南京航空航天大學 計算機科學與技術學院，南京 211106

2.軟件新技術與產業化協同創新中心，南京 210016

1 引言

在嵌入式系統開發生命周期中，開發者經常會一次又一次地改變需求，而如何去捕獲這些改變對系統的影響往往是一項復雜的任務。此外，對于長生命周期的軟件，隨著時間的推移，為了引入新硬件或為了糾正現有的缺陷，對其進行維護是必不可少的。對于安全關鍵系統而言，引入這些改變是尤為慎重的。例如，美國航空航天局等組織已經設立了變更委員會，要求對變更進行安全分析，并在委員會實施之前予以批準[1]。因為在這樣的情況下，軟件變更可能會在部署變更之前觸發生命周期任務的重復，包括需求分析、設計、代碼和測試的重復。能力成熟度集成模型（capability maturity model integration，CMMI）[2]明確地指出在開發過程中維護需求的可追蹤性及制品之間的可追蹤性是保障系統安全的重要前提[3]。ANSI/IEEE標準830—1984中首次提出了可追蹤性的概念，其早期主要被用于在功能上提高系統的可重用性。需求可追蹤性旨在管理需求鏈接和模型，可被定義為：“通過相關規范以及定義，朝著需求的起源或實現這兩個方向，能夠描述和追蹤需求的整個生命周期”[4-5]。

在安全關鍵系統中，很多重大的失效都是由于系統需求在設計過程中沒有被精確和完整地追蹤而引起的，因此在開發過程中通常會使用特定開發標準對項目進行要求[6]，例如 DO-178B/C[7]、ISO 26262-6[8]、ECSS-E-40[9]等標準適用于航空航天、汽車醫療領域。這些標準詳細規定了系統開發生命周期中需要實現的目標以保證軟件的安全性，而可追蹤性則是其中一個重要的目標。例如：DO-178B就指出“對于某些關鍵程度的系統，應提供源碼到低級需求間的追蹤關系以及對于低級需求完全實現的驗證”。盡管缺乏追蹤關系的系統不一定會產生安全性事故，但健全的追蹤信息可以有效地關聯不同開發階段間的制品，并可以此很好地檢驗需求在其他階段中的滿足情況。這可以有效地降低因設計人員對需求的誤解、遺漏以及更改而產生的安全性事故。因此，如何建立需求整個生命周期的可追蹤性對于提升軟件以及系統的安全性顯得至關重要。

本文基于模型驅動工程（model-driven engineering，MDE）來解決安全關鍵系統中需求可追蹤性這一問題，主要致力于安全關鍵系統開發過程中需求可追蹤性的早期建立（即事先追蹤）。采用模型驅動的方法進行系統開發，使得在開發早期即將追蹤信息包含到模型中，避免了事后的恢復，提高追蹤信息的準確性。模型驅動工程主要使用不同抽象層次的模型進行系統設計和開發，可以使用元建模（meta-modeling）構建適用于不同場景的模型。本文選取了系統建模語言（systems modeling language，SysML）作為建模語言對系統進行建模，SysML是一種圖形化建模語言，它為軟件體系結構建模提供了一套豐富的圖表，支持各種復雜系統的詳細說明、分析、設計和驗證，彌補了統一建模語言（unified modeling language，UML）在系統工程領域建模的缺陷，已經成為工業界在系統工程設計與分析過程中的標準建模語言。目前SysML已經被NASA、歐洲航天局等機構廣泛應用到實際的項目開發中。但是，其對于可追蹤性的支持仍有局限，例如無法從需求追溯到它們的起源（包括利益相關者等）。此外，缺少針對SysML的特定追蹤模型，用于對追蹤信息的表述，使得潛在的追蹤信息無法為工程師應用于實際的安全性分析中（如：需求變更的影響分析等）[10]。

本文的主要內容及貢獻如下：

（1）對SysML模型進行了擴展，給出了擴展配置文件（profile），用于在安全關鍵系統開發中追蹤信息的捕獲。

（2）給出了一個用于表達追蹤信息的元模型（meta-model），并利用模型轉換（model transformation）自動化生成追蹤模型。該追蹤模型提供了描述需求與設計制品間追蹤信息的能力。

本文的結構如下：第2章介紹MDE以及SysML，并在此基礎上給出用于追蹤信息捕獲的SysML擴展模型；第3章給出用于追蹤信息展示的追蹤元模型以及用于自動化生成追蹤模型的ATL（ATLAS transformation language）規則；第4章給出案例分析；第5章介紹相關工作并與本文方法進行比較；第6章總結全文并展望未來工作。

2 追蹤信息捕獲

本章主要對SysML進行介紹并由此引出用于追蹤信息捕獲的配置文件。

在模型驅動的軟件工程中，可追蹤性被認為是非常重要的。其中，模型轉換、代碼自動生成等技術理論上可以隱式地自動建立和維護軟件設計和代碼之間的追蹤關系，但這種追蹤關系一般是單向的，即順著目標模型生成的方向。此外，需求的可追蹤性涉及到需求工程，它主要用于確保開發模型，代碼實現以及測試計劃都滿足項目的原始需求。在模型驅動工程中主要有以下兩種方法對可追蹤性的管理：

（1）通過自動化模型轉換過程創建可追蹤性鏈接；

（2）通過事件捕獲來管理可追蹤性鏈接。

2.1 SysML簡介及方法概述

本文選取了SysML作為建模語言對系統進行建模，SysML是一種圖形化建模語言，是對象管理組織（object management group，OMG）在對UML2.0的子集進行重用和擴展的基礎上，提出的一種新建模語言。它致力于建模具有眾多組件、難以描述、理解、預測、管理、設計以及更改的系統，并提供了表達個人需求及其組成的手段，已被學術界和工業界所廣為接受，作為一種標準建模語言。

在安全關鍵系統中，系統的安全往往不僅限于純粹軟件的安全，軟件設計存在缺陷會導致事故的發生，此外對于某些系統硬件的控制不當，同樣也可能造成安全事故。故而，在系統開發中，開發者需要對安全相關（safety-related）的組件（包括軟硬件部分）進行嚴格的安全性分析、驗證。有效地保證需求到這些組件的可追蹤性，將為后續的安全性分析提供巨大的幫助。

下面給出本文方法概述，如圖1所示，主要分為兩個階段：第一階段為對追蹤信息的捕獲。首先對SysML進行擴展，得到一個用于追蹤建模的配置文件，使開發者建模過程中即可將追蹤信息捕獲到模型中。第二階段為追蹤信息的表達。通過第一階段捕獲到的追蹤信息包含在SysML模型中，此時需要構建一個可以用于描述追蹤信息的追蹤元模型。接著通過模型轉換將SysML模型轉換到追蹤模型。利用追蹤模型以及圖形化表達為開發者提供直觀的追蹤信息展示，使開發者可以利用這些信息對系統進行后續的安全性分析。

Fig.1 Automatic generation of trace model圖1 追蹤模型自動生成

2.2 SysML配置文件構造

SysML提供了多種建模圖供開發者使用。本文中主要使用需求圖（requirement diagram）和塊定義圖（block definition diagram）分別對需求和設計制品進行建模。SysML提供對于需求追蹤的機制，其中<>類型提供了一個廣泛意義上的追蹤關系鏈接；<>、<>等提供了描述需求間相互關系的能力；<>、<>則用于描述需求與其他制品間的關系。但總體上，SysML提供的可追蹤性能力非常有限，首先其不支持雙向的追蹤（只可從需求向下一階段的制品進行追蹤），其次缺乏面向特定目的以及領域的追蹤能力，無法很好地滿足安全關鍵領域中安全性分析的工作。為了有效捕獲面向安全關鍵領域的可追蹤性信息，首先需從元模型層面進行設計分析。

需求的追蹤本質上是對需求間以及需求與其他設計制品間的關系進行刻畫。那么首先要做的就是進行追蹤信息的捕獲（例如：需求的類型、需求的提出者、利益相關者等），這將決定可追蹤性的粒度。在本文中利用SysML的擴展機制，對SysML進行擴展，使擴展后的模型可用于追蹤信息的捕獲。

關于SysML的擴展機制，官方主要提供了如下3個途徑：

（1）基于UML構造型（stereotypes）；

（2）基于UML圖表擴展（diagram extensions）；

（3）基于模型庫（model libraries）。

SysML構造型機制通過用新的屬性和約束來擴展現有的UML2構造型，從而定義新的建模元素；SysML圖表擴展通過定義新的圖表符號，用于補充從UML2中重用的圖表符號；SysML模型庫則用于描述可供重用的專用模型元素。上述這些方法最終都需通過配置文件實現[11]。

本文構建配置文件的方法如圖2所示：首先對需要擴展的領域元素進行收集，本文中即為追蹤信息（如：利益相關者、測試用例等）。接著對這些元素進行形式化，映射到SysML的元模型。進而利用EMF（eclipse modeling framework）工具將得到的元模型構建成SysML的配置文件，其表現形式為SysML圖。配置文件中構造的模型元素可以通過標記定義（構造型的屬性）和約束進行精化。其中約束可以使用對象約束語言（object constraint language）表示。

Fig.2 Phases of building SysML profile圖2 SysML配置文件構建過程

當配置文件定義完成后，將其導入到建模的工具中，此時進行SysML模型開發即可選用擴展的配置文件。而建模得到的SysML模型將符合定義的配置文件要求，同時也將追蹤信息捕獲在模型中。針對安全關鍵系統的特性以及本團隊的需要，下面給出本文中用于需求追蹤的配置文件結構圖。如圖3所示，所有的構造型都是基于元類中類（class）的擴展。元類是UML配置文件中提供的一個類，可以通過一個或者多個構造型進行不同方向的擴展。而構造型則是用于創建配置文件的主要手段，它們通過擴展元類進行定義，然后作為模型元素應用于用戶定制的模型中。

Fig.3 Profile for trace information capture圖3 用于追蹤信息捕獲的配置文件

下面給出擴展的SysML模型的形式化描述：定義標記“├”代表擴展關系，ST為SysML中構造型的集合，MT為SysML中元類集合，則有ST├MT，即構造型可以通過擴展元類得到。定義標記“→”代表繼承關系，如果a→b，b∈ST，那么a∈ST，即新構造型也可以通過繼承原有的構造型生成。本文配置文件使用的構造型和元類集合分別為st、mt，故st?ST，mt?MT，并且有st={TestCase，Owner，Block，Requirement，Safety-relatedReq，ConstraintBlock}，mt?MT，mt={Class}。

原SysML中Requirement構造型只有id和text兩個字段，分別對應每一需求的標識符和文本描述。針對安全關鍵系統加入Safety-relatedReq構造型用于表示對系統安全性相關的需求。該構造型是對SysML中Requirement構造型進行繼承，并在此基礎上添加Reqlevel屬性，用于描述需求所對應的構件級別。

構造型Block和ConstraintBlock為SysML中原有的構造型，它是系統描述的單元。每個Block定義一組特征用于描述系統或開發者關切的其他元素。其中可能包括結構以及行為特征，例如屬性和操作，用于表示系統可能出現的狀態和行為。而ConstraintBlock提供了一種集成的機制，用于結合其他模型元素對系統的性能和可靠性進行分析（例如：數學表達式的約束）。

加入TestCase構造型，用于關聯驗證需求的測試用例，可指向狀態圖等。

加入Owner構造型（可能是個人或公司）用于關聯需求的所有者或者其利益相關者。

3 追蹤模型生成

在第2章中，完成了對SysML模型的擴展，使其可以捕獲特定追蹤信息。在本章中，將構建一個追蹤元模型，用于追蹤信息的表達。

3.1 追蹤元模型構建

傳統的可追蹤信息模型（traceability information model，TIM）抽象定義了項目中追蹤鏈的類型（trace link type）和被追蹤軟件制品類型（artifact type）等，為實際項目中追蹤鏈的建立提供指導。而在安全關鍵系統開發過程中進行安全性分析時往往需要提供更為詳細的信息，因此要求追蹤模型可以為開發者提供如下的追蹤信息：

（1）可以描述需求與設計制品之間的雙向追蹤關系以及需求與其他元素間的追蹤關系；

（2）可以描述對不同類型的追蹤元素。

下面首先給出追蹤元模型的形式化描述[5]：M=(K,A)，即追蹤模型由追蹤鏈集合K和對應的追蹤元素集合A構成。使用符號“→”描述追蹤鏈，則追蹤鏈K可表示為A→KA，即追蹤鏈代表一組從源制品到目標制品的關系。定義函數fs：K→A映射每個追蹤鏈對應的源制品；函數ft：K→A映射每個追蹤鏈對Verify應的目標制品。例如：Requirement→TestCase，因此fs(Verify)=Requirement并且ft(Verify)=TestCase。

接著給出追蹤元模型的圖形化表示，如圖4所示。其中，根元素為TraceModel，它可能包含多個TraceLink元素（追蹤鏈）。TraceLink包含一個Tracetype（追蹤類型）的屬性（其值可能為Satisfy，Responsible Of或Verify，取決于關聯的不同類型的制品）。TraceLink關聯了TraceElement元素，對應一個源元素以及一個目標元素。TraceElement元素為對應包含追蹤信息的元素：Requirement、Block、TestCase以及Stakeholder。

Fig.4 Trace meta-model圖4 追蹤元模型

3.2 模型轉換

本節主要通過模型轉換技術完成從SysML模型到追蹤模型的轉換，實現追蹤模型的自動生成用于展示建模階段捕獲到的追蹤信息。

模型轉換是模型驅動架構中使用的關鍵技術，本文采用ATL和EMF工具實現模型轉換。ATL是ATLAS研究組開發出的一種符合OMG查詢/視圖/轉換（query/view/transformation，QVT）提案的模型轉換語言。ATL是基于Eclipse模型框架的語言，其元模型、模型均用EMF文件描述，并使用了對象約束描述語言（object constraint language，OCL）定義規則。本質上，ATL屬于基于規則的模型轉換語言。

上面給出本文中使用的SysML模型到追蹤模型的ATL轉化規則，用于實現自動化生成追蹤模型。代碼功能如下：首先定義一個helper，用于判斷制品的構造型值，其功能類似于函數，可在不同的模塊中被調用。規則Safety-relatedReq2Req用于實現SysML模型中構造型Safety-relatedReq到追蹤模型中Requirement的轉換；規則Block2Artifact用于實現SysML模型中Block構造型到追蹤模型中Block的轉換，此時若有與其關聯的需求，則將追蹤鏈的類型設置為Satisfy；規則 Owner2Stakeholder和 Test2TestCase與規則Block2Artifact分別用于實現SysML模型中Owner和TestCase構造型追蹤模型元素的轉換，以及追蹤鏈類型的設置。

4 案例分析

襟縫翼控制系統是飛控系統中控制襟翼和縫翼行為的重要組件，在起飛和降落過程中增加升力，提高失速臨角。該單元直接影響著飛行的安全及穩定，保障其安全性至關重要[12]。本團隊在前期工作中已通過模型檢測技術實現了襟縫翼控制系統源代碼層面的驗證[13]，本文將關注該系統開發的可追蹤性研究。

本文選取了如下所示的襟縫翼控制單元的部分需求[14]作為案例進行追蹤關系的構建與驗證：

R0：系統周期自檢中，對硬件設備輸出的有效性進行檢測。

R1：系統的周期自檢中，需要對風扇轉速、處理器溫度輸出的有效性進行檢測。

R2：系統應提供對處理器溫度輸出有效性的檢測功能。

R3：系統應該提供對風扇轉速輸出有效性的檢測功能。

Fig.5 Requirement diagram of slat control system圖5 襟縫翼控制系統需求圖

以上需求均為安全相關的需求，根據需求之間的關系可以得到：其中需求R1是對需求R0的精化；需求R2和需求R3則是對需求R1的分解。

使用擴展后的SysML對其進行建模，得到需求圖如圖5所示。

接著進行系統設計的建模，塊CPU是對處理器的建模，它與需求R2存在著滿足關系；而測試用例StateMachine1則是對需求R3的測試用例進行建模，它與需求R3存在驗證關系。

圖6為CPU模塊的塊定義圖。它由一個傳感器塊和數據處理塊組成，分別負責溫度的探測和數據的交換。

Fig.6 Block definition diagram of CPU unit圖6 CPU單元的塊定義圖

為了生成追蹤模型，將建模得到的擴展模型以及追蹤元模型同時導入EMF工具中并加入ATL代碼，利用EMF工具對ATL代碼進行編譯執行，即可自動生成追蹤模型。得到的實例文件如下所示。

第一個追蹤鏈類型為Satisfy，對應的追蹤元素為需求R2和設計制品CPU塊定義圖，代表該CPU塊圖用于實現需求R2；R3與StateMachine1的追蹤鏈生成，其追蹤類型為Verify，代表StateMachine1與需求R3存在著驗證關系；R0和StaffA之間生成追蹤鏈，類型為ResponsibleOf，代表StaffA是需求R0的利益相關者。

利用繪圖軟件對XML文件進行處理，得到如圖7所示的圖形化追蹤模型，為追蹤信息提供直觀的展示。從生成的追蹤模型文檔以及圖形化的模型可以觀察到，通過配置文件擴展的SysML模型在建模時成功地捕獲追蹤信息，使用EMF工具實現模型轉換后自動生成的追蹤模型符合追蹤元模型，具有表達追蹤信息的能力。

Fig.7 Graphical representation of trace model圖7 追蹤模型的圖形化表示

5 相關工作

本文的相關工作主要包括SysML的相關擴展以及需求追蹤關系的建立方法。

5.1 SysML的擴展

SysML是在UML基礎上擴展的，它本質上是一個UML的配置文件擴展。SysML擴展的主要目的為：通過擴展使建模語言獲得原始模型不具備的分析能力和信息存儲、表達能力。

目前基于SysML擴展的需求可追蹤性領域中已有許多相關工作。文獻[15]中Soares等人致力于強化需求表達中的可追蹤性概念。作者在文中提供了SysML需求圖和SysML需求表的擴展。提出了用戶需求和追蹤的分類，增強了需求和追蹤一致性的檢查。該工作僅擴展需求圖和需求表，沒有追蹤類型以及元素的擴展，而本文中通過擴展SysML新構造型，提供了增加新追蹤元素的能力。Paige等人在文獻[16]中提出了一種通過可追蹤性抽取來識別模型驅動過程中追蹤鏈的方法，并提供了一種定義和實現此類追蹤鏈的方法。

此外，基于SysML擴展進行系統建模和安全性分析的研究也是一個熱點。Hause和Thom給出了一個在安全關鍵系統設計中使用UML和SysML的指南[17]。他們提供了用于建模安全完整性等級（safety integrity level，SIL）的構造型，確保系統構件關系滿足相關的安全性需求。文獻[18]提供了一個名為“SafeML”的SySML的配置文件，用于對安全關鍵系統中的安全相關信息進行建模。利用該配置文件對系統進行建模，可以模擬以及管理系統的風險。文獻[18]提出了SecureUML配置文件，用于傳達軟件系統安全問題。它用于模擬基于角色的訪問控制，以記錄系統中用戶和實體的訪問權限。構造型可以對這些資源執行的角色、資源、動作進行建模，以及授權約束（使用邏輯謂詞建模）。周書華等人在文獻[19]中對SysML進行擴展來支持兼容Modelica的設計建模，最后實現了SysML與Modelica模型的自動轉換，使得設計人員得以將設計模型自動轉化為系統仿真模型進行仿真。曹德建等人[20]提出了一種將故障樹分析擴展到SysML活動圖模型的方法以及故障擴展SysML活動圖的概念，統一了系統功能模型與安全需求分析模型。黃傳林等人[21]提出一種結合MARTE語義信息的擴展SysML活動圖模型，用于描述安全關鍵應用中的嵌入式系統動態行為的設計，設計了一個基于AMMA平臺的面向擴展SysML活動圖的模型轉換與驗證框架。

與本文工作相比，該類方法利用SysML的擴展能力致力于系統的建模與安全性分析，例如故障、風險分析等。其關注點在于系統建模和模型驗證，追蹤信息可能會被集成包含進系統模型，但缺少針對安全關鍵系統的特定追蹤信息捕獲以及專門用于表達追蹤信息的模型。而本文重點則在于建模過程中追蹤信息的捕獲，以及專門用于表達追蹤信息的模型生成。

總結如下，現有的SysML擴展工作可主要分為兩類：一類旨在擴展模型語義或者結合形式化方法，進行系統安全性分析；另一類則不側重于形式化方法的使用，而旨在信息的存儲以及表達。本文聚焦于建模過程中的追蹤信息捕獲以及追蹤信息的表達，本質上即通過擴展使SysML模型具備存儲特定追蹤信息的能力，可為后續安全性分析提供數據支持。本文配置文件的主要擴展內容如表1所示。

Table1 Main extension elements in profile表1 配置文件中主要的擴展元素

5.2 需求追蹤關系的建立

關于需求追蹤關系的建立方法，從事先和事后角度進行分類，主要有基于信息檢索的事后恢復和基于模型驅動的事先建立方法。

基于信息檢索的可追蹤性恢復，主要利用IR模型計算需求文本與其他文本制品的相似度，然后通過設定閥值進行篩選，重新建立不同制品間的追蹤鏈。

目前已有很多的模型采用IR的技術恢復追鏈接。文獻[22]表明，該類型的可追蹤鏈恢復過程與手動方法相比，明顯更快，追蹤鏈的準確性也得到了一定的提升。但是，最終開發者仍然需要做出關于候選鏈接有效性的最終決定。文獻[23]利用自然語言文本的語法特性，分析需求文檔和用例的語法結構，標注句子成分，根據制定的規則進行關系匹配。

在模型驅動的軟件工程中，模型轉換、代碼自動生成等技術可以隱式地自動建立和維護軟件設計模型、軟件設計和代碼之間的追蹤關系。

目前有一些方法嘗試將需求轉換為UML或XML的形式化表達，然后實現一定程度的追蹤鏈生成自動化。文獻[24]提出一種稱為REQDL（requirement description language）的領域特定語言用于描述需求，同時捕獲雙向的追蹤信息并利用模型轉換自動生成追蹤模型。該文獻側重于構建新的需求描述語言，用于需求建模。文獻[25]提出了一種半自動方法，用于維護需求和UML制品之間的追蹤鏈，該方法基于捕獲建模工具中的事件流。但該方法只可用于處理基于事件的UML制品，而本文的方法可以處理SysML中原有的所有結構以及行為制品，并具備將這些制品綁定到利益相關者的能力。

本文采用模型驅動的方法。不同于信息檢索方法的追蹤鏈的事后恢復，本文致力于追蹤關系的事先建立。在基于信息檢索的方法中常見問題為追蹤鏈的錯誤恢復，即兩個制品間本不存在追蹤關系，經過信息檢索方法處理后卻建立了追蹤鏈，該追蹤鏈即為一個錯誤恢復的鏈接。安全關鍵系統要求高安全高可靠，而利用信息檢索方法恢復的追蹤鏈存在以上錯誤恢復的情況，因此信息檢索方法不能很好地適用于該類系統的追蹤關系建立。本文方法正向建立追蹤關系，即首先進行需求分解和追蹤關系的指派，再進行制品的設計，理論上將不會存在錯誤建立的追蹤鏈（需排除人為指派錯誤的影響）。此外，在完成建模后可支持進一步采用模型檢測（model checking）、形式化方法（formal method）等技術進行模型的驗證以及分析，可以幫助開發者在開發早期發現問題，保障系統的安全性。

6 結束語

在航空航天等安全關鍵領域，嵌入式系統的需求追蹤信息缺失將導致后期維護的困難加大，更可能直接導致由于需求未被滿足而引發重大安全性事故。本文針對這一問題展開研究，給出了一種基于模型驅動工程的方法，用于安全關鍵系統中需求追蹤的事先建立。通過對SysML配置文件的擴展、追蹤元模型的構建以及模型轉換技術的使用實現了追蹤模型的自動化生成。該追蹤模型提供了需求與設計制品間的追蹤能力以及從需求向前追蹤的能力。

未來的工作將著重于需求到代碼的可追蹤性研究以及追蹤信息粒度的細化。