インタフェースの provide-require 関係の解析に基いた自動的な

インタフェースの Provide-Require 関係の
解析に基いた
自動的な構成管理手法の提案
早瀬康裕† 神谷年洋†† 松下誠† 井上克郎†
†
大阪大学大学院情報科学研究科コンピュータサイエンス専攻
†† 科学技術振興機構さきがけ
E-mail: {y-hayase,kamiya,matusita,inoue}@ist.osaka-u.ac.jp
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
1
研究の背景

ソフトウェアシステムは部品 (サブシステム) 単位で作られる
サブシステムの例: 関数・メソッド・クラス・モジュール・パッケージ

全てのサブシステムを作るのは現実的ではない
再利用や、外部からの調達によりまかなわれる
外部調達のサブシステムでは、ソースコードが付属しない場合や、付属し
ても編集できない場合がある

サブシステムには複数の実装 (バージョン) がある
(例) 複数の組織が、同じサブシステムを作る
システム
サブシステム c
サブシステム a
サブシステム d
サブシステム b
サブシステム e
ソースコードの
あるサブシステム
ソースコードのない
サブシステムや
編集できない
サブシステム
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2
問題

サブシステムには複数のバージョンがある
サブシステムを組み合わせたとき、正しく動作するのか?
確認には多くの労力が必要になる

ソースコードの無いサブシステムに問題が見つかったとき、どう
解決したらよい?
Java のバイトコードを対象として、オブジェクトの持つメソッド
の情報で、互換性を調べる手法を提案
 メソッドの不足しているソースコードを編集できないときに、問
題を解決する方法について考察

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
問題例 1

クラス A と B は、 C の異なる
バージョンに依存している
A

A と B を同時に用いると非互
換性問題が起こる
C
A
m1
+m()
+m1()
m1
+m()
C
B
m2
MethodNotFound
+m()
B
C'
A
m2
+m()
+m2()
+m1()
m1 MethodNotFound
+m()
C'
B
m2
+m2()
+m()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4
問題例 2

クラス C が変更されて、メソッドが無くなると非互換性問題
が起こる
A
m
+main()
<<create>>
<<create>>
C
C'
B
obsoleteMethod
obsoleteMethod
+m(in c : C)
MethodNotFound
+obsoleteMethod()
+unused()
+unused()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
問題が起こらない例
この例では、クラス C のメソッドが無くなるが、非互換性問
題は発生しない
 「メソッドが無くなった = 非互換性問題が起こる」ではない

A
m
+main()
B
B
+m(in cc :: C)
C)
+m(in
+neverCalled()
+neverCalled()
m
m
obsoleteMethod
C
C'
+m()
+m()
+obsoleteMethod()
MethodNotFound
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
提案手法

システムの非互換性を解決するための 3 つのステップ
検出: サブシステムの集合に潜在的な非互換性があるかどうか
特定: どのサブシステム間で、どのオブジェクトが非互換の原因
になっているか
解消: どのサブシステムを、どのように修正するか
サブシステムのバイトコードを調べて、自動的に非互換性を
検出・特定する
 特定された問題を、手作業で解消する

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
7
モデル (オブジェクト)
オブジェクトはメソッドを持つ
 オブジェクトは 1 つのクラスに属する
 クラスには継承階層がある

 サブクラスに属するオブジェクトは、スーパークラスに属するオブ
ジェクトとして振舞うことができる
 クラス C とクラス D があったとき、 C が D のサブクラスであるか、
C = D であるとき、 C is_a D であると言う
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
8
モデル (サブシステム)
サブシステム間で、オブジェクトが受け渡されるモデルを考える
サブシステム = Java のメソッドとする
メソッドの集合をサブシステムとして扱うことで、より大きな単位をサブシステムと
して扱うことも可能
サブシステム間でオブジェクトを受け渡す方法は以下の3つ
1. メソッドの引数と返り値
全てメソッド呼出しとして
考えることができる
2. コンストラクタによる生成
→ 新しいオブジェクトが作られる特殊なメソッドと考える
3.
公開変数への代入と、公開変数からの読み出し
→ 仮想的な setter/getter メソッドと考える
引数のオブジェクト
サブシステム a
サブシステム b
返り値のオブジェクト
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
モデル (インタフェース)
インタフェースを、クラスとメソッドの組の集合と定義する
(≠ Java の interface)
 オブジェクトの provide するインタフェース
そのオブジェクトが持つ全てのメソッドについて、オブジェクトが
属するクラスと、そのメソッドの組の集合
(例) クラス C のオブジェクト c が、メソッド m1(), m2() を持っている場
合、オブジェクト c は {(C, m1()), (C, m2())} を provide する

サブシステムの require するインタフェース
そのサブシステムの中で起こりうる全てのメソッド呼出しについ
て、呼出されるオブジェクトのクラスとメソッドの組の集合
(例) サブシステム a の中でクラス A のオブジェクトのメソッド m1() と、
クラス B のメソッド m2() を呼出している場合、サブシステム a は {(A,
m1()), (B, m2())} を require する
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
非互換性問題が起こらない状態・起こる状態
サブシステム a
クラス C のオブジェクト c
Provide
{(C,m1()),(C,m2())}
サブシステム a
クラス C のオブジェクト c
Provide
{(C,m1())}
サブシステム b
Require
{(C,m2())}
サブシステム b
Require
{(C,m2())}
下の図では、渡されるオブジェクト c は m2() を持たない
このように、 require に含まれているメソッドが、 provide に含まれてい
ないとき、非互換性問題が起こる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
Provide-Require 関係
サブシステム b に、クラス C のオブジェクト c が渡されるとき、
c と b が Provide-Require 関係を満たす条件を、以下の
ように定義する
サブシステム b の require するインタフェースの全ての要素
(D, m) について、C is_a D ならば、オブジェクト c の
provide するインタフェースに、 (C, m) が含まれている
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
Provide と require の計算
あるクラスに属するオブジェクトが持つメソッドは、そのクラスの
バイトコードを読むことで分かる
これにより、オブジェクトが provide するインタフェースを知る
ことができる
 同様に、あるサブシステムが呼出す可能性のあるメソッドは、
そのサブシステムのバイトコードを読むことで分かる
これにより、サブシステムが require するインタフェースを知る
ことができる

実際に、どのクラスのオブジェクトが渡されるかを知るために、
データフロー図を用いて計算を行う
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
データフロー図

データフロー図とは、サブシステムを頂点、オブジェクトの受
渡しを有向辺としたグラフ


一つの引数や返り値には、一つの辺が対応する
辺のラベルには、渡されるオブジェクトのクラスを列挙する
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
14
データフロー図を計算する方法
与えられたバイトコードから、全てのサブシステムを抽出し、
頂点を作る
2. 同様に、クラスの継承階層を抽出する
3. 同様に、全てのサブシステムについて、サブシステム内で起こ
りうるコンストラクタ呼出しを抽出し、辺とラベルを作る
4. 全てのサブシステムについて、サブシステム内で起こりうるメ
ソッド呼出しを抽出し、入力辺のラベルにあるクラスと、引数
や返り値のクラス制約に基いて、出力辺とラベルを作成する
5. 4. をグラフが変化しなくなるまで繰り返す
1.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
問題例 2 のデータフロー図
A
m
<<create>>
+main()
C
B
obsoleteMethod
+obsoleteMethod()
+unused()
+m(in c : C)
クラス C のオブジェクト
A.main()
クラス C のオブジェクト
C#obsoleteMethod()
C.C()
B.m(C c)
C#unused()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
非互換性の検出と特定
検出
データフロー図内で Provide-Require 関係を満たさない状
態があるかどうかを調べる
特定
Provide-Require 関係を満たさない状態に至るまでのデー
タフロー図上の経路を計算する
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
問題例 2 における非互換性の検出と特定
A
m
+main()
<<create>>
B
C'
obsoleteMethod
+m(in c : C)
クラス C のオブジェクト
Provide
{(C,unused())}
C.C()
+unused()
MethodNotFound
A.main()
クラス C のオブジェクト
Provide
{(C,unused())}
Provide-Require 関係を
満たさない
コンストラクタに至るまで、
グラフを逆向きに辿る
C#unused()
B.m(C c)
Require
{(C,obsoleteMethod())}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
非互換性の解消

特定された問題を起こしているオブジェクトの属するクラスの
ソースコードを編集できる場合
→ ソースコードを編集して解消

編集できない場合
→ 他の方法で解消
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
非互換性の解消 (継承を利用)
非互換性問題を起こすオブジェクトのコンストラクを呼出しているサ
ブシステムのソースコードが編集できる場合には、継承したクラスを
作成し、代用することで問題を解消できる
A

+m()
特徴
関係が保持できる
 分かりやすい
 サブクラス毎に、継承したクラス
を作成する必要がある
 is_a
B
B_ex
+obsoleteMethod()
+obsoleteMethod()
C
C_ex
+obsoleteMethod()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
非互換性の解消(同名のクラスで差し替え)
オブジェクトのコンストラクタを呼出している部分のソースコードが
編集できない場合には、同名のクラスで置き換える方法が考えら
れる
1. 全て実装しなおす

2.
リバースエンジニアリングして再利用

3.
労力を厭わない場合
ライセンスで可能な場合
A
元のクラスの実装に委譲
スーパークラスが二重に存在しても
良い場合
 実行環境を変更できる場合

+m()
B
B
+m2()
+m2()
+obsoleteMethod()
B (差し替え用)
<<uses>>
開発者は、適切な解消方法を選択する必要がある
+m2()
+obsoleteMethod()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
問題例 2 に対する非互換性解消
クラス C を継承したクラス D を作成し、
obsoleteMethod()を実装する
 A.main() では、クラス C の代わりにクラス D のオブジェクト
を作り、 B.m() に渡すようにする

C'
A
m
+main()
<<create>>
<<create>>
B
B
+unused()
C' D
obsoleteMethod
obsoleteMethod
+m(in cc :: C)
C)
+m(in
MethodNotFound
+unused()
+obsoleteMethod()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
問題例 2 に対する非互換性解消
解消された状態をデータフロー図で表すと、以下の図のよう
になる
 全ての Provide-Require 関係が満たされている

クラス D のオブジェクト
Provide
{(D,unused()),
(D,obsoleteMethod())}
A.main()
クラス D のオブジェクト
Provide
{(D,unused()),
(D,obsoleteMethod())}
B.m(C c)
D.D()
C#unused()
D#obsoleteMethod()
Require
{(C,obsoleteMethod())}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
まとめ
Java を対象として、サブシステムの互換性問題を調べる手
法を提案
 サブシステムと受渡されるオブジェクトの関係に着目

 サブシステムの
require するインタフェース
 渡されるオブジェクトの provide するインタフェース

互換性問題の解消方法について考察
将来の課題
 手法の実装
 適切な修正方法の自動的な提案
 Java 以外の言語への適用
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24

Download Report