セミナー詳細にご興味がある方は、下記のリンクよりご確認をお願い致します。

https://kke.lmsg.jp/v2/seminar/11672/aGQ1allO

システムの本質をUML/SysMLで表現する

株式会社エクスモーション

エグゼクティブコンサルタント　

斎藤　賢一　様

Q1:　只今紹介いただいている内容は、EAでSysMLをかき、ハンドコードするスタイルを

イメージしているのでしょうか？Simulink等でオートコードまで考えた場合、機能モデル

設計と詳細モデル設計をどのようにつなげたらよいのでしょうか？

A1:　具体的な制御ロジックに踏み込むか、踏み込まない論理の世界か、が分かれ目になり

ます。SysMLで記述する目的は、どのようにシステムを分割するかであり、ブロック内部のロジックまで踏み込まないようにします。逆に、システム分割後はSimulinkで詳細化して

いくという考え方が定番です。最初からSimulinkだど、役割分担を決めているのか、

ロジックを決めているのかごちゃ混ぜになり、最終的に複雑で分かりにくいSimulinkモデルになることがありました。そこにSysMLを入れることで、モデルの目的が明確になり、

理解性の良い構造からSimulinkに落とし込むことができるようになります。

Q2:　流用、派生開発でスパゲッティになったソースコードは、どのようにモデル化すべき

ですか。ノウハウがあれば教えていただきたいです。

A2:　派生開発プロセス「XDDP」ではスペックアウトと呼ばれ、コードから仕様を引き

出す際にモデルを使うことが多いです。その際、モデル化したい着目点によってどのようにモデル化すべきかが変わってきます。例えば、関数の構造をスペックアウトするのか、関数内部のロジックをスペックアウトするのかなど。しかし、複雑なコードはモデル化しても

複雑なままなので、コードで実現したい意味的な機能を抽出してモデルで整理し、コードと紐づけるやり方が良いと思います。

Q3:　要求図の作成では、車両のような抽象度の高いところから設計を始めた場合、掘り下

げると膨大になります。どのようにして二段だけに収めることができるのでしょうか?

A3:　車両すべての要求は膨大になりますが、最初は構成分割でユーザの利用観点でまとめ

るのが良いと思います。その後、システム設計で分割したら、そのシステム単位に要求を

書くというように段階的に要求と設計を繰り返すと良いと思います。

Q4:　SysMLに慣れないメンバーで取り組むと、初めの段階で詳細になりすぎてしまい、

なかなか進捗せず中断してしまいました。

A4:　システム設計のゴールを明確にすると良いと思います。要求仕様に対してどんな設計

解が明らかになったら良いかを最初にイメージすることで、詳細化は防げると思います。

Q5:　USDMの各要求仕様とモデルとのトレーサビリティはどのようにとられています

でしょうか？(例：要求仕様とステートマシン図の状態、シーケンス図のメッセージ)

A5:　USDMがExcelなので、列を追加してモデル名を入れてマトリクス的にトレースを取る

のがほとんどですが、トレーサビリティツールを使う場合もあります。

Q6:　SysMLとUSDMの共用は一元管理が困難と感じております。SysML一本でどうにか

仕様まで管理できる事が望ましいと考えますが、おすすめはできませんか？

A6:　SysMLが複雑化せずに仕様までうまく整理で来るのであれば一本化でも良いと思います。しかし、私が見てきた現場は、要求を書くマナーもなく、巨大な要求図があるだけで、仕様を確認できるようなレベルではないものが多くありました。そうならないように要求図をコントロールできれば、一本でいくのも良いと思います。

Q7:　今回、要求仕様からモデル作成の流れでしたが、モデルを作成して抜け漏れのない

要求仕様を作成する流れはいかがでしょうか？

A7:　良い質問ですね。要求を理解するためにモデルで表現することは良くありますので、

どちらの流れでも良いと思います。しかし、モデル作成が深くなり、要求仕様を超えて

設計に踏み込むことがあります。モデル作成者はなかなかそこに気づかずに突き進むことがありますので、その点だけ注意するのがポイントだと思います。

Q8:　SysMLを初心者が学ぶのに、お奨めの書籍があれば、ご紹介ください。 A8:　以下の2冊を推奨します。

　・システムズモデリング言語SysML 　東京電機大学出版局

　・モデルに基づくシステムズエンジニアリング　日経BP

モデリングツールの必要性とその価値

スパークスシステムズジャパン株式会社

代表取締役　河野　岳史　様

Q9:　いろいろなモデリングツールがありますが、データ互換性はありますか？

A9:　基本的には、互換性はないと思っていただく方が良いと思います。多くの場合には、

それぞれのツールで、他社ツールからのインポート機能を持っていることが多いです。

Q10:　USDMプラグインについて質問します。このプラグインでUSDMを作成して「要求」

と「仕様」を表現できるかと思います。本日の斎藤様の発表にあったような分析モデルを

作成して、要求→仕様→分析モデル（静的モデル＋動的モデル）を一貫して関連付けて管理することができますでしょうか。現在はユースケースをもとに「仕様」→「分析モデル」を関連付けています。

A10:　EAで作成した要素は、EAのトレーサビリティの機能で結びつけ・参照でき、要素の

種類による制限はありません。つまり、仕様と分析モデルの要素を結びつけ、デモでご覧

頂いたようなマップで階層的に上位要素を追うことも可能です。

発見困難な不具合の自動検出を実現する形式検証と適用事例

モデルベース形式検証ツールのご紹介

株式会社構造計画研究所

事業開発部AOR研究室　太田　洋二郎

Q11:　形式検証を導入するにはまず何から始めればよいですか？

A11:　まずは形式検証が自社の開発のどこに適用できてどのような効果が得られるのか、

その有難さを実感して頂く必要があります。過去に後工程で不具合が顕在化した事例を

お持ちであれば、設計段階でモデル化と形式検証を導入していたら発見できていたのかを

検証するのが効果的です。ただし最初はハードルが高いと思われますので弊社では試解析

サービスを実施しております。

Q12:　DynaSpecは，モデルの入力値・出力値が離散値または連続値の場合，仕様の反例と

なる入力値を自動的に探索することはできますか？つまり，Falsificationできますか？

A12:　モデルの組み方次第ですが、本質的にモデル検査は反例を見つけ出すことを目的とし

ています。入力値がどの範囲の値をとり得るかを明示することで、どの値が反例に繋がるかを検出できます。

Q13:　形式検証では不具合の状態を定義することが必要ですが、不具合定義にも手法が

存在するのでしょうか？

A13:　不具合状態を定義するというよりは常に満たしておくべき条件を定義するイメージ

です。それを満たさない状態が検出されるとそれが不具合です。満たすべき状態は要求仕様から導き出すことになりますが、その全てを定義するのは現実的ではなく、明確な手法を

回答できませんが、形式検証で何に注目して検証したいのかの目的ははっきりさせておく

必要があります。

Q14:　本システム設計プロセスでの成果物は下流工程にどのように連携できるのか？　

どのツールにInput可能なのか？他社さんのツールにInputするためのI/F、APIは何か準備

されているのか？

A14:　DynaSpecを導入したとしても最終成果物は（検証済の）EAモデルになりますので、

そこからはEAの領域になります。

Q15:　動的にオブジェクトが複数生成されるようなモデルの検証は可能でしょうか？可能な場合どのように不具合を定義するのでしょうか？

A15:　DynaSpecでは動的オブジェク生成への対応は現時点では考慮しておりませんが、

DynaSpecではないですが、弊社の踏切モデル検査の事例では、オブジェクト（列車）最大数を予め配列で用意し、全列車共通で満たすべきASSERT条件を各オブジェクトに適用しておりました。DynaSpec上でも同じ考え方でモデル化できる可能性はあります。

Q16:　形式言語コードを実際の開発言語（C、C++)にどうやってコンバートするの

でしょうか？また、逆に既存のコードを取り込むことは出来ますか？

A16:　形式言語によってはC言語に変換できるものもありますし、C言語コードをそのまま

形式検証できるものもあります。DynaSpecが採用しているSPIN（Promela言語）はC言語

へのコンバート機能はありません。あくまでモデルの正しさを検証するものために形式言語へ変換するのであり、最終成果物はモデルになります。

Q17:　モデル検査は状態爆発で処理が終わらないという心配がありますが、どのような形でコントロールするのが良いと考えていますでしょうか。

A17:　直接的にはよりハイスペック（主にメモリサイズ）なマシン環境（最近ではAWS

環境等が利用可能）を準備することが考えられますが、これでは解決しないことが多い

です。本質的な解決策は、よりモデルを抽象化すること（本質のみに絞ってモデル化）、

検証対象を本当に評価したい範囲のモデルに絞って検証すること、1回の検証実行で全てのパターンを網羅検証するのではなく、条件の組み合わせを変えて何回かに分けて検証して

網羅性を担保すること等が考えられます。

　さらにモデルではなく形式言語に依存した対応になりますが、不要な中間状態を削減することで劇的な改善効果が得られる場合もあります。

　以上、皆様のご参考になれば幸いです。

　さらに詳しい情報をお知りになりたい場合は、個別に対応させて頂きますので、お問合せ下さい。