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

信学技報
TECHNICAL REPORT OF IEICE.

Java プログラムにおける設計情報を用いた
意図的なアクセス修飾子過剰性の抽出手法
大西 理功†

小堀 一雄††

松下誠†

井上 克郎†† 大阪大学大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1 番 5 号†† 株式会社 NTT データ 技術開発本部〒 135-8671 東京都江東区豊洲 3-3-9
E-mail: †{r-ohnisi,matusita,inoue}@ist.osaka-u.ac.jp, ††koborik@nttdata.co.jp
あらましJava プログラム内には，実際の被アクセス範囲より広い範囲が設定された状態である，アクセス修飾子

過剰性 (Accessibility Excessiveness, AE) が多数存在することが既存研究により判明している. しかし, 既存研究では,

AE が設計者の意図により生まれたかどうか判別できていない．そこで本研究では, Java プログラムの設計情報を用
いて, 設計者の意図により生じた AE を判別する手法を提案する. また, 既存のソフトウェアに適用することで，本手法の有効性を考察する．
キーワード

アクセス修飾子，Java プログラム，開発履歴，設計情報

A Detection Method for Intended Accessibility Excessivenessin Java Programs Using Design Information
Riku OHNISI† , Kazuo KOBORI†† , Makoto MATUSITA† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University
Suita, Osaka 565-0871, Japan†† Research and Development Headquarters, NTT DATA Corporation
Toyosu 3-3-9, Koto-ku, Tokyo 135-8671, Japan
E-mail: †{r-ohnisi,matusita,inoue}@ist.osaka-u.ac.jp, ††koborik@nttdata.co.jp
Abstract In Java Program, we have found there are many access modifiers that have the status Accessibility
Excessiveness(AE) which is declared more extensive area than its real access. In previous research, we couldn’t
decide whether an AE was made by designer’s intention or not. In this paper, we propose a detection method forintended Accessibility Excessiveness in Java programs using design information. We also discuss the validity of themethod by applying to an existing example software.
Key words Access Modifier, Java Program, Development History, Software Design

1. は じ め にこういった問題を防ぐために，Java ではアクセス修飾子を適切に設定することで，意図しないフィールドやメソッドへのア

現在のソフトウェア開発においては，大規模化や短納期化なクセスを防止することができる [1] [2]．しかし，全てのフィーどに伴い，複数の開発者がチームを組んで設計，プログラミン

ルドおよびメソッドに関する適切なアクセス範囲を把握するこグ，テストを実施することが多い．チームに所属する開発者はとはコストがかかるため，何らかの支援が必要であると考えた．

全員がソースコードの仕様を完全に把握していることが望まし

我々は こ れ ま で ， ア ク セ ス 修 飾 子 過 剰 性 検 出 ツ ー ル

いが，コストや期間の関係上難しい場合がある．その場合，例

ModiChecker を開発した [6]．ModiChecker は，ソースコー

えば Java を用いた開発の場合には，ソースコード上のフィード群に対して，アクセス修飾子の宣言とフィールドとメソッド

ルドやメソッドに対して設計時には意図していない不適切なアの被参照状況を静的に解析して，過剰に広い範囲に設定されたクセスの仕方をプログラミング時に行ってしまう可能性がある．

可能性のあるアクセス修飾子を抽出する．これにより，開発者—1—

表 1 アクセス修飾子の種類
アクセス修飾子

アクセスを許容する範囲

public

全ての部品

protected

自身と同じパッケージに所属する部品
および自身のサブクラス

default

自身と同じパッケージに所属する部品

private自身と同じクラス

public class X {// フィールド y の初期値は null．
private String y = null;// フィールド y に値を設定する．
// クラス外から呼ばれることを想定していない．
private methodA( ) {y = new String( hello );}は意図しないフィールドやメソッドへのアクセスを事前に防止// フィールド y の文字列長を返す．

できる．さらに，ModiChecker の分析対象にどこからも参照さ// クラス外から呼ばれることを想定していない．

れていないフィールドやメソッドを含めることにより，ユーザ

public methodB() {がアクセス修飾子の修正を効率的に行えるような支援機能を追y．length();

加した [7].

}

一方で，アクセス修飾子過剰性には，設計者が意図したも// 値の設定されたフィールド y の文字列長を返す．

のとそうでないものが考えられるが，この既存研究ではその// クラス外から呼ばれることを想定している．

区別が考慮されていなかった．本研究では，設計者の意図はソ

public methodC() {フトウェアの設計情報に現れると考え，その中でもアクセス

this.methodA();

修飾子の設定に関係のある UML クラス図を分析することで，

this.methodB();

ModiChecker にアクセス修飾子過剰性を意図的なものとそうでないものに分類する機能を追加した．機能を実装するに当た
り，ソフトウェアの設計情報を用いることで設計者の意図した
アクセス修飾子の検出を行う手法を提案する．
本論文の構成について説明する．2 節では，研究の背景となる Java アクセス修飾子の仕様および過剰なアクセス修飾子の宣言によって引き起こされる問題について述べる．3 節では，
アクセス修飾子の過剰性の定義や分析するツール ModiCheckerについて述べる．4 節では意図的な AE を検出する手法について，5 節では，開発ツールによるソフトウェア内の意図的なア
クセス修飾子の分析について述べる．6 節で関連研究について，

7 節で本論文のまとめと今後の研究について述べる．

2. アクセス修飾子によって引き起こされる問題}}
上記のソースコードでは，まずメソッド methodA を呼び出して y にオブジェクトを代入した後メソッド methodB を呼び出す必要がある．そこで，そのようなメソッド呼び出し
順序を実装したメソッド methodC を用意した．このメソッド

methodC は外部から呼び出されることを期待して作られているため，アクセス修飾子を public に設定した．一方，メソッド

methodB は外部から直接呼び出されてはならないにもかかわらず，アクセス修飾子を public に設定してしまっている．これ
により，methodA を呼ばずに methodB を呼ぶことが可能となってしまう．このような呼び出され方をした場合，フィール
ド y が初期値 null の状態でメソッド length が呼ばれるため，
例外 NullPointerException が発生する．

Java の言語仕様では，フィールドやメソッドに対して外部
からのアクセス範囲を制限できる修飾子を宣言することができ

このように，アクセス修飾子が過度に広く設定されている場
合，意図しないメソッド呼び出しが不具合を産む．また，開発る．これをアクセス修飾子と呼ぶ．Java のアクセス修飾子は途中において開発者間で設計情報が共有されていない場合，想表１に示す 4 種類があり，上にいくほど広い範囲からのアクセ

定外の状況下でメソッドが呼ばれてしまい，論理的なバグ発生

スを許容する [3]．
特に，クラスの外部から直接変更されるとプログラムの動作に異常をきたすようなフィールドは，クラス外部からの直接ア
クセスを許可しないアクセス修飾子 private を宣言しておくこの原因が作られる．しかし，この状況は Java の構文上問題がな
いため，コンパイラ等を用いて機械的に検出することは難しい．
また，全てのアクセス修飾子が適切に設定されているかどうかを，レビューによって確認するには高いコストが必要である．

とで，フィールドの利用方法をクラス設計者の想定内に収めることができる．これをカプセル化と呼び，オブジェクト指向プ
ログラミングの主要な性質の１つとされている [4]．ところが実際には，ソフトウェアを開発する際，各部品の最終的なアクセ
ス範囲が不透明なままコーディングを開始することがあり，そのような状況では最終的に必要なアクセス範囲以外からのアクセスを許可するアクセス修飾子を設定することがある [5]．この問題を以下に示す 3 つのメソッドを持つクラス X を例に説明する．

3. ModiChecker
我々は，指定された Java のソースコード群に宣言されたメ
ソッドとフィールドに対して，宣言されているアクセス修飾子と実際に呼び出されている範囲との差異を表現する Accessibility

Excessiveness (以下 AE) を定義し，AE をソースコード中から検出するためのツール ModiChecker を開発した [6]．本節では，AE と ModiChecker について説明する．
宣言されているアクセス修飾子と，実際にアクセスされている範囲の組み合わせにより，表 2 の背景色がある位置に示す—2—

るため，View からのアクセスを意図して設定されたアクセス

表 2 AE の種類*

publicprotected

default

privateNo Accesspublicpub-pub

pub-propub-def pub-pri

pub-naprotected×

pro-propro-def

pro-pri

pro-nadefault××

def-def

def-pri

def-naprivate×××

pri-pripri-na**修飾子は AE として判断されることになる．このような場合，
ソースコードだけでなく設計情報まで解析対象を広げることにより，ソースコードの解析だけでは判断できないアクセス関係を入手した上で AE の解析を行う必要がある．
そこで，ModiChecker から出力される AE に対して，設計者の意図するアクセス修飾子と意図しないアクセス修飾子を分*列タイトル：実際にアクセスされている範囲

類することで，本当に修正しなければならない AE（意図的で**行タイトル：宣言されているアクセス修飾子ない AE）を開発者に推薦する際の適合率を上げることを試みた．意図的な AE は，設計者が意図的に広い範囲となるよう設定したアクセス修飾子を指しており，開発者が設計情報やそのpub-pro，pub-def，pub-pri，pro-def，def-pri，pub-na，prona，def-na，pri-na の 10 種類を AE として定義する．表中のNo Access は，対象のフィールドまたはメソッドが実際にはアクセスされていないことを示す．例えば，pub-pro とは， アクセス修飾子として public が宣言されているフィールドまたはメ
ソッドで，かつ，実際にアクセスされている範囲は protectedと同じである状態を意味する．
一方，pub-pub, pro-pro, def-def そして pri-pri は，メソッドやフィールドのアクセス修飾子の宣言と実際にアクセスされている範囲が等しい状態，つまり適正な宣言が行われている状態を意味する．また，表 2 で × と表示されている箇所の記述は通常コンパイラによりエラーとして検出される状態を意味する．

ModiChecker は，与えられたソースコード中の AE であるフィールドやメソッドを探し出し，現在宣言されているアクセス修飾子，静的解析によって判明した実際にアクセスされている範囲をリスト (以下, AE リストと呼ぶ) で出力する．このよ
うに，ModiChecker を用いることで，開発者はソースコード
中で AE であるフィールドおよびメソッドの状態を知ることができる．

4. 意図的なアクセス修飾子の検出手法

他の情報を参照することでアクセス修飾子で指定されたアクセ
ス可能範囲が意図されているかどうかを判別可能であるとする．

AE リストから全ての意図的な AE を除去することができれば、既存の ModiChecker の修正機能を用いることで，不要な AEを全て除去することができる．
本研究では，意図的でない AE の再現率を落とすことな
く適合率を伸ばすことを目的とする．具体的には，既存のModiChecker が求めた AE リストから意図的な AE をリストから取り除き，修正が必要なものの割合を大きくすることを目指す．また，提案手法により，設計情報から分類できなかった
意図的な AE については，設計情報そのものに対するフィード
バックとなりうると考える．本来，設計者の意図する AE は，
設計情報に記述されているべきであり，意図的な AE を設計情報に反映させることで，設計情報を，ひいてはソフトウェアをより高品質なものにすることができる．
以下，提案手法の具体的な処理について述べる．

4. 1 設計情報の利用
AE から意図的なアクセス修飾子を検出するために，設計者の意図が反映される設計情報を利用する．設計情報のモデルとしては，一般的に普及している UML を用いる．
設計情報からフィールドやメソッドのアクセス修飾子の情報

既存ツールである ModiChecker には，入力として与えられる Java プログラム内のフィールドやメソッドに対するアクセス関係を静的解析により読み取り，AE となっているフィール
ドやメソッドの実際の被アクセス関係をカバーする最小限のア
クセス範囲を持つアクセス修飾子を推薦・修正する機能が存在する．
しかしこの機能では，静的解析したプログラム内でのアクセス関係が考慮された AE が出力され，プログラム外からのアクセス関係は考慮されず，結果としてプログラム外からのアクセスを考慮した上での意図的な AE に関する判別は行われない．
例えば，MVC(Model View Controller) モデルを実装したプ
ログラムでは，ユーザからの入力は View を通じて Controllerを呼び出し，Controller がユーザからの入力に対応した必要な Model を呼び出すという関係にある．また，MVC モデルをJava で実装した場合，Controller と Model は Java で実装され，View は HTML や JSP といった別の形式で実装されることがある．この場合，ModiChecker に Controller と Model を入力として与えても，View からのアクセスは解析対象外となを取得するために，クラス図を用いる．また，フレームワークなどとの動的なアクセス関係を取得するために，シーケンス図を用いる．本研究では，これら 2 つのモデル図を利用し，設計者の意図したアクセス修飾子の検出を行う．

UML モデルの設計情報は基本的に図表現により与えられるため，設計情報を文書として処理するために文字列に変換する．
ここでは UML モデリングツール astah* [8] を利用し，UML
モデル図を XML 出力する．ただし，XML 形式で出力される情報には，UML モデルを管理する astah* のプロジェクト情報が含まれるため，必要な情報のみを抽出する必要がある．後述
する ModiChecker の追加機能にて，XML から必要な情報を抽出する処理を実装している．

4. 2 ModiChecker の追加機能
ModiChecker の追加機能として，従来の ModiChecker の出力である AE リストと，設計情報を解析するアナライザ機
能を実装した．アナライザの機能としては，前述したように，

ModiChecker の出力する AE には意図的な AE と意図的でな
い AE が混在しているため，AE リストから意図的な AE を判—3—

別・除去する役割を担っている．

フィールドやメソッドのアクセス修飾子と所属クラスを取得
する．

2 つ目の処理は，ModiChecker から得られる AE となっていᚑ᮶䛾ᡭἲ

るフィールドやメソッドに対して、設計情報の該当するフィーDŽĚŝŚĞĐŬĞƌ㛤Ⓨ⪅ពᅗⓗ䛺;ពᅗ䛧䛶Ⓨ⏕Ϳ

設計情報のそれを比較する．これらのアクセス修飾子が一致しᥦ᱌䛩䜛ᡭἲ
ពᅗⓗ䛷䛺䛔䠄䝭䝇ᐇ⿦䛻䜘䜚Ⓨ⏕䠅DŽĚŝŚĞĐŬĞƌ

ĂƐƚĂŚΎタィ᝟ሗᅗ⾲⌧ている場合，該当フィールドやメソッドについて，ソースコー
ドが設計者の意図に従って実装されているとして，意図的な䛾䝸䝇䝖

䝋䞊䝇䝁䞊䝗



ルドやメソッドを所属クラスにより判別し，ソースコード上で設定されていた該当フィールドやメソッドのアクセス修飾子と䛾䝸䝇䝖

䝋䞊䝇䝁䞊䝗

タィ᝟ሗ䛛䜙⮬ືⓗ䛻ពᅗⓗ䛺䜢ุู䜰䝘䝷䜲䝄

AE と判断する．そして，意図的な AE と判断されたフィール
ドやメソッドについては，ModiChecker から得られていた AE
リストから除去する．

タィ᝟ሗ
ᩥᏐิ⾲⌧

㛤Ⓨ⪅

5. 提案手法を用いたアクセス修飾子の意図分析
4 節で説明した意図的なアクセス修飾子の検出手法を用いて，

図1

意図的な AE の検出手法

Fig. 1 detection method of intended AE

実際のプロジェクトで発生している AE に対し，検出手法により意図されない AE がどの程度削除されることなく維持されるのか (再現率)，および手法を適用した前後で全ての AE に対し

図 1 は，設計情報を用いて AE リストから意図的な AE を検て意図されない AE の割合はどの程度になるのか (適合率) に出する手法の概略図であり，従来のソースコードのみを用いたついて分析を行った．今回分析を行うにあたって，2 つの研究

場合との対比を示している．従来の場合は，開発者がリストの課題を設定した．

全ての AE が意図的な AE か否かを判断していたのに対し，提RQ1 検出手法により意図的でない AE が削除されることな案手法では，AE リストから自動的に意図的な AE の一部が取く，すべて検出されるかどうかり除かれる．

RQ2 検出手法の適用前後で，最終的に提示される AE のう

設計情報を用いて，AE リストから意図的な AE を判別・削除

ち，意図的でない AE はどの程度含まれるかするアナライザについて説明する．アナライザは，ModiChecker

本研究では， 文部科学省の助成事業 enPiT [9] のプログラから AE リストを，astah*から設計情報を受け取り，フィール

ムの 1 つである，“enPiT Cloud”の演習で用いられた Javaドやメソッドのアクセス関係が乖離している部分，ソースコーのプログラムと UML モデルの設計情報を伴うソフトウェア

ドと設計情報のアクセス修飾子が異なっている部分を探し出“EventSpiral”を実験対象とした．以下，RQ1,RQ2 についてのす．これは，AE となっているアクセス修飾子を対象とし，ソー分析手順をそれぞれ示す．

スコード上のアクセス関係から推薦されるアクセス修飾子が，設計情報におけるアクセス修飾子すなわち設計者の意図した

アクセス修飾子と異なっている場合，当該 AE を修正する必









要のないものと判断している．アナライザは，AE リストのうK<ち，設計情報から判別できる意図的な AE を除外したものを，

ModiChecker の利用者に提供する．これにより，設計情報を用

䜰䝘䝷䜲䝄

yϭ͘

෌⌧⋡ϭϬϬйyϮ͘෌⌧⋡ϲϲ͘ϲ͘͘й䛾䝸䝇䝖

E'

いて分類できる一部の意図的な AE が取り除かれるので，開発者が確認する AE リストのうち，修正の必要ないものを減らすことが出来る．

4. 2. 1 アナライザពᅗⓗ䛺

ពᅗⓗ䛷䛺䛔

アナライザの処理は，大きく分けて 2 つある．1 つ目は astah*で記述された設計情報を解析し，フィールドやメソッドのアクセス修飾子および UML 図上での接続関係などを抽出をする処

図 2 RQ1

Fig. 2 RQ1理である．2 つ目は，設計情報と ModiChecker より得られるAE リストのフィールドやメソッドのアクセス修飾子の比較を

RQ1 に着目した，アナライザの適用前後での AE リストの行い，該当フィールドやメソッドが意図的な AE かを判断し，変化を図 2 に示す．RQ1 はアナライザの適用前後で意図的でそうであれば，AE リストから除去する処理である．

ない AE が削除されることなく検出されるかを確認する．ソー

1 つ目の処理は，対象 Java のソフトウェアの設計情報からスコードの任意のフィールドやメソッドをランダムに選定して，アクセス修飾子などの必要な情報を抽出するという処理であ

アクセス修飾子を編集することで故意に意図的でない AE を生る．クラス図のモデルを XML 形式に変換したものを対象に，成する．生成した AE を含めた AE リストをアナライザに適用—4—

し，意図的でない AE が検出されるかを確認し，RQ1 を分析

5. 3 RQ2 の分析実験

する．

5. 3. 1 実 験 方 法

RQ2 はアナライザ適用前後での AE の中の意図的でない AEの適合率を比較することで，分析を行うことを考えている．しかし，AE が意図的でない AE かどうかの判断ができないため，
正確な適合率を求めることができない．なぜなら，現在 AE が意図的な AE かどうかを設計情報のみで判断しているが，設計

RQ2 を分析するにあたり，アナライザの適用前後での意図的でない AE の候補数を求めた．

5. 3. 2 実 験 結 果
表4

メソッドにおける適合率についての実験結果

状況

全 AE の数

意図的でない AE の候補数

情報が意図を完全に表現していることを保証できないからであアナライザ適用前

92

92

る．そこで，検出手法により意図的でない AE が削除されるこ

アナライザ適用後

00となく検出されることを前提に，アナライザ適用前後での AEの数の変化を比較することで，適合率の変化を求める．

5. 1 実 験 準 備

表 4 より，メソッドにおいて，AE はすべて意図的な AE という結果が得られた．アナライザにより、意図的でない AE の本実験で，対象とするソフトウェア “EventSpiral”について簡単に説明する．本ソフトウェアは，イベント情報を登録・閲
覧し，開催されるイベントの参加チケットなどの購買する機能

候補が全て設計情報により意図的な AE と判断できる，つまりソースコード上のアクセス修飾子と設計情報におけるアクセス
修飾子が一致していたことを示す．

を提供するウェブサービスを実現する．本ソフトウェアのソー
スコードは，MVC モデルで実装された Java ソースコードによって成り立っている．また，設計情報として，UML モデルを利用している．基本的な機能は Java プログラムで実装されているが，フレームワーク処理などクライアント側とのイン

表 5 フィールドにおける適合率についての実験結果
状況

全 AE の数

意図的でない AE の候補数

アナライザ適用前

28

28

アナライザ適用後

28

28

タフェース部分やアカウント情報などデータを管理するデータベース部分は JavaScript や MongoDB など他の言語で実装さ

表 5 より，フィールドの AE は，いずれも意図的な AE とアナライザで判断できないことが分かる．AE のうち，18 個は例れている．
本実験では，RQ1，RQ2 の分析を行うにあたり，再現率，適外処理クラスの中で宣言されている．設計情報のクラス図において，例外処理クラスが存在しない．また，残り 10 個のフィー合率の順に実験を行った．

ルドのアクセス修飾子は，設計情報のそれと異なる．

5. 2 RQ1 の分析実験
5. 2. 1 実 験 方 法

5. 4 分析結果の考察

RQ1 を分析するにあたり，ランダムに選択した AE でない

RQ1 について，アナライザにより意図的でない AE が取りフィールドやメソッドを故意に意図的でない AE に変更し，変除かれないことを高い水準で保証しているように考えられる．

更した AE を含む AE リストを対象に 3 回のテストを行った．

ただ，設計情報に記述されていないクラスやメソッド，フィー

テストではアナライザの適用前後で AE の数を確認する．AE

ルドを想定し，そういったオブジェクトをどのように分類する

でないメソッドやフィールドのうち，AE に変更可能，すなわ

かは考える必要がある．ソースコードから設計情報へのリバー

ちアクセス修飾子の設定範囲を広げることができるものが，メスエンジニアリングを考えるのであれば，設計情報に漏れていソッドに 3 個，フィールドに 63 個確認できた．1 回目は 3 個る情報を付け足すことで，設計情報の品質を高めることが可能のメソッドを，2，3 回目のテストはそれぞれ 10 個のフィールである．また，今回の実験で，対象としたソフトウェアは 1 つ

ドを対象に行った．

のみであるため，アナライザの機能が検証されたとはいい難く，
複数のソフトウェアに対して適用する必要がある．

5. 2. 2 実 験 結 果

RQ2 について述べる．メソッドの適合率は，すべての AE が
表 3 再現率についての実験結果

意図的な AE という結果が得られた．意図的でない AE の候補

テスト

故意に作成した意図
しない AE のメソッド
あるいはフィールドの数

アナライザ適用後の故意に作成された AE のメソッド
あるいはフィールドの数

1

3

3

2

10

10

め，意図的でない AE は 0 個になる．一方，フィールドの適合

3

10

10

率は，設計情報によりいずれの AE についても意図的な AE で数は初期段階では ModiChecker の出力の AE リストそのものである．開発者が確認することで AE が意図的かどうかを判断するのだが，メソッドについては全て設計情報で説明できるたあるという説明ができなかったため，意図的でない AE の候補
表 3 は，メソッドやフィールドの意図的でない AE がアナラ
イザの適用によって，どの程度検出されたかを示している．今回の実験では，再現率は 100 ％を示しており，RQ1 について検出手法により意図的でない AE が削除されることなく，すべ数はアナライザ適用前の 28 個から変化しなかった．そこで設計情報により，意図的な AE かどうかの判断ができなかったものについては，設計情報に情報が不足している可能性があるた
め，設計情報にフィードバックする必要がある．

て検出されることを示す．

—5—

6. 関 連 研 究ていない．検出できていない部分に関しては，網羅的なテストを行うことが証明されているテストコードを分析対象に含める

6. 1 アクセス修飾子の解析に関する関連研究など，現手法の拡張を考える必要がある．さらに，ソースコー

アクセス修飾子の解析に関して，いくつかの研究がなされドの設計情報へのリバースエンジニアリングを行うことで，設ている．Müller は Java のアクセス修飾子をチェックするた

計情報の品質向上を実現し，ソフトウェアの現場でより高い精めのバイトコード解析手法を提案している [10]．この研究で度の保守・運用を実現する研究を行うことが考えられる．

は，我々と似た目的のために Java のバイトコードを解析する

今後の課題として AE を用いたプログラムの品質判定方法を

AMA(Access Modifier Analyzer) というツールを開発してい提案することで，プログラムのリリース時としていつが適切かる．しかし，バイトコードに対する解析は，コンパイル時に追を判断するための支援ツールの構築を行いたい．

加されるフィールドやメソッドの影響で，必ずしもソースコー
ドに対する解析と同じ結果にはならない．さらに，Müller はツールを用いた実践的な実験結果を報告していない．一方，我々の研究では実際に既存のソフトウェアに対して複数の側面から実験したデータを明示し，評価を行った．

Cohen は複数のサンプルメソッドにおける各アクセス修飾
子の数の分布を調査した [11]．Evans らは，静的解析によるセキュリティ脆弱性の解析を研究した [12]．これらの研究で課題となっているアクセス修飾子の宣言に関しては Viega らによって議論が行われている [13]．Viega らは，private にすべきだがそのように宣言されていないメソッドやフィールドについて，警告を出すツール Jslint を開発している．一方，我々の開発したツール ModiChecker では，private だけでなく全てのアクセス修飾子に対する警告を出すことができる．
アクセス修飾子の数をメトリクスとしている点については，
我々の過去の研究とも関連がある [14]．この研究では，Java のソースコードの類似性を計算するためのメトリクスの一部として，アクセス修飾子の宣言数が用いられている．

6. 2 ソースコードの静的解析に関する関連研究
Java に関するソースコード静的解析ツールは多数存在す
る [15] [16]．これらのツールはデッドロックやオーバーロード，
配列のオーバーフロー等のコーディング上の悪いパターンや，
潜在的なバグを検出するため，今日の Java プログラム開発では重要なツールである．

Rutar らは，このような機能を持つ５つのツールを比較分析
した [17]．しかし，これらのツールは，本論文のようにアクセス修飾子の冗長性を解析する機能を持っていない．

7. まとめと今後の課題
本 研 究 で は ，Java の ア ク セ ス 修 飾 子 を 分 析 す る ツ ー ル

ModiChecker を利用して，以下のことを行った．
（ 1 ） 設計情報を用いて設計者による意図的な AE を検出する手法を提案した（ 2 ） ModiChecker を拡張し，設計情報をもとに AE の中から本当に修正する必要がある AE を検出・分類する機能を開発し，その妥当性を検証した．
検証実験においては，本手法の適用により開発者に対して提示する AE について，意図的でない AE の再現率を落とすことなく，適合率を上げることに成功した．しかし，設計情報に記載のないものなど，意図的な AE の全てを検出するには到ら

謝辞

本研究は，日本学術振興会科研費基盤 (S)(課題番号25220003) の助成を得た．
その他，記載されている会社名，商品名，又はサービス名は，各社の登録商標又は商標です．
文

献[1] G. Booch, R. Maksimchuk, M. Engel, B. Young, J. Conallen
and K. Houston,: Object-Oriented Analysis and Design
with Applications , Addision Wesly, 2007
[2] K. Arnold, J. Goslin and D. Holmes,: The Java Programming Language, 4th Edition , Prentice Hall, 2005.
[3] J. Gosling, B. Joy, G. Steele, G. Bracha and A.
Buckley,:
The Java Language Specification, JavaSE 7 Edition, http://docs.oracle.com/ javase/specs/jls/se7/html/index.html[4] K. Khor, N. Chavis, S. Lovett and D. White,: Welcome to
IBM Smalltalk Tutorial , 1995
[5] Nghi Truong, Paul Roe, and Peter Bancroft,: Static analysis of students’ Java programs , In Proc. ACE ’04, 317-325,
2004.
[6] D. Quoc, K. Kobori, N. Yoshida, Y. Higo and K. Inoue,:
ModiChecker: Accessibility Excessiveness
Analysis Tool
for Java Program, 日本ソフトウエア科学会大会講演論文集
vol.29, pp.212-218, 2012, コンピュータ・ソフトウェア.
[7] 石居達也 小堀一雄 松下誠 井上克郎:アクセス修飾子過剰性の変遷に着目した Java プログラム部品の分析, 情報処理学会研究報
告 Vol.2013-SE-180, No.1, pp.1-8 2013[8] astah*, http://astah.change-vision.com/ja/[9] enPiT, http://www.enpit.jp/[10] A. Müller,: ”Bytecode Analysis for Checking Java Access
Modifiers , Work in Progress and Poster Session, 8th Int.
Conf. on Principles and Practice of Programming in Java(PPPJ 2010), Vienna, Austria, 2010.
[11] T. Cohen,: Self-Calibration of Metrics of Java Methods
towards the Discovery of the Common Programming Practice , The Senate of the Technion, Israel Institute of Technology, Kislev 5762, Haifa, 2001.
[12] D. Evans and D. Larochells,: Improving Security Using
Extensible Lightweight Static Analysis , IEEE software,vol.19, No.1, pp. 42-51, 2002.
[13] J. Viega, G. McGraw, T. Mutdosch and E. Felten,: Statically Scanning Java Code: Finding Security Vulnerabilities , IEEE software, Vol.17 No.5 pp. 68-74, 2000.
[14] K. Kobori, T. Yamamoto, M. Matsushita and K. Inoue,:
Java Program Similarity Measurement Method Using Token Structure and Execution Control Structure , Transactions of IEICE , Vol. J90-D No.4, pp. 1158- 1160, 2007.
[15] FindBugs, http://findbugs.sourceforge.net/[16] Jlint, http://jlint.sourceforge.net/[17] N. Rutar, C. Almazan, and J. Foster,:
A Comparison of
Bug Finding Tools for Java , 15th International Symposium on Software Reliability Engineering (ISSRE 04), pp.
245-256, Saint-Malo, France, 2004.

ず，結果として意図的でない AE の適合率１００％は達成でき—6—