【論文メモ】A systematic literature review on source code similarity measurement and clone detection: techniques, applications, and challenges
原論文
A systematic literature review on source code similarity measurement (arxiv.org)
Abstract
ソースコードの類似性を測定し評価することは、コード推薦、重複コード、盗作、マルウェア、およびスメル（異臭）検出など、幅広いアプリケーションにおける基本的なソフトウェアエンジニアリング活動です。本論文は、既存のアプローチとその特性に光を当てるため、コードの類似性測定と評価技術に関する体系的な文献レビューとメタ分析を提案します。私たちは最初に、4つのデジタルライブラリをクエリして1万以上の記事を見つけ、最終的に136件の主要な研究を抽出しました。研究は、その方法論、プログラミング言語、データセット、ツール、およびアプリケーションに従って分類されました。深い調査の結果、5つのアプリケーションドメインで8つの異なる技術を用いて動作するソフトウェアツールが80あります。ツールの約49％がJavaプログラムで動作し、37％がCおよびC++をサポートしていますが、多くのプログラミング言語はサポートされていません。注目すべき点は、ソースコードの類似性測定と重複コードに関連する12のデータセットが存在し、そのうちの8つのデータセットのみが公開されていることでした。信頼性のあるデータセットの不足、経験的評価、ハイブリッド手法、およびマルチパラダイム言語への焦点が、この分野の主な課題です。コードの類似性測定の新興アプリケーションは、メンテナンスに加えて開発フェーズに集中しています。
Introduction
ソースコードの類似性測定は、ソフトウェアエンジニアリングにおける多くのコード関連タスクを解決するための基本的な活動です。これには、クローンの識別や再利用 [1]–[9]、盗作の検出 [10]–[16]、マルウェアや脆弱性の分析 [17]–[22]、およびコードの推奨 [23]–[26] が含まれます。ほとんどの機械学習ベースのアプローチは、プログラムの品質を測定 [27]–[30]、コードのスメルを検出 [31]–[34]、リファクタリングを提案 [35]、プログラムを修正 [37]、[38]、およびソースコードを要約する [24]、[39] ためにソースコードの類似性指標の一種を使用しています。そのため、ソフトウェアエンジニアリングにおけるコード類似性測定技術、その本質、および応用について包括的な見解を持つことが重要です。
文献において、コードの類似性はコードクローンまたは重複コードとも呼ばれます [1]、[40]–[47]。コードの類似性はコードクローンよりも広い概念ですが、クローンコードはソフトウェアのメンテナンスに影響を与える主要な要因の一つです。ソフトウェアシステムにおけるコードクローンは、しばしばコピペプログラミングの実践から生じます [41]、[48]、[49]。このプロセスは、プログラマーがコードの一部を迅速に再利用し、開発プロセスを加速するのに役立ちますが、大規模なコードクローンの断片を生じる可能性があります。コードクローンを生じさせる他の行動には、言語の制限、コーディングスタイル、同じルールを実行するためのAPI、および異なる開発者によって偶然に同じロジックを実装することがあります [6]、[48]。
ソフトウェア開発ライフサイクルにおけるコードクローンの作成または使用には、困難と利点があります。クローンされたコードの主な課題の1つは、コードの一部で欠陥が検出された場合、すべてのクローンされた部分を特定して欠陥の可能性を確認する必要があることです。RahmanとRoy [50]は、コードクローンがプログラムの安定性を低下させることを示しています。一方で、いくつかの研究では、重複コードのリファクタリングが常に望ましいわけではないと主張しています。たとえば、コードクローンを削除すると、異なるコンポーネント間の依存関係が増加し、1つのコード部分を参照することによって密接に結合される可能性があります。そのため、多くの研究者が、何も行動しなくてもクローンコードを少なくとも特定するべきだと述べています [51]–[55]。残念ながら、コードクローンのインスタンスを検出することは簡単ではありません。しかし、クローンタイプの定義や分類は明確でない場合があり、コードクローンとコードの類似性の境界線が研究で十分に定義されていません。
コードの類似性測定に関する研究は成熟していますが、最新のアプローチを網羅した分野における包括的な調査は見当たりませんでした。本論文では、コードの類似性測定および評価手法に関する体系的な文献レビュー（SLR）とメタ分析を提案し、分野内の技術的側面を分類し、利用可能な課題と機会を明らかにします。この目的のために、最も重要なデジタルライブラリを検索し、初期の10000以上の記事のセットを得ました。関連する除外および含蓄基準、スノーボーリング、および品質評価を適用した後、136の記事がコードの類似性測定分野の主要な研究として選択されました。すべての主要な研究を詳細にレビューし、調査結果を分析・分類し、結果を報告しました。SLRの主な目標と貢献は次のとおりです。
コードの類似性測定とクローン検出のために提案された最新の手法、ソフトウェアツール、およびデータセットを示します。
利用可能なコード類似性測定研究の重要な側面を特定し、分類し、さまざまなアプリケーション領域（クローン検出、マルウェア検出、盗作検出、およびコードの推奨）での利点と欠点を比較します。
現在のコードの類似性測定における既存の課題と機会、および分野で新たに出現する新しいアプリケーションを指定し、議論します。
私たちの研究では、コードの類似性測定に関連するさまざまな手法、ツール、データセット、およびアプリケーションが示されています。最も重要なのは、研究者によって提案された80以上の異なるソフトウェアソースコードの類似性測定およびクローン検出ツールであり、少なくとも8つの異なる手法に基づいています。提案されたほとんどの手法は、コード断片内のトークン間の類似性を測定しますが、より高度な手法では機械学習やハイブリッド手法が新たに登場しています。利用可能な研究の最も重要な課題の1つは、公開されているツールやデータセットの不足、およびJavaアプリケーションでのクローン検出への焦点です。大規模なコードベースの急速な成長に伴い、ソースコードの類似性測定およびクローン検出アルゴリズムの効率性、精度、および拡張性が重要な要因となっています。
論文の残りの部分は以下のように構成されています。まず、セクション2では、コードの類似性測定およびコードクローンの文献で使用される主要な用語と概念を簡単に説明し、さまざまな種類のコードクローンについてレビューします。その後、セクション3では、体系的な文献レビューのための研究方法論と基本プロトコルを概説します。セクション4では、主要な研究の高レベルの分類を説明し、この体系的なレビューの結果を報告します。セクション5では、分野の課題と機会について議論します。私たちのSLRの妥当性に対する脅威は、セクション6で議論されます。最後に、セクション7でSLRをまとめ、将来の展望を示します。
Background
ソースコードの類似性は、テキスト、構文、および意味に関連して、コードスニペット間の類似度を測定するために使用される概念です。一般的に、コードの類似性のための明確な定義はありませんが、通常、任意の2つのコードスニペット 𝑐1、𝑐2 の類似性スコアは、実数 𝑠 で測定され、スコアが高いほど 𝑐1 と 𝑐2 が類似しています。山本ら [56] は、ソフトウェアシステムの類似性を、具体的な類似性メトリックを考慮して、与えられた2つのシステム内の類似要素の割合と全要素対の合計数の比率として定義しています。秦琴と春海 [57] は、プログラムソースコードの類似性はソフトウェアシステムと同様であり、山本の定義はプログラムソースコードの類似性測定の基礎として使用できると述べています。
コードの類似性を測定するタスクと類似またはクローンコードを特定するタスクを区別することは重要です。前者は一般的な概念であり、後者はコードの類似性測定のアプリケーションの1つとして分類されます。たとえば、類似性測定の結果をフィルタリングするために閾値を使用して、最も類似したインスタンスをクローンインスタンスとして報告できます。この調査では、コードの類似性測定が、ソフトウェアエンジニアリングのさまざまな問題に対処するための基盤を提供し、幅広いアプリケーションを示していることが議論されます。ただし、コードクローン検出は、この分野の多くの論文やツールの主要なアプリケーションであり、その先進的な検出方法は他のコード類似性測定アプリケーションの進化を促進しています。したがって、コードクローンの定義とタイプに焦点を当てます。コードクローンの定義について、研究者は多くの定義を提案しています。広く受け入れられている定義の1つとして、Baxterら [1] は、次のようにクローンコードを定義しています：
定義1（クローンコード）：2つのコードスニペット 𝑐1、𝑐2 がある定義に従って類似している場合、それらはクローンです。
定義1のコードスニペットのペアは、異なるプログラミング抽象化レベルで、プログラム内のステートメント、ブロック、メソッド、クラス、パッケージ、またはコンポーネントになります。さらに、コードの類似性測定は、意図されたアプリケーションに応じて1つ以上のプロジェクトの範囲内で実行できます。異なるプロジェクトのエンティティが調査され、類似性が測定される場合、いわゆるクロスプロジェクトの類似性測定技術が定義されて使用されます。実際には、コードの類似性測定の結果は、与えられたコードスニペットの類似性と同じエンティティレベルのすべてのコードスニペットのランク付けされた類似性を含むベクトルで報告される場合があります。
定義1により、類似性測定の定義に応じて、さまざまなクローンタイプが形成されます。実際、クローン検出タスクにはコードの類似性測定の一般的な定義と比較して、類似性タイプと閾値の2つの追加の側面が考慮される必要があります。類似性の閾値は、クローンインスタンスの近さを示すために使用されます。この閾値の最大類似性値は、インスタンスの正確な一致を示します。
したがって、すべての類似性測定アプローチや類似性メジャーがクローン検出タスクに適しているわけではありません。本論文では、コードの類似性測定の一般的な問題に焦点を当てます。ただし、提案された技術は、ほとんどの場合、クローンの種類などのクローン検出の概念に基づいてのみ比較されます。
コードクローンは1つのプログラミング言語または複数の言語間で検出できます。後者のタイプのクローン検出は、クロス言語クローン検出（CLCD）とも呼ばれます。クロス言語クローンは、コードベースが移植用に異なる環境で使用するために準備されている場合に発生します。たとえば、ゲームのメインコードベースは実際には同じであり、異なるオペレーティングシステム用にゲームを構築する際には各オペレーティングシステムごとにわずかな違いがあります。
Related research
私たちの知る限りでは、ソースコードの類似性測定技術およびそのアプリケーション、ツール、データセットの一般的および特定の側面に関する体系的な文献レビューは行われていません。ただし、いくつかの研究では、クローン検出アプローチ [48]、[67]–[71]やそれらの特定のアプリケーション [72]についてレビューされています。たとえば、Novakら [72]は、ソースコードの盗作検出をレビューしています。私たちの調査は、特定のアプリケーションを強調せずに、最近提案されたアプローチとコード類似性測定の新興アプリケーションを補完するものです。私たちのSLRの目標は、さまざまなソフトウェアエンジニアリング活動の自動化の基礎としてのコード類似性測定を示すことです。
RoyとCordy [48]は、ソフトウェアクローン検出研究に関する初の包括的な技術レポートを公開しました。著者は、クローン文献で頻繁に使用される用語を説明し、一般的に使用されるクローンタイプにマッピングしました。彼らはまた、クローンの分類法、検出方法、および実験評価に関する57のオープンな質問や問題のリストを提案しました。クローン検出方法とツールの間で基本的な比較が行われ、これはソフトウェア開発者にとって貴重な情報を提供しています。ただし、彼らは関連するすべての作品を見つけてカバーするための体系的な検索を行っておらず、彼らのレポートはほぼ10年前に公開されました。
Rattanら [67]は、ソフトウェアクローンの検出と管理に関する体系的なレビューを行いました。彼らは、11の主要なジャーナルと37の会議から213の記事をレビューした結果を報告しています。彼らの調査では、クローン定義、クローンタイプ、クローン作成の理由、クローン検出方法、およびクローン検出ツールなど、ほぼすべてのソフトウェアクローンのトピックがカバーされています。彼らはまた、クローンが「有用」なのか「有害」なのかという基本的な問いに答えようとしました。彼らのレビューは異なる矛盾した答えで終わり、クローンインスタンスを単に削除するのは適切なアプローチではないと結論付けました。代わりに、開発者はさまざまな状況で適切な戦略を取り扱うためのツールを必要としています。著者らは一般的なコード類似性測定をレビューしていませんでした。
MinとPing [68]およびAinら [69]によって最近、ソフトウェアのクローン検出に関する類似の調査が行われました。これらの研究では、コードクローン検出に使用されるアプローチ、ツール、オープンソースの被験システムがカバーされており、研究者が自身のニーズに応じて適切なアプローチやツールを選択するのに役立ちます。ただし、コード類似性測定の一般的な問題とその幅広いアプリケーションについては、体系的にカバーされていません。
コード類似性の他の応用に関しては、Novakら [72]によって盗作検出技術とツールがレビューされています。彼らは、大学教授が学生から提出されたソースコードの盗作を検出するのを支援するために、この分野の体系的なレビューを行いました。彼らの研究では、盗作の定義、盗作検出ツール、比較メトリクス、難読化方法、比較に使用されるデータセット、およびアルゴリズムの種類について議論しています。著者らは、学術界でのソースコードの盗作検出ツールと、盗作を犯した学生が通常使用する盗作難読化方法に焦点を当てました。彼らは、学術界およびその外で「ソースコードの盗作」の多くの定義が存在するが、文献に明確な合意された定義が存在しないと結論付けました。さらに、定量的な分析に使用できるデータセットとメトリクスがほとんどないと指摘しています。他のコード類似性測定関連のアプリケーションについても同様の状況が観察されています。
一部の研究では、ソースコードの類似性測定およびクローン検出の一部の手法を実証的に評価し比較しています [43]、[62]、[73]、[74]。ただし、そのような比較の結果はデータセットによって非常にバイアスがかかります。BurdとBailey [73]は、中規模のJavaプログラム上で5つのコードクローン検出ツールのパフォーマンスを評価しました。彼らは、クローン検出のための単一かつ明確な優勝手法は存在しないと結論付けました。ただし、報告された結果は単一のプログラム内のクローンに基づいています。
Bellonら [62]は、8つの大規模なCおよびJavaプログラムを含むベンチマークを使用して、6つのクローン検出器の精度、再現性、および実行時間を評価しました。選択されたツールは、テキスト情報、レキシカルおよび構文情報、ソフトウェアメトリクス、およびプログラム依存グラフを扱う異なるコード類似性測定アプローチに基づいています。著者らは、8つのソフトウェアシステム内のコードクローンに言及し、ツールを提案されたデータセットと比較しました。彼らは、テキストベースおよびトークンベースのツールが、ツリーベースおよびグラフベースのツールと比較して再現性が高いが精度が低いこと、また、ツリーベースの技術の実行時間が他のテキストベースおよびトークンベースの技術よりも長いことを結論付けました。この論文では、クローン検出の結果を判断するために1人の人間の専門家のみを使用し、報告された結果の信頼性に関する脅威があります。
Biegelら [74]は、4つのJavaプロジェクトでテキストベース、トークンベース、およびツリーベースのソースコード類似性測定アプローチの再現率と計算時間を実証的に比較しました。彼らは、コード内のリファクタリングフラグメントを検出するためにツールを使用しました。著者らは、異なるツールの結果には大きな重複があることを発見しました。しかし、トークンベースのクローン検出ツールであるCCFinder[2]は、他の2つの類似性測定アプローチよりもはるかに遅いことがわかりました。彼らの実証的研究のデータセットとレプリケーションパッケージは公開されていません。
最近の実証的研究では、Ragkhitwetsagulら [43]が30のコード類似性検出技術とツールを評価しました。著者らは、ソースコードが広範な変更を受ける場合、一般的なテキストベースの類似性測定ツールは専門のコード類似性測定ツールと同様のパフォーマンスを提供することを発見しました。ただし、特定のソースコード類似性測定手法とツールは、一般的なテキストベースの類似性測定手法よりも優れたパフォーマンスを発揮できます。JPlag盗作検出ツール [10]は、ローカルコード変更を検出する際の最良のパフォーマンスを示し、CCFXは広範に変更されたコードで最高のパフォーマンスを達成します。ツールの最適なパラメータ（クローンコードを検出するために使用されるしきい値など）は、特定のデータセットに偏っています。
Chenら [70]は、2006年から2020年までの異なるコード重複アプローチを批評的にレビューしました。著者らは、有効な大規模サンプルを持つ検証用の有効なテストデータセットが存在しないことを結論付けました。さらに、著者らは、ほとんどの手法が非常に複雑で、単一のプログラミング言語をサポートし、意味的なクローン（タイプIVクローン）を検出できないことを報告しました。ただし、彼らは当社の論文で議論されている広範なコード類似性測定アプリケーションの範囲を調査していません。本SLRでは、ソースコードの類似性測定に関連するすべてのアプリケーションを徹底的にレビューしました。また、研究者や実務家が取り組んでいる最新のアプローチを包括するように、既存のコード類似性測定アルゴリズムとアプリケーションの分類を拡大しました。具体的には、学習ベース、テストベース、画像ベース、およびハイブリッドアルゴリズムを以前に識別されたソースコード類似性測定手法に追加して、議論しました。また、コード類似性測定の新興アプリケーション（コード推薦および障害予測を含む）をいくつか特定しました。
Research Methodology
本文献レビューは、KitchenhamとChartersによって確立されたガイドラインに従います[75]。これにより、ソフトウェアエンジニアリングにおけるシステマティック・リテラチュア・レビューが計画、実施、報告の3つの段階に分解されます。さらに、我々は、実証的ソフトウェアエンジニアリング、コードスメル、ソフトウェアリファクタリング、ソフトウェア盗用に関連する最新の高品質のシステマティック・リテラチュア・レビューからインスピレーションを得ました[14]、[76]–[78]。図2は、研究方法論の全体的なプロセスを示しており、トピックと研究の問題の定義、検索文字列の作成、および記事の選択が含まれています。括弧内の数字は、各ステップで取得された記事の数です。当社の研究方法論は、SLR中に回答されるべき研究問題を記述することから始めます。
Research questions
ソースコードの類似性の測定と評価は、広範なアプリケーションを持つ多次元の問題です。以下の研究質問は、導入で議論された目的を見つけるために当社のレビューを実施するために設計されました：
• RQ1：既存のソースコードの類似性測定の手法とテクニックは何であり、それぞれの利点と欠点は何か？
• RQ2：ソフトウェアエンジニアリングの活動およびタスクでのソースコードの類似性測定の応用は何か？
• RQ3：既存のソースコードの類似性測定ツールは何であり、各ツールがサポートするプログラミング言語は何か？
• RQ4：ソースコードの類似性測定ツールの構築と評価に使用されたソフトウェアプロジェクトとデータセットは何か？
• RQ5：既存のソースコードの類似性測定手法のパフォーマンスはどうか？
• RQ6：ソースコードの類似性測定における既存の課題と機会は何か？
Classifying and comparing code similarity studies
主要な研究の分析から、ソースコードの類似性測定に関する研究はいくつかの共通の側面を示しています。これらの側面を適切に分類することは、異なるソースコードの類似性測定アプローチを標準的なスキームで比較し、研究上のギャップを明らかにするために多くの利点を提供します。私たちは、各研究について、手法、ツール、サポートされているプログラミング言語、データセット、およびアプリケーションドメインの5つの直交する次元を指定しました。図5は、提案された分類と各カテゴリ内の既存のサブカテゴリを示しています。私たちは、この分類に基づいて私たちの調査を組織しました。提案された分類は、現在および将来のソースコードの類似性測定に関する研究を体系的に比較するための標準的な方法と見なすことができます。残念ながら、すべての研究が図5に示されている5つの提案されたカテゴリの情報と議論を提供しているわけではありません。セクション4の残りの部分では、これらの5つの次元のそれぞれについて詳細にレビューし、ソースコードの類似性測定の研究の現在の状態を発見します。
手法に関して、既存の研究は静的または動的プログラム解析に基づいています。静的解析に基づく手法[10]、[40]、[61]、[81]–[83]では、プログラムの実行を使用せずに類似性を測定します。アルゴリズム、データ駆動型、またはハイブリッドアプローチを使用して類似のソースコードを見つけます。一部の研究[84]、[85]では、テストスイートまたはワーキングロードでプログラムを実行し、プログラムの機能出力などのランタイム情報を取得し、取得した情報を比較することで類似したコードフラグメントを見つけます。セクション4.4では、既存の手法について詳細に議論します。
ツールに関して、提案された研究はツールによってサポートされている場合とそうでない場合があります。一部の研究は、自分たちのツールを公表しています[10]、[81]、一方で、他の研究はそうではありません。また、非学術的なソースコードの類似性測定ツールもありますが、これらは主要な研究で議論されていません[86]–[89]。既存のツールとアプローチは、1つまたは複数のプログラミング言語でソースコードの類似性を検出する場合があります。また、言語に依存しないツールもあります[90]。セクション4.5では、既存のソースコードの類似性測定ツールとサポートされている言語について説明します。
主要な研究のレビューによると、ソースコードの類似性測定手法を作成および検証するために使用されるデータセットには3種類あります：人間のオラクルを使用したデータセット[62]、[91]、機械のオラクルを使用したデータセット[92]、[93]、およびハイブリッドデータセット[43]。最初のカテゴリのデータセットは、その場の専門家によって手動でラベル付けされるか、プログラミングコンテストプラットフォーム（Google CodeJam[94]およびCodeforces[95]など）で特定の問題への解決策に基づいています。自動生成されたデータセットは、異なる既存のツール間での多数決[62]、変異演算子[93]、プログラム変換ルール[96]、またはコードベースのバージョン履歴を使用して、人間の介入なしで類似および非類似なコードフラグメントのラベルを作成します。最後に、これらのアプローチの組み合わせを使用して、大規模かつ品質の高いデータセットを作成できます。既存のソースコードの類似性ベンチマークとデータセットの詳細については、セクション4.6で議論されています。
ソースコードの類似性測定の応用に関して、ソースコードクローンと再利用の検出の直接的な応用と、いくつかの間接的な応用が観察されました。これらは、さらに、プラガリズム検出、マルウェアおよび脆弱性検出、コード予測、およびコード推奨に分類されます。大多数の主要な研究がクローンインスタンスを見つけることに焦点を当てていますが、私たちの調査では、ソースコードの類似性測定がソフトウェアエンジニアリング活動の多くのコード関連タスクに対処できることが示されています。セクション4.3では、私たちがレビューした研究でカバーされているソースコードの類似性測定のさまざまな応用について説明します。
Code similarity measurement applications
私たちのシステマティック・リテラチュアレビュー（SLR）によれば、コードクローンと盗作検出に加えて、マルウェア検出、欠陥予測、およびコード推奨の3つの他のコード類似性測定アプリケーションがあります。実際、後者の3つのアプリケーションは、コード類似性測定の観点からはほとんど議論されていませんでした。図6は、主要研究におけるトップ5のコード類似性測定アプリケーションの頻度を示しています。図6の円グラフによれば、コードクローン検出がコード類似性測定研究の中で最も頻繁なアプリケーションです。それが84%以上の主要研究で議論されています。実際、ほとんどの研究は、特定のアプリケーションに直接言及するのではなく、コードクローンの一般的なドメイン内でコード類似性を調査しています。コードクローンは、本番コードとテストコードの両方で検出されます。
コード盗作検出は、プログラムソースコードの不正な再利用を特定することを目的とする、二番目に頻度の高いコード類似性測定アプリケーションの1つです。マルウェア検出では、コード類似性測定の第3の頻度の高いアプリケーションによれば、プログラムソースコードが検索され、悪意のあるソースコードスイートのクローンインスタンスが見つけられます。これらのインスタンスにはおそらく悪意のある動作が含まれています。同様に、既知の欠陥を持つソースコードスイートのクローンインスタンスは、欠陥を持つ可能性のあるプログラムとして特定されます。最後に、コード推奨は、コード類似性の基礎となる既存のコードに開発中のコードが類似している場合に、バグ修正パッチ、エンティティ名、リファクタリング、およびコード生成などのコード変更と改善を推奨する最近のアプリケーションの1つです。例えば、プログラマーにメソッドやクラス名を提案するためのいくつかのアプローチが、ソースコード品質要因を向上させるために提案されています。
Code similarity measurement techniques
多くの方法や技術が類似性を特定するために文献で提案されていますが、商業化されたものはほとんどありません。実際、ほとんどのアプローチは、ソフトウェアメンテナンスを目的として学術研究で開発されています。私たちは、主要研究で使用されているコード類似性を測定するための9つの技術を特定しました。図5は、ソースコードの類似性測定技術の構造化されたレベルを示しています。以前の調査では、最大で6つのカテゴリーまでしか考慮されていませんでしたが、私たちのシステマティック・リテラチュアレビューでは、学習ベース、画像ベース、およびテストベースのメソッドを含む、ソースコード類似性測定の3つの新しいカテゴリーが特定されました。
図7は、主要研究での異なるコード類似性測定技術の頻度を示しています。ハイブリッドメソッド、つまり2つ以上の基本メソッドを組み合わせた方法が、コード類似性測定に最も使用される技術であることが観察されます。図によれば、約28%の研究がソースコード類似性を測定するためにハイブリッドメソッドを提案しています。学習ベースとトークンベースの方法が2位と3位にあります。グラフベース、ツリーベース、およびテキストベースの技術がそれぞれ4位、5位、および6位に位置しています。最後に、メトリックベース、テストベース、および画像ベースの方法が最も詳細に検討されていない方法です。各技術に基づいて提案された最も重要な主要研究について、このセクションの残りの部分でそのメカニズムと詳細を提供します。
Text-based techniques：
👍特徴
・コード類似性測定において、最も単純で初期の手法。
・ソースコードを文字列のシーケンスと見なす。
・2つのコードスニペットを一緒に比較して、文字列の最長共通シーケンスを見つける。その一致する部分をクローンインスタンスとする。
・通常、前処理を行わずに生のコード上で行われるが、一部のアプリケーションでは、シーケンスの一致前に空白やコメントが削除される場合がある。
👍長所
👎短所
📚関連研究
Gapped Code Clone Detection with Lightweight Source Code Analysis (researchgate.net)
Token-based techniques：
👍特徴
・トークンベースの手法では、プログラムのソースコードがトークンのシーケンスに変換される。通常、レキシカルパーサーがトークンを生成するために使用される。
・トークンベースの手法は、テキストベースの手法よりも、識別子のレキシカル要素の変更などのコード変更に対してより堅牢である。
👍長所
👎短所
たとえば、ASTVisitorツールがあります。次に、トークンが索引付けされます。トークンシーケンス間の類似性インデックスは、クローンが存在することを示します。
トークンベースの手法では、プログラムのソースコードがトークンのシーケンスに変換され、それからこれらのシーケンスが共通の部分シーケンスを見つけるために比較されます[P7]、[P98]。トークンベースの手法は、テキストベースの手法よりも、識別子のレキシカル要素の変更などのコード変更に対してより堅牢です[P15]、[P18]、[P26]。また、ソフトウェア開発プロセス中に頻繁に使用されるほど効率的です[P53]。ただし、トークンの認識と置換操作により処理時間が増加します。トークンベースの手法は、タイプIおよびタイプIIのコードクローンを特定する際に優れたパフォーマンスを示しています[P13]、[P87]、[P89]、[P92]、[P95]、[69]、および多数の編集を含むタイプIIIのクローンを検出する際にも[P68]、[P75]、[P79]。
Tree-based techniques：
👍特徴
・ソースコードは、木ベースの方法では、プログラミング言語のパーサーを使用して構文解析ツリーまたは抽象構文木（AST）に変換されます
・大規模なコードベースの構文解析ツリーやASTの作成には時間がかかり、各プログラミング言語に特有のパーサーが必要です
・コードクローン検出のアプリケーションでは、木ベースの方法はタイプI、II、IIIのコードクローンを正確に認識できます。
ソースコードは、木ベースの方法では、プログラミング言語のパーサーを使用して構文解析ツリーまたは抽象構文木（AST）に変換されます[P8]、[P16]、[P78]、[P121]。類似したコードを検索するには、構文解析ツリーまたはAST内で類似の部分木を見つけます[P24]。この方法は、ブロッキングや括弧の異なるコードの変更にも強力です。ただし、大規模なコードベースの構文解析ツリーやASTの作成には時間がかかり、各プログラミング言語に特有のパーサーが必要です[P93]。また、部分木の一致は計算コストが高いです[P93]。コードクローン検出のアプリケーションでは、木ベースの方法はタイプI、II、IIIのコードクローンを正確に認識できます。また、マルウェア検出[P74]や欠陥予測[P115]など、コード類似性測定の他のアプリケーション領域にも適用されています。
Discovering Vulnerable Functions: A Code Similarity Based Approach | SpringerLink
TECCD: A Tree Embedding Approach for Code Clone Detection (nsf.gov)
📗📕
Graph-based techniques
グラフベースの方法では、通常、プログラム依存グラフ（PDG）[119]をコードスニペットに作成し、これらのグラフを比較して類似性を認識します[P21]。 PDGには、プログラム文間のデータおよび制御依存関係が含まれており、構文だけでなくプログラムの意味論も伝えます。 PDGのノードはプログラム文であり、エッジはデータまたは制御依存関係です。 PDGベースの方法の適切な実装により、すべてのタイプのクローンを識別できます[P34]、[P119]。ただし、PDGの比較は、NP完全な問題であるグラフ同型性によって行われることが多いです[P23]、[P31]。したがって、いくつかのアプローチでは、クローン検出に使用するためにPDGをより単純なツリー表現に変換します[P64]。
KomondoorとHorwitz[P4]は、プログラム内の連続テキストとして発生しないクローンを見つけるためのグラフベースのクローン検出アプローチを提案しました。彼らのアルゴリズムは、バックワードスライシング技術を使用して、PDG内の一致ノードのペアごとに2つの同型部分グラフを見つけます。一致ノードは、変数名と値を考慮せずに合成的に類似しているPDG内のノードです。スライスベースのアプローチは一般的に同型部分グラフを見つけるより効率的ですが、大規模なPDGを持つプログラムでは時間がかかります。
Krinke[P3]は、最大類似部分グラフを計算することで類似したコードを識別するためのグラフベースのアプローチを提案しました。このアプローチは、意味的に類似したコードを検出できます。ただし、著者によれば、提案されたアルゴリズムの時間複雑度は𝑂(|𝑉|2)であり、ここで𝑉はPDG頂点の数です。そのため、大規模なPDGを持つコード断片では、アルゴリズムは効率的ではありません。Gabelら[P12]は、PDGサブグラフを関連する構造化構文にマッピングすることによって、グラフ類似性測定問題をより単純なツリー類似性測定問題に簡略化しました。ツリー類似性測定を使用することで、サブグラフの比較プロセスが効率化されます。
Wangら[P58]は、C#プログラム向けのPDGに基づいたクローン検出ツールであるCCSharpを提案しました。CCSharpは、ソースコードを小さなスニペットに分割し、各コードスニペットのPDGを構築してPDG作成時間を短縮します。次に、これらのグラフを比較してクローンインスタンスを検出し、グループ化します。CCSharpの利点は、比較的高い精度（99.3％）とリコール（89.8％）ですべてのクローンタイプを検出することです。Tajimaら[P71]は、プログラムのメソッドからインターフェース情報とPDGを抽出して、同じプロジェクト内での類似性検出に使用しました。
大規模なプログラムのPDGを構築することは時間がかかり、エラーの原因になります。Avetisyanら[P41]は、PDGに基づくプログラムの意味解析を使用したLLVMベースのコードクローン検出フレームワークを提案しました。彼らの提案されたクローン検出アプローチは、複数段階のプロセスです。まず、生成されたPDGがメモリにロードされます。第二に、異なる手法でPDGをサブグラフに分割します。第三段階は、線形複雑度で検出される十分に大きな同型部分グラフを持たないことを証明しようとする高速チェックアルゴリズムの適用です。第四ステージは、プログラムスライシングに基づく最大同型部分グラフの検出です。第五ステップは、対応する同型部分グラフのソースコードが散在しすぎていないことを確認するフィルタリングです。最終的に、検出されたクローンの対応するソースコードが印刷されます。著者は、アプローチの効率と拡張性に焦点を当て、タイプI、II、IIIのコードクローンを特定しました。ただし、彼らのアプローチはクローンタイプIVを検出することができず、LLVMエコシステムに制限されています[120]。一部のアプローチでは、類似したソースコードを検出するために遺伝的アルゴリズムなどの進化的アルゴリズムが使用されていますが、これらのアプローチは、近似グラフマッチングでクローンされたコードを見つけることができる可能性があります[P51]。
Metric-based techniques
メトリックベースの方法では、まず、ソースコードを異なるコードメトリックのベクトルとして表現し、ベクトル空間モデル理論を使用して類似性を測定します[121]。その後、ベクトルの類似性を使用して、与えられた各ソースコードの類似性を測定します。ベクトルの類似性は、プログラミング言語の定義されたメトリックの量と品質に大きく依存します。大規模なプログラムのためのソースコードメトリックの計算には、適切な効率が得られるように、合理的な時間がかかります[P1]、[P114]。表2には、コード類似性測定とクローン検出に使用される一般的なソースコードメトリックが示されています。研究者が使用するソースコードメトリックのセットが限られていることが観察されています。
Sudhamaniら[P56]は、Javaプログラム向けのメトリックベースのクローン検出アプローチを提案しました。彼らの方法では、プログラム内の制御文に対するControl Feature Metric Tables (CFMT)のセットが抽出されます。これには、算術演算の数、論理演算の数、条件演算の数、識別子、および制御コードの行数が含まれます。抽出されたメトリックのベクトルはコードスニペットを表し、ユークリッド距離が各コードスニペットのペア間の類似性を測定するために使用されます。著者らは、彼らのアプローチがすべてのタイプのコードクローンを検出できると主張していますが、この方法の正確な評価は報告されていません。
Nafiら[P100]は、クロス言語クローン（CLC）を検出するために9つのコードメトリックを使用しました。 ANTLRツール[118]を使用してソースコードメトリックを抽出し、コサイン類似度距離が類似性の尺度として計算されました。 CLCの典型的な例は、開発者が異なるプラットフォームで単一のゲームを利用可能にしようとするモバイル電話ゲームの開発です。たとえば、人気のあるモバイル電話ゲームであるTemple Runは、Windows、iOS、およびAndroidの3つのモバイル電話プラットフォームで利用できます。目標は、C＃、Java、およびPythonプログラミング言語間の異なるクローンを特定することです。この方法はまずソフトウェアメトリックを取得し、次に各コードをメトリックと比較します。この方法のF1スコアは、異なる言語で65％から71％の間で報告されています。
Sudhamaniら[P86]は、セマンティッククローンを識別するためのメトリックベースの方法を提供しています。彼らは、制御文の種類と順序、入れ子になった制御文、演算子の種類と数、および変数の数などのメトリックを使用しました。この方法は、次の5つのステップで構成されています：1. 前処理、2. 特徴量の計算、3. 不類似度行列の計算、4. 類似性値の計算、5. クラスタリングを通じた類似プログラムの検出。メトリックは比較のために制御文機能テーブル（CSFT）行列に配置されます。異なる行列間の不類似性は、都市ブロック距離に基づいて計算され、最後に類似していないコードは削除されます。この方法のF1は、異なるJavaプロジェクトで実施された調査に応じて異なりますが、平均すると90％から95％の間になります。
Parsaら[P133]は、メソッド名推奨タスクのための類似したJavaメソッドを見つけるためのメトリックベースのアプローチを提案しました。ソースコードメトリックに基づく軽量プログラム表現が、Code2Vec [P85]やCode2Seq [24]などの複雑な深層学習ベースのモデルよりも、コード関連のタスク、特にメソッド名の提案において、より高い精度を達成することを示しました。ただし、彼らのアプローチでは意味的に類似したコードフラグメントを検出することはできません。
Learning-based techniques
近年、機械学習が広く普及していることを考慮し、学習ベースの方法を独立したカテゴリとして議論することを選択しました[122]。このセクションで要約された機械学習方法は、コード類似性の測定およびクローン検出のタスクで有望な結果を示しています[P17]、[P42]、[P49]、[P59]、[P84]、[P101]、[P102]、[P103]、[P108]、[P109]、[P118]、[P120]、[P132]。複雑なパターンを学習して認識する能力により、学習アルゴリズムはこれらのタスクに適しています。ただし、学習ベースの方法は、正しく機能するためには大規模かつクリーンなコードクローンデータセットが必要であり、すべての言語で利用可能ではありません。ほとんどのアプローチでは、機械学習のために必要なデータを準備するために既存のコードクローン検出ツールを使用しますが、これはツールが常にエラーを起こすため信頼性が低いです。
学習ベースのアプローチは、既知の類似および非類似のコードのデータセットを学習して、類似したコードフラグメントを分類またはクラスタリングすることを目指しています[P42]、[P59]、[P84]、[P102]、[P105]、[P107]。Cesareら[P37]は、パッケージレベルでクローンを識別するために従来の分類モデルを使用しました。著者らはランダムフォレストを最良の学習モデルと報告しました。Joshiら[P46]は、関数レベルでI型およびII型のクローンを識別するためにDBSCANクラスタリングアルゴリズム[123]を使用しました。Keivanlooら[P42]は、k-meansクラスタリングアルゴリズムを使用して、非類似性のしきい値を問わずIII型の真のクローンと偽のクローンを特定しました。著者らは、クラスタリングアルゴリズムの𝑘パラメータの異なる値に対するクラスタリング品質を評価するために、フリードマン法を使用しました。彼らのアプローチは、IV型のクローンを検出することはできません。
Mostaeenら[P67]は、12のソフトウェアJavaプロジェクトでクローンインスタンスを識別するために5つのクローン検出ツールを使用しました。その後、専門家の開発者が検出されたインスタンスを評価して偽陽性とラベル付けされたクローンの距離を認識しました。機械学習モデルがクローンと非クローンのサンプルを分類するために適用されました。これらのデータは、人工ニューラルネットワーク（ANN）に入力され、クローンを分類するように学習します。この方法はI型、II型、およびIII型のクローンを識別でき、異なるJavaプロジェクトでのこの方法の精度は89.5％から100％の間です。再現率は67.6％から96.7％の間です。Liら[P59]は、クローンと非クローンのインスタンスを分類するために類似ネットワーク（SNN）[124]を使用しました。PatelとRoopak[P129]は、III型およびIV型のコードクローンを検出するためにシャムニューラルネットワーク（SNN）[124]を使用しました。ただし、彼らの評価では、非シャムニューラルアーキテクチャの方が高い精度を示しています。TPCaps [P132]は、プログラム依存グラフ（PDG）から抽出された特徴に基づいてクローンペアを識別するためにカプセルネットワークモデル[125]を使用します。
コードのクローン検出は効果的なソフトウェアメンテナンスのために重要です。クローンが意味的に類似している（Type-IV）場合、つまり構造的に似ていない場合、このタスクはより難しいです。ほとんどの既存の手法は、AST（抽象構文木）またはPDG（プログラム依存グラフ）のいずれかの間でシーケンス類似性と/またはグラフ同型性を使用して、Type-I、II、IIIクローンを検出します。しかし、それらは主に意味的またはType-IVクローンを検出することに失敗します。本研究では、4種類のクローンを自動検出するための機械学習を使用した新しい検出フレームワークを提案します。2つのコードブロックから抽出された特徴は、参照ブロックに関連するクローンの可能性のある検出のために組み合わせられます。2つの特徴ベクトルを3つの異なる代替手法を使用して融合した後、両方のコードブロックのASTとPDGの特徴を使用してラベル付きトレーニングサンプルを準備します。提案されたスキームの予測性能を評価するために、Deep Convolutional Neural Networkを含む6つの最新の分類モデルを使用します。フレームワークの効果を評価するために、7つのデータセットを使用し、その性能を5つの最新のクローン検出器と比較します。また、コードクローン検出の大量のアルゴリズムを比較します。多数の機械学習技術（ANNおよび非ANN）の性能を比較し、ASTとPDGの特徴を融合することが、深層学習およびブーステッドツリーアルゴリズムを使用して競争力のある結果を与えることを確立します。XGBoostのようなブーステッドツリーアルゴリズムは、クローン検出においてかなり競争力があります。実験結果は、当該アプローチが予測精度の点で既存のクローン検出方法を上回ることを示しています。
Image-based methods
画像ベースのコード類似性測定方法は、コードフラグメントを画像に変換し、その後画像処理技術を使用してコードフラグメント間の類似性を見つけます[132]。視覚的クローン検出に触発され、WangとLiu[P77]は、クローン検出のための画像ベースの方法を提案しました。この方法では、事前処理されたソースコードが画像に変換され、画像間のジャカード類似性が計算され、類似したソースコードを見つけます。ソースコードの事前処理手順には、主にコメントと空白の削除、およびコード内のキーワード、データ型、識別子、およびリテラルのハイライトが含まれます。このアプローチは、主にコードスニペットの外観に依存しているため、タイプIVのクローンや意味的に類似したコードを検出することはできません。
Test-based methods
Hybrid methods
ハイブリッド手法は、個々の手法の課題に対処するために2つ以上の基本的な手法を組み合わせます。表3には、私たちの主要な研究によって提案された異なる手法の組み合わせとその適用領域が示されています。テキストベースの手法とトークンベースの手法が、主にグラフベースの手法や木ベースの手法と組み合わされていることが観察されます。前者の手法は効率的ですが効果が低く、一方、後者の手法は効果的ですが効率が低いです。そのため、これらの組み合わせは、コード類似性の測定に効率と効果を提供します。
トークンベース+テキストベースの手法
タイプI、II、IIIのクローンを見つける際の効率を保持しながら高い頑健性を実現するために組み合わされることもあります[P20]、[P29]、[P55]。
トークンベースと木ベースの手法
メトリックベース＋グラフベースの手法
Wangら[P40]によって提案されました。候補クローンは、メトリックベースの方法によって選択され、その後、クローンインスタンスのPDGを比較することによって結果がフィルタリングされます。メトリックベースとグラフベースは、Roopamら[P5]によって全プログラムのPDGを作成する高いコストを削減するために一緒に使用されました。Kodhaiら[P39]は、メソッドレベルでクローンインスタンスを検出するためにメトリックベースとテキストベースの手法を組み合わせました。候補クローンはメトリックベースによって検出され、その後、結果はテキストベースの手法によってフィルタリングされ、偽陽性サンプルが減少します。Higoら[P38]は、メソッドレベルでのクローンインスタンスを検出し、2つのトークンのシーケンス間のJaccard類似度を測定することによって行いました。選択されたクローンの名前は、その後、最終的なサンプルを特定するために比較されました。Tekchandaniら[P54]は、セマンティッククローンまたはクローンのタイプIVを見つけるための到達定義とライブネス分析に基づいたアルゴリズムを提案しました。彼らのアプローチは、IoT領域で開発されたプログラムを対象としています。彼らはまず、トークンベースの手法を使用して候補クローンを選択し、次に選択された候補のCFGを比較してクローンインスタンスの最終グループを特定しました。彼らは、各コードスニペットのペアにおける無関係なステートメントを見つけるために、データと制御フロー解析の両方を活用しました。著者らは、クローンペアの数がデッドステートメントの数が増加するにつれて増加すると結論付けています。ただし、提案された手法は、精度と再現率の尺度に関して経験的に評価されていません。
トークンベース＋グラフベースの手法
Yangら[P90]によって、トークンベースとグラフベースの手法が組み合わされました。ただし、彼らはグラフの比較にASTを使用しました。Dongら[P104]は、学生の宿題の盗作を検出するためにハイブリッド手法を使用しました。彼らのアプローチでは、与えられたコードを異なるコードスタイルを含むデータベースと比較して、まずコードのスタイルを認識します。同じスタイルのソースコードのASTが作成され、最終的なクローンインスタンスが決定されます。Thallerら[P127]は、トークンベースとテストベースを使用して意味的なクローンを特定しました。入出力パラメータのタイプは、トークン化されたコード断片を使用して静的解析フェーズで比較されます。その後、実行可能フラグメント（例：関数）の入力と出力値が比較され、プログラムの各ペア間の類似性が決定されます。彼らの提案されたツール、SCD-PSMは、テキストの類似性が異なる問題セットを表すため、コードクローンのタイプ2および3を検出することができません。木ベースとグラフベースは、Fangら[P99]によって組み合わされ、特に機能的なコードクローンを検出するために必要な構文と意味の特徴を抽出します。
木ベース+学習ベースの手法
近接ミスや意味的クローンを適切に検出するために主に組み合わされています[P80]、[P81]、[P82]、[P83]、[P97]、[P125]、[P126]、[P134]、[135]。
最近では、多くの研究者が学習ベース、木ベース、グラフベースの手法を組み合わせ、クローン検出のための機械学習モデルの特徴空間を改善しています[P48]、[P80]、[P81]、[P82]、[P94]、[P97]、[P106]、[P107]、[P109]、[P134]。
一部のハイブリッドベースのクローン検出手法は、上記の手法を単純に組み合わせるだけではありません。これらは主にプログラミング言語コンパイラによって提供される低レベルのコード表現に依存しています[P20]、[P28]、[P96]、[P117]。
Code similarity measurement tools and languages
Code similarity benchmark and datasets
データセットは、コード類似性測定ツールの構築と検証において重要な役割を果たします。主要な研究の調査によれば、ソースコードの類似性とクローン検出研究に関連する12のデータセットがあります。表5には、利用可能なコード類似性データセットといくつかの追加情報のダウンロードリンク、サポートされる言語、サイズ、および主な参考文献がリストされています。136のうち68（50％）の研究がこれらのデータセットを使用しています。残りの50％の主要な研究は、主に限られたオープンソースプロジェクトを使用しており、提案手法のほぼ半数に対して信頼性のある評価が欠けていることを示しています。私たちの調査によれば、これらの記事で70以上の異なるオープンソースプロジェクトが使用されています。ほとんどの研究では、GitHubプロジェクトを使用していますが、詳細がないため、異なるアプローチを公平に比較するのが難しいです。図10は、主要な研究で報告された情報に基づいて作成されたプロジェクトを使用してコード類似性測定ツールを作成および評価するために使用されたプロジェクトのワードクラウドプロットを示しています。主要な研究では、Apache Ant、ANTLR、JDK、およびPostgreSQLプロジェクトを主に使用して、自分たちのアプローチを構築および検証しています。
Bellonら[62]は、8つのソフトウェアスイート（4つのCプログラムと4つのJavaプログラム）でタイプI、II、およびIIIのクローンコードのリファレンスコーパスを作成しました。Bellonのベンチマークは、ファイル名、開始行番号、および終了行番号でコードクローンの位置情報を表しています。ベンチマークデータセットには、ギャップのある行の位置データは含まれていません。したがって、一部のタイプIIIのクローンを正しく評価することはできません[137]。Murakamiら[137]は、Bellonのデータセットにギャップのある行の位置情報を追加しました。ただし、このデータセットへのパブリックリンクは廃止されていることが観察されました。Charpentierら[138]の実験によると、参照クローンのかなりの割合が議論の余地があると示されており、これがBellonのベンチマークを使用して得られた結果にノイズをもたらす可能性があります。
BigCloneBench（BCB）[92]、[135]、[139]は、IJaDatasetソースリポジトリ内の既知のクローンのクローン検出ベンチマークです。ベンチマークの現在のバージョンであるIJaDataset（修正済み）およびクローン検出再現率を測定するツールは、GitHubリポジトリで公開されています（表5参照）。BCBデータセットのソースコードファイルは、さまざまなJavaオープンソースプロジェクトからクロールされています。私たちの知る限り、BCBはクローン検出およびコード類似性測定のための最大のデータセットです。それは、25000のシステムからのプロジェクトを含み、6000000の真のクローンペアと260000の偽のクローンペアがドメインの専門家によって注釈付けされています。KrinkeとRagkhitwetsagul[140]は、BCB [92]、[135]、[139]の構築方法を批判し、機械学習技術と特にともにコード類似性測定の学習において問題があると述べています。例えば、BCBには異なる機能に対する真のがラベル付けされていないクローンペアが含まれています。さらに、BCBデータセットは不均衡で偏っています。著者はBCBの既存の欠点を修正する解決策を提案していません。
CDLHの作業[141]は、クローンペアに真偽のタグがないコード断片を破棄したBCBのフィルターされたバージョンを提供しています。そのようなフィルタリングの結果、CDLHデータセットには9134個のコード断片が含まれています。しかし、著者はフィルタリングされたデータセットを公に公開していません。Schäferら[142]は、学習ベースのクローン検出タスクでのグラウンドトゥルース品質の役割を調査しました。著者は、CDLHデータセット[141]は学習ベースのクローン検出ツールを評価するのに適していないと結論付けました。BCBとCDLHの両方のデータセットには2つの主要な問題があります：（1）トレーニング、検証、および評価セットが厳密に分離されていないこと。 （2）ネガティブサンプルに対するグラウンドトゥルースがないこと、つまり、コードクローンでないものが何であるかが分かりません。
Luら[143]は、最近、コード理解と生成のための機械学習ベンチマークデータセットであるCodeXGlueを紹介しました。CodeXGlueには、14の異なるデータセットを持つ10のタスクのコレクションが含まれており、そのうち2つのデータセットはコードクローン検出タスクに属しています。CodeXGlueは、CDLHデータセットの9126サンプルとOJClone/POJデータセットのすべてのサンプルを使用しています[144]。
OJClone/POJ（POJ-104）データセット[144]には、104のプログラミング問題と、それぞれの問題に対する500人の学生が提出したC/C++のソースコードが含まれています。教育用のプログラミングオープンジャッジ（POJ）システムは、特定の問題に対して提出されたソースコードの有効性をテスト入力でコードを実行することで自動的に検査します。同じプログラミング問題を解決する異なるソースコードは、クローンインスタンスと見なされます。CF-500 [145]には、Cで書かれた23,000以上のコードスニペットが含まれており、Codeforces [95]というオープンジャッジングプラットフォームからの500の問題がカバーされています。各2つのコードスニペットでコードペアを構築できます。したがって、データセット内のコードペアの数は、すべての可能な組み合わせを使用すると10,000,000を超える場合があります。Code4Bench [91]は、Codeforcesプログラミングコンペティションプラットフォーム [95]に提出されたソースコードをベースに作成された類似のデータセットです。Code4Benchは、主に欠陥予測タスクに使用されています。Floresら[146]が提案したSOCOデータセットは、C/C++およびJavaプログラミング言語で再利用されたソースコードを検出することに焦点を当てています。このデータセットには、427のクローンコードのペアと66628の非クローンコードのペアが含まれています。
コード類似性データセットのサイズと多様性を増やすために、ZhaoとHuang[147]は、Google CodeJamコンペティション[94]の12の競技問題から1669のプロジェクトのセットを収集しました。このデータセットの各問題に提出されたコードスニペットには類似した機能があり、Googleがそれらを検証しています。したがって、これらは機能類似性（クローンのタイプIV）を検出するツールを構築および評価するために使用することができます。AtCoder [148]などの他のオンラインプログラミングコンペティションプラットフォームのデータはPerezとChiba [149]によって使用されています。ただし、最も頻繁に使用されるプラットフォームは、Google CodeJamコンペティション[94]とCodeforces [95]です。
GPLAGデータセットは、PDGベースの方法による盗用検出を評価するためにLiuら[16]によって作成されました。著者は、オープンソースのLinuxプログラム「join」から5つの手順を選択し、一連の盗用演算子[16]を適用してプログラムの変更バージョンを生成しました。このデータセットは公開されていませんが、著者によって提供された完全な説明に基づいて再構築することができます。マルウェアデータセット[20]は、マルウェア検出タスクを評価するために提案されました。オリジナルの悪意のあるコード、マルウェアの変種、およびVisual Basic言語で書かれた無害なコードが含まれています。GPLAGとマルウェアは、学習ベースのアプローチでは使用できない小規模なデータセットです。全体として、コード類似性測定の多くのアプリケーションに関するデータセット（コード推奨、コード予測、マルウェア、および脆弱性検出など）は限られていることが観察されています。
Comparison of code similarity measurement techniques
Challenges and Opportunities
Conclusion
この体系的文献研究は、主要な電子図書館で自動検索を実行し、関連するコード類似性測定とクローン検出の研究を選択します。初期の10000以上の記事から合計136の研究が選択され、それぞれの研究について、このトピックの異なる側面に関する5つの研究質問に答えるために詳細にレビューされます。この論文では、主要研究を次の5つの次元で分析します：手法、アプリケーション、データセット、ツール、およびサポートされるプログラミング言語。私たちの調査は、コード類似性測定の主要研究を分類することを目指しています。コード類似性測定に関する提案された分類に関する研究質問に対する簡潔な回答と、このレビューでの議論に基づく関連する結果は次の通りです：
RQ1の結果：当社のSLRによれば、ソースコードの類似性測定に使用される基本的な手法の少なくとも8つの異なる手法が存在します。学習ベースの手法とテストベースの手法は、最近のソースコードの類似性測定とクローン検出のコンテキストで適用されており、以前の調査ではカバーされていませんでした。SLRによれば、ほとんどの研究（27％以上）が、コードスニペットのテキストと構造の内容を比較してコードの類似性を測定するハイブリッド手法を採用しています。ただし、41％の記事のみが提案されたアプローチを公開されたソフトウェアツールでサポートしています。
RQ2の結果：当社の調査結果によれば、コードの類似性測定に関する研究は主にクローンおよび再利用の検出に焦点を当てています。しかし、私たちはソースコードの剽窃検出、マルウェア検出と脆弱性、コード予測、およびコード推奨という他の4つのアプリケーションドメインを発見しました。コードの類似性測定は、コードスメル検出、リファクタリングの提案、および不具合予測など、ソフトウェアエンジニアリングにおける労力を自動化できます。
RQ3の結果：主要研究からは、ソースコードの類似性とクローンを測定するための80のソフトウェアツールが抽出されましたが、そのうち33のツール（すなわち、41％）が公開されています。利用可能なツール全体では、18種類の異なるプログラミング言語についてコードの類似性測定とクローンの検出がサポートされています。これらのツールのうち、77％以上がJava、C、およびC++言語で書かれたプログラムをサポートしており、他のプログラミング言語やパラダイムに対するコード類似性測定ツールの不足が示されています。
RQ4の結果：主要研究の少なくとも50％が、主にGitHub上のJavaプロジェクトなどの限られたオープンソースプロジェクトを使用しています。コードクローンの検出とソースコードの類似性測定のために明示的に設計された12の異なるデータセットの使用が観察されました。136の主要研究のうち、わずか68件がこれらのデータセットを使用しており、報告されたデータセットがすべて公開されているわけではありません。産業や実際のソフトウェアシステムを含む公開、大規模、および品質の高いソースコードの類似性とクローンのデータセットの不足が観察されました。
RQ5の結果：コード類似性測定研究のパフォーマンスは、効果、効率、および拡張性の異なるメトリクスによって評価されます。既存の手法の効果に関して、当社のメタ分析では、適合率、再現率、F1スコア、および精度の平均がそれぞれ約86.3％、88.4％、86.5％、および82.5％であることが示されています。ただし、これらの結果は既存のツールを評価するために使用される異なるデータセットに基づいており、中程度の信頼性しかありません。コード類似性に基づく新しいアプリケーションのパフォーマンスは、古いアプリケーションよりも低いです。すべてのアプリケーションドメインでのコード類似性測定と標準データセットのさらなる実証評価が必要です。
RQ6の結果：当社のSLRは、ソースコードの類似性とクローン検出に関する研究の将来の方向性として考慮されるいくつかの潜在的な解決策を持つ、分野における6つの注目すべき課題を特定し、リスト化しています。包括的で大規模で信頼性の高いデータセットの不足、メトリクスベースおよび学習ベースの手法への注意の不足、人気のあるプログラミング言語と新しいプログラミングパラダイムの限定的なサポート、異なるアプローチの効率性と拡張性の経験的分析の不足、およびコード類似性測定に基づく新興アプリケーションを考慮した場合、分野における最も重要な課題と機会です。
コメント
コメントを投稿