(57)【特許請求の範囲】
【請求項１】
Ｊａｖａ（登録商標）ソースコードの品質をチェックする処理をコンピュータに実行させるプログラムであって、前記コンピュータに、
Ｊａｖａソースコードを記憶装置から読み込む読込ステップと、
前記Ｊａｖａソースコードに記述されているコメント部分のうち、Ｊａｖａ命令をコメントアウトした部分と、一般コメント部分とを区別し、Ｊａｖａ命令をコメントアウトした部分のみを検出するコメントアウト検出ステップと、
前記Ｊａｖａソースコードに記述されているコメント部分のうち前記Ｊａｖａソースコード内に記述されているＪａｖａクラスの作成者名を記述したタグ部分を検出し、そのタグ部分から前記作成者名を抽出する作成者抽出ステップと、
前記Ｊａｖａクラスのステップ数をカウントするカウントステップと、
前記読込ステップ、前記作成者抽出ステップ、および前記カウントステップを１以上の前記Ｊａｖａソースコードについて実行するステップと、
前記Ｊａｖａクラス１つ当たりのステップ数を前記作成者毎に集計してその結果を出力するステップと、
を実行させ、
前記コメントアウト検出ステップでは、前記コンピュータに、
前記Ｊａｖａソースコードを１行分読み込むステップと、
前記行読込ステップで読み込んだ行がコメント行であるか否かを判定するコメント行判定ステップと、
前記コメント行判定ステップにおいてコメント行であると判定した行の末尾に、Ｊａｖａ命令文の終端子、Ｊａｖａ言語における開始括弧、またはＪａｖａ言語における終了括弧が存在するか否かを判定するＪａｖａ命令判定ステップと、
前記Ｊａｖａ命令判定ステップにおいて、前記終端子、前記開始括弧、または前記終了括弧が行末に存在すると判定した場合、当該行は一般コメント行ではなく、Ｊａｖａ命令をコメントアウトしたコメントアウト行であると判定するステップと、
を実行させることを特徴とするＪａｖａソースコードチェックプログラム。
【請求項２】
前記コンピュータに、
１人の前記作成者が作成した全ての前記Ｊａｖａソースコードについて、全行数に対するコメント行の割合を算出するステップと、
前記作成者毎に前記割合を集計してその結果を出力するステップと、
を実行させることを特徴とする請求項１記載のＪａｖａソースコードチェックプログラム。
【請求項３】
前記コンピュータに、
前記作成者毎の前記Ｊａｖａクラスの作成数を集計してその結果を出力するステップを実行させる
ことを特徴とする請求項１または２記載のＪａｖａソースコードチェックプログラム。
【請求項４】
前記コンピュータに、
前記Ｊａｖａクラス内のメソッドの循環的複雑度を算出するステップと、
１人の前記作成者が作成した全ての前記Ｊａｖａクラスについて前記循環的複雑度を合算するステップと、
前記作成者毎に前記合算の結果を集計してその結果を出力するステップと、
を実行させることを特徴とする請求項１から３のいずれか１項記載のＪａｖａソースコードチェックプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｊａｖａ（登録商標）言語で記述されたプログラムソースコードの品質をチェックするプログラムに関するものである。
【背景技術】
【０００２】
ソフトウェア開発では常に高品質な成果物が求められており、品質向上のために様々な点検活動が行われている。開発の期間は限られているため、品質点検を素早く高精度に実施する必要がある。
【０００３】
開発下流工程の成果物であるソースコードの品質点検に目を向けると、大きくテストと目視点検の２つの方法がある。このうちテストではソフトウェアに要求される仕様を確認し、目視点検では仕様確認に加えてテストで発見しにくい誤作動、非効率な記述、保守性などの品質も確認する。このように多くの内容を確認する目視点検は品質確保の活動として重要であるが、時間がかかる割に見落としが発生しやすく、さらに属人的で精度がばらつくという問題を含んでいる。
【０００４】
近年、Ｊａｖａなどのオープン系言語では、目視点検をサポートするツールとしてＦｉｎｄＢｕｇｓ（非特許文献１）やＣｈｅｃｋｓｔｙｌｅ（非特許文献２）のようなツールが登場して、様々なプロジェクトで利用されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ＵＲＬ：http://findbugs.sourceforge.net/
【非特許文献２】ＵＲＬ：http://checkstyle.sourceforge.net/
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記非特許文献１〜２に記載の技術では、あらかじめ定めておいた検出規則に基づき、Ｊａｖａソースコードのバグを自動的に検出したり、Ｊａｖａソースコードの記述スタイルが規則に適合しているか否かを判定したりすることができる。
【０００７】
しかし、ソフトウェア開発プロジェクトにおいては、バグの発生やソースコードの記述スタイルは各開発者固有の傾向が反映されやすいといえる。かかる属人的な傾向は、従来の品質チェックツールではあまり意識されてこなかった。
【０００８】
本発明は、上記のような課題を解決するためになされたものであり、Ｊａｖａソースコードの品質に影響を与える事項について、プログラム作成者毎の傾向を把握することができる品質チェックプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係るＪａｖａソースコードチェックプログラムは、Ｊａｖａソースコード内に記述されているＪａｖａクラスの作成者名を記述したタグ部分から作成者名を抽出し、作成者毎の１クラス当たりの作成ステップ数を集計する。
【発明の効果】
【００１０】
本発明に係るＪａｖａソースコードチェックプログラムによれば、各プログラム作成者の１クラスあたりのステップ数傾向を把握することができる。１クラスあたりのステップ数が多いということは、サイズが大きいクラスを作成しているということであるため、ソースコードの保守性の観点で好ましくない。本発明に係るＪａｖａソースコードチェックプログラムによれば、かかる傾向のある作成者を特定し、改善を促すなどの対策を適切に取ることができる。
【図面の簡単な説明】
【００１１】
【図１】実施形態１に係るＪａｖａソースコードチェックプログラム１１０を実行するコンピュータ１００および関連するデータの入出力を示す図である。
【図２】Ｊａｖａソースコード２００のサンプルを示す。
【図３】Ｊａｖａソースコード２００のサンプルを示す。
【発明を実施するための形態】
【００１２】
＜実施の形態１＞
図１は、本発明の実施形態１に係るＪａｖａソースコードチェックプログラム１１０を実行するコンピュータ１００および関連するデータの入出力を示す図である。コンピュータ１００は、Ｊａｖａプログラムのチェック作業を行うために用いるコンピュータである。
【００１３】
コンピュータ１００は、チェック対象であるＪａｖａソースコード２００と、チェック規則を定義するチェック規則データ３００を入力として受け取り、Ｊａｖａソースコード２００のチェック結果を出力する。これらのデータは、必要に応じてコンピュータ１００が備える記憶装置に格納される。
【００１４】
コンピュータ１００は、Ｊａｖａソースコードチェックプログラム１１０を格納するＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの記憶装置と、Ｊａｖａソースコードチェックプログラム１１０を実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などの演算装置を備える。また、各データを入出力するインタフェース、メモリなどを適宜備える。以下では説明の便宜上、Ｊａｖａソースコードチェックプログラム１１０を動作主体として説明する場合があるが、実際にＪａｖａソースコードチェックプログラム１１０を実行するのはＣＰＵなどの演算装置であることを付言しておく。
【００１５】
チェック規則データ３００は、Ｊａｖａソースコードチェックプログラム１１０がＪａｖａソースコード２００をチェックする際の基準となるチェック規則を１以上定義する。チェック規則データ３００が規定する具体的な手順については、以下の図２を用いて改めて説明する。
【００１６】
図２は、Ｊａｖａソースコード２００のサンプルを示す。説明の便宜上、行番号をソースコードの左側に併記した。図２中、「／＊」と「＊／」で囲まれている部分は、コメント部分である。具体的には、３〜７行目、１１〜１３行目、１７〜２０行目がコメント部分である。
【００１７】
各コメント内に記載されている項目のうち、「＠」で始まる部分は、Ｊａｖａソースコードのコメント特有の情報を記述することを指定するタグ部分である。各タグの内容には、以下の項目を記述すべきであることが、Ｊａｖａ標準のコメント規則であるＪａｖａｄｏｃ仕様によって規定されている。
（図２：＠ａｕｔｈｏｒタグ）当該Ｊａｖａクラスの作成者名を記述するタグである。
（図２：＠ｖｅｒｓｉｏｎタグ）当該Ｊａｖａクラスのリリースバージョンを表す数値を記述するタグである。
（図２：＠ｐａｒａｍタグ）Ｊａｖａクラス内のメソッド引数を記述するタグである。
【００１８】
Ｊａｖａｄｏｃ形式のコメントは、本来はＪａｖａクラスの仕様書を自動的に生成するために記述するものである。例えば、各Ｊａｖａクラスが有するメソッド、その引数と戻り型、などの情報を、Ｊａｖａソースコード本体およびＪａｖａｄｏｃ内の各タグから抽出することにより、Ｊａｖａクラス仕様書を自動生成することができる。
【００１９】
かかるＪａｖａｄｏｃ仕様の目的に起因して、一般にＪａｖａｄｏｃコメントはＪａｖａクラスの属性をコメント内に記述するために用いられており、したがって「＠ａｕｔｈｏｒ」タグは補助的な情報として用いられるに留まっていた。
【００２０】
本発明は、Ｊａｖａソースコード内にＪａｖａクラスの作成者名が埋め込まれていることに着目し、Ｊａｖａソースコードの品質傾向をプログラム作成者毎に把握するために用いることを図るものである。
【００２１】
プログラム作成者毎の品質傾向を測定する目安として、１クラス当たりのステップ数が挙げられる。一般にＪａｖａクラスは、その目的に特化したＪａｖａ命令のみを記述するのが通常であるため、各Ｊａｖａクラスのステップ数は、当該Ｊａｖａクラスの目的に相当するステップ数内に収まるはずである。しかし、１つのＪａｖａクラスが複数の目的に対応するようにＪａｖａクラスを作成すると、そのＪａｖａクラスのステップ数は相応に多くなると予想される。
【００２２】
１つのＪａｖａクラスが複数の目的に対応していると、どの機能がどのＪａｖａクラスに属しているか分からなくなり、Ｊａｖａクラスの保守性が低下する。このような保守性の低いＪａｖａクラスを作成する傾向は、プログラム作成者毎に固有のものであることが多い。そこで本実施形態１では、１クラス当たりのステップ数をプログラム作成者毎に集計し、極端にステップ数の多いＪａｖａクラスを作成する傾向のあるプログラム作成者を特定して注意を喚起するなどの対策を取ることを図る。
【００２３】
Ｊａｖａソースコードチェックプログラム１１０は、上記集計処理を以下の手順で実行する。
【００２４】
（Ｊａｖａソースコードチェック手順：ステップ１）
Ｊａｖａソースコードチェックプログラム１１０は、Ｊａｖａソースコード２００（ソースコードファイル）を、ＨＤＤなどの記憶装置から読み込む。複数のＪａｖａソースコード２００をまとめて読み込んでもよいし、１つずつ読み込んでもよい。
【００２５】
（Ｊａｖａソースコードチェック手順：ステップ２）
Ｊａｖａソースコードチェックプログラム１１０は、ステップ１で読み込んだＪａｖａソースコード２００のコメント部分を特定する。具体的には、「／＊」と「＊／」で囲まれた部分、および「／／」で開始する行がコメント部分であると特定する。
【００２６】
（Ｊａｖａソースコードチェック手順：ステップ２：補足）
厳密には、Ｊａｖａｄｏｃ仕様のタグは、「／＊＊」と「＊／」で囲まれた部分に記述される。したがって本ステップでは、単なるコメント部分を検出するのみならず、Ｊａｖａｄｏｃの対象となるコメント部分を検出する必要がある。ただし、Ｊａｖａソースコードチェックプログラム１１０固有のルールとして、任意のコメント内から「＠ａｕｔｈｏｒ」タグを検出することとした場合や、「＠ａｕｔｈｏｒ」以外の記述方式でプログラム作成者名を記述することとした場合などは、これに限られるものではない。いずれの場合でも、プログラム作成者名をコメント内に記述しておき、Ｊａｖａソースコードチェックプログラム１１０がこれを認識できればよい。
【００２７】
（Ｊａｖａソースコードチェック手順：ステップ３）
Ｊａｖａソースコードチェックプログラム１１０は、ステップ２で特定したコメント部分から、「＠ａｕｔｈｏｒ」タグに記載されているプログラム作成者名を抽出する。図２に示した例では、プログラム作成者名は「ＡＵＴＨＯＲ＿００１」である。
【００２８】
（Ｊａｖａソースコードチェック手順：ステップ４）
Ｊａｖａソースコードチェックプログラム１１０は、Ｊａｖａソースコード２００内に記述されているＪａｖａクラスのステップ数をカウントする。Ｊａｖａ言語は１つのＪａｖａソースコード２００ファイル内に１つのＪａｖａクラスを記述するという規則があるので、Ｊａｖａソースコード２００の行数をカウントすればよい。図２に示した例では、ＨｅｌｌｏＷｏｒｌｄクラスのステップ数は２５である。
【００２９】
（Ｊａｖａソースコードチェック手順：ステップ５）
Ｊａｖａソースコードチェックプログラム１１０は、ステップ１〜４を、品質検査対象とする全てのＪａｖａソースコード２００について実行する。
【００３０】
（Ｊａｖａソースコードチェック手順：ステップ６）
Ｊａｖａソースコードチェックプログラム１１０は、Ｊａｖａクラス１つあたりのステップ数を、プログラム作成者毎に集計する。具体的には、ステップ３で抽出したプログラム作成者毎にステップ数を合算し、さらにそのステップ数を、当該プログラム作成者が作成したＪａｖａクラス数で除算すればよい。
【００３１】
（Ｊａｖａソースコードチェック手順：ステップ７）
Ｊａｖａソースコードチェックプログラム１１０は、ステップ６の結果を、ファイル出力、画面出力などの形態で出力する。
【００３２】
以上、図２のソースコードをチェックする過程を例に取り、Ｊａｖａソースコードチェックプログラム１１０の動作を説明した。
【００３３】
＜実施の形態１：まとめ＞
以上のように、本実施形態１に係るＪａｖａソースコードチェックプログラム１１０は、Ｊａｖａソースコード２００の作成者毎に１クラス当たりのステップ数を集計してその結果を出力する。この結果を利用して、プログラム作成者毎のクラスサイズの傾向を把握することができる。これにより、極端にサイズの大きいＪａｖａクラスを作成する傾向のあるプログラム作成者には、クラスを分割するなどの改善を促すことができるので、結果としてＪａｖａソースコード２００の品質改善につながる。
【００３４】
また、本実施形態１に係るＪａｖａソースコードチェックプログラム１１０は、Ｊａｖａソースコード２００の「＠ａｕｔｈｏｒ」タグからプログラム作成者名を抽出する。これにより、プログラム作成者の名称などの情報を、Ｊａｖａソースコード２００とは別に管理する必要がなくなる。この機能がないと、Ｊａｖａソースコード２００とは別にプログラム作成者の属性情報を管理する必要が生じ、ソースコード品質チェックとは直接の関係がない作業負担が生じる。この点、本実施形態１に係るＪａｖａソースコードチェックプログラム１１０によれば、Ｊａｖａソースコード２００そのものからプログラム作成者名を取得するので、かかる作業負担は生じず、プログラム作成者毎の集計作業を自動化することができる点で有利である。以下の実施形態でも同様である。
【００３５】
＜実施の形態２＞
本発明の実施形態２では、Ｊａｖａソースコードチェックプログラム１１０がＪａｖａソースコード２００内のコメントアウト部分を検出する手法を説明する。Ｊａｖａソースコードチェックプログラム１１０および周辺環境の構成は、実施形態１と同様である。実施形態１で説明した手法と、本実施形態２で説明する手法は、組み合わせて用いてもよいし、個別に用いてもよい。
【００３６】
Ｊａｖａソースコード２００内のコメントには、メモ書き目的、クラスやメソッドの役割を説明する目的などでプログラム作成者が付与した一般コメントと、古いＪａｖａ命令を無効化するためにコメントアウトしたものがある。このうち古いＪａｖａ命令をコメントアウトしたものについては、Ｊａｖａソースコード２００内に残したままにしておくと可読性が低下するので、保守性など品質維持の観点から好ましくない。
【００３７】
そこで本実施形態２では、Ｊａｖａソースコード２００内のコメントアウト部分を、他の一般コメントと区別した上で、コメントアウト部分のみを抽出する手法を説明する。
【００３８】
図３は、Ｊａｖａソースコード２００のサンプルを示す。図２で示したサンプルと概ね同様であるが、２９〜３０行目、および１７〜２１行目にコメントが追加されている。これらコメントの内訳は、以下の通りである。
【００３９】
（図３：３０行目のコメント）
３０行目は、３２行目に記載しているＪａｖａ命令の古いバージョンをコメントアウトしたものである。コメントアウトとは、Ｊａｖａソースコードのうち不要な部分を無効化するため、当該部分をコメントとして取り扱うように所定の記号を付与したものである。ここでは、行初に「／／」を追加することにより、当該行をコメントとして取り扱うことを示している。
【００４０】
（図３：２９行目のコメント）
２９行目は、３０行目をコメントアウトする際に、プログラム作成者がメモ書きとして付与したものであると思われる。このようなコメントは、Ｊａｖａ命令をコメントアウトしたものとは異なり、一般コメントに分類することができる。
【００４１】
（図３：１７〜２１行目のコメント）
１７〜２１行目は、「／＊」と「＊／」で囲むことによりコメント部分となっている。このうち１８行目と１９行目は、３０行目と同様に古いソースコードをコメントアウトしたものである。２０行目は、プログラム作成者がメモ書きとして付与した一般コメントである。
【００４２】
以上例示したように、コメント部分のなかには、一般コメントとコメントアウトが混在している。Ｊａｖａソースコード２００の保守性の観点からは、古いソースコードが残っていることは好ましくないので、本実施形態２ではコメントアウト部分のみを検出する。以下、その手順を説明する。
【００４３】
（コメントアウト検出手順：ステップ１〜２）
これらのステップは、実施形態１のステップ１〜２と同様である。
【００４４】
（コメントアウト検出手順：ステップ３）
Ｊａｖａソースコードチェックプログラム１１０は、ステップ２でコメント行であると判定した行の末尾に、Ｊａｖａ命令文の終端子（セミコロン）、Ｊａｖａ言語における開始括弧「｛」もしくは「（」、またはＪａｖａ言語における終了括弧「｝」もしくは「）」が存在するか否かを判定する。これらが行末に存在する行は、コメントアウト行であるとみなす。これら括弧のいずれか一方のみを検出するようにしてもよい。
【００４５】
（コメントアウト検出手順：ステップ３：補足）
本ステップにおいて、セミコロン、開始括弧、または終了括弧が行末に存在するか否かを判定するのは、行末にこれらが存在する場合、当該行はＪａｖａ命令を記述していると想定されるからである。例えば図３の３０行目は、コメントアウトされる前はＪａｖａ命令文を記述していたので、末尾にＪａｖａ命令の終端子であるセミコロンが存在する。同様に１８〜１９行目には、Ｊａｖａソースコードにおいて頻繁に用いられる開始括弧と終端括弧が存在している。これら括弧は行末に記載されるので、行末にこれら括弧が存在している行は、Ｊａｖａ命令を記述していると考えられる。
【００４６】
（コメントアウト検出手順：ステップ４）
Ｊａｖａソースコードチェックプログラム１１０は、ステップ３の結果を、ファイル出力、画面出力などの形態で出力する。
【００４７】
以上、図３のソースコードを例に取り、Ｊａｖａソースコードチェックプログラム１１０がコメントアウト部分を検出する動作を説明した。
【００４８】
＜実施の形態２：まとめ＞
以上のように、本実施形態２に係るＪａｖａソースコードチェックプログラム１１０は、Ｊａｖａ命令をコメントアウトした部分と、一般コメント部分とを区別し、Ｊａｖａ命令をコメントアウトした部分のみを検出する。これにより、古いＪａｖａ命令を残したままの状態になっているＪａｖａソースコード２００を検出することができるので、Ｊａｖａソースコード２００の保守性を向上させることができる。
【００４９】
また、一般コメント部分とコメントアウト部分の区別は一概にはつけ難いが、本実施形態２に係るＪａｖａソースコードチェックプログラム１１０は、行末のＪａｖａ命令特有の記号に着目し、コメントアウトを適切に検出することに成功した。これにより、コメントアウト部分を適切に検出することができる。
【００５０】
＜実施の形態３＞
Ｊａｖａソースコードチェックプログラム１１０は、以上説明した実施形態１〜２と併用して、またはこれらとは別に、Ｊａｖａソースコード２００の全行数に対するコメント行の割合をプログラム作成者毎に集計することもできる。
【００５１】
一般に、Ｊａｖａソースコード２００の全行数に対するコメント行の割合は、適正な範囲が存在する。コメントが少なすぎてもＪａｖａソースコードの内容が分かりにくくなるので好ましくないし、コメントが多すぎても却って効率がよくない。
【００５２】
そこで本実施形態３に係るＪａｖａソースコードチェックプログラム１１０は、Ｊａｖａソースコード２００の全行数に対するコメント行の割合をプログラム作成者毎に集計して、コメント行の割合が適正範囲にない傾向のあるプログラム作成者を特定する。
【００５３】
具体的には、「＠ａｕｔｈｏｒ」タグに記載されているプログラム作成者名毎に、作成したＪａｖａソースコード２００の全ステップ数とコメント行数をカウントし、後者を前者で除算して割合を求めればよい。算出結果は、ファイル出力、画面出力などの形態で出力する。
【００５４】
＜実施の形態４＞
Ｊａｖａソースコードチェックプログラム１１０は、以上説明した実施形態１〜３と併用して、またはこれらとは別に、プログラム作成者毎のクラス作成数を算出することもできる。
【００５５】
特定のプログラム作成者のみクラス作成数が極端に多い場合、そのプログラム作成者は既存のＪａｖａソースコード２００をコピーするなどしてＪａｖａクラスを作成しているのではないかと想定される。これはプログラムの品質低下につながるので、かかる行為を検出するため、クラス作成数をプログラム作成者毎に集計し、ファイル出力、画面出力などの形態で出力する。
【００５６】
一方、特定のプログラム作成者のみクラス作成数が極端に少ない場合も、当該プログラム作成者が何らかの問題を抱えているか、またはスキル面で不足しているなどの状況が想定される。このような開発進捗管理の観点からも、本実施形態４に係る手法は有用であるといえる。
【００５７】
＜実施の形態５＞
Ｊａｖａソースコードチェックプログラム１１０は、以上説明した実施形態１〜４と併用して、またはこれらとは別に、Ｊａｖａクラス内のメソッドの循環的複雑度を、プログラム作成者毎に集計することもできる。
【００５８】
循環的複雑度（Ｃｙｃｌｏｍａｔｉｃ  Ｃｏｍｐｌｅｘｉｔｙ）とは、メソッドの複雑さを表す指標として一般に用いられているものである。これは主に、メソッド内の分岐が多いと当該メソッドは複雑度が高いものとして取り扱う手法である。例えば、ｉｆ文内の分岐、メソッド内で他メソッドをコールする、などの処理が分岐に相当する。
【００５９】
循環的複雑度は、１０以下であることが好ましいとされる。循環的複雑度が５０を超えるとテストが不可能、７５を超えるといかなる変更も誤修正を生む原因となる、とされている。どの程度の循環的複雑度を許容するかは、Ｊａｖａソースコードチェックプログラム１１０を利用する者が適宜定めればよい。
【００６０】
メソッドの複雑さは、プログラム作成者毎にある程度の傾向が見られることが経験的に分かっている。そこで本実施形態５に係るＪａｖａソースコードチェックプログラム１１０は、プログラム作成者が作成したメソッドの循環的複雑度を、チェック規則の基準値を超えるメソッドについて合算し、さらにプログラム作成者毎の合算結果を、ファイル出力、画面出力などの形態で出力する。これにより、複雑なメソッドを作成する傾向のあるプログラム開発者を特定することができる。
【符号の説明】
【００６１】
１００：コンピュータ、１１０：Ｊａｖａソースコードチェックプログラム、２００：Ｊａｖａソースコード、３００：チェック規則データ。
【図１】
0005419804.tif 000002
【図２】
0005419804.tif 000003
【図３】
0005419804.tif 000004