会場の様子

講演

JEITA ソフトウェア事業基盤専門員会の活動状況が報告された。この委員会の最初の課題認識である擦り合わせ開発をベースに、これまでに品質向上、開発スピードアップ、アーキテクトの育成、モデリングの各テーマについて活動してきたことが報告された。今回のワークショップでは、モデリングを成功させるための方法を探っていくことが示された。
JEITAソフトウェア事業基盤専門委員会委員長 五味氏（ＯＫＩ）

本講演では最初に、ソフトウェアエンジニアリグ知識体系ガイドであるSoftware Engineering Body of Knowledge (SWEBOK) Guide 最新版を用いて、ソフトウェアにまつわる職業人が押さえるべき知識・技術の広がりと境界を解説しました。続いて、その中でも特に重要なソフトウェアのモデリング技術と関連する品質を、IoTにおける重要性も含めて解説しました。
鷲崎　弘宜 教授(早稲田大学)
質疑応答 質問： モデル駆動開発の今のトレンドとして、ドメイン特化のモデリングをして、リンクで合わせるというやり方を紹介されました。 我々でもドメインに分かれてやっているが、リンクした時に全体の整合性が難しく、リンクで合いません。 回答： そこはこの取組が２０１５年に始まったばかりですが、まず一つはアーキテクチャをベースとして押さえておくようにします。 そして全体を見通せるアーキテクトが品質要求に駆動される形で検討しておかなければなりません。 もう一つはそのうえで回していくところが大事です。 「それぞれにＤＳＬで表現して変換してガチャンと組み合わせてハイ完成しました。」でおしまいではなくて、その結果に対して全体として検証して品質を測定評価などして不足があればそれぞれのドメインに戻ってまた改善修正してというサイクルをいくらか回すべきです。 アーキテクチャのところと、プロセスのところと、両方必要でしょう。当たり前、実直と言えば実直だが、そういう風に感じます。 質問： 最後の評価のところに興味があります。実際に評価したものと有識者の主観的な評価とどのくらい一致していたのでしょうか。 回答： まさに指摘の点が重要です。ピタリとはまるということではないが、「ある程度エキスパートなどが見るべきポイント、それは結果として以降も実装や保守などに効いてくるようなところをある程度定量的につかめそうだ」という感触を得ています。 例えば講演資料の＜品質測定：構造的複雑さ（結合性）＞で見ると、ＥＴロボコンで縦軸がエキスパートによる主観的・定性的な評価、 横軸が機械的・定量的な測定評価＜Coupling Factor:COF＞で、これらにある程度の負の相関がみられます。 構造が複雑なほどエキスパートによる評価は低くなっています。一方でこちらの例＜品質測定：意味的複雑さ＞では、その逆に意味的な複雑さが低いほど(Class Relational Structure Understandability:CRSUが高いほど）エキスパートによる主観的評価が高いという正の相関があります。 厳密にピタッとはまるということではないので、そこは測定評価に関して多面的にみる必要があります。 つまり、我々はまず個別に複雑さの特徴をとらえようとしているが、ある一つだけで代替するのではなくて、複数の評価の仕方を組み合わせて多面的にみるということが重要です。そこに関しては例えば機械学習などが使える、そういう総合的な取り組みが必要だろうと捉えています。 質問： 相関係数はどの程度でしょうか。 回答： 強くはないですがソコソコあります。例えば前者で0.5〜0.6です。 一定の関係はありそうだという推測は成り立ちうるぐらいです。 だから、これ単独ではだめで、多面的にみるべきです。

モデリングのさまざまな手法、ツールを紹介し、組織/テーマの解決したい課題によって適切に選択し、導入する必要があることを紹介しました。プリンター・プロジェクター等のテーマへモデリングを導入した事例と、現在取り組んでいる要求モデリングの現状を紹介しました。
河内　美紀 氏(リコー)
質疑応答 質問： 2000年にRhapsodyを使って高い自動生成率を成功されましたが、その後、モデルツールとして EA に変えた理由はなんでしょうか。 回答： ツールの初期導入コストです。最初、Rhapsodyを使ったインクジェットの時は数名での開発でしたが、EAを導入したテーマでは設計者数十名へのツール導入が必要でした。Rhapsodyの良かったところは取り入れたかったので、コード生成の部分やドキュメント生成の部分を自分たちでカスタマイズして使いました。Rhapsodyと同等とは行きませんが、ツールを導入し、モデル＝ソースコードとするために必要な部分についてカスタマイズしました。 質問： コード生成をする場合、かなりモデルを細かく書かないといけないと思います。例えばモデルの中に最終的には関数とかそういうもとを組み込む必要があります。その場合、モデルが見づらくなります。そういうことはなかったのでしょうか。 回答： モデルの骨格を表示するときには、属性や操作関を非表示にするなど、色々な機能があります。 質問： Rhapsodyでの自動生成率が、個人的には驚異的な数字だと思います。自分も自動生成しているところはありますが、状態遷移図などを使うときはデザインパターンのステートマシンをよく使ってやりますが、そういうのは自動生成がすごくし難いなと感じています。そこまで自動生成で対応するよりはコードで書いた方が柔軟でやりやすいと思ってやっています。そういうものをどのように自動生成で対応したのでしょうか。 回答： この時は状態設計の吐き出しをデザインパターンを使わずにSwitch-Caseで対応していました。自動生成のルール部分もカスタマイズしています。状態遷移については動的モデリングをきちんと行い、さらにモデルでのシミュレーションで設計検証を実施したかったので、モデル上にソースコードを全て埋め込むことにこだわりました。コード生成部分については自分たちの目的にあわせてプロパティーファイルなどのカスタマイズで対応しています。 質問： モジュール間の繋ぎやドメイン間の繋ぎなどに関しては、どのように自動生成をしているのでしょうか。 回答： Rhapsodyで繋ぎの部分をうまく実施するためには、初めの構成の検討が重要です。コンポーネントの構成や、コンポーネントに対するincludeルールを決定するなどモジュール間の結合シミュレーションが部分ごとに実施可能となるように設計しました。

講演では富士ゼロックスのモデリングに関する取り組みやMDDの適用事例について紹介し、また、講演者は2015年よりETロボコン本部審査員として、活動してきたことを紹介しました。2016年度はモデリングを活かせる課題を目指し、競技と審査規約を大きく変更されたことを紹介し、後半ではその変更の狙いと、実際に提出されたモデルの変化、そして課題について紹介しました。
土樋　祐希 氏(富士ゼロックス)
質疑応答 質問： WHATモデルのところで、そのモデルを書くために気付きが必要になります。HOWの方は与えられた要求というか事象をそのまま形にするのでモデルとしては万人が理解しやすいです。WHATモデルの方は気づいた人はいいですが、気づかないときに問題になると思います。例えばレビューの時に、レビュアーが（モデルを書いた人と）同じレベルでないと、あまりレビューにならないにならないのではと思いました。実際のところはどうなのでしょうか。 回答： まさにその通りです。最初のゴールはWHATモデルを書くのではなくて「見て読み解けるようにぐらいになりましょう」というのを目標にやっています。描くのは難しいです。書けるようになるためによく言っているのは「箱から書くな」ということです。箱ではなくて絵から書くようにします。絵が重要です。いっぱい絵を描かないとダメです。絵に描けないものはモデル化できません。まず絵を描いてそのあとに箱を描きます。箱から描き始める人は大抵失敗しています。

差分開発が多数を占める組込みシステム開発におけるアーキテクトの役割と設計上で行うモデリングについて紹介しました。またアーキテクトが活躍しやすい組織の条件について触れました。
四反田　秀樹 氏(パナソニック)
質疑応答 質問： 「アーキテクチャに影響を与えたその理由を残せ」は非常によく判ります。 その中で「特に仕様以外の項目を」とあったが、「仕様以外」とは何でしょうか。 回答： 仕様とはこういう機能であるとか、例えば、カメラだとシャッターはどんな時でもすぐに効かなければいけないとか、そういう常識があります。シャッターボタンは性能要件が厳しいので保守性よりも優先して処理します。仕様から来るものは後から見ても大抵わかります。ところが歴史的経緯で来ているのは仕様に表れていません 例えば、明文化されていない非機能要件などを指します。