システムモデリング言語SysMLの現状と可能性 ~ツールベンダーの視点から~

河野 岳史(スパークスシステムズ ジャパン株式会社)

はじめに

この記事では、最近利用者が増えていると感じているシステムモデリング言語SysMLについて、ツールベンダーという立場・観点で最近の状況をお伝えします。
 

SysMLとは?

SysMLとは、OMG(Object Management Group)によって公開されている、システムをモデリングするための記述言語(Modeling Language)です。

OMGはSysMLだけでなく、ソフトウェアの設計を視覚的に表現することを目的に定義されたUML(Unified Modeling Language)や業務の流れを可視化するBPMN(Business Process Modeling Notation)など、さまざまな記法・記述言語の定義や普及に努める国際的な団体です。SysMLの現在のバージョンは1.5で、次期メジャーバージョンアップとなるSysML2.0の検討も進められています。

このSysMLは、主にソフトウェアの設計のために利用されるUMLを、システム設計のために拡張したものです。
図の種類は9種類ですので、拡張というよりは絞り込みというほうが適切かもしれません。
その結果、UMLよりも理解・導入しやすい面があります。

UMLと比較すると、ステートマシン図などいくつかの図はそのまま利用し、アクティビティ図などいくつかの図はシステム設計を行うために必要な記述方法を追加しました。また、タイミング図などは削除したほか、要求図のようにSysMLで追加された図もあります。

なお、SysMLを利用するためにUMLの知識がある方が良い面もありますが、必須の知識ではありません。以前は、UMLを知っている方がSysMLを使うようになることが多かったように思いますが、最近はUMLを経由せずにSysMLから使う方が増えているように思います。

SysMLの特徴の1つとして、システムの「機能」「振る舞い」「制約」をモデルとして定義するだけでなく、そのシステムに対する「要求」やそのシステムの「テスト」の概念をモデルに取り込んだことが挙げられます。
従来の方法では別の文書で管理されることの多い要求やテストなどもモデル内に表現し、要求とその要求を実現するブロックとの関係や、テスト項目とテスト対象のブロックとの関係を目に見える形で表現できます。
 

SysMLの図をご紹介

参考までに、SysMLのいくつかの図を紹介します。

次の3つの図のうち、図1は「要求図」になります。
システムへのそれぞれの要求を要素(図形)として表現し、要求間の依存関係などを線で可視化します。

▼図1 要求図の例

図1

 

図2は「アクティビティ図」です。
UMLにもアクティビティ図はありますが、より詳細・複雑な内容の表現ができるように拡張されています。

▼図2 アクティビティ図の例

図2

 

図3は「内部ブロック図」です。
SysMLではシステムの構成要素をブロックという単位で取り扱いますが、そのブロックの内部の構成を表現できます。

 

▼図3 内部ブロック図の例

図3

 

ツールベンダーから見たSysMLの現状

SysMLが日本で知られ始めたのは、今から10年近く前のことかと思います。

その当時は、UMLの利用もそれほど広がっていない状況で、SysMLをどのように使うのかを一部の人が試行錯誤している状況であったかと思います。

弊社(スパークスシステムズ ジャパン)ではUMLモデリングツールEnterprise ArchitectのアドインとしてSysMLが利用できる製品を販売していましたが、その当時は、1本ないしは2,3本程度を、研究や試行目的で購入するようなケースがほとんどでした。

現場での設計に利用する目的で、設計者の人数分に該当するような多い本数の購入はほとんどありませんでした。(なお、この内容は日本の話で、海外でのその当時の状況はわかりません。)

最近はどうかと言いますと、その当時と同じような2,3本程度の購入も依然としてありますが、その件数が以前に比べるとずっと多くなりました。

また、10本~20本あるいはそれ以上の、現場で設計者全員が利用すると思われるような購入も珍しいものではなくなりました。ツールベンダーからの視点では、SysMLの状況は10年前から比べると大きく変わりました。もはや、一部の人だけが知っている記法ではないと言えます。

余談となりますが、今年(2017年)の6月に、アメリカ・ヨーロッパ・日本のSparx Systemsの関係者がEnterprise Architectの開発地であるオーストラリアに集まり情報交換を行いました。その際の情報として、SysMLはヨーロッパでも広く利用されるようになってきているとのことです。

IPAが公開している情報「ドイツ・欧州企業におけるシステムズエンジニアリングの実践に関する調査・分析結果報告」※によりますと、ヨーロッパ(特にドイツ)の自動車業界ではモデリングツールとしてEnterprise ArchitectとMATLABを利用している人が50%以上とのことです。この中に、SysMLを利用している人が少なからず含まれていると考えています。

http://www.ipa.go.jp/sec/reports/20161219.html

 

なぜSysMLが必要になるのか

なぜSysMLが必要になるのか、さまざまな理由があるなかで、大きく分けると標準規格への対応と設計上の理由とがあると考えます。

前者の標準規格への対応については、例えば、自動車業界における機能安全規格ISO26262では、不具合が起きた際に人命に関わる範囲の設計など、特定の条件を満たす範囲については準形式手法の記述を用いて設計を表現することを推奨しています。SysMLも準形式手法の記述言語です。こうした標準規格への対応のために、UMLだけでなくSysMLを利用することが増えています。

後者の理由については、昨今話題になることの多いIoTのようなキーワードで語られるように、セキュリティなどの以前にはない要求が増え、システムとして考慮する必要がある範囲・内容が広がっています。また、要求を実現するために複数のシステムを連携させる場合もあり、この面でも考慮すべき点が増えます。こうした内容を設計に盛り込んでいくと、従来の文章・表形式では内容の把握が難しくなります。

SysMLのような視覚的な記述言語を利用しさまざまな観点の図を組み合わせることで、複雑な内容の把握や考慮漏れなどを見つけやすくすることが期待できます。その中で、現実的な選択肢としてSysMLが選ばれることが増えてきました。

 

SysMLとツール

SysMLは言語(Language)ですので、その言語を利用する際のツール(道具)にはルールはありません。

日本語を使う場合のツールを考えてみますと、手書きでも、メモ帳のようなテキストエディタでも、Wordのような高機能なツールでも良いです。同様に、SysMLを使う場合でも、専用のツールは必須ではありません。実際に、ExcelやPowerPointのオートシェイプを駆使してSysMLの記法に合う図を作成しているという話を耳にすることもあります。

しかし、現実的には専用のモデリングツールは必須であると考えています。その理由として、SysMLの仕様では、ツールの存在を前提としていると思われる点が少なからずあることです。今回は、その具体的な例として以下の3つの点を挙げます。

・トレーサビリティ
・ブロック内の区画表記
・パラメトリック図
 

SysMLにおけるトレーサビリティ

まず、SysMLでは要素間のトレーサビリティに関する関係が複数定義されているという特徴があります。

例えば、要求要素とブロック要素では<<satisfy>>を利用することが多いですが、一方で要求要素とテスト要素の場合には<<verify>>を利用します。このようにさまざまな関係が定義されていることで、必要に応じて特定の条件のトレーサビリティのみを絞り込んで影響範囲や漏れ抜けの存在の確認ができます。

このようなトレーサビリティはツールの機能を利用して確認することができます。

例えば下の図では、ある要求に対して対応するブロックが存在していないことが視覚的にわかります。モデリングツールでなければ、図としてこれらの関係を利用していたとしても、こうした情報を把握することは困難です。

モデル_ツール表


 

ブロック内の区画表記

2番目の例のブロック内の区画表記とは、下の図のようにブロックが保持する情報を「区画」として表示する表記を指します。それぞれの区画に何を表示するかは、仕様である程度定められています。

Ports区画_01

 

ここで、例えばPorts区画にはブロックが持つポート要素の情報が表示されますが、上の図の内容は下の図のようにポート要素を実際に表示するような表現にすることもできます。

Ports区画_02

 

モデリングツールを利用すると、下の図からポート要素を削除すると自動的に上の図の表示に変わり、上の図の表示でポートを要素として表示するようにすると下の図に自動的に変わります。状況や目的に応じて複数の表記形式から選択できる点もSysMLの特徴になりますが、ExcelやPowerPointのような作図ツールではこのような表記の変更が自動で行われることはなく、手作業になります。
 

パラメトリック図とシミュレーション

最後の例につきましては、パラメトリック図は「制約」を表現することのできる図ですが、この図の真価はシミュレーションにあります。対象のシステムの制約を表現できても、その制約が適切かどうかを確認する手段がなければ効果は半減します。OpenModelicaなどの既存のシミュレーションツールと連携することで、図として表現することのメリットが生かせます。

そのほか、専用のモデリングツールにはSysMLの作成の効率向上に役立つさまざまな機能を搭載していますので、作図をするだけでも効率向上につながります。このような効率を向上させる機能はそれぞれのモデリングツールで独自に開発が進められていますので、ツールを選択する際の大きなポイントになります。

 

まとめ

この記事ではツールベンダーとしてさまざまなお客様の元に伺う中で得られた情報・感触も含めて、ツールベンダーの観点からSysMLの現状をお伝えしました。少しでも皆様のお役に立てる情報があれば幸いです。

なお、SysML自体は単なる表記法であり方法論やプロセスは定義されていませんので、SysMLをどのように使うか、という点について試行錯誤しながら学んでいかなければなりません。以前に比べると、最近は日本語の書籍も増えているほか、トレーニング(教育)・コンサルティングなどの支援サービスも充実しています。

SysMLは現実的に導入可能な状況であると言えます。仕様の表現方法に悩んでいる方、視覚的な表記法を探している方はぜひ導入を検討してみてください。
 

≪参考情報≫

・モデリング言語SysMLの概要とくにUMLとの関係に関して
ThinkIT記事 モデリング技術の新しい動向1:UMLの現状とSysMLの最新動向
https://thinkit.co.jp/story/2010/09/08/1745

・SysMLとモデリングツールに関して
ThinkIT記事 モデリング技術の新しい動向2:SysMLを利用可能なモデリング・ツール「Enterprise Architect」
https://thinkit.co.jp/story/2010/09/15/1756

・SysMLの日本での普及に関して
InfoQ記事 IPA/SEC 統合モデリング技術WG 内田氏インタビュー
https://www.infoq.com/jp/articles/InterviewIPA_20120723?utm_source=arti…
 

関連する豆蔵のサービス