【MBSE】ビューとビューポイント
MBSEはシステムモデリングツールを使ってシステムモデルを作成し、システムエンジニアリング情報を構造化するものですが、情報構造化をする手法やツールはシステムモデリングツールだけではありません。要求管理ツールや最近のALM/PLMと呼ばれる開発環境の統合プラットフォームでも情報構造化をしていますし情報の種類や構造（グラフ構造）もよく似ています。じゃあALM/PLMだけで良くない？いいえ、システムモデルには他の情報構造化には無い特徴があります。それは「ビュー/ビューポイントがある」という点です。
ビュー/ビューポイントとは
ビューポイントとは対象を見るときの視点、ビューとはある視点から見たときの対象の姿です。視点は見る人の立場や関心事、目的で決まります。システムモデルは複数の視点をもつところが他の情報構造化には無い特徴で、要求分析ツールやALM/PLMの情報構造が線や面なのに対し、システムモデルはn次元の立体（nは視点の数）です。SysMLでいう要求、構造、振舞、パラメトリックというのも一種の「ビューポイント」で、要求図、構造図、振舞図、パラメトリック図が「ビュー」です。ビューは要求、構造、振舞等に限定される訳ではなく、ステレオタイプなどで拡張することで「リスク分析ビュー」や「製品企画ビュー」、「経営者ビュー」などさまざまなものを定義できます。
ビュー/ビューポイントの種類
さまざまな設計メソッドや標準規格でさまざまなビュー/ビューポイントが定義されています。例えばSysMLの要求、構造、振舞、パラメトリック、DoDAFのオペレーショナルビュー、システムビュー、サービスビュー、テクニカルスタンダードビューなど。MARTEのリアルタイムユニットモデル、SRM、HRMもビューの一種といえます。
ところでビュー/ビューポイントは性格の異なる３つのタイプ、階層(Layer)、関心領域(Domain)、抽象度(Abstraction)に分類できます。
階層(Layer)ビュー
対象の空間的、構造的な範囲を表すもので全体と部分の階層構造を形成します。例えば世界全体から始まって、会社、会社のプロジェクト、プロジェクトの一部であるシステム、システムの構成要素であるエレメント、といった具合です。
関心領域(Domain)ビュー
一般にビューというと真っ先に思いつくのがこれで、SysMLの要求、構造、振舞、パラメトリックなどが代表的です。
抽象度(Abstraction)ビュー
通常の(シミュレーションなどで使う)モデルには階層(Layer)ビュー、関心領域(Domain)ビューしかありませんが、システムズエンジニアリング特有のビューとして抽象度(Abstraction)ビューがあります。設計プロセスが進むにつれてシステムが具体化していく段階に応じたビューで、例えばA-SPICEのSYS1、SYS2、SYS3ではそれぞれのプロセス内容に応じたビューが必要になります。
ビュー/ビューポイントのタイプによる違い
ビュー/ビューポイントのタイプによる性格の違いは、プロセス構築や構成管理を考える上で重要なポイントになります。一覧でまとめるとこうなります。
| 階層(Layer) | 抽象度(Abstraction) | 関心領域(Domain) | |
| 同一タイプ間の関連 | 集合/分解関係 | 抽象化/詳細化関係 | 意味論的な結合 |
| 他のタイプへの従属性 | – | 階層毎に再帰的に再定義される | 階層×抽象度に応じて体系が決まる |
| 順序性 | あり(全体→部分) | あり(抽象的→具体的) | なし |
| プロセスへの影響 | ビューの工程順序を規定しやすい | 工程の並列性・反復性が強い | |
| 構成管理への影響 | ビュー毎に分割してバージョン管理可能 | 複数のビュー間の整合性をチェックしつつ管理する必要がある | |
同一タイプ間の関連
階層(Layer)間の関係は、集合/分解の関係になります。SysMLの例でいうと、ブロック定義におけるコンポジションや要求の包含(containment)関係、アクティビティ図のCallBehaviorなどです。
抽象度(Abstraction)間の関連は抽象化/詳細化の関係で、SysMLでいうと《refine》や、（厳密にはちょっと変だが）汎化関係などが使われます。
関心領域(Domain) 間の関連は意味論的な結合を表すもので、SysMLでいえば《allocate》、《satisfy》、《verify》などですね。
他のタイプへの従属性
階層(Layer)構造は他のタイプに関係なく定義されます。
抽象度(Abstraction)はシステムズエンジニアリングのプロセスによって決まるものですが、各階層に対して「再帰的に」プロセスを適用するのがシステムズエンジニアリングのキモであることから、必然的に抽象度(Abstraction)も各階層毎に「再帰的に」定義することになります。なので実は抽象度の名前が同じでも、階層が違えば絶対的な抽象度は違う、という点には注意が必要です。
関心領域(Domain)の体系が階層や抽象度によって変わるというのは、改めて文章で書くと意外な感じを受けるかもしれませんが、考えてみれば当然のことです。会社全体の階層とシステムエレメントの階層で同じ関心領域ビューを使うことはまずあり得ないということは少し考えればすぐわかります。同じ階層であっても企画段階ではユースケース図を使いますが、詳細設計段階でユースケース図を使うやつはいないでしょう。関心領域(Domain)ビューって、プロジェクト全体を通して定義できると思いがちですが、実際はある階層の範囲、ある抽象度の範囲内でのみ適用できるものなのです。
順序性
階層(Layer)、抽象度(Abstraction)は順序性を持ちますが、関心領域(Domain)は順序性を持ちません。だから何？って思うかもしれませんが、これがプロセスや構成管理を考える上で重要なポイントになるのです。
プロセスへの影響
階層(Layer)や抽象度(Abstraction)には順序性があるので、プロセスの順番は自然と決まります。アジャイル開発であっても1回のスプリントの順序性は階層や抽象度で決まるはずです。一方、関心領域(Domain)には本質的に順序性がありません。要求→振舞→構造の順番で作る・・・みたいな順序を決めてるメソッドもあるけど、ああいうのは鵜呑みにしない方がいい。実際は要求、振舞、構造を反復的に修正しながら各ビューの整合性を取ることになります。なので領域(Domain)ビューのプロセス定義には柔軟性が必要、というか同時並列的＆反復的なのでビュー毎に分けてプロセス定義するのはナンセンスとすら言えます。以上のことからシステムエンジニアリングのプロセス定義は階層(Layer)ビューと抽象度(Abstraction)ビューに沿って定義するのが理に適っていて、領域(Domain)ビューでは定義しないということになります。実際にA-SPICE等多くの標準プロセスもそういう構成を採用しています。
構成管理への影響
階層(Layer)や抽象度(Abstraction)には順序性があり、上位のビューは下位のビューの影響を受けにくい（因果関係が一方向に決まる）ことから、ビュー毎のバージョン管理が容易にできます。ビュー単位での再利用性も維持しやすい。一方で領域(Domain)の各ビューは意味論的に結合しているため、単体のビューだけでバージョン管理しても意味がない。各ビューの整合性をチェックし、整合性が取れた段階でひとまとめにして管理することになります。よって構成管理でも主軸は階層(Layer)と抽象度(Abstraction)ということになります。
システムモデルリポジトリへの影響
ビュータイプによる特徴、プロセスやバージョン管理のことを考えれば、システムモデルリポジトリのパッケージ構成は階層(Layer)‐抽象度(Abstraction)‐関心領域(Domain)の順序で階層化するのが自然という結論になります。まあ色々事情があって別の構成にすることはあるかもですが、ビュータイプの性質を考えるとこうなるということは押さえておくべきでしょう。
SysMLV2ではどうなる？
ところでSysMLの泣き所は異なる抽象度間の関連にあると思います。SysML V1では異なる抽象度間の関連を表現する手段がなく、UMLから継承した汎化関係で代用していました(意味的にはrefineなんだろうけどポート情報やバリュータイププロパティを継承できるメリットの方が大きい)。SysML V2でもこの状況はあまり変わってないようです。むしろ言語の厳密性が増したために(V1の「汎化関係を使って誤魔化す」ような真似が使えず）異なる抽象度間の関連定義がクソ面倒になる可能性もあります。
ま、こんなことはV2の規格化している人は先刻ご承知だろうから、どんなベストプラクティスを出して解決してくれるのか、乞うご期待ってところです(他力本願)。