基于SysML模型的需求建模及測試方法

黃 晨，于 倩，左萬娟，陳華南，王小麗

(1. 北京控制工程研究所，北京 100190； 2. 北京軒宇信息技術有限公司，北京 100190)

航天領域星船系統受限于資源的局限性，大多數系統為嵌入式系統，嵌入式系統具有強實時性等特點，對系統時序的要求和限制非常嚴格，部分設計受限于系統硬件資源，需要軟硬件協同高效配合來保證系統的正確性，系統的任務執行時間、 功能的計算時間、 響應時間等都是通過時間約束來保證[1]，因此時間性能指標的測試是系統測試非常重要的一項測試內容. 在測試時，應考慮和測試各種場景的系統運行情況，如系統負載最大，多任務并發訪問，執行路徑深度最大等等. 傳統的嵌入式系統測試都是采用非形式化的需求規格說明，由人工進行分析后形成非形式化的自然語言描述的需求，這種方式成本較低，但是容易產生歧義，不容易發現需求遺漏，很多問題通常是在設計、 測試的后期才能發現. 基于模型的測試方法通過測試左移，能夠更早地發現系統設計、 需求分析中存在的問題，以及不完整性、 模糊性和不一致性[2]. 使用建模語言進行需求建模，能夠將抽象數學模型轉化為易于理解和可以描述的通用性語言，如UML統一建模語言[3]，Perit網[4]等. 系統大部分功能都可以采用建模的方式進行描述，再通過形式化的方法驗證模型的正確性[5,6]，并根據模型自動生成測試用例[7]. 基于UML的狀態機圖、 活動圖、 時序圖等各種圖形化的建模語言已經在系統需求分析中得到廣泛應用，文獻[8]采用SysML狀態圖表示系統的行為模型，通過體系結果和業務需求對行為模型進行驗證. 為實現基于模型的測試有效投入工程應用，需要建立能夠覆蓋嵌入式系統各項測試類型的需求模型，本文用建模的方式描述系統的運行場景和需求，針對與時間相關性能指標的模型給出分析方法，說明應如何分析和建模，基于多種覆蓋準則可由模型自動生成性能測試的用例集，以滿足性能測試要求.

1 建模語言及表示方法

1.1 SysML建模語言

目前，從建模語言的表示形式大致可以分為3種類型： 非形式化、 半形式化、 形式化. 非形式化方法是指采用自然語言描述的方法，這種方法描述系統需求相對比較簡單，但是如果描述不清楚，會存在二義性，并且容易遺漏需求； 半形式化方法是一種受限制的描述方法，采用自然語言加特定的符號進行描述，可以是一種帶有受限制句子結構和具有特殊意義的關鍵字的自然語言或圖表. 這種方法相對于自然語言更加形式化； 形式化方法是一種基于數學的形式化描述語言，優點是能夠提高描述的正確性，減少二義性和不一致性，增強可讀性，缺點是表示極為復雜. 系統建模語言SysML(Systems Modeling Language)是目前國際上系統工程領域最新的標準建模語言，是統一建模語言UML在系統工程領域的延伸和擴展，是一種半形式化的圖形建模語言，使用自然語言描述約束和詳細語義，是對象管理組織OMG在對UML2.5的子集進行重用和擴展的基礎上，針對系統工程領域中系統設計與建模的特點，提供了可視化、 圖形化的系統建模支持語言，廣泛應用于復雜系統建模，涵蓋了從系統需求到設計階段的各項要求，廣泛運用于航空航天軟件開發過程[9]. 基于MOF定義的4層元模型結構，SysML建模語言位于元模型層，在元模型層定義的抽象語法的基礎上，定義了模型描述語言的模型，提供了表達系統的各種包、 模型元素的定義類型、 標記值和約束等，它與特定的應用領域有關. 元模型為SysML的所有元素在語法和語義上提供了簡單、 一致、 通用的定義性說明，使開發在語義上取得一致，在一定程度上消除了人為表達方式所造成的影響[10]. 通過ISO-AP233數據交換標準和XMI模型交換標準，語法上支持各種系統工程工具之間的互操作[11]. SysML為系統提供定了4種類型模型和9種圖的完整語義. 4種類型是： 結構模型、 行為模型、 需求模型和參數模型； 9種圖是： 模塊定義圖、 內部模塊圖、 包圖、 活動圖、 序列圖、 用例圖、 狀態機圖、 參數圖和需求圖. 結構模型強調系統的層次以及對象之間的相互連接關系，包括類和裝配. 行為模型強調系統中對象的行為，包括它們的活動、 交互和狀態歷史. 需求模型強調需求之間的追溯關系以及設計對需求的滿足關系. 參數模型強調系統或部件的屬性之間的約束關系.

1.2 狀態機圖

狀態機圖主要描述一個特定對象的所有可能狀態以及由于各種事件的發生而引起的狀態之間的轉移. 可以清晰描述對象之間是如何交互和通信的，尤其是通信發送消息的時間關系非常清晰. 狀態機圖有一個或多個狀態，零個或多個轉移組成. 狀態和轉移描述了一個對象在其生命周期里的行為. 狀態是對象生命周期中的一個條件或狀況，在此期間對象滿足某些條件，執行某些活動或等待某些事件. 狀態機圖是Harel的經典狀態圖的變體，狀態機圖的處理原則是，在下一個時間處理之前，必須保證上一個事件已經被處理完畢； 當發生轉移沖突時遵循底層優先的策略，轉移所在層次越低，執行優先級越高[12].

1.2.1 抽象語法

本文所指的狀態機為行為狀態機，通過類圖的方式表示狀態機類元之間的關系，用來描述狀態機圖的抽象語法. 狀態機類元包括： 狀態機、 區域、 節點、 轉移、 觸發、 約束、 參考連接點、 偽狀態、 狀態、 行為等，這些類元之間存在的關系包括： 關聯、 繼承、 復合等.

圖1 狀態機類元抽象語法

1.2.2 圖元符號及含義[12]

對狀態機圖的基本圖元語義進行解釋說明.

1) 狀態(State)

是指在對象的生命期中的一個條件或狀況，在此期間對象將滿足某些條件、 執行某些動作或等待某些事件.

每個狀態可以沒有或者由多個活動組成，這些活動都是非原子活動，在執行過程中可被中斷，可以表示為

〈behavior-type〉[′ /′〈behavior-expression〉],

(1)

其中，behavior-type行為類型是行為發生的場景，有3種：

entry： 進入當前狀態時執行的動作；

do： 在當前狀態下，一個持續進行的動作或行為，或者特定表達式；

exit： 退出當前狀態時執行的動作.

狀態可以分為3類： 簡單狀態、 復合狀態和子機狀態.

簡單狀態(simple State)是指其中沒有嵌套狀態的狀態，可以分為3個分區： 命名分區、 內部行為分區和內部轉移分區.

復合狀態(composite State)： 至少包括一個區域，可以是只有一個區域的簡單復合狀態，可以是具有多個區域的正交狀態.

子機狀態(submachine State)： 指的是整個狀態機，認為它是在狀態中嵌套的.

2) 偽狀態(PseudoState)

偽狀態是指包含多種類型暫態節點的抽象概念. 偽狀態主要用于連接多個轉移組成更加復雜的復合轉移. 偽狀態包含多種類型，有初始狀態、 終止狀態、 淺歷史狀態、 深歷史狀態、 分叉、 合并、 選擇、 連接、 進入點、 退出點、 終止[13].

3) 轉移(Transition)

狀態機模型中的轉移元素屬于非常重要的元素之一. 是兩個狀態之間的一種關系，它指明對象在第一個狀態中執行一定的動作，并當特定事件發生或特定的條件滿足時進入第二個狀態，轉移描述了一個或者多個狀態之間是如何發生轉換的. 轉移也存在優先級，轉移可以沒有或者有多個事件，一個事件對應一個觸發，觸發能夠導致狀態的轉移. 連接源狀態和目標狀態之間的弧線就是轉移，可以表示為如下形式

{〈trigger〉}*[′ [′〈guard〉′]′]

[/〈behavior-expression〉] ,

(2)

其中，trigger是觸發事件，表示在時間和空間上占有一定位置的有意義的事件. 轉移可以沒有觸發事件或者有多個事件. 分為4類： 信號事件(信號用于對象間異步傳遞的信息包，它沒有任何操作，只有自身攜帶的信息，通過信號來觸發，有接收信號事件和發送信號事件)、 調用事件(請求在類語境的實例上調用特定的操作)、 時間事件(相對時間關鍵字after說明事件被觸發的臨界時間，絕對時間關鍵字at)和改變事件(關鍵字when說明事件改變所滿足的條件). 多個觸發事件時間采用‘,’進行連接.

guard表示守護條件，是一個布爾表達式，如果表達式值為真，則轉換可以發生； 如果表達式為假，則轉換不能發生. 每一個轉移可以沒有或者有多個守衛條件.

behavior-expression表示由匹配觸發的事件和守衛條件滿足后發生的事件所造成的特定影響，是一個行為表達式，可以不寫.

轉移有3種類型： 外部轉移，局部轉移和內部轉移.

外部轉移： 指轉移從其源頂點退出，如果頂點為狀態時，轉移的發生會導致執行相關狀態的退出動作.

局部轉移： 與外部轉移相反，轉移不會從包含它的狀態中退出，轉移發生時包含局部轉移的狀態的退出動作不會執行，但是，局部轉移的源頂點和目標頂點不能相同，只能應用于復合狀態.

內部轉移： 是局部轉移的一種特殊情況，也叫作自轉移，具有相同的源頂點和目標頂點. 當這種轉移執行時，不會執行入口和出口動作. 內部轉移只能用于狀態頂點.

1.2.3 形式化語義

在此采用形式化方法定義狀態機語法，狀態機多元組表示為[14]

STD=(S,B,ε,V,P,N,X,D,subStates,T),

(3)

其中，S表示狀態的集合，包括偽狀態；B表示行為描述的集合；ε表示事件的集合；V={V1,…VNv}表示Nv(Nv∈Ν)變量的集合；P：S→Pr將每個狀態關聯上屬性Pr={簡單非終止狀態，復合狀態，終止狀態，初始狀態，歷史狀態}；N∶S→((B∪{?})×List(F))將每個狀態關聯入口行為；F表示對應變量V的指定函數列表；X∶S→((B∪{?})×List(F)關聯退出行為的狀態；D∶S→((B∪{?})×List(F))關聯do行為的狀態；subStates：S→2s關聯每個狀態直接子狀態的集合；T表示狀態轉移t的集合，t=(S1,e,g,(b,f),sLevel,S2).S1,S2?S，分別表示源狀態和目標狀態，約束限制條件為：S1和S2僅包含一個狀態(兩個狀態之間的轉移)，或者超過1個狀態(合并和分叉轉移)； 如果S1或者S2包含超過一個狀態，復合狀態不同區域的直接子狀態必須要有一個直接子狀態，復合狀態不能有比狀態還要多的區域個數；e∈ε∪{noEvent}，noEvent表示沒有觸發事件的轉移；g是守衛條件，表示V中變量的布爾表達式； (b,f)∈((B∪{?})×List(F))表示觸發轉移后會執行的行為動作；sLevel∈S為包含轉移的狀態優先級，屬于S1∪S2的任意狀態，都屬于sLevel的子狀態.

2 需求建模及用例生成

在工程應用中，性能測試是嵌入式系統測試過程中必測的、 非常重要的一個測試類型，各項性能指標的確定與系統設計要求緊密結合，功能中如果涉及到時間相關指標要求的，應作為性能指標進行測試，并分析系統的設計是否滿足時間設計要求. 嵌入式系統軟件任務正常執行過程中被外部中斷事件打斷的場景、 看門狗喂狗最長時間間隔的測試、 某系統初始化時間最大值的測試、 以及隱含性能需求等，都應作為性能指標進行測試.

2.1 測試要求

嵌入式系統的性能指標一般包括以下幾方面測試要求：

1) 時間間隔： 是指系統在進行兩個處理操作之間需要保證的時間間隔. 嵌入式系統一般存在設計下限或者上限的指標要求.

2) 處理時間： 系統進行某個處理或者某一系列操作的時間要求. 嵌入式系統受限于軟件嚴格的時序設計，如果處理時間超過限制，會導致后續處理不及時，丟失外部指令等情況發生. 對于并發訪問時也需要通過嚴格的時序設計保證系統運行的正確性，因此也存在類似的指標要求，例如中斷函數處理時間的要求.

3) 響應時間： 是指從接收到某個事件，到做出反應的時間. 要求能及時反應外部事件的請求,在規定時間內完成對該事件的處理，并控制所有實時設備和實時任務，協調一致地運行.

2.2 測試方法

目前，嵌入式軟件時間性能指標的測試通常是采用代碼插樁和人工分析相結合的方式，系統運行受限于當前運行工況和場景，代碼執行的路徑無法完全確定和預知，很多時候需要統計軟件在最深的執行路徑或最大強度負載情況下的運行情況，或者統計所有工況下的某段時間性能實測值，取多次測試的最大值、 最小值或者平均值作為實際測試結果.

采用圖形化的建模語言、 描述方式能夠非常清晰，明確的表示需求的物理意義和處理邏輯. 在測試系統性能時，分析方法如下：

1) 時間間隔測試： 狀態機模型中的時間類型事件需要作為時間性能指標進行測試,所建立的需求模型中存在after(x)的時間類型轉移事件，均應作為性能指標測試，如果出現when，at等事件類型的關鍵字時，也需要注意是否需要作為性能指標進行測試.

2) 處理時間測試： 可以統計測量連續兩次發生同一個狀態的時間間隔或者處理時間.

3) 響應時間測試： 構造極限和極大強度負載運行場景，測試軟件響應某個事件的響應延遲時間.

2.3 用例生成

根據建立的性能需求狀態機模型，提取其中生成測試用例所需的信息，生成測試用例. 首先生成抽象測試操作序，再將抽象路徑與時間或者狀態、 操作關鍵字、 數據等進行關聯，生成實際的測試用例. 根據轉移上的事件作為測試輸入，狀態中執行的動作作為預期輸出，建立從需求到用例設計的對應關系.

生成的抽象測試序的完備性決定了測試用例覆蓋的充分性，基于狀態機圖生成的操作序需要保證狀態覆蓋、 轉換覆蓋和路徑全覆蓋.

將狀態機圖中的狀態用數字進行編號，轉移用小寫英文字母編號，選取一條典型路徑，可以表示為1(a)2(b)3(d)4(e)1.

圖2 抽象序列執行路徑示意圖Fig.2 Abstract sequence execution path diagram

建立的模型如果是多層、 并發等更為復雜的情況下，通過人工方式篩選可達路徑也容易存在遺漏造成測試不充分，可通過靜態的數據篩選方式，生成所有可執行路徑，以保證各項測試的完備性和充分性.

3 建模實例分析

根據嵌入式系統的性能指標要求，采用建模的方式對性能需求進行描述.

3.1 時間間隔測試

需求描述： 某接口芯片采集模擬量為12 b AD芯片，芯片量程為0 V～10 V，數據轉換最大時間為35 μs. 片選地址為XXH，AD轉換啟動地址為XXH，寫0表示啟動AD轉換. 數據采集地址為XXH(8位有效，為采集12位數據的高8位)和(XX+1)H(高4位有效，為采集12位數據的低4位).

每路采集處理的過程如下：

A． 選通片選，向模擬選通地址XXH寫入片選信號；

B． 通過地址XXH或P口設置通道號；

C． 向地址XXH寫入0，啟動AD轉換器；

D． 等待一段時間35 μs轉換完成后，先從地址XXH讀取高8位結果、 讀取地址(XX+1)H內容高4位作為采集數據的低4位，拼接成12位有效數據作為采集結果.

E． 對AD采集數據進行補償處理，連續采集多次后進行濾波.

分析： 上述需求中要求從啟動AD轉換到轉換完成需要等待一段時間，約35 μs，軟件再讀取采集數據，保證AD芯片從接收到啟動信號到轉換完成有充足的時間.

性能指標要求： 從啟動AD轉換到開始采集AD數據之間的等待時間需要大于35 μs. 建立需求模型如圖3 所示.

圖3 時間間隔需求模型Fig.3 Time interval requirement model

測試場景： 測試軟件正常采集數據下，軟件兩個操作(向地址XXH寫入0，讀取地址XXH，(XX+1)H數據)之間的時間間隔最小值是否大于35 μs.

3.2 處理時間測試

受限于系統嚴格的時序控制，某段功能或者代碼的執行時間需要滿足一定的設計要求才能保證執行邏輯的正確性.

需求描述： 周期性觸發某外部中斷周期為100 ms，中斷服務子程序中設置遙測數據組織標志為真，看主程序中周期性進行判斷數據組織標志是否為真，是則進行遙測數據組織并發送，否則不組織發送.

分析： 軟件按照一定的時間間隔周期性執行主程序，如果主程序執行處理時間超過中斷的觸發周期，主程序還未及時處理中斷設置的遙測數據組織標志就接收到新的遙測數據組織標志，會導致少進行一次遙測數據組織發送.

性能指標要求： 主程序執行時間應小于100 ms. 選取主程序執行過程中的某個狀態，建立需求模型如圖4 所示.

圖4 處理時間需求模型Fig.4 Processing time demand model

主程序執行一次有可能會經歷不同的場景和狀態，圖4 的性能指標需要測試的是主程序的最大執行路徑，可以選擇狀態變化最多，或者選擇最為耗時的一個遷移狀態機作為當前性能測試的模型，也可以將主程序所有功能的狀態機圖，統計所有用例中相鄰兩個周期進入同一個狀態的時間間隔作為主程序的處理時間.

測試場景： 制造主程序執行過程中計算算法耗時最長，狀態轉移最多的場景，測試主程序連續兩次進入同一個狀態，執行同一個操作的最大時間是否小于100 ms.

3.3 響應時間測試

在測試時間最大值時，很難保證測試的場景是一條最大路徑，采用建模的方式能夠更容易分析所加負載最多的一條路徑是怎么觸發的，從而測試最長響應時間的測試場景.

需求描述： 軟件接收到某條指令并及時處理該條指令.

分析： 軟件通過中斷接收指令，將指令放入隊列緩存區，或者按照優先級排序，按照隊列的指令順序依次執行或者按照隊列中的指令優先級排序，優先執行高優先級指令.

性能指標要求： 軟件從接收指令到響應執行該指令需要保證在50 ms以內，否則，50 ms后接收到新的指令后，如果指令隊列長度有限，會回卷覆蓋之前的指令，導致舊的指令未執行就被新的指令覆蓋. 建立需求模型如圖5 所示.

圖5 響應時間需求模型Fig.5 Response time demand model

從圖5 模型中可分析得到： 在接收到新指令時，如果之前的指令隊列長度最長時，會導致當前新指令響應時間最長.

測試場景： 制造指令隊列長度最大值的場景，并在該場景下發送指令x，測試從接收到指令x到執行指令x之間的響應時間最大值是否小于50 ms.

4 結束語

明確SysML狀態機抽象語法，圖元符號和含義，對嵌入式系統典型性能需求進行測試，說明需求建模和用例生成方法，總結基于狀態機模型的3種性能指標測試方法，通過實例化方法建立模型，描述性能需求場景. 從工程化的角度將狀態機模型應用到實時嵌入式軟件測試過程中，覆蓋性能測試類型，未來還將繼續研究從狀態機模型中自動提取各種測試類型的方法，保證測試覆蓋性，實現模型驅動測試在航天領域的全面工程化應用，提升測試自動化程度.