この連載では、2025年にリリースされたシステムモデリング言語SysML v2を取り上げ、業界での利活用に乗り遅れないために基本的な情報や新しい構成要素の紹介、今まで使っていたSysML v1とv2の変換などを紹介していきます。第五回は「VerificationCase」を紹介します。

SysML V2の新しい構成要素やその使い道を知る: VerificationCase

※本稿はSysML v2 beta4の仕様を参照して記述しています。

今回はVerificationCaseの紹介をします。 SysML v2にはCaseという概念が導入されました。SysML v1にもあったUseCaseや、今回紹介するVerificationCaseもCaseのサブクラスです。 Caseとは、ある目的（objective）をもって、特定の対象（subject）に対して行う評価・検証・分析の枠組みです。日本語で一般に言う「こういうケースは～」の”ケース”に近いイメージです。

この記事では、それ自体を使うことの少ないと思われるCaseや、SysML v1の頃から存在したUseCase(仕様は変わりましたが)ではなく、SysML v2で新たに出てきたVerificationCaseに着目します。

VerificationCaseは「テスト・検証」を記述するSystems Libraryの一種です。テストの目的、対象、検証パス条件などをモデリングできるようになったことで、システムモデルに対する検証の自動化やCI/CDの活用が期待できます。

「検証」を扱う都合上、説明に出てくる事項が多いため最初にこれらを説明します。下図はVerificationCaseを考える時に関係する事項とその関係性をモデリングしたものです（VerificationCaseを用いたモデリング例ではありません）。「テストケース」には「テスト対象」と「テストの目的」が紐づいていること、また「テストの目的」は「要求」に関連付けられることを示しています。

モデル例

このサンプルは SysML v2 リファレンス実装（Systems-Modeling/SysML-v2-Release）の一部を改変したものです。 ライセンスは GNU Lesser General Public License v3.0 (LGPL-3.0) に基づきます。

今回のサンプルモデルは（仕様が難解なこともあり）SysML v2仕様書といっしょに公開されているサンプルモデルをベースにしています。ここからはモデルの各要素の意味を説明していきます。

冒頭で説明した通り、VerificationCaseでは以下をモデリングします。後に示すサンプルモデルも、これらの要素をモデリングしています。

• テストの目的（objective…Requirementに関連付けて）
• テスト対象（subject…典型的にはPartとして）
• 期待する出力・検証パス条件（VerificationCases::PassIf）
  • PassIfはSysML v2標準ライブラリに定義された関数で、式が真ならPassと評価されます（現在のところVerificationCasesの関数はこれ一種類のみのようです）。

加えて、以下の要素も定義しています。必須ではないものも含めて次のような意味で記載していきます。

• Verification def VerificationCase：各テストケースの定義。必須。
• Verification def VerificationPlan：複数のテストケースを束ねたテスト計画。大規模なテストの定義に用い、ツールによる一括実行などに活用する想定。
• Part verificationContext：テストの実行対象となる実体(subject)を決めるコンテキスト。ツールによるテスト自動実行にあたりテスト対象を定義する用途を想定。

今回のサンプルモデルは「検証」を扱う都合上規模が大きいため、順を追って説明します。参考までに全体像を掲載しますがこの規模になると一枚絵では読むのが難しいと思います。

①テストの目的…要求モデルの定義

まず要求を定義します。要求のモデリングについて詳細は本連載の第四回を参照してください。

今回は「車速リミッター要求」と「デイタイムランニングライト要求」について、それぞれ各国法規に則った要求が定義されているイメージです。なお、デイタイムランニングライト要求は、日中でも自動車のライトを点灯する機能に関する要求です。実際には複数国向け仕様をバリエーションとして定義することが多いと思いますが、今回は「日本」のみを定義しました。

package Requirements {
  doc /* 要求定義 */
  import LogicalDesign;
 
  requirement def SpeedLimiterRequirement {
    doc /* 国ごとの車速リミッター要求 */
    attribute country;  //国
    attribute speedLimit;  //最高速度
    subject roadVehicle : LogicalDesign::Vehicle;  //要求が掛かる対象
    require constraint{ roadVehicle.speedLimiter <= speedLimit  } //要求が満たすべき制約
    
  }
  requirement spdLmtReq_JPN : SpeedLimiterRequirement{
    doc /* 日本国の車速リミッター要求 */
    redefines country := "JPN";
    redefines speedLimit := 180;
  }
  
  requirement def DaytimeRunningLightRequirement {
    doc /* 国ごとのデイタイムランニングライト要求 */
    attribute country;  //国
    attribute ability;  //有効/無効
    subject roadVehicle : LogicalDesign::Vehicle;  //要求が掛かる対象
    require constraint{ roadVehicle.daytimeRunningLight == ability  } //要求が満たすべき制約
    
  }
  requirement drlReq_JPN : DaytimeRunningLightRequirement{
    doc /* 日本国のデイタイムランニングライト要求 */
    redefines country := "JPN";
    redefines ability := "disabled";
  }
}

②テスト対象…設計モデルの定義

次に要求を満たす設計モデルを定義します。設計モデルに用いているPart要素の詳細は本連載の第二回を参照ください。

今回は要求に応える形で「車速リミッター速度」「デイタイムランニングライト有効/無効」の設計値を持つpart要素を定義しました。

package LogicalDesign{
  doc /* 論理設計モデル */
  part def Vehicle {
    attribute speedLimiter;  //車速リミッター速度
    attribute daytimeRunningLight;  //デイタイムランニングライト有効/無効
  }
  part vehicle_JPN : Vehicle{
    doc /* 日本国向け車両 */
    attribute redefines speedLimiter := 180;
    attribute redefines daytimeRunningLight := "disabled";
  }
}

③テストケースの定義

いよいよ本題のVerificationCaseを使っていきます。まずはテストケースを定義します。テストケースはverification defとして定義します。中身にはテスト対象(subject)、テストの目的(objective)、テストのパス条件(VerificationCases::PassIf)を定義しています。

package VerificationDefinitions{
  doc /* テストケースの定義 */
  import LogicalDesign;
  import Requirements;
  verification def SpeedLimiterTest_JPN {  
    doc /* 日本向け車両の車速リミッターテストケース定義 */  
    subject tgtVehicle : LogicalDesign::Vehicle;  //テスト対象
    objective {
      verify Requirements::spdLmtReq_JPN;  //テストの目的（テストする要求）
    }
    VerificationCases::PassIf(Requirements::spdLmtReq_JPN(roadVehicle = tgtVehicle))  //テストのパス条件
  }
  verification def DaytimeRunningLightTest_JPN{
    doc /* 日本向け車両のデイタイムランニングライトのテストケース定義 */
    subject tgtVehicle : LogicalDesign::Vehicle;  //検証される要素
    objective {
      verify Requirements::drlLmtReq_JPN;  //検証する要求
    }
    VerificationCases::PassIf(Requirements::drlReq_JPN(roadVehicle = tgtVehicle))  //検証パス条件
  }
}

なお今回は省略していますが、より詳細なテスト手順を定義することも可能です。例えば、データ取得、データの計算、評価、評価結果の出力といったステップに分けて記述できます。

④テスト実行方法の定義

テスト実行方法をモデリングすることも可能です。ただしこのモデルは人間にとってのうれしさはあまりないと思います。

まずはverification def VerificationPlan_JPN要素の説明です。この要素は複数テストケースを束ねたテスト計画です。子要素としてverification usageを定義し(verificationCase1,2)、これらがひとまとまりで実行されるテストケース群となるイメージです。

次にpart verificationContext要素の説明です。テスト対象の実体を用意します。この箇所は意図がやや分かりにくい部分ですが、ここでいう“実体”は「型に対するインスタンス」といった抽象的な話だけでなくおそらく具体的な実物（自動車で言えば個車情報）までも含むと考えられます。今後のツールの整備などにもよりますが、具体的な実物（に紐づいたモデル要素）を指定することで、生産段階で個別製品に対する試験までもモデリングし自動実行することを想定しているのかもしれません。

package VerificationExecution{
  doc /* 検証実施方法の定義 */
  import LogicalDesign;
  import Requirements;
  import VerificationDefinitions;
  
  verification def VerificationPlan_JPN {
    doc /* 複数テストケースを統合したテスト計画 */
    subject tgtVehicle : LogicalDesign::Vehicle;
    objective {
      verify Requirements::spdLmtReq_JPN;
      verify Requirements::drlReq_JPN;
    }
    verification verificationCase1 : VerificationDefinitions::SpeedLimiterTest_JPN;
    verification verificationCase2 : VerificationDefinitions::DaytimeRunningLightTest_JPN;
  }

  part verificationContext {
    doc /*テストの実行対象となる実体(subject)を決めるコンテキスト */
    verification verificationPlan : VerificationPlan_JPN {
      subject tgtVehicle = LogicalDesign::vehicle_JPN;
    }
  }
}

VerificationCaseのうれしさ

設計、テストケースと要求のトレーサビリティ確保

SysML v1で設計、テストケースと要求のトレーサビリティを取る方法は、主に割り当て(allocate)によってそれぞれのモデル要素を関連づけることでした。SysML v2のVerificationCaseでは各要素のトレーサビリティがそれぞれ別のキーワードで定義されており、意味が具体的になりました。

ツールによるテスト実行、管理の自動化

SysML v2仕様に準拠した各種ツールが連携することで、例えば次のような自動化が期待できます。

• 要求の変更に伴うテストケース変更の自動化（例：要求管理ツール）
• 設計変更時または毎日のテスト実行、テスト管理の自動化（例：CD/CIツール）
• 要求および設計モデルからテストケースを自動生成（例：形式検証ツール）

従来もこういった機能を持つツールは存在しましたが、それぞれのツールの定めたルール通りにモデルを作らないといけないことが大半でした。SysML v2のVerificationCaseでは言語仕様通りに作ったモデルをそのままツールに掛けることが可能になると期待できます。

次回予告

次回は、原因と結果を記述できるCause & Effectについて紹介します。安全系の検討に活用できそうです。