2017年02月02日情報システム学専攻・ソフトウェア論講座
山本研究室（山本修一郎教授・森崎修司准教授）
【研究室の概要】
山本研究室では，ソフトウェア要求、設計、製造、試験、保守、運用を含むソフトウェア開発・運用プロセスの全ライフサイクルを一貫して支援するディペンダビリティ保証技術の研究に取組んでいます．また，そのライフサイクルにおける理論，技術を実際のソフトウェア開発に適用し，その効果を確かめる実証的ソフトウェア工学に取組んでいます．これらの具体的なテーマを紹介します．
【A. 保証ケース自動生成技術】
どのようなモデルも，必ずモデル要素と要素関係によって定義されています．したがって，モデルを保証する場合，モデル要素と要素関係に基づいて，保証ケースを一般的に分解することができます（モデル構成に基づく分解であることからこの分解をアーキテクチャ分解と呼びます）．また，モデル要素とその関係が期待される品質特性をもつことについて，品質特性の下位特性ごとに分解して保証することができます（品質特性の構成に基づく分解であることから，この分解を品質特性分解と呼びます）．さらに，モデル要素とその関係が必要な品質特性を持つうえでのリスクとその対策が実施されていることに対して分解することができます（リスク対策についての分解であることから，この分解をリスク分解と呼びます）．このように，対象とするモデルが品質特性を持つことを，アーキテクチャ分解，品質特性分解，リスク対策分解にしたがって統一的に保証ケースを作成できます． この考え方に基づいて保証ケースを作成する支援ツールUC2CT(Unified Context to Claim Tool)を試作しています（図1）．このツールでは，モデル定義情報を入力として，保証ケース情報を表形式画面に自動生成して，必要があれば編集でき，保証ケースエディタへの図式情報に変換できます．
図1 保証ケースの自動生成方式
試作ツールを用いた保証ケース作成実験の結果が図2です．実験対象としたモデルは，保証ケース作成支援ツールUC2TCのシステム構成であり，このシステム構成図に対する保証ケースの規模は，主張218個，戦略53個，前提47個，証拠165個でした．ツールを使わずに保証ケースを作成した時間は275分であり，ツールを使用して保証ケースを作成した時間は47分でした．この結果，ツールの利用により，保証ケース作成時間を約5.6倍（約82％削減）に向上できることがわかりました．後者の作成時間にはモデル定義情報，品質特性情報，リスク対策情報を記述するためのXML定義時間28分を含みます．もし，モデルからXML定義を自動抽出できれば，保証ケース作成時間が約14.5倍になることもわかりました．なお，19分には，ツールへのXML入力，アーキテクチャ分解，品質特性分解，リスク対策分解，保証ケースエディタ変換を含みます．
図2 保証ケース作成時間
【B. コンポーネントに対する保証ケース作成法】
モデルに対する保証ケースの作成手法として，これまでパターン分解による手法がありましたが，コードに対する保証ケースの作成法はありませんでした．また，既存システムを保証する場合，モデルが定義されていないことが多いという課題もありました．そこで，リポジトリに格納される静的情報と保証ケースの構成要素との関係の明確化とそれに基づく既存コンポーネントに対する保証ケース作成手法の具体化をするための手法を考案しました．
コンポーネント･コードに対する保証ケースの作成では，コンポーネントへの入力と出力に着目します．コンポーネントの入出力仕様に対して対応するコードでは指定された入力に対する処理によって出力を作成する必要があります．この点に着目して、コンポーネントコードに対する保証ケースでは，図3に示すように入出力分解層で必要な入出力に対する主張を分解することにより対応するコードについて具体化すべき証拠層を用意します．次いで，コードを探索して対応するコードがあれば，証拠として明記します．もし対応するコードがなければ証拠がないことになり，仕様を実現するコードが抜けていることを検出できます．この考え方を証拠に基づく欠陥摘出原理（Defect Detection by Evidence, DDBE）と呼んでいます．
図3 コンポーネントに対する保証ケース作成法
コンポーネントコードに対する保証ケース作成手法DDBEを定式化し，手法としています．手法の評価により，以下を確認しています．
- １） 手法をOpenSSLに適用し，12個の具体化すべき証拠に対して11個のコードが対応することを確認しました．対応するコードがない1個が脆弱性であることを摘出できました．
- ２） 保証ケースと対応するリポジトリのメタモデルを，前提，主張，具体化すべき証拠，証拠，識別子，式，ブロックによって定義しました．
【C.保証ケースの客観的なレビュ手法】
既存の保証ケースをレビュするときに客観的なレビュ手法が明確ではないため，属人的なレビュになりやすいという課題があります．特に，保証ケースの主張では、「システムが安全である」などのように，自然言語を用いるため，用語間の関係があいまいになりやすいという課題があります．本手法は，保証ケースレビュ観点の分類、観点に応じたレビュプロセスの定式化をしています．
保証ケースのレビュプロセスを，理解，問題識別，原因分析，欠陥修正から構成しています（図4）．理解段階で保証ケースからシステミグラムを作成することによりシステミグラム上で問題識別，原因分析を客観的に実施できるようにします．この結果に基づいて，保証ケースの欠陥を修正しやすくします．システミグラムは，名詞をノードとし動詞をノード関係で表現する単純な図式です．システミグラムを用いて保証ケースを構成する主張の理解を助けることができます．
手法の考案により次の2つを実施しました．システミグラムを用いた保証ケースのレビュ指標として，完全性，明確性，適切性，追跡性を定義しました．保証ケースのレビュプロセスの指標として，理解率，問題件数，原因分析率，欠陥修正率を定義しました．問題件数は，完全性，明確性，適切性，追跡性の指摘件数の総和としています．
図4 保証ケースレビュ作成法
【実証的ソフトウェア工学】
実証的ソフトウェア工学では，他の実証的科学分野と同様に，規則性の存在や技術の効果，限界を実際のソフトウェア開発活動を通じて確かめます．たとえば，ソフトウェアを理解するためにどのくらい時間がかかるかといった調査を実施したり，設計技法やテスト技法の効果を実際にソフトウェア開発において活用し，活用しなかった場合と比較したときの効果を確かめたりします．
【D. 拡張開発における所要時間と正確さの調査】
ソフトウェアを新規に開発することは減ってきており，既存のソフトウェアを拡張して開発する形態が増えています．そうした開発で既存の機能を維持したまま，拡張や変更をすることは簡単ではありません．拡張や変更の副作用として，意図せず既存の機能が使えなくなる場合があるからです．そうした開発での変更を判断する時間と判断の正確さを確かめるために，ソフトウェア開発の実務者65名に既存バージョンのソフトウェアを読解してもらい，4つの変更仕様とそれに対応するソースコードの差分を確認してもらいました．
図5はその結果をグラフにしたものであり，指摘レベル（判断の正確さ）とレビュー時間（判断の所要時間）の分布を表しています．所用時間と正確さの間には有意な差がないこと，実務者のレビュー経験が正確さに影響を与えていることがわかりました．これにより，対象のソースコードにおいて時間をかけたからといって必ずしも正確に読めているわけではないことが示されました．
図5 ソースコード変更差分の妥当性の判断に要した時間と判断の正確さ
【E. ソフトウェアリポジトリマイニング】
ソフトウェア開発の成果物の改版履歴や作業履歴を保持しておくデータベースをソフトウェアリポジトリと呼びます．そうした履歴から特徴や傾向を見いだそうとする研究分野をソフトウェアリポジトリマイニングと呼びます．ソフトウェアリポジトリが保持するレビュー指摘やバグの情報から，修正の手間が大きなバグを明らかにしたり，重点的に検出すべき欠陥やバグを明らかにしたりしようとしています．
詳細は次の論文で報告しています。
- K. Kasubuchi, S. Morisaki, A. Yoshida and C. Ogawa, An Empirical Evaluation of the Effectiveness of Inspection Scenarios Developed from a Defect Repository, In Proc. of International Conference on Software Maintenance and Evolution 2015, pp. 430-448(2015)
- 森崎 修司, 松本健一, 業務観点でのレビューを目指した不具合情報の分析,情報処理学会研究報告 ソフトウェア工学, Vol. 2013-SE-179(35), pp.1-7 (2013)
- 森崎 修司, 久保 匡, 荻野 利彦, 阪本 太志, 山田 淳，過去の不具合の修正工数を考慮したソフトウェアレビュー手法，電子情報通信学会論文誌 D Vol.J95-D No.8 pp.1623-1632 (2012)
【F. ソフトウェアドキュメントに出現する単語の特徴】
段階的詳細化を進めるソフトウェア開発においては，まず，どのようなソフトウェアを開発すべきかを定義する要求仕様書を作成します．次に，それをどのように実現するか設計書を作成します．要求仕様書の記述よりも設計書の記述のほうが具体的になっていることが期待されますが，それが要求仕様書と設計書に使われる単語にも表れるかどうかを複数の要求仕様書と設計書で確かめました．
日本語語彙大系で定義された単語の抽象度別に出現割合を要求仕様書と設計書で比較したものが図6です．図6は2つのソフトウェアでの結果を示しています．図6の横軸は抽象度，縦軸は出現割合を表しています．また，黒い棒グラフは要求仕様書での出現頻度，グレーの棒グラフは設計書での出現頻度です．これら2つのドキュメントにおいては，要求仕様書のほうが抽象的な単語の出現割合が大きくなっていました．
単語によってソフトウェアドキュメントの抽象度が計測できるようになれば，目視を要さないソフトウェアドキュメントの評価が可能になるため，この結果を計測手法につなげていく計画です．
図6 ソフトウェアドキュメントに表れる単語の抽象度と出現割合