社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

インタフェースの provide-require 関係の解析に基づいた自動的な構成管理手法の提案
早瀬康裕†

神谷 年洋††

松下誠†

井上 克郎†† 大阪大学大学院情報科学研究科コンピュータサイエンス専攻 〒 560–8531 大阪府豊中市待兼山町 1–3†† 独立行政法人 科学技術振興機構 さきがけ 〒 560–8531 大阪府豊中市待兼山町 1–3
E-mail: †{y-hayase,kamiya,matusita,inoue}@ist.osaka-u.ac.jp
あらましソフトウェアシステムは，複数のサブシステムから構成するのが一般的である．しかし，それぞれのサブシステムが独立に進化するような状況においては，サブシステムを組み合わせたときにシステムが正しく動作するかどうかを確認するのは難しく，ソフトウェア開発において問題となっている．そこで， Java 言語を対象として，オブジェクトのインタフェース情報と，データフロー解析を利用して，サブシステムの互換性を計算する手法を提案する．
キーワード

互換性，インタフェース，provide-require 関係, データフロー

A Proposal of Automatic Configuration Management with
Provide-Require Relation on Interface
Yasuhiro HAYASE† , Toshihiro KAMIYA†† , Makoto MATSUSHITA† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University
1–3, Machikaneyama-cho, Toyonaka-shi, Osaka 560–8531, Japan†† Japan Science and Technology Agency
1–3, Machikaneyama-cho, Toyonaka-shi, Osaka 560–8531, Japan
E-mail: †{y-hayase,kamiya,matusita,inoue}@ist.osaka-u.ac.jp
Abstract It is a common practice to develop a software system as a collection of sub-systems. In case of eachsub-system being independently evolving, the developers have to confirm it will work well in company with the othersub-systems, which is a difficult and troublesome task in a development process. This paper presents an automatic
analysis for Java program to calculate compatibility among sub-systems from interface and data flow of objects.
Key words compatibility, interface, provide-require relation, dataflow

1. は じ め にばならない．近年では，セキュリティ問題の修正や，機能追加

ソフトウェアシステムは一般に，関数やクラス，モジュールり，リリース間隔も短かくなる傾向にある．そこで，我々は，といった部品（以降，「サブシステム」と呼ぶ）の組み合わせとJava 言語 [1] [2] を対象として，サブシステムの互換性を確認すして作られる．現在のソフトウェア開発においては，これらのる手法を提案する．提案する手法では，メソッドのシグネチャ部品をすべて新規開発することは現実的ではなく，多くのサブの不整合があった場合に，それによって起きる問題と，その原システムは再利用あるいは外部からの調達でまかなわれる．こ

因を検出することができる．のようなとき，サブシステムはソースコードが付属せず，バイナリのみで提供されることも多い．このようにして調達したサの要求の高まりなどにより，サブシステムの進化は早まってお

2. 問

題

ブシステムを組み合わせて作成されたシステムの動作を検証す

サブシステムの組み合わせとして作られたシステムは，サブる際，システムが意図通りに動作するか確認する作業には多くシステムのバージョンが上がってメソッドが無くなったり，サの労力が必要とされる．

ブシステム間で想定しているインターフェイスが異なる場合に，さらに，サブシステムは独立に進化するため，サブシステムの新しいバージョンがリリースされる度に，作業を行わなけれうまく動作しなくなる．このような問題を， Java 言語を例に用いて説明する．

—1—

図 1 A と B は異なるバージョンの C を要求する

本節の問題の説明では，メソッドが無くなった場合を想定しているが，メソッドのシグネチャ（メソッド名前，仮引数の型，戻り値の型）の変更を，メソッドが無くなって新しいメソッドが作られたと見なすことで，これらの問題はシグネチャが変更

図2

相反する要求された場合にも一般化することができる．

2. 1 例 1: 相反する要求

ン 2 で差し替えると，図 4 のようになる．このシステムでは，それぞれ別の開発者によって作られているクラス A B C か

B の要求する C のメソッド obsoleteMethod が存在しないたら成るシステムがあったとする．
クラス C には二つのバージョン 1，2 があり，異なるメソッド m1 m2 を実装している．クラス A は，クラス C のバージョン 1 で実装されているメソッド m1 を要求する．(図 1) 同様に，クラス B は，クラス C のバージョン 2 で実装されているメソッド m2 を要求する．(図 1) クラス A と B を同時に使用しない場合には，クラス C の適切なバージョンと組み合わせれば，問題は起こらない．
ここで，更に別の開発者が，クラス A と B を同時に利用したいと考えたとする．しかし，図 2 のように，C のバージョン

め， B のメソッド m が C のメソッド obsoleteMethod を呼出そうとした時点で MethodNotFoundException が生成され，正しく動作することはできない．

2. 3 例 3: 実行されないメソッド
それぞれ別の開発者によって作られているクラス A B C から成るシステムがあったとする (図 5)．
クラス A はクラス B のメソッド m を呼出し，そこから Cのメソッド m が呼出される．このシステムでは，クラス B のメ
ソッド neverCalled と，クラス C のメソッド obsoleteMethodが存在するが，呼出されることは無い．

1 またはバージョン 2 のどちらを用いたとしても，クラス A B

ここで，クラス C のバージョン 2 がリリースされた (図 6)．の要求を同時に満たすことは出来ない．このため，部品 A とクラス C のバージョン 2 では，メソッド obsoleteMethod がB を同時に用いることは出来ない．

削除されてる．

2. 2 例 2: 失われたメソッド

このシステムでは， B のメソッド neverCalled からクラそれぞれ別の開発者によって作られているクラス A B C かス C への要求が満たされていない．しかし， B のメソッドら成るシステムがあったとする．クラス A のメソッド main は，neverCalled は使用されることは無いため，このシステムは正クラス C のインスタンスを作成し，そのインスタンスを引数常に動作する．

として，クラス B のメソッド m を呼出す．B のメソッド m は，引数である C のインスタンスのメソッド obsoleteMethod を呼出す．この組み合わせで作られたシステムは，問題なく動作する．

3. 提案手法 (オブジェクトのインタフェース情報を利用したバージョン管理)
前節で説明したような問題を，人間が管理するのは手間がここで， C のバージョン 2 がリリースされたとする．C の大きく，システムの運用や管理の妨げとなる．特に，近年はセバージョン 2 では，メソッド obsoleteMethod は無くなった．

キュリティ上の問題などにより，サブシステムが頻繁に更新さ

図 3 のシステムの C のバージョン 1 を，単純に C のバージョれるため，大きな問題となっている．

—2—

図 3 C バージョン 1

図 4 C バージョン 2

図 5 C バージョン 1

図 6 C バージョン 2

この問題を解決するために，サブシステムを組み合わせてシうには，それらをメソッドの集合として扱えばよい．

ステムを作る場合ににシステムが動作するかどうかを自動的に3. 2 メソッド間でのオブジェクトの受渡し検査するする手法を提案する．

提案手法のモデルでは，メソッド，オブジェクト，クラスに以下，提案手法で用いられるモデルおよび解析アルゴリズム以下の関係がある．

を順に説明する．この説明では，特定のサブシステムが 2 つの• メソッド間でオブジェクトが授受されるバージョンを持つ場合を想定しているが，3 つ以上のバージョ• あるオブジェクトはあるクラスのコンストラクタによっンが存在する場合には，それぞれのバージョンの組み合わせをて生成される．すなわち，あるオブジェクトは一つのクラスに総当たりで調べればよい．

属する．

3. 1 サブシステムの粒度• あるクラスはいくつかのメソッドを持つ．あるオブジェ

互換性を検査する対象であるサブシステムの粒度としては，クトを callee とするメソッド呼び出しにより，そのオブジェシステムの規模に応じて，例えば，jar ファイルなどによる配クトが属するクラスが持つメソッドが実行される．もし，そ布系， package， クラス， メソッドなどが考えられる．ここのクラスが呼出されようとしているメソッドを持たなければ，では，これらのうち最小単位であるメソッドを対象とした分析

MethodNotFound となり，プログラムの実行が停止される．

手法を述べる．一般に，より大きな粒度を対象とした分析を行• クラス間には継承関係がある．すなわち， is a による半—3—

順序関係が存在する．
一般に， Java 言語のメソッドの中で，オブジェクトが授受されるのは以下の場合である．
（ 1 ） new (コンストラクタ) により作られる（ 2 ） メソッドの引数として渡される（ 3 ） メソッドの返り値として渡される（ 4 ） 公開変数に代入される（ 5 ） 公開変数から読み出される
このうち，(4) 公開変数への代入と (5) 読み出しについては，仮想的な setter/getter メソッドがあるものとして扱うことで，図7

例 1 で， A と B を混在させない場合メソッドの引数と返り値の枠内で扱うことができる．
また，(1) コンストラクタもまた，静的なメソッドと同じよソッドである．

うに考えることができる．コンストラクタ以外のメソッドとのここで，あるメソッドは他のメソッドからオブジェクトを受違いは，コンストラクタはオブジェクトの発生源となることでけ取ることがあるため，データフローを参照してそのクラスがある．すなわち，通常のメソッドは，自身に渡されたオブジェ受け取るオブジェクトを突き止める必要がある．

クト以外のオブジェクトを，他のメソッドに渡すことはないが，上述のインターフェイスの要求と同様に，メソッドが提供すコンストラクタは新しいオブジェクトを作成して他のメソッドるインターフェイスを，クラスとメソッドの組の集合 P としてに渡すことができる．

表すことができる．

従って，以降の説明では，コンストラクタ，メソッド，get-ter/setter をまとめて「メソッド」と呼ぶ．

3. 6 provide-require 関係に基づく非互換性の検出
前述のデータフローにおいて，オブジェクトを渡す側のメ

3. 3 データフロー解析

ソッドが提供するインターフェイスは，受け取る側のメソッド

まず，実際に呼び出されるメソッドを特定し，さらに，それの要求するインターフェイスを「満たす」必要がある．

らのメソッドで参照されるオブジェクトが属するクラスを特定する．

すなわち，要求するインターフェイス R の要素（クラス Cとメソッド m）について，提供するインターフェイス P が，以実際に呼び出されるメソッドを特定しておかないと，すべてのメソッドが呼び出される可能性があるとして扱うことにな

下の条件を満たす場合，提供するインターフェイスは，要求するインターフェイスを満たす．

り，2. 3 節の例のような，実際には不要なメソッドを，必要なメソッドと判断してしまう場合がある．
まず，すべてのメソッド間の呼び出し関係（コールグラフ）を∀(D, n) ∈ P, ∀(C, m) ∈ R,(D = C) ∨ (D is subclass of C) −→ (D, m) ∈ P

作成し，コンストラクタをオブジェクトの発生源として，コールグラフ上でオブジェクトの受け渡し（データフロー）を調べる．これにより，それぞれのメソッド中で参照されるオブジェ
クトがどのコンストラクタで作成されたか，すなわち，そのオブジェクトがどのクラスに属するかを特定することができる．
従って，それぞれのメソッド呼び出しについて， callee のクラスを特定することができる．一般に，そのようなクラスは複数存在する可能性があるが，簡単に説明するため，以下ではそのようなクラスが 1 つ求まる場合を想定する．

3. 4 インタフェースの要求 (require)
メソッドが要求するインタフェースとは，そのメソッドの中で呼び出しているメソッドのことである．
メソッド内での全てのメソッド呼び出しについて，メソッドの名前とシグネチャ，callee の静的なクラスの組を記録する．
メソッドの要求するインタフェース R は，クラスとメソッドの組の集合で，以下のように表される．

R = {(C1 , m1 ), (C1 , m2 ), (C2 , m3 ) · · · }3. 5 インタフェースの提供 (provide)
メソッドが提供するインターフェイスとは，そのメソッドが他のメソッドに渡すオブジェクトのクラスに定義されているメ

データフロー内の隣接するメソッド間に，この条件を満たさないものがある場合には，そのシステムの実行中に Method-NotFound が発生する可能性がある．

4. 提案手法を使った構成管理
4. 1 例 1 に適用した場合
2. 1 節の例 1 に，提案する手法を適用した場合を説明する．
図 7 は ，ク ラ ス A B を 混 在 さ せ な い で 用 い る 場 合 の ，provide-require 関係を表した図である．
頂点はメソッドを表し，実線の矢印はメソッドの呼出し関係を表している．また，点線は，メソッド呼出しによって起きるデータフローを表しており，矢印の基点に，受渡されるオブジェクトの提供するインタフェースが記述されている．
この図では，クラス A, B の要求は満たされており， Method-NotFound が発生することは無いと分かる．
図 8 は， A B を混在させて用いた場合の provide-require関係を表した図である．この図では， C のバージョン 1, 2 のどちらを用いたとしても， A B 両方の要求を満たすことは出来ないことが分かり， MethodNotFound が起きる可能性があることが分かる．条件を満たさない部分から，データフローを—4—

図8

図9

例 1 で， A と B を混在させた場合

問題 2 の初期状態と C をバージョン 2 で差し替えた状態逆にたどり，クラスのコンストラクタに至るまでの経路に含まれるメソッドが問題の原因である．

4. 2 例 2 に適用した場合

ラス D を作り， C の代わりに B に渡すことで，解決できる．

5. ま と め

2. 2 節の問題は，一見，クラス B に問題があるように見え

本論文では， Java 言語を対象として，サブシステムの互換る．しかし実際には，クラス A で生成されたオブジェクトが性を確認する手法を提案した．提案した手法では，データフ

B に渡される時に，要求を満たしていない事が分かる．(図 9)

ロー解析を利用して，オブジェクトの提供するインタフェース

そこで，図 10(b) のように，クラス A は， C を継承したク

情報と，サブシステムの要求するインタフェース情報の関係か—5—

(a) C を継承したクラス D で代用(b) provide-require 関係

図 10

問題 2 の C をバージョン 2 で差し替えた状態

ら，サブシステムの互換性を計算する．
将来の課題としては，まず，手法を実装し，実際のソフトウェアシステムに適用することが挙げられる．次に，互換性の無いシステムであると判断した場合に，修正方法を自動的な提案する手法を考案したいと考えている．また，システムを検査した
結果，用いられることの無いメソッドやフィールドがあると分かった場合に，それらのメソッドやフィールドを除去することが出来れば，少ない資源でシステムを動作させることが出来るだろう．

Java 以外のオブジェクト指向言語への適用も，課題の一つである．
文

献[1] The java language specification.
http://java.sun.com/docs/books/jls/secondedition/html/j.title.doc.html.
[2] The java virtual machine specification.
http://java.sun.com/docs/books/vmspec/2ndedition/html/VMSpecTOC.doc.html.

—6—