ソースコード縮退による ソースコード理解 神谷年洋 科学技術振興事業団 さきがけ研究21 オブジェクト指向シンポジウム2003

背景 ソフトウェアの保守においては、ソースコードを理解することが必要とされる 文書化された仕様、設計を利用する JavaDocなどのコメントによるものも含む ソースコードを分析する 抽象度の高い文書を生成する手法 リバースエンジニアリングツール 意味的なまとまりを抽出する手法 プログラムスライス、Concept Lattice、etc 明示的に記述されない情報を抽出する手法 クロスリファレンス、コンポーネントの分類、エイリアス解析、コードクローン分析, etc オブジェクト指向シンポジウム2003

意味的なまとまりを抽出する手法 プログラム中の要素間の依存関係に基づいて、一部を取り出す プログラムスライス Concept Lattice 影響波及解析 プログラム中の要素間の依存関係に基づいて、一部を取り出す 引用: Paolo Tonella, “Using a Concept Lattice of Decomposition Slices for Program Understanding and Impact Analysis,” IEEE TSE, Vol. 29, No. 6, pp. 495-509, (June 2003) オブジェクト指向シンポジウム2003

問題点 循環した関係が存在すると、一部分を取り出すことが不可能になる 循環した関係の中にある要素の１つが指定されると、その循環に含まれるすべての要素が取り込まれる オブジェクト指向シンポジウム2003

例題：ファイルシステム ユースケース ディレクトリやファイルを作成する・削除する ディレクトリやファイルの名前を変える・移動する ドライブの残り容量を求める … 導き出されるオブジェクト・性質 ファイルシステムはいくつかのドライブを持つ ドライブは特殊なディレクトリであると見なされる ディレクトリはいくつかのノードを持つ ノードはディレクトリかファイルである オブジェクト指向シンポジウム2003

ファイルシステムのクラス図（設計） 依存関係の循環 オブジェクト指向シンポジウム2003

ファイルシステムのクラス図（実装） オブジェクト指向シンポジウム2003

ソースコード縮退とは ソフトウェアを構成する要素（クラスなど）の一部を、副作用を持たない「疑似定数要素」に指定する 副作用＝その要素の状態や、その要素と関係を持つ要素の状態、あるいは関係を変化させること クラスを指定した場合 メソッド呼び出しが（戻り値を意味する)定数に置き換わる インスタンス変数が削除される オブジェクト指向シンポジウム2003

ソースコード縮対の効果 要素間の関係の循環を断ち切る ある要素が依存している要素の数が減少する 疑似定数要素、および、疑似定数要素のみに関係をもつ要素を取り除く 要素自体の記述の量が減少する オブジェクト指向シンポジウム2003

例題のソースコード（部分） public abstract class Node { private Directory parent = null; private String name = null; private Drive driveCache = null; …. public Drive getDrive() { if (driveCache != null) { return driveCache; } else { if (this instanceof Drive) { return (Drive)this; return parent.getDrive(); public class File extends Node { private String contents = ""; File() { } public int getSize() { return contents.length(); public void setContents(String contents) { Drive drive = getDrive(); drive.free(this.contents); this.contents = drive.alloc(contents); public String getContents() { return this.contents; オブジェクト指向シンポジウム2003

縮退後のソースコード クラスNodeを 擬似定数要素に指定 public abstract class Node { private Directory parent = null; private String name = null; private Drive driveCache = null; …. public Drive getDrive() { return GET_DRIVE_RETVAL; } public class File extends Node { private String contents = ""; File() { } public int getSize() { return contents.length(); public void setContents(String contents) { Drive drive = Node.GET_DRIVE_RETVAL; drive.free(this.contents); this.contents = drive.alloc(contents); public String getContents() { return this.contents; クラスNodeを 擬似定数要素に指定 オブジェクト指向シンポジウム2003

インクリメンタルなソースコード理解 与えられたソースコードを理解したい それなりに大きい 複雑な依存関係を持っている 1. ソースコード縮退を利用して、依存関係の循環を除去する 2. 他に依存しない少数の要素を抽出してレビューする 3. まだレビューされていない要素から、レビュー済みの要素のみに依存する要素を取り出してレビューする 4. 以下、3を繰り返す オブジェクト指向シンポジウム2003

ケーススタディGemini GUIを用いたソースコード分析ツール Javaで実装され、約１万５千行 クラス115個、パッケージ13個 オブジェクト指向シンポジウム2003

すべてのクラス間の依存関係 見る気が起きない オブジェクト指向シンポジウム2003

Geminiのパッケージ間の依存関係 コントロール 他の ビュー ツールを 起動する モデル ユーティリティ オブジェクト指向シンポジウム2003

パッケージclonedata 楕円はクラス 矩形はパッケージ オブジェクト指向シンポジウム2003

ソースコード縮退適用後 クラスCloneDataを「疑似定数要素」としてソースコード縮体を行う  循環する依存関係に含まれるクラスが9個から４個に減少 依存の方向をさかのぼるようにコードレビューを行うことができる オブジェクト指向シンポジウム2003

学習曲線の比較 ９個のクラスを 一気に ４個のクラス オブジェクト指向シンポジウム2003

まとめ 「ソースコード縮退」を提案した 目的 プログラム理解を助ける プログラムから意味的なまとまりを取り出す手法を補助する 効果 依存関係の循環を断ち切る 疑似定数化された要素のソースコードを取り除く ケーススタディとして、コードレビューへ応用した オブジェクト指向シンポジウム2003

課題 応用 ソースコード分析ツールへの応用 IDEへの組み込み 発展 「疑似定数要素」を選択する基準を明確にする 疑似定数要素に置き換えるよりよい方法を考える ソースコード書き換え アスペクト指向技術の利用 テスト・ドリブンの援用 オープン・プロブレム リファクタリングにより依存関係が循環しないように修正できるか？ 依存関係が循環しないようなパッケージへの分割はリーズナブルか？ オブジェクト指向シンポジウム2003

関連研究：オブジェクト指向プログラムのリバースエンジニアリング 齊藤　寿和※1, 海尻　賢二※1, “オブジェクト指向プログラムのリバースエンジニアリング”, 研究報告 「ソフトウェア工学」 No.136 – 016 ※1 信州大学大学院工学系研究科情報工学専攻 アブストラクト 近年、ソフトウェア開発において、オブジェクト指向開発が注目されている。しかし、オブジェクト指向開発の普及につれて適切なドキュメントを持たないソフトウェアも増えてきている。また、オブジェクト指向言語におけるリバースエンジニアリングでは、実装段階でのクラス構造とリバースエンジニアリングによって実現されるべき分析・設計段階におけるクラス図との抽象度の違いについて考慮する必要がある。本研究では、オブジェクト指向言語としてC++、ドキュメントとしてUMLのクラス図を対象とした。リバースエンジニアリングを行う事によって得られる情報に抽象的な情報を付加することで、より設計に近いクラス図を復元するための手法を提案する。 http://softeng-www.cs.shinshu-u.ac.jp/Thesis/2001/Master/csaito/csaito.ppt オブジェクト指向シンポジウム2003

関連研究２：UMLクラス図からのワークロードの見積もりとスケジュール作成 お手元の予稿集のpp.153-160！ 「大規模なシステムを設計した場合にはクラス間の依存関係が複雑になり、クラスの実装やテストの実行順序の決定が困難になる」 オブジェクト指向シンポジウム2003

Lessons Learned Javaソースコードをレビューあるいはリバースエンジニアリングする場合に インスタンス変数は「集約(aggregation)」と「コンポジション(composition)」の両方に用いられることに注意する 自動的に判定することは困難 ソースコードからクラス図を作るツールは適当にごまかしている 名前付けのコーディング規約は重要である メソッド名  副作用 クラス名、インターフェイス名  デザインパターン、ロール パッケージ名  配置 オブジェクト指向シンポジウム2003

パッケージclonedata、クラス図 オブジェクト指向シンポジウム2003

「インスタンスを生成している＝コンポジション」と推定 同、集約とコンポジションを推定した場合 「インスタンスを生成している＝コンポジション」と推定 オブジェクト指向シンポジウム2003

オブジェクト指向シンポジウム2003