図書館問題 2.0 ：ソフトウェア工学研究における共通問題例

ウィンターワークショップ２０１２・イン・琵琶湖ウィンターワークショップ２０１２・イン・琵琶湖図書館問題 2.0：ソフトウェア工学研究における共通問題例鵜林尚靖亀井靖高九州大学大学院システム情報科学研究院２０１２年１月１９・２０日

概要　ー　共通問題の事例提示 • 共通問題はソフトウェア工学研究コミュニティにおいて重要な研究目標を提示する。 • 本発表では、先達が残した財産を活かしつつ、既存の共通問題を現在の研究トレンドの観点から再生し、それらをカタログ化する方法を提案する。 • 具体例 • 図書館問題 2.0

発表内容 • 共通問題に関わる現状の課題 • 共通問題のカタログ化 • 事例：図書館問題 2.0 • まとめ

共通問題に関わる現状の課題

共通問題とは • 概要 • ソフトウェア工学の研究成果を評価するための例題。 • 皆が同一課題に取り組むことにより、その成果を同じ土俵で評価できる（評価のためのモノサシ）。 • 形態 • ベンチマーク型（分析比較型） • コンテスト型（結果比較型） • グランドチャレンジ型（課題達成型） • 課題 • 作成が容易ではない既存の問題が再利用できないか？（本発表）

既存の共通問題 • 図書館問題 • 酒屋の在庫問題 • 国際会議チェア問題 • 話題沸騰ポット • ESSロボットチャレンジ（飛行船） • MSR（Mining Software Repository）Challenge

現状の課題 • カタログという形で整備されていない。 • 複数のバリエーションが存在する共通問題はどれが正式版か分からない。 • 現在的な研究チャレンジの視点が含まれていない（内容が若干時代遅れ）。

提案するアプローチ • 先達が残した財産を活かしつつ、既存の共通問題を現在の研究トレンドの観点から再生し、それらをカタログ化する。 • 新たな共通問題を作るのも重要であるが、まずはその前に慣れ親しんだ問題を甦らせようというアプローチ。

共通問題のカタログ化

カタログの構成 • 「対象（問題文）」と「研究チャレンジ」の二次元で表現。 • 同じ図書館問題でも、研究チャレンジを差し替えることにより、新たな共通問題として定義しようという考え方。

既存問題の再生例（１） • 図書館システムを対象とした設計・コードの同期問題 • 概要 • オブジェクト指向によるソフトウェア開発で、どのようにアーキテクチャ設計と実装の同期をとって行けば良いかという共通問題 • 組み合わせ • 対象：図書館問題 • 研究チャレンジ：設計・コードの同期

既存問題の再生例（２） • 組み込みシステム（電気ポット）を対象とした設計・コードの同期問題 • 概要 • ハードウェア制約を考慮した設計・コードの同期問題はどうなるかという共通問題 • 組み合わせ • 対象：話題沸騰ポット • 研究チャレンジ：設計・コードの同期

事例: 図書館問題 2.0

カタログの内容 • 研究課題名（課題タイプ） • 図書館問題 2.0　（グランドチャレンジ型） • 研究チャレンジ • 抽象度を考慮した設計・コード間の同期 • 説明 • 図書館での図書の貸し出しシステムを考える。図書館は開架式であり、ユーザは自分で図書を選び、借りたい図書を窓口に持って行き、ユーザカードを沿えて、貸し出しを申し込む。窓口の係員は貸し出し情報を登録し、図書とユーザカードを利用者に返す。返却時には同じく図書とユーザカードを沿えて、窓口で返却を依頼する。窓口の係員は返却処理を行い、ユーザカードを返す。窓口の係員は毎日、貸し出し状況をチェックし、２週間以上延滞しているユーザには電話により督促を行う。 • 上記の問題に対し、以下を行う。 • 設計モデルとコードの間で双方向のトレーサビリィティが確保されるようにせよ。トレーサビリティとはモデルを変更すると対応するコードが同期して変更され、その逆も成立することをいう。 • 同期の抽象度が設定できるようにせよ。

カタログの内容（つづき） • テーマの妥当性説明 • アーキテクチャ設計はソフトウェア開発において重要な役割を果たす。 • しかし、その一方で、開発者の意図を正確に反映し整合性のとれたアーキテクチャを構築すること、そのアーキテクチャを正しく実装につなげることは必ずしも容易ではない。 • Taylor, R. N.らは、ソフトウェア設計における重要研究テーマの一つとして、「アーキテクチャ設計から実装への移行」と「両者の間の頻繁な行き来への適切な支援」を指摘している。 • 現状の課題をまとめると以下のようになる。 • 抽象化: 　ソフトウェア開発において、抽象化は要求分析、設計、プログラミング、テストを通じて最も重要な能力である。しかし、現在のソフトウェア工学は、抽象化に対して、ほとんど支援できていないし、そのための理論基盤もない。 • トレーサビリティ: 　要求と設計、設計とコード、要求とテスト、などソフトウェア開発では、様々なレベルでトレーサビリティが求められる。しかし、現状のソフトウェア工学が提供するトレーサビリティのための技術は実用レベルに達しているとは言い難い。特に、上記の「抽象化」を考慮したトレーサビリティは実用化されていない。

カタログの内容（つづき） • 研究内容例 • 現在、アーキテクチャが記述可能なプログラミング言語（ArchJavaなど）やインタフェース機構（Archfaceなど）が提案されているが、まだ研究の初期段階にある。 • DSL（Domain-Specific Language）を用いた同期機構、トレーサビリティの自動検証機構など、多くの研究の余地が残されている。 • 上記の図書館システムの問題文では、実装については触れられていない。抽象度をどう設定し、どのように設計とコードの間の同期をとるか、考える必要がある。 • 評価方法 • 以下の実現度により評価する。 • 抽象度を測定するためのメトリクスが提供されており、実際に図書館システムを例にその値が算出されている。 • 設定した抽象度に基づいて、設計とコードの間で同期をとるための機構が提供されている。さらに、それをサポートするツールが提供されている。 • 研究例 • Ubayashi, N., Nomura, J., and Tamai, T.: Archface: A Contract Place Where Architectural Design and Code Meet Together,ICSE 2010.

まとめ

まとめ • 共通問題の事例として、「図書館問題 2.0」を提示。 • 今後、ソフトウェア工学研究会の活動の一環として、まずは既存の共通問題を現在的視点から再生しカタログ化することが重要だと思われる。

図書館問題 2.0 ： ソフトウェア工学研究における 共通問題例