汎用グラフィカルモデリング言語「SysML」 パート1: 要件、ユースケース、およびテストケースのモデリングThe Rational Edge(3/3 ページ)

» 2006年09月22日 12時00分 公開
[Laurent Balmelli博士(IBM T.J. Watson東京研究所 リサーチスタッフメンバー),@IT]
前のページへ 1|2|3       

◆ 要件ダイヤグラム

 上述のように、開発ライフサイクルのコンセプト段階は、製品要件へと進化する顧客のニーズ分析とは分離している。要件は従来から、テキストと、しばしば図表を交えて描写され、ファイルあるいはデータベースに保管されていた。これらの要件は、製品の機能すべてのほか、その機能を実現する際の制約も記述している。

 SysMLでは、要件をモデルの要素として描写できるようになる。従って、要件は製品アーキテクチャにとって欠くことのできない部分になる。同言語は、テキストベースのあらゆる特性の要件(機能要件あるいは非機能要件など)と、それらの間のリレーションを描写する柔軟な手段になる場合が多い。図3にRSWの要件ダイヤグラムを示す。

ALT 図3 雨滴検知ワイパーシステムのSysML要件ダイヤグラム (クリックすると拡大

 要件ダイヤグラムには、機能要件と非機能要件の両方があることに注意したい。SysMLにおける要件は、オペレーションも属性もない抽象的な分類子だ。つまり、これらはインスタンス化することができない。にもかかわらず、要件ステレオタイプに属性を登録することで要件の要素に属性を登録することはできる。ステレオタイプの属性を使えば、これらの属性に設計時に値を割り当てることができるようになる(注1)。要件はアソシエーションもしくはジェネラリゼーションに参加することができない。しかし、あらかじめ定義された一連のリレーションがあれば、要件間のリレーションを描写する際に役立つ。これらのリレーションについては以下で解説する。


[注1] 分類子属性にクラスの値を割り当てる選択もあるが、分類子属性には実行中に値を保持する役割もあり、これはSysMLにおける要件の意味と矛盾する。


 サブ要件は、ネームスペースが埋め込まれていることを示す十字のリレーションを使って、その親要件と関連付けられる。例えば図3では、Automatic Wiping要件のサブ要件の中に、この十字を使って接続されているものがいくつかある。親要件は、組み込み要件のパッケージになっている。このようなことから、親要件を削除すると組み込み要件はすべて自動的に削除される。ほかの要件のパッケージとして機能している要件のもう1つの例が、2つのサブ要件を含むCore Functions要件だ。モデルを見やすくするために、ユーザー定義キーワードである「パッケージ」は、要件ステレオタイプの横に置いている。

 要件分析(例:分解やフローダウン)の中では、新しい要件が派生により作成される。これらの新しい要件は、DeriveRqt依存を使って最初のものに接続することができる。例えば、図3では、製品のコア機能セットがAutomatic Wipingの下で一連の要件から派生している。DeriveRqtという名前が選ばれたのは、UML 2.0標準のDerive依存との混同を回避するためだ。派生した要件の例としてはほかに、各機能の技術的な選択肢がある(図3のTechnical Choicesボックス参照)。設計者が、センサーをフロントガラスに固定した理由をRationaleのコメントを使って説明していることに注意したい。派生した要件の最後の例としては、System Calibration品質要件がある。これは、システムを調整する必要があることを述べている。これが、RSWにあの忌まわしい障害が発見された後から製品に追加された要件だ。この要件を満足させれば、センサーやフロントガラスの特性に変化があっても製品が確実に対応できるようになる。

 要件間にあるもう1つのリレーションがRefineだ。絞り込み要件の例は図3に示されている。速度作動要件は、低、中、高といった速度を選択することで絞り込むことができる。最後に、一般的なTrace依存は、一組の要件に何らかの形のリレーションがあることを強調するのに利用できる。図3では、手動停止の要件を自動停止のところまでトレースすることができる。

 要件には、これまで解説してきたリレーションのステータスを保存する多数の派生属性がある。本稿のパート2で解説するが、要件のリレーションが要件ダイヤグラムの外で描写されている場合はこれらの属性が特に便利になる。

 要件は、製品のライフサイクル全体から引き出されることも多く、これらを描写するために新たな要件ダイヤグラムが利用される。従って、製品の要件は一連の要件ダイヤグラムで詳細に説明されるのが一般的だ。

 SysMLは、機能要件と非機能要件の両方のモデリングを可能にする要件のジェネリックモデルを提供する。標準以外の一連の要件タイプはOMG SysML仕様の付録で提唱されている(注2)。特定のタイプの要件(タイミングやスケジューリングなどに関連するもの)は、言語拡張によって処理が行われる。SysMLは、プロファイルメカニズムをサポートすることで言語を拡張する。OMGでは、パフォーマンスや品質に関連する非機能要件のモデリングに関する特定のニーズ(注3)(注4)や、テストケースのモデリング(注5)に対応した一連のモデリング標準をリリースしている。これらのプロファイルは、一切制限を受けずにSysMLで利用することができる。


[注2] 「SysML 1.0 Specification (ptc/06-05-04)」のOMG最終採用仕様はhttp://www.omgsysml.org/を参照。

[注3] 「UML Profile for Modeling QoS and Fault Tolerance Characteristics and Mechanisms (ptc/04-06-01)」のOMG最終採用仕様はhttp://www.omg.org/docs/ptc/04-06-01.pdfを参照。

[注4] 「[STP] UML Profile for Schedulability Performance and Time (ptc/05-01-02)」のOMG最終採用仕様はhttp://www.omg.org/technology/documents/formal/schedulability.htmを参照。

[注5] 「UML Testing Profile (ptc/05-07-07)」のOMG最終採用仕様はhttp://www.omg.org/technology/documents/formal/schedulability.htmを参照。


◆ ユースケースダイヤグラムとテストケース

 SysMLは、UML 2.0から受け継いだユースケースダイヤグラムを無修正で提供している。RSWが持つ主なユースケース(楕円)と一緒に外部アクター間のやりとりを図4に示す。

ALT 図4 雨滴検知ワイパーシステムのSysMLユースケースダイヤグラム (クリックすると拡大

 このユースケースダイヤグラムは3つのアクターを示し、これらをそれぞれのユースケースに接続している。「Automatic Wiping」と呼ばれる中央のユースケースは、一連のサブユースケースによって構成されている。また、階層リレーションはInclude依存によってモデリングされている。

 SysMLは、テストケースを描写し、これを関連する要件やユースケースに結び付けることもできる。テストケースには、操作と動作モデル(インタラクション、ステートマシン、もしくはアクティビティ)の両方がある。

 図5および図6は、RSWのテストケースを示している。このテストケースは、System Calibration要件を確認している(図3)。これは次のようにして実現される。

 最初に、異なるコンポーネント(センサー、フロントガラス、ソフトウェアコンフィギュレーションファイル)の特性を取り出す。

 次に、互換性を評価するため、これらの特性を使ってセンサーとフロントガラスの作動範囲を計算する。センサーとフロントガラスが適合すればテストケースは成功だ。そうでない場合は警告が出る。アクティビティダイヤグラムの中にあり、各手順に貢献するアクションは、見やすくするために四角で囲ってある(図5参照)。

ALT 図5 System Calibration品質要件のSysMLテストケースダイヤグラム。テストケースがアクティビティダイヤグラムによって実現されている (クリックすると拡大)

 この例では、異なるコンポーネントに関連した成果物を格納するレポジトリに対し、一連のWebサービスを使ってアクセスを行うことで最初の手順が実現されている(図5の左端の四角を参照)。正確には、センサーやフロントガラスの特性を知るために、原材料部品一覧表(製品データ管理システムなどに保存されているもの)に対して問い合わせが行われる。そして、ソフトウェアコンフィギュレーション管理システムなどからコンフィギュレーションファイルが取り出される。

 2番目の手順(図5の中央の四角を参照)は、SysMLパラメータダイヤグラムの中でセンサーとフロントガラスの属性に対する制約を定義することで実現される。これらのダイヤグラムの構成については本稿のパート2で解説する。

 図6では、テストケースの実行に必要なWebサービスなどの各種機能のプロトタイプをホスティングするためにテストコンテキストが作成されている。このコンテキストは、要件の部分までトレースすることができる。(本稿のパート2で解説する)アクティビティダイヤグラムは、このテストコンテキストの機能を使って実行する。

ALT 図6 System Calibration品質要件のSysMLテストケースダイヤグラム:要件とテストケースのトレーサビリティ (クリックすると拡大

 今月のパート1では、SysMLを簡単に紹介し、要件、ユースケース、テストケースのモデリングを行う機能の概要を説明した。次回は、これらの要件を満足させる製品構造を作成する際のSysMLの使い方と、そのアロケーションメカニズムの使い方を解説する。


本記事は「The Rational Edge」に掲載された「An overview of the Systems Modeling Language for product and systems development -- Part 1: Requirements, use-case, and test-case modeling」をアットマーク・アイティが翻訳したものです。


「The Rational Edge」バックナンバー
前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ