研究速報
2. メソッド抽出を必要とする兆候
メソッド抽出の必要性を評価するソフトウェアメト

出がある [2]．メソッド抽出とはメソッド内のコードのリックスの提案
三宅達也†井上克郎†（正員）

肥後 芳樹†（正員）

一部を新規メソッドとして抽出するリファクタリングである．以下では，メソッド抽出の必要性を示す既存

A Software Metric for Identifying Extract Method Candidates
Tatsuya MIYAKE† , Nonmember, Yoshiki HIGO† , andKatsuro INOUE† , Members†

典型的なリファクタリング作業の 1 つにメソッド抽の不吉な匂いと，それを定量的に表すソフトウェアメトリックスに関して述べる．
長すぎるメソッド 長すぎるメソッドはメソッド抽出

大阪大学 大学院情報科学研究科，豊中市

Graduate School of Information and Science Technology, Os-を行うことにより，短くすることが望ましい [2]．メ

aka University, Toyonaka-shi, 560-8531 Japan

ソッドを短くすることにより，可読性や再利用性が向上する．このため，メソッドの行数を表すソフトウェアメトリックスである LOC(Lines Of Code) が大き

あらまし リファクタリングはソフトウェアの設計

いメソッドはメソッド抽出の候補であるといえる．

品質を改善するための有効な技術である．しかし，ど制御フローの複雑なメソッド 制御フローの複雑なメのようなときにリファクタリングが要求されるかを判

ソッドもメソッド抽出の候補である．MaCabe は制断するのは容易ではない．そこで，本論文ではメソッ

御フローの複雑さを表すソフトウェアメトリックスとド抽出リファクタリングを行う必要のあるメソッドのしてサイクロマチック数 (以降，CYC) を提案してい候補を自動的に識別するためのソフトウェアメトリッ

る [5]．この値は直観的にはソースコード上の分岐の数クスを提案する．また，定性的な評価や適用事例を通に 1 を加えた数を表し，値が大きいほどそのメソッドして，提案メトリックスを用いることにより，既存のの制御フローは複雑であるといえる．経験的に CYC

メトリックスでは識別できないメソッド抽出リファクは 10 以下に抑えることが望ましいといわれている [5]．

タリングの対象を識別できることを示した．

凝集度の低いメソッド 凝集度はモジュール内の構成

キーワード リファクタリング，ソフトウェアメトリックス

要素が特定の機能を実現するため協調している度合を表す．メソッドの凝集度を表すメトリックスにはプロ

1. は じ め にグラムスライスを用いる手法が提案されている [6]．こリファクタリングとはソフトウェアの外部的振る舞のメトリックスが低いメソッドはプログラムスライスいを保ったまま，ソフトウェアの内部構造を改善するを用いたメソッド抽出の候補である [4]．凝集度は 7 つ

ことによりソフトウェアの設計品質を高める技術であのレベルに分けることができ，通常，メソッドの凝集る [2]．しかし，どのようなときにリファクタリング

度は最も高いレベルであることが望ましい [7]．プログが要求されるかについての厳密な基準は存在しない．

ラムスライスを用いたメトリックスはそのうちの下位

Fowler は過去の経験や知識をもとにリファクタリング

4 つを凝集度の低いモジュール (メソッド抽出の候補)が要求される可能性を示すいくつかの兆候 (不吉な匂として識別できるが，最上位 (機能的凝集) より低い 2い) を定義している [2]．また，それらの不吉な匂いのつのレベル (逐次的・通信的凝集) にあるモジュールをいくつかはモジュールの行数やサイクロマチック数な識別することができない場合が多い．これは出力変数

どの複雑度メトリックスを用いて定量的に示すことが(返り値やメソッド内で変更される属性など) のみに着できる．しかし，本来モジュールは行数や複雑さでは目してメトリックスが計測されるためである．

なく，機能に基づいて分割することが望ましい．

3. 提案メトリックス: COB

モジュールの機能はモジュール内の構成要素が協調オブジェクト指向には，処理 (機能要素) および処しあって実現される．本論文ではメソッドの構成要素

理に必要なデータ (データ要素) を 1 つにまとめるとの協調度合に着目することにより，メソッド抽出リファいう重要な考え方がある．同様に，機能要素が必要とクタリングを必要とするメソッドの候補を自動的に識しないデータ要素は互いに分離しておくことが望まし別するための新しいメトリックスを提案する．また適い．この考えに基づき構成されたモジュールは機能要用事例を用いて既存のメトリックスとの比較を行い，素とデータ要素が互いに協調しており，凝集度が高く提案メトリックスの有効性に関して議論する．

なる．クラスの場合，その度合を表すメトリックスと電子情報通信学会論文誌 X Vol. Jxx–X No. xx

pp. 1–3 xxxx 年 xx 月

1

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx

調している．一方，BLOCK1，2 で構成されるコード

ǀŽŝĚƐĂŵƉůĞ;Ϳ΂ŝŶƚ ǀϭ͕ǀϮ͕ǀϯ͕ǀϰ͖䊶䊶䊶䊶䊶䊶䊶䊶䊶䊶>K<ϭ ΂ǀϭсǀϭнǀϮ͖΃>K<Ϯ ΂ǀϮсǀϭнн͖΃>K<ϯ ΂ǀϯсǀϯнǀϰ͖΃>K<ϰ΂ǀϰсǀϯнн͖΃΃ϭϯǀϮǀϮǀϭǀϭǀϰǀϰǀϯǀϯϮ

いない．このとき COB の値は 0.5 となる．変数 v4 の使用を変数 v1 の使用に置き換えたとき，図 1(c) のよϰǀϮǀϮǀϭǀϭ

うに全てのコードブロックが変数 v1 を介して協調するため，COB の値は 0.66 に上昇する．さらに，変数(b) sample() の抽象図

ϭ

片と BLOCK3，4 で構成されるコード片は協調してv3 と使用を変数 v2 の使用に置き換えると全変数が全Ϯ

コードブロックで使用され COB は最大値 1 となる．
ここで，呼び出し関係にある 2 つのメソッドについて考える．一方のメソッド内のローカル変数は基本的ϯ

ǀϭ

ǀϭ
ǀϯ

ǀϯ

ϰ

(c) sample() の抽象図 (変数 v4 を変(a) sample() メソッド数 v1 に置換)

図 1 サンプルコードFig. 1 A sample codeにもう一方のメソッドからはアクセスできない．引数を利用してアクセスすることは可能であるが，2 つのメソッドが適切に切り分けられているとき引数の数は少なくなる傾向がある．このため，適切に切り分けられた 2 つのメソッドを 1 つにまとめたとき，メソッド内の要素の協調状況は図 1(b) と似たものになり，COBは低くなる．このことから，COB の低いメソッドはして LCOM が提案されている [1], [3]．LCOM は属性メソッド抽出を行い，2 つに分割するべきメソッドのをデータ要素，メソッドを機能要素とみなし，その協候補であるといえる．

調度合を表す．

既存のメトリックスと比べ，COB は次の利点を持つ．

本論文では，メソッドの構成要素の協調度合を示すため，メソッド内で使用されている変数をデータ要素，コードブロックを機能要素とみなし，ソフトウェアメ•

メソッド内の要素の協調度合を表すため，LOC

や CYC より機能に基づいた評価が行える．

•

LOC や CYC と異なり適切にメソッド抽出しトリックス COB(Cohesion Of Blocks) を次のようにた場合のほうが，元のメソッドと新規メソッドのメ定義する．b はメソッド内のコードブロックの数，vトリックス値が高くなる．例えば，図 1(b) においてはメソッド内で使用されている変数の数，Vj はメソッ

BLOCK1 と BLOCK3 をメソッド抽出しても COB

ド内で使用されている j 番目の変数，μ(Vj ) は変数 Vjは変化しないが，BLOCK1 と BLOCK2 をメソッドを使用しているコードブロックの数を示す．

抽出した場合は上昇する．

COB =

11bv

v
Xμ(Vj ) (0 <= COB <= 1)

jCOB は LCOM* [3] と同様に，特定のデータ要素と協調する機能要素の割合の平均に着目している．

•

出力変数だけでなく全ての変数に着目するため，逐次的・通信的凝集が機能的凝集よりもメトリックス値が低くなる傾向がある．

4. 適 用 事 例
既存のソフトウェア (apache-ant-1.7.0) に対して

図 1(a) の sample メソッドコードを用いて COB 計

COB，LOC(空白・コメントを含む)，CYC を計測し，測の例を示す．sample メソッド内の BLOCK1-4 はそれぞれのメトリックスごとに，メトリックス値の大コードブロックを示す．また，図 1(b) は sample メ

きさでソートし，上位 20 メソッドをメソッド抽出のソッドの構成要素であるコードブロックと使用されて候補として検出した．

いる変数の協調関係を抽象化した図である．図 1(b)計測の結果，COB でソートした場合は 0.066 以下，において四角はコードブロックを，四角内の円はそのLOC の場合は 146 以上，CYC の場合は 22 以上のメ

コードブロック内で使用されている変数を，点線は 2

トリックス値をもつメソッドがメソッド抽出の候補とつのコードブロックが変数を介して協調しているこして検出された．検出されたメソッドのうち COB でとを意味する．図 1(b) からわかるように，sample メ

ソートした場合のみ検出された 6 つのメソッドを表 1

ソッドは BLOCK1 と BLOCK2 は変数 v1,v2 を介しに示す．6 つのメソッドをメソッド名やコードコメントて協調している．同様に BLOCK3 と BLOCK4 も協をもとに調査した結果，JUnitTestRunner#main メ

2

レター

ソッド以外のメソッドはメソッド抽出の対象として適当であると判断できた．JUnitTestRunner#main メ
ソッドに関してはコードコメントが存在しなかったた
め評価を控えた．
図 2 にメソッド抽出候補の例としてメソッド Con-cat#validate の概略を示す．このメソッドは 6-37 行の範囲に含まれるコードブロック群内では 10 個の変数が，38-89 行の範囲に含まれるコードブロック群では 14 個の変数が使用されていたが，6-37 行と 38-89行の両方の範囲内で使用されている変数は 2 個であった．つまり，片方の範囲で使用されている変数のほとんどがもう片方では使用されておらず，互いに協調していなかった．このため，COB が減少し，メソッド抽出の候補として検出された．また，このメソッドは 6行と 38 行のコードコメントから，6-37 行のコード片はバイナリデータとして入力の正当性検証を，38-89

ϬϭƉƌŝǀĂƚĞZĞƐŽƵƌĐĞŽůůĞĐƚŝŽŶ ǀĂůŝĚĂƚĞ;Ϳ΂䊶䊶䊶䊶䊶䊶䊶⋭⇛䊶䊶䊶䊶䊶ϬϲͬͬŝĨďŝŶĂƌǇĐŚĞĐŬŝĨŝŶĐŽŵƉĂƚŝďůĞ䊶䊶䊶ϬϳŝĨ;ďŝŶĂƌǇͿ΂䊶䊶䊶䊶䊶䊶䊶⋭⇛䊶䊶䊶䊶䊶ϯϯ΃䊶䊶䊶䊶䊶䊶䊶⋭⇛䊶䊶䊶䊶䊶ϯϴͬͬ^ĂŶŝƚǇĐŚĞĐŬŽƵƌŝŶƉƵƚƐ͘ϯϵŝĨ;ƌĐ сŶƵůůΘΘƚĞǆƚƵĨĨĞƌ сŶƵůůͿ΂䊶䊶䊶䊶䊶䊶䊶⋭⇛䊶䊶䊶䊶䊶ϰϯ΃ϰϰŝĨ;ƌĐ ͊сŶƵůůͿ΂ϰϱŝĨ;ƚĞǆƚƵĨĨĞƌ ͊сŶƵůůͿ΂ϰϲƚŚƌŽǁŶĞǁƵŝůĚǆĐĞƉƚŝŽŶ;䊶䊶䊶Ϳ͖ϰϳ΃ϰϵZĞƐƚƌŝĐƚŶŽĞǆŝƐƚZĐ сŶĞǁZĞƐƚƌŝĐƚ;Ϳ͖䊶䊶䊶䊶䊶䊶䊶⋭⇛䊶䊶䊶䊶䊶ϴϵ΃ϵϬ΃;ϬϲͲϯϳⴕͿ૶↪ᄌᢙᢙ͗ϭϬਔᣇ䈪૶↪䈘䉏䈩䈇䉎ᄌᢙᢙ͗Ϯ;ϯϴͲϴϵⴕͿ૶↪ᄌᢙᢙ͗ϭϰ

図 2 COB を用いて検出されたメソッド抽出候補の例
Fig. 2 An example of Extract Method candidates
identiﬁed by COB

行のコード片はソースコードとして入力の正当性検証を行っていることがわかり，38 行を境に 2 つのメソッドに分割することが適切であると判断できた．

謝

辞

本研究は一部，文部科学省「次世代 IT 基盤構築の5. まとめと今後の課題ための研究開発」（研究開発領域名：ソフトウェア構築

本論文では，メソッド抽出の候補を識別するために，状況の可視化技術の開発普及）の委託に基づいて行わメソッド内の構成要素の協調度合を示すソフトウェアれた．
文

メトリックス COB を提案した．適用事例では COBを用いることにより，LOC や CYC などでは識別で[1]

Software Engineering, 25(5):476–493, Jun 1994.
[2]

M. Fowlor. Refactoring: improving the design of[3]

B. Henderson-Sellors.とは異なる要素に着目して協調度合を評価しているため，両方のメトリックスを用いることにより，機能に基づいたメソッド抽出候補の検出を多角的に行うことができると考えられる．

A Metric Suite

for Object-Oriented Design. IEEE Transactions on

きないメソッド抽出の候補を識別できることを示した．
また，COB はスライスベースの凝集度メトリックス

献

S. Chidamber and C. Kemerer.

existing code. Addison Wesley, 1999.
Object-Oriented Metrics:

Measures of Complexity. Prentice Hall, 1996.
[4]

J. Krinke.

Statement-Level Cohesion Metrics andtheir Visualization. In Proc. of the 7th International

今後の課題としては，より多くのソフトウェアに対Working Conference on Source Code Analysis andManipulation, pp. 37–48, Sep 2007.

して適用することにより，より定量的に有効性を評価[5]する必要がある．

T. McCabe. A Complexity Measure. IEEE Transactions on Software Engineering, 2(4):308–320, Dec
1976.

[6]

L. M. Ott and J. J. Thuss. Slice-based metrics for estimating cohesion. In Proc. of the 1th International

表 1 COB を用いた場合のみメソッド抽出の候補となる
メソッド
Table 1 Extract Method candidates identiﬁed only
by COB
メソッド名
DirectoryScanner#scan
ModiﬁedSelector#conﬁgure
Parallel#spinThreads
JUnitTestRunner#main
Concat#validate
MacroDef#sameOrSiminlar

COB
0.066
0.065
0.065
0.065
0.060
0.055

LOC64115
136
1068955

CYC121817192016

Software Metrics Symposium, pp. 71–81, 1993.
[7]W. Stevens, G. Myers, and L. Constantine. Structured Design. IBM Systems Journal, 13(2):115–139,1974.

（平成 xx 年 xx 月 xx 日受付）

3

Abstract Refactoring is an eﬀective technique to improve design quality of software. However, it is noteasy to identify where to be refactored. This paper proposes a software metric to automatically identify
Extract Method Candidates. A case study shows the proposed metric is useful to identify Extract Method
candidates that existing metrics cannot identify.
Key words Refactoring, Software Metrics