INCOSEシステムズエンジニアリングをSysMLモデルで読み解く
システムズエンジニアリングの解説って、たいていわかりにくい。高尚かつ抽象的な文言で結局何なのかさっぱりわからない。「わかりやすく解説」っていうやつは高尚かつ抽象的な内容をくどくど説明するだけで、わかりやすくなってない。「実例で解説」というやつは質が悪くて、あれは誤解と勘違いを誘発する。だって実例から抽象的な本質を見抜くっていうのは途轍もなく難しいことなのだから。
じゃあどうすれば良いのか？別の説明の仕方を考えないといけない。ここではシステムズエンジニアリングの抽象的な内容を、SysMLという図的表現に変えて解説したいと思う。
対象のシステムズエンジニアリングプロセス
システムズエンジニアリングプロセスって言っても幅広い。今回説明するのはINCOSEシステムズエンジニアリングハンドブックに書いてある以下の技術プロセスです（かっこはA-SPICEでの表記）。
- 利害関係者ニーズおよびシステム要求分析プロセス（SYS1）
- システム要求定義プロセス（SYS2）
- システムアーキテクチャ定義プロセス（SYS3）
システムズエンジニアリングプロセスをSysMLでモデル化する
システムズエンジニアリングプロセスだってシステムだからSysMLでモデル化できます。その前の準備として、モデルの意味をはっきりさせるために以下のステレオタイプを追加します。
| ステレオタイプ | 意味 | |
| 《contextModel》 | コンテキストモデル | 特定のコンテキスト(アーキテクチャ)における役割や制約によって定義されるモデル |
| 《blackboxModel》 | ブラックボックスモデル | 外部からみた振舞いや能力で定義されるモデル |
| 《architectureMode》 | アーキテクチャモデル | 内部構造を定義したモデル |
これらのステレオタイプを使って、「システムズエンジニアリングプロセス」を、「SysMLを使ったモデル作成」に置き換えていきます。
利害関係者ニーズおよびシステム要求分析プロセスのモデル化
このプロセスは問題空間モデルの作成に置き換えられます。
このプロセスでやることは、上図のような問題空間モデルを定義し、問題空間の振舞としてアクティビティ図などを使ってライフサイクルコンセプトやユースケースシナリオを描くことです。それと問題空間の内部ブロック図（コンテキスト図）を描いて、システムがやり取りする情報やインタフェースを決めます。
このプロセスではシステム要求を決めますが、要はユースケースシナリオでシステムがやっていることを言語化するだけです。「ユーザからaを受け取ったら外部システムにbを出力する」とかね。
システム要求定義プロセスのモデル化
このプロセスはシステムのブラックボックスモデル作成に置き換えられます。
システムのブラックボックスモデルは、問題空間で定義したシステムのコンテキストモデルの特殊解として定義されます。
このプロセスでやることは、問題空間での役割を全うするために必要な、システムの能力や機能を決めることです。能力はバリュープロパティで定義し必要ならパラメトリック図で制約式などを追加します。必要な機能はアクティビティ図を使ってシステムの入出力関係を説明することで定義します。状況に応じて機能や能力が変わるのなら、ステートマシン図を作成してシステムの状態を定義します。必要な機能や振舞が決まったら、必要な入出力があるかポートとの整合性も確認しましょう。
このプロセスではシステム仕様を定義しますが、要はブラックボックスモデルの内容を言語化するだけです。「inport1にaが入力されたらoutport1にbを出力する」とかね。
アーキテクチャ定義プロセスのモデル化
このプロセスはシステムのアーキテクチャモデル作成に置き換えられます。
システムのアーキテクチャモデルはシステムのブラックボックスモデルの特殊解として定義されます。
アーキテクチャモデルでやることはブラックボックスモデルで定義した機能や能力を実現できる内部構造を決めることです。みてわかるとおり問題空間モデルとアーキテクチャモデルは形式的には同じで、やることもだいたい同じです。ブラックボックスモデルで定義した機能が、アーキテクチャの中でどうやって実現されるのかという説明（シナリオ）を描いてシステムエレメントの要求（役割）を定義します。シナリオはアクティビティ図でも良いし、シーケンス図でも良いかもしれません。あとこのプロセスで大事なのはインタフェースを決めることです。内部ブロック図を作成しエレメント間のポートを接続するとともにインタフェースブロックを使ったポート型定義もします。
ここではシステムエレメントの要求を定義します。これも問題空間でシステム要求を定義したのと同じことですね。
SEプロセスの全体像＝システムモデルリポジトリ構造
SEプロセスの全体像を抽象度と範囲で分割したスコープにマッピングするとこうなります。
で、システムモデルのリポジトリ構造がこう。
システムズエンジニアリングプロセスを実行することがきれいにシステムモデルリポジトリを作ることに置き換わっていることがわかると思います。
一応断っておくけど、これはあくまでシステムズエンジニアリングの説明のために作ったモデル化手法の一例で、世の中には別のモデル化メソッドもあります。細かい違いは気にしないでください。
なぜSysMLでの説明がわかりやすいのか
・・・と、堂々と書いてしまったが、ほんとうに世間一般のシステムズエンジニアリングの説明よりもわかりやすいものになっていたのだろうか？自分じゃ公平な判断はできないですが、わかりやすかっただろうということで、何故わかりやすかったかの種明かしをしたいと思います。
それは「SysMLで形式化したから」です。
抽象度の違いをステレオタイプで定義し、抽象度と範囲で決まるプロセス毎のスコープをモデルという形（ブロック）で表現する、要はシステムズエンジニアリングの説明で出てくる抽象的で掴みにくい「概念」に名前を付けて形式化して図的に表現しているからわかりやすいのです。
「MBSEとはシステムズエンジニアリングの形式化である」準形式記法SysMLの真価とはつまりそういうことなのだよ。