ウィンターワークショップ２０１１・イン・修善寺 ソフトウェア工学研究における グランドチャレンジ 鵜林 尚靖 九州大学 大学院システム情報科学研究院 ２０１１年１月２０・２１日 1 概要 ー ソフトウェア研究に夢を！ ソフトウェア工学研究にグランドチャレンジを！ グランドチャレンジは研究分野共通の目標を設定する！ 夢のあるグランドチャレンジを提示することにより分野全体の研究水 準が大きく向上する！ 議論のスタンス ソフトウェア工学は総合学問であり、複数の研究要素（例えば、設計 技法と検証技術）が組み合わさって有用になる場合が多い グランドチャレンジパターンの提案 複数の研究要素が一つの課題に含まれている 問題と評価基準から構成される 2 発表内容 グランドチャレンジとは ソフトウェア工学研究の中長期的未来 グランドチャレンジ・パターン 今後の議論に向けて 3 グランドチャレンジとは 4 ちょっとその前に ー前回の提案ー ソフトウェア工学研究は様々な •分類することは良いことだが、それだけでは研究 領域に横断的にまたがっている。 は活性化しない！ そのため、一律的な指標で研究 成果を評価することは難しい。 •夢のあるソフトウェア工学研究の方がもっと重 要！ 本発表では、ソフトウェア工学 研究の方向性と評価のあり方を、 「研究指向 vs. 現場指向」「技 術指向 vs. 実証指向」の2軸か ら分析するフレームワークを提 案する。 評価フレームワーク 5 M.Shaw: Prospects for an engineering discipline of software, IEEE Software, 7(6):15-24, November 1990 図は「ソフトウェア工学の基礎」（玉井哲雄著）から引用 温故知新：ソフトウェア工学の成熟度 土木工学の成熟プロセス コンパイラを超える発明はあっ たであろうか？ １７００年 静力学、材料力学 科学（Science） 生産（Production） 工芸（Craft） 工学（Professional engineering） 商業化（Commercial） １７５０年 材料属性 １８５０年 橋の分析 １世紀ローマ ソフトウェア工学の成熟プロセス １９６５〜１９７０年 アルゴリズム、データ構造 科学（Science） 生産（Production） 工芸（Craft） 商業化（Commercial） 工学（Professional engineering） 個別の例 （コンパイラ） １９８０年代 ソフトウェア開発方法論 6 グランドチャレンジ グランドチャレンジ 研究分野共通の目標を設定 分野全体の研究水準が向上 目標が共通であるため、評価尺度を決めて個々の研究成果あるい は提案技法をお互いに比較することが可能 グランドチャレンジの例 The Verifying Compiler グランドチャレンジではないが。。。 MSR Challenge 7 ソフトウェア工学研究における グランドチャレンジのあり方 ソフトウェア工学研究の特徴 ソフトウェア工学は総合学問であり、複数の研究要素（例えば、 設計技法と検証技術）が組み合わさって有用になる場合が多い グランドチャレンジのあり方 開発現場における実際的問題とそれを解決できる複数の研究要素 を対応付けながらグランドチャレンジを設定する必要がある グランドチャレンジは中長期的な研究課題を設定することが望ま しい、すぐには解決できないからこそ挑戦し甲斐がある 8 ソフトウェア工学研究の 中長期的未来 9 コミュニティにおける未来予測 FoSE 2007（SIGSOFT、ICSE2007に併設） モデル駆動、ソフトウェアテスト、検証、ソースコード解析、ソ フトウェア設計とアーキテクチャ、要求工学など25編の論文が発 表 FoSE 2010 10 私の興味分野とその私的予測 興味分野 モデル駆動と検証技術の未来像 中長期的予測（or 願望） プログラミング言語理論とソフトウェア工学の融合 言語技術を核にモデル駆動開発が再構成 DSL構築とモデル駆動開発の融合 型理論と形式検証技術（静的/動的検証）の融合 双方向変換技術と設計・実装間のトレーサビリィティ技術の融 合 大規模に耐えうる自動検証技術 ソフトウェア工学が対象とするのは「現場で役に立っている か？」の世界 大規模の壁を超えて行かなければ、ソフトウェア工学の未来は明 るくない 大規模デザイン検証 大規模静的検証、大規模実行時検証 11 グランドチャレンジ・パターン 12 グランドチャレンジ・パターン パターンの構成 問題 背景 目標 課題 チャレンジ事項 関連技術 グランドチャレンジ技術 評価基準 問題ごとに設定 13 パターンの適用例 シナリオ（開発現場の問題とその解決） ソフトウェア保守の問題をモデル駆動 と検証を用いて解決する 14 問題 -- OSSのデザインリカバリ 背景 ソフトウェア開発プロジェクトの多くは、ソースコードはあるも のの役に立つ設計書が欠損している場合が多い 目標 コードから設計を適切な抽象度で復元し、その後、設計とコード の同期をとりながらソフトウェアを保守できる技術を確立する 小規模ではなく大規模プロジェクトで利用可能な技術とする 課題 OSS（Open Source Software）であるEclipseから一つプロジェ クトを選択し（例えば、EMF: Eclipse Modeling Framework）、 リポジトリデータからソフトウェアアーキテクチャ設計を復元せ よ 15 問題（つづき） チャレンジ事項 復元されたアーキテクチャと元のソースの間で双方向のトレーサ ビリィティが確保されるようにせよ。ここでいうトレーサビリ ティとはアーキテクチャを変更すると対応するコードが同期して 変更され、その逆も成立することをいう 復元したアーキテクチャは適切な抽象度のDSLで表現可能である こと。そのDSLは既存言語（Scala等）の内部DSLとして実現され ていること リポジトリデータ（ソースの他にテスト実行結果、バグ修正も含 む）から復元されたアーキテクチャが満たすべき性質を自動抽出 せよ 上記性質を自動検証せよ 16 問題（つづき） 関連技術 リバースエンジニアリング DSL 静的検証 実行時検証 グランドチャレンジ技術 抽象化技術 双方向変換 漸進的型付け（gradual typing）の内部DSLへの応用 型とContractの融合 17 評価基準 解法の評価基準 復元アーキテクチャの抽象度（記述量削減率） DSLの行数 / 元のソース行数 * 100 大規模性: ソース行数 アーキテクチャ復元時間 自動検証 検証スピード 検証項目網羅率 留意点 適用対象のEclipseプロジェクトを定めると、チャレンジャ間の横 並びの比較が可能となる 18 今後の議論に向けて 19 提案内容のまとめ ソフトウェア工学研究の評価を真に意味あるものにするには、 評価以前に研究そのものが夢あるものにする必要がある 今回、そのための一つの方法として、グランドチャレンジを 掲げて世界中の研究者がそれを目標に切磋琢磨して研究に邁 進することを提案 20 今後の課題 今回提案したのはあくまでもグランドチャレンジの課題を設 定するための枠組み（パターン）のみ グランドチャレンジを考える際にポイントとなるのは、面白 い適用事例を考えられるか否かである（たとえば、「OSまる ごとデザイン検証」「車載ソフトまるごとアーキテクチャリ カバリ（ビジュアル表現）」） グランドチャレンジを考える際、夢物語を否定しないことが 重要（「そんなの出来っこ無い」と言ってしまえば、そこで 終わりで発展はない） 21
© Copyright 2025 ExpyDoc
