モデルベースシステムズエンジニアリングと SysML

1. モデルベースシステムズエンジニアリングとは？

モデルベースシステムズエンジニアリング（以下、ＭＢＳＥ）とは何でしょうか。そのことについて考えるとき、まずはその逆を考えてみるのがよいでしょう。
あなたにはこんな経験がないでしょうか。システム設計をしたいのに、だれが見るのかもわからないドキュメントを書いていたり、ドキュメントにまとめておいたのに、それを無視して開発が進んでいたり、ドキュメントに書いたものの、メンテナンスされることなく捨て置かれたり…これらはどこにでもある開発の悲劇かもしれません。 この過ちを二度と犯さないために、MBSEというアプローチが考案されたのです。

① 「すべて」をモデルに

そう、すべてがモデルに詰め込まれるのです。つまり、あなたが書いていたシステムのためのあらゆるドキュメントがモデル上で表現されるので、モデルを見ればそのシステムの全てが分かるようになります。モデルをもとにシステムを視覚的に設計するので、情報がより具体的になります。さらに、MBSEを実践するツールを用いれば、システムに関する情報やパラメータはすべて一貫性をもって管理されるので、新たな要求があった際に関係するドキュメントを総ざらいして直すなんてことをしなくてもよいのです。

② MBSEの誤解

すべてをモデルに集約とは言ったものの、ドキュメントは必要です。モデルにはメタ的な情報も記載するようにできますが、モデルから切り離されるべき情報もまた存在します。MBSEはあなたのシステム設計の負担を減らすことはできても、難しい作業の全てを取り去ってはくれません。そもそも開発メンバーはMBSEを実践するためにUMLもしくはSysMLを学ばないといけませんし、ステークホルダーがUML/SysMLを理解できないのであれば、レビューのたびに必要な形式でドキュメントを作らねばならないでしょう。
MBSEは唱えればシステムズエンジニアリングができてしまう魔法の呪文ではないのです。後ろ向きな発言にはなりますが、これはMBSEについて知っておかなければならない部分です。

③ モデルとは―― ビューとの関係

モデルはシステムの全てを表現したものから成り立ちます。ではその「もの」はどうすればモデルからわかりやすく引き出せるのでしょうか？それは図です。百聞は一見に如かずという言葉があるように、人に何かを伝えたいとき、文字よりも図や絵のほうが直感的に理解できます。
MBSEで使用される図として、一番なじみが深いのはユースケース図やシーケンス図でしょう。これらは図として、システムが何を価値として提供するのか、どういった挙動をするのかという情報をあなたに示します。このとき、一つの図が示すことのできる情報には限りがあります。図は目的によって細分化され、必要な情報だけを都度あなたに提供するでしょう。この目的こそが、ビューと呼ばれるものであり、モデルの一側面を見せるものなのです。
では、その「図」はどうやって描けばよいのでしょうか？ここからはその答えであるSysMLについて述べていきます。

2. SysML（Systems Modeling Language）とは

SysMLは、その前身としてUMLを持つ、OMG（Object Management Group）によって作成されたモデリング言語です。UMLはこのコラムを読んでいる方ならなじみ深いかと思いますが、日本語訳すると統一モデリング言語と訳され、オブジェクト指向のシステム開発に用いられるシステム設計を、視覚的にわかりやすく表現するための手法です。UMLは言語として統一され規格化され、曖昧さを排した表現方法で通常の言語の垣根を超えて、あるシステムに対する考えをたやすく共有することができます。
しかし、こと複雑なシステム開発にUMLを用いる場合、UMLの記法では賄いきれない情報や表現が見つかりました。それを解決するために、システムにさらにフォーカスしたのが、SysMLなのです。

① SysMLは手段である

前述したように、SysMLは言語です。そして、それ以外でもありません。
どういうことかというと、SysMLはモデリングする際のルールを提供しますが、どうモデリングするかまでの方法を提供することはありません。その部分は、あなたがどのような目的でSysMLを使用するのか、何を成し遂げたいのかという部分にかかわってきます。SysMLを用いればドキュメント管理から解放されるということが幻想であると同様に、SysMLの作法に則ればシステム設計が美しく完遂されるというのも幻想なのです。SysMLはあくまで「どうやって」に対する解としての手段であり、あなたが具体的な目標とそれを実行するだけの熱意をもってはじめて、SysMLは輝くのです。

② SysMLで描くことができる図

さて、そんなSysMLでは、あなたの目的のために9つの図を描くことができます。順番に、

• ブロック定義図（Block Definition Diagram: BDD）
• 内部ブロック図（Internal Block Diagram: IBD）
• ユースケース図（Use Case diagram: UC）
• アクティビティ図（ACTivity diagram: ACT）
• シーケンス図（Sequence Diagram: SD）
• 状態遷移図（STate Machine diagram: STM）
• パラメトリック図（PARametric diagram: PAR）
• パッケージ図（PacKaGe diagram: PKG）
• 要求図（REQuirement diagram : REQ）

これら9種類の図はその目的に応じてモデルの一側面を切り取り、モデルの一部を表現するために使用されています。一部はその前身であるUMLと同じものもありますが、削られて新規に考案されたものもあります。すべてについて述べることはできないので、主要なものを概説します。
前述したユースケース図やシーケンス図のほかに、専ら使われるのがブロック定義図（以下、BDD）です。このBDDはUMLでいうクラス図であり、その発展形となります。ブロックはオブジェクト指向のクラスとして自身が持つパラメータや操作を定義します。このブロックが相互にどう関連するかをBDD上で表現することによって、このシステムがどのように成り立つかを視覚的に検討することができます。
さらに、シーケンス図にこのブロックを持ち込むことができます。シーケンス図上で複数のクラスの相互作用と流れを記載することで、そのシステムが果たす役割の流れを追うことができ、しかもSysMLを理解できる全員にあなたの考えを伝えることができるのです。

3. まとめ

さて、ほんのさわりだけではありましたが、ここまでMBSEとSysMLについて触れてきました。MBSEの理念とそれを実現する手段のSysMLは、取り掛かるには少し難易度が高くはありますが、それでも言語として、1回覚えてしまえばあなたの長いエンジニア人生の一助となってくれることは間違いありません。少なくとも、増え続ける膨大な数のドキュメントをプロジェクトごとに手際よく整理する術を身に着け、それを実践し続けるよりは、実りあるものになることは確かでしょう。システム設計にかかわりのない無駄を省き、設計行為に注力できるようになったそのとき、MBSEは報われるのです。