汎用グラフィカルモデリング言語「SysML」 パート2
グラフィカルなモデル言語で製品構造を記述

IBM認定シニアプログラムマネジャー
Rose Ritchie
IBM認定シニアITアーキテクト
Bernie Michalik

2006/11/15

｜1　2｜次のページ

※ 本稿のパート2で使われている図は、パート1からの続き番号を使っている。

　本シリーズでは、システムエンジニアリング用標準モデリング言語の1つであるSysMLを紹介する。SysMLは、共通の言語を使ったコラボレーションにおいて、システムエンジニアとアーキテクトが切望する手法を提供する。SysMLは、製品デザインの電子化を実現することにより開発チーム内のコミュニケーションを改善し、システムの複雑な部分の管理を支援し、システム開発ライフサイクルの全フェイズにおいて意思決定の迅速化と効率化を推進する分析の基盤となることができる。

　パート1ではSysMLの基本的な目的と価値について解説し、Unified Modeling Language（UML）と結び付けて、要件ダイヤグラム、ユースケースダイヤグラム、そしてテストケースダイヤグラムについて説明した。パート2では、SysMLのストラクチャダイヤグラムと要件アロケーションメカニズムをカバーする。そして、パート3では、SysMLを使った製品機能のモデリングについて解説する。

　全3回にわたってお送りする本シリーズでは、SysMLで利用可能なすべてのダイヤグラムと、各ダイヤグラムと関連付けられた構成エレメントの大半を網羅する。筆者は本稿全体を通じて、自動車への応用例の1つである雨滴検知ワイパーの組み込みシステムを実例として用いている。

■ システムストラクチャの解説

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　雨滴検知ワイパー（RSW）のシステムストラクチャを構築するに当たっては、コストやパフォーマンスなど、利害関係者の懸念に基づいた要件エンジニアリングプロセスを通じて、サブシステムとコンポーネントの組み合わせは特定済みであると仮定した。

　SysMLは、「ブロック」と呼ばれる基本構造エレメントを提供する。これは、分野にとらわれない基盤部品をシステムに提供することを目的としたもの。ブロックは、機能的、物理的、人的など、あらゆるタイプのシステムコンポーネントの表現に利用できる。ブロックは、これらが集まることでアーキテクチャを形成し、システムの異なるエレメントの共存状態を示す。

　SysMLのブロック定義ダイヤグラム（BDD）は、UMLのクラスダイヤグラムに相当し、システムの構造を表す最も簡単な手法となっている。これは、分解されたシステムを結合や構成の関係を使って示す。BDDは、プロパティや動作といったブロックの機能を示すのに理想的だ。SysMLでは、ブロックが「ブロックプロパティ」や「分散プロパティ」といった特殊なプロパティを持てるようになっている。ブロックプロパティは、従来からあるUMLプロパティに新たな制約条件を課し、SysMLバリュータイプなどが持てる。また、バリュータイプは単位や寸法を持てる設計になっている。分散プロパティでは、ユーザーがプロパティの値に確率分布を適用できる。SysMLは、単位、寸法、および確率分布として考え得る値のモデルライブラリを提案している。

　図6は、RSWのBDDを示している。図を見やすくするため、サブシステム間の関係や雨滴検知ワイパーのエレメントは反映させていないが、実際のモデルにはこのような関係が存在する。ここではその代わりとして、各コンポーネントセット（コンポジットおよび外部）を四角で囲み、コンポジットコンポーネントにはビジュアルな構成エレメントとして黒のダイヤモンド形ブロックを重ねている。RSWのメインコンポーネントには、ワイパーを作動させるインターフェイス、電子コントロールユニット、センサー、およびフロントガラスの各パーツがある。インターフェイスもフロントガラスも、RSWの有無にかかわらず車に装着できる。従ってこれらは、SysMLではいわゆる参照プロパティとなる。

　図6からは、各ブロックのプロパティとオペレーションが分かる。コンポーネントの物理特性は、プロパティ（もっと正確にいえば、<<blockProperty>>ステレオタイプを使って示されているSysMLのブロックプロパティ）を使ってモデリングされている。システムの機能面は、オペレーション（サービスと呼ばれる場合もある）が示している。

図6 雨滴検知ワイパーシステムのブロック定義ダイヤグラム （クリックすると拡大）

・ブロックへの要件アロケーション

　ここからは、製品構造と製品要件を関連付ける方法について解説していく。モデルエレメントとして要件を用意することが重要な理由の1つに、それによって設計者が所定の要件を満たすシステムコンポーネントを指定可能になる点がある。これは、アロケーションプロセスと呼ばれる。要件アロケーションの一例を図7に示す。図7の左側は、RSWのエレメントをいくつか示しており、右側は要件の階層を示している。アロケーションを行う方法の1つとして、Satisfy依存を使う方法がある。例えば図7では、雨滴検知ワイパーモデルのエレメントが「Automatic Wiping」という要件にアロケートされている。SysMLのエレメントは、いずれも1つの要件を満たすことができる。

　アロケーションを表すもう1つの方法が、「要件関連」という専用のコンパートメントを使う方法だ。このコンパートメントは、要件に関連して生成された一連のプロパティのステータスを表示する。図7では、ECUエレメントがこのようなコンパートメントを示す。ECUエレメントが「専用ECUを利用」という要件にアロケートされることに注意したい。

図7 要件アロケーションの例 （クリックすると拡大）

・内部ブロックダイヤグラム

　SysML内部ブロックダイヤグラム（IBD）は、設計者がモデルの構造面を洗練させられるようにする。IBDは、UMLのコンポジット構造に相当する。IBDでは、プロパティ（もしくはパーツ）が集まってブロックの動作を実現するためのコラボレーション方法を定義する。パーツは、別のブロックの使い方を示す。

　IBDで最も重要な側面が、下記の説明にあるようなポートの定義で、設計者がブロック間のやりとりの定義を洗練できる部分だ。

　ポートは、所有するブロック外部との接続に使うパーツで、やりとりできるものを定義するインターフェイスやブロックごとのタイプ別に分類される。ポートは、IBDにおける結合の使用を示すコネクタを使って接続される。

　SysMLでは、ほかのブロックと連携してサービスのリクエストと呼び出し（つまり、ファンクションコール）を処理する「Standard Port」と、ブロックに情報や資材の流れをやりとりさせる「Flow Port」の2つのタイプのポートが利用できる。Standard Portでは、ブロックが提供するサービスの一覧を用意するためにインターフェイスクラスが利用されている。一方のFlow Portでは、Flow Specificationが作成され、そのポートを流れることのできるデータのタイプが一覧される。たった1種類のオブジェクトしか流れることができない場合は、オブジェクトのタイプがポートのタイプに直接割り当てられ、このようなポートは「Atomic Port」と呼ばれる。Item Flowクラスは、特定の利用方法においてブロック間を実際に流れるものを示すために利用される。項目の流れに関する詳細について興味のある読者は、SysML標準仕様［注1］をご覧いただくようお勧めする。図8にIBDの例を示す。

［注1］ SysML 1.0 Specification（ptc/06-05-04）。OMGの最終採用仕様はhttp://www.omgsysml.org/を参照。

図8 雨滴検知ワイパーシステムの内部構造 （クリックすると拡大）

　図8では、雨滴検知ワイパーという名前のブロック内でパーツがどのように接続されているか示すことで、最初のRSWに関する説明を一段と洗練させた。IBDを構築する際は、その前にまず異なるブロック間の関係を示すモデルを定義する必要がある。ポートを分類する目的などから、ブロックを追加定義することもある。このモデルは、付録にある別のBDDで示す。

　図8の中央部分は、システムの組み込みハードウェアを表すパーツを示している。その下のパーツは、このシステムを車載するためのものだ。その上のものは、ソフトウェアを示している。標準のポートとインターフェイスのセットは、パーツ間の通信機能を示すために定義されている。例えば、処理ユニットは「WiperECUCommunication」インターフェイス経由でワイパーの作動インターフェイスにアクセスする。このIBDで使用されるインターフェイスの詳細は、次回のパート3で解説する。

　この処理ユニットはFlow Portを使ってセンサーと通信する。交換データは2ビットストリームで、1つはセンサーからの各種数値を持ち、もう1つは同期データを持っている。ポートは、「SensorECUCommunication」エレメント（パート3参照）を使い、これらのフローの仕様で分類されている。定義内の流れの方向には注意したい。

　利便性から、Flow Portはインターフェイスの定義に関して入出力が逆になるよう変えることができる（「入力」と宣言されたフローが「出力」になったり、あるいはその逆になる）。これは、Flow Portが相互に応じて変化する2つのシステムを接続するときに有効だ。例えば、図8の処理ユニットとセンサーがこのようなケースになる。変化したFlow Portは黒で示されている。同期データフローは「入出力」と定義されているため、ポートの変化はこれに何の影響も与えない。

　図8では、ポート間のコネクタがブロック内で定義されたパーツをリンクしている点に注意したい。実際のところ、SysMLでは、パーツ内で定義された2つのポートなど、各種レベルで定義されたポート間の直接接続が可能になっている。このようなタイプのコネクタはネステドコネクタと呼ばれる。これらのコネクタに関する詳細はSysMLの標準仕様を参照。

　Flow Portは、物理接続を定義するのにも有効だ。例えば、「SensorAttachment」ユニットは接着剤でフロントガラスに固定されている。接着剤を示すブロックは、これらのパーツを接続するFlow Portの分類に使用されている。

・IBDの要件アロケーション

　要件は分類子であり、そのためIBDでは表現することができない。このようなタイプのダイヤグラムでは、図7で紹介されたコンパートメント表記を使って要件アロケーションを表現する。

　図8には、「Use Sensor on Windshield」の要件を満たすためにフロントガラスを示すパーツとセンサーアタッチメントが使われた例がある（パート1の図3参照）。これらの要件が満たされると各パーツで分かるようになっている。

　規模が大きく複雑なモデルは、数百あるいは数千のエレメントによって構成される。従って、このようなモデルは、IBDのセットを使って詳細に説明される。デザイン方法論の大半は、モデルの内容を整理するために、利害関係者から見た関心時などの視点を考えるよう提唱している。SysMLは、ユーザーが視点の特性を把握できるようにするViewpointというモデルエレメントを提供している（例えば、ターゲットとなる利害関係者、対応する懸念、構成ルールなど）。そして、Viewというコンテナエレメントを使い、視点の内容に応じてモデルを整理する。

　図9は2つに分かれており、視点モデリングを使って関心の分離について説明している。図9aは、視点の定義モデルを示している。サンプルモデルでは、システムのエレメントが「Systems」という中央のパッケージに入っている。いくつかのエレメントはこのパッケージから、システムの消費電力に関与するエレメントのグループ化を目的とする「RSW Power」というビューへと読み込まれる。このビューは視点で説明された定義に準拠している。このビューでは、「Power System RSW」エレメントが定義され、システムの消費電力に関連して読み込まれた各種エレメントがどのように連動しているのかが示されている。

図9a RSW Powerビューの定義 （クリックすると拡大）

図9b 「Power System RSW」ブロックのIBD （クリックすると拡大）

　図9bは、車の電力サブシステムに関連して読み込まれたエレメントの役割を解説している。車の電気系統は、「Atomic Flow Port」タイプのパーツに「Power Supply Channel」ブロックを使って電源を供給する。この場合、ポートの方向（入力もしくは出力）はポートの属性の1つを使って指定する。

｜1　2｜次のページ

	Page1 システムストラクチャの解説
	Page2 制約条件を使った属性間の関係の定義

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）