---
# System prepended metadata

title: 2023年研究テーマ

---

# 2023年研究テーマ

## higo

### テスト自動生成ツールによって生成されたテストは本当にバグ発見に役立つのか？(テスト，欠陥限局，自動プログラム修正)


テスト自動生成ツールによって自動生成されたテストは本当にバグの発見に役立つのかを調べる．バグ混入コミットの直前，バグ混入コミット，バグ修正コミットからテストを自動生成する．バグ混入コミットの直前から生成したテストがバグ混入コミットで落ちたならば，その生成されたテストはバグの発見に寄与している．他にもテストをいろいろクロス実行することでなにかわかるかも．


### 大規模言語モデルを利用したコードクローン検出手法（LLM，コードクローン）

An Empirical Comparison of Pre-Trained Models of Source Code(https://arxiv.org/abs/2302.04026)ですでにクローン検出されているけど，大規模言語モデルを利用していない他の検出手法との比較はないのでそれをする価値はあるかも．また，FEMPデータセット(https://github.com/YoshikiHigo/FEMPDataset)を利用してファインチューニングすることで検出の精度をあげることはできないだろうか．


### Java以外の機能等価メソッドペアデータセットの作成

機能が等価なメソッドペアのデータセットはソフトウェア工学におけるさまざまな研究において役に立つ．
Javaに対しては機能等価メソッドペアデータセットを作成した(https://github.com/YoshikiHigo/FEMPDataset)．
次にPythonや他の言語に対しての機能等価メソッドペアデータセットの作成を行う．
Ｐｙｔｈｏｎのような動的言語では引数の型が明示されていないことが多く，それに対処してデータセットを作る必要がある．


### ChatGPTはStackOverflowの人間による回答よりも賢いかの調査（LLM）

StackOverflowで，人間がよい回答をした質問，よい回答をしていない質問をChatGPTに投げてみる．


### Mock関連でなにかできないか(テスト)

Mockって使うのが難しい＆めんどくさい．
Mockの使用例は以下．
この例では下記の仕様を満たすRandomオブジェクトを生成している．
- nextBooleanは一回目の呼び出し時にfalseを返す．
- nextIntは一回目の呼び出し時に1を返し，二回目の呼び出し時も1を返す

https://github.com/kusumotolab/kGenProg/blob/3826ba82e9ffb97b53fe8239f94282a83801de31/src/test/java/jp/kusumotolab/kgenprog/ga/crossover/UniformCrossoverTest.java#L134-L138
Mockを使うコードの自動生成，Mockがどのように使われているかの調査等，なにかmock関連でできないだろうか．
Mock関連の研究は余り行われていないような気がする．


### ラージコミットを対象としたファイル追跡の改善（リポジトリマイニング）

gitリポジトリではgit-logコマンド等でそのコミット履歴を辿ることができるが，ラージコミット（多くのファイル変更を含むコミット）がある場合に，追跡精度が著しくさがることが知られている．そこで，ラージコミットを分析し，ラージコミットが存在しても高い精度でコミット履歴を辿ることができる手法の考案を目指す．
関連ツール：https://github.com/kusumotolab/FinerGit
関連論文：https://www.sciencedirect.com/science/article/pii/S0164121220300522


## matusita

### MUDABlue revisited: OSSプロジェクトマップの作成
多種多様なOSSプロジェクトが持つ生成物から、各プロジェクトの持つ特徴（コード、開発者、開発環境、開発地域、バイナリなど）をベクトルデータとして表現し、プロジェクト間類似度、ないしクラスタリング手法によってプロジェクト間の相互依存関係を定義する。定義された情報を用いて、多数のOSSプロジェクトの関係（ないし関係の一部に着目したデータ）を可視化するツールを作成する。ツールにより、全体ないし部分の把握、ならびにプロジェクトの検索を行えるようにする。[可視化はたぶんあとで、先にそういうプロジェクト間依存関係をうまく決めるのが先だとは思います]

### プログラミングコンテストの過去の結果を利用した式単位でのバグ出現箇所の予測
デバッグには多くのコストがかかるため，コーディング段階でバグを発見し修正できることは有用です．そこで本研究では，プログラミングコンテストの 過去の結果を利用し，コーディングの最中にバグ出現箇所を予測，提示するツールの作成を目的とします． コンテストサイトの提出履歴を用いるのは，バージョン管理システムに比べて細かな粒度で変更履歴が残っていることが期待されるためです． 手法としては，まず過去のコンテストサイトへの提出を集計し，バグ修正の行われた箇所の統計をとります(配列外アクセスや演算子など，式単位で)．そして，現在のソースコードの静的解析結果と合わせて，バグの起こりやすい箇所が見つかれば提示することとします．

### 機能単位で見たライブラリの利用状況遷移の可視化
ある機能を実現するソフトウェア（ライブラリ）は世界で1つしかないということはなく複数考えられますし、単に進化の過程で1つの開発が複数に分岐、ならびに統合されたり、複数のソフトウェアが共存する場合もありえます（すでにそのような分析を行う研究があります）。従って、上記で述べた話は、ソフトウェア全体を俯瞰して考えた場合、単一ソフトウェアの複数バージョンのみならず、単一機能（というのをどう定義するかは別途議論あるでしょうが）の複数バージョンを前提としたほうがより自然ではないかと考えます。過去の研究を参考にしつつ機能を組み合わせて、そういう話を考えるのは、これから何かソフトウェアを作成する際に有用ではないかと考えます。さらに、Mavenリポジトリなどの大規模リポジトリ全体でこの話を考えた場合、「世の中でどのような機能が（ライブラリ等の形で）提供されているか（ないし、されていないか）」を整理して提供できることが考えられます。これは今後必要となるであろうライブラリが、どのような分野でありえるかを考える指針になりそうですし、現時点におけるソフトウェアのトレンドを分析する材料にもなりそうです。

### 一般化したコード修正方法の記述
[実現可能性の検討が多少薄めなんですが]EditScriptだったり、AST作った木の差分だったり、実はよくつかわれているのがdiff(1)だったりしそうですが、いわゆる「ソースコードを修正した内容」を表現する話は様々あります。が、現状はまあ仕方ないと思いますが一定の書き方ってよくわからなくて、結局その目的その他であれこれ都合がいい話が使われています。ただ、「これをこうする」って話はなんか都合のいい方書き方があってしかるべきではないか、と考えています。モチベーションの1つは過去の研究でbugfixないし機能改善をやろうと思った時、修正内容が書けさえすればあとはそれを適用して...gはできるはずなのに、一般的方法がなくて毎回AST作るって話になってしまうのを何とかしたい、のでした。データ定義のJSONじゃないですけど、必要なデータが書ける方法を考える、のと、（それだけでは全くうれしくならないので）そのデータを入力としてソースコードの書き換えをできるツールの作成、くらい。汎用性を上げてるけど使えるものにしたいので設計がそもそもできるんか、ってあたりが悩ましいですが。


## t-kanda

### SPDXファイルを活用したエコシステムの分析技術の開発

ソフトウェアパッケージのメタデータを格納するフォーマットであるSPDXは、GitHubのリポジトリからSPDXファイルを取得する公式機能が追加されるなど、最近急速に普及している。このSPDXファイルを利用して、エコシステム全体を分析する手法を開発する。南山大・井上先生と共同


### マージコンフリクトの片側採用について自動解消ツールの判断との比較

マージコンフリクトの解消方法を提案するツール（深層学習系）が提案されている。OSSのコンフリクトでは「片側だけを採用（もう片側は完全に切り捨て）」することが多くあり、これは「片側採用でよかった」ケースと「開発者が内容を精査していない」どちらの可能性もある。これらのコンフリクトをツールにかけて片側採用に近い判定になるかを見たり、マージ時のメッセージを見たりして分析する

### マイグレーションガイドの整備状況の調査

ライブラリの進化に伴って互換性のない（破壊的な）APIの変更が起こることが知られている。変更が起きたときに開発者が対処するためのドキュメントがどの程度整備されているか（ガイドがある、気をつけろくらいしかない、書いてないなど）を調査し、ライブラリ移行支援ツールやマイグレーションガイド自動生成ツールの必要性を考える

### package.jsonのスクリプト部分のマイニング

package.jsonに関して、比較的記述の自由度が高い部分としてscriptsのセクションがある。スクリプト名と実行されるコマンドの組なので、スクリプト名と中身は世の中的にどれくらい一致しているのか（命名ルールはあるのか）、同じスクリプト名で中身が違ったり逆はないか、そもそもフレームワークのテンプレ以外に自分で書き足しているのかを調べてみたい

## yangsy

### Validity of code snippets posted on Stack Overflow that contain JavaScript libraries

There is a plethora of JavaScript libraries for use on the web and in node.js apps out there. This greatly simplifies, but we need to stay update on security fixes. "Using Components with Known Vulnerabilities" is now a part of the OWASP Top 10 and insecure libraries can pose a huge risk for your webapp. Q&A sites like Stack Overflow have accumulated a wealth of information. There are no studies available for the security of JavaScript libraries used in code snippets posted on StackOverflow. Therefore it is necessary to investigate the validity of code snippets on StackOverflow that use JavaScript libraries.

### Explore the usage frequency and popularity of tags on Stack Overflow

We can perform a quantitative analysis of the frequency and popularity of various tags on Stack Overflow, compare the usage patterns of different tags, and examine differences in tag usage across diverse languages and domains.


## k-kawabt

### プログラミング演習問題の難易度推定

プログラミング演習問題の難易度を機械学習モデルなどで推定する。AtCoder、Codeforcesなどで出題された問題は何人に何分で解かれたかを基準として難易度が数値で示されている。
これを機械学習等で学習して難易度が付与されていない問題(出題前の問題、他サイトの問題等)に難易度を付与できるツールを作成する。

## tyngtmyn

### ソフトウェアライブラリ依存関係問題解決手法の開発

ソフトウェアの開発には様々なソフトウェアライブラリが利用される。しかし、利用するライブラリの組み合わせによっては依存関係による問題が発生し、実行時に期待した動作を得られないことがある。本研究ではソフトウェアライブラリのソースコードを解析してライブラリ間の依存関係について調べることで依存関係問題を解決することを目指す。

