# 2024年研究テーマ

## higo

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

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

### コード（メソッド）の進化とテストの関係はどうなっているのか？

ソフトウェアの開発においてプロダクトコードは何度も修正されるが，そのテストについてはどうだろうか？Javaのメソッドに注目し，メソッドの制御フローに変化があるような変更が行われたときに，ちゃんとテストも変更・追加されているのかを調査する．

### テストコードの分析

よいテストコードとしては，構造が簡単（分岐がない）やアサーションの数が少ない等があるが，実際のテストコードはどうなっているだろうか．
また，よい構造をしているテストの方が対象メソッドに帯するコードカバレッジは高いだろうか？
悪い構造をしているテストがあったときその原因は何だろうか？悪い構造を持ったテストになっている原因は悪い構造を持ったプロダクトコードになっていないだろうか？

### SBFL-SuitabilityやAutorepairabilityの変遷調査

対象プログラムにおいてどの程度欠陥限局がうまく働くかを表す指標であるSBFL-Suitabilityや，どの程度自動プログラム修正ツールがうまく働くかを表す指標であるAutoreparabilityが対象メソッドの進化に伴いどのように変化していくのかを調査する．また，対象メソッドがどのように変更された時に，その値が大きく下がるのか上がるのかを明らかにする．
SBFL-Suitablity: https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=210658&file_id=1&file_no=1
Autoreparability: https://sdl.ist.osaka-u.ac.jp/pman/pman3.cgi?DOWNLOAD=621

### 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関連の研究は余り行われていないような気がする．

### 機能等価メソッドペアのデータセットを使って何かしたい

Javaのメソッドの機能等価メソッドペアのデータセットを作ったので，このデータを使って何かしたい．2023年度B4井上くんの卒論はこのデータをファインチューニングに使ったクローン検出精度の改善だった．
機能等価メソッドペアのデータセット：https://github.com/YoshikiHigo/FEMPDataset
井上SIGSS:https://sel.ist.osaka-u.ac.jp/lab-db/betuzuri/archive/1288/1288.pdf

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

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

## D3 Shiyu Yang

### Assessing the Security Risks of JavaScript Library Usage in Stack Overflow Code Snippets

In the dynamic landscape of web and node.js development, JavaScript libraries play a pivotal role by streamlining the development process. However, this convenience comes with the caveat of staying vigilant about security updates. The inclusion of "Using Components with Known Vulnerabilities" in the OWASP Top 10 highlights the critical risk posed by insecure libraries to web applications. Despite the wealth of knowledge available on Q&A platforms like Stack Overflow, there's a discernible gap in research regarding the security of JavaScript libraries embedded within code snippets shared on the platform. This gap underscores the imperative need to scrutinize the validity and security implications of employing JavaScript libraries in Stack Overflow code snippets, aiming to safeguard web applications from potential vulnerabilities.

### Evaluating the Performance Differences of Large Language Models in Bidirectional Translation between Natural Language and Code

This research project aims to evaluate the performance differences among various large language models (LLMs) in the bidirectional translation tasks between natural language and code. By conducting a series of experiments across multiple programming languages and complexity levels of coding tasks, this study seeks to quantify the effectiveness, efficiency, and accuracy of LLMs in generating executable code from natural language descriptions and vice versa. The project will explore the models' capabilities in understanding and generating code, identifying strengths and limitations for specific applications such as software development, code review, and programming education. Through this analysis, the research intends to provide valuable insights into optimizing the use of LLMs in coding tasks, contributing to advancements in automated programming and AI-driven code documentation.

### Predicting Technology Trends Based on Stack Overflow Data

This project involves analyzing data from Stack Overflow to identify trends in the questions related to different programming languages and technologies over the past few years, with the aim of predicting future popular technologies. By collecting and analyzing the number and growth rate of questions tagged with specific programming languages and technology tools, researchers can identify the fastest-growing areas. Additionally, considering the community's engagement (such as the number of answers to a question and their quality) and user feedback (like votes and favorites), deeper insights into the community interest and market demands behind these trends can be gained. This study not only reveals current technology trends but also helps predict the development direction of future programming languages and technological tools.

### Research on Automated GitHub Project Documentation Generation using ChatGPT

This study aims to explore the feasibility and effectiveness of using ChatGPT to automatically generate documentation for projects on GitHub. By selecting samples from projects of various sizes and domains, this research will utilize ChatGPT to generate new documentation based on project code and existing documents. The study will evaluate the differences in quality, comprehensiveness, and user satisfaction between these auto-generated documents and traditional manually written documentation, to investigate the potential of ChatGPT in improving documentation writing efficiency and quality.

## M2 Yamamoto

### Kubernetes周りで何か
近年Kubernetesと呼ばれるコンテナオーケストレーションツールが広く使用されている．
Kubernetesはコンテナ化されたアプリケーションのデプロイや管理を行うことができる．
また，KubernetesはIaC(Infrastructure as Code)の1つでもあり，コンテナ自体の設定やコンテナ間のネットワーク設定などをManifestと呼ばれるYAMLファイルでソースコードとして設定・管理可能である．
(ただKubernetesが好きというだけで，Kubernetes関連で何か研究できないかなあという軽い気持ちで以下にいくつか候補を挙げます．)
関連ワード：`Kubernetes`, `IaC`, `Platform Engineering`

1. KubernetesはYAMLファイルを使用してManifestでインフラ環境を定義することができるが，アプリケーションの規模に比例してManifestが増加し，管理しにくくなるという問題がある．これを「YAML地獄」とも呼んだりする．こういった課題を解決するためのツールとしてKustomozeやHelmなどが一般的であるが，これらに問題点はないだろうか．もしあればそれを解決するツールを作ったら面白いかもしれない．つまり，IaCの**Code**の部分をソフトウェアと見做し，課題解決するツールを提案したい．
2. Kubernetesを使用したシステムの開発者視点での懸念点として複雑化したアプリケーションのインフラ構成を掴みにくいという問題点がある．特に大量のManifestを見せられただけではアプリケーション全体の設計イメージが沸いてこない．設計図を自作して管理している開発組織も多いがコンポーネントの増加と共に設計図を更新するのは手間がかかるしなかなかドキュメントを頻繁に更新している組織も少ないんじゃないかと思われる（これは主観）．よって，Manifestを読み込ませると全体のシステム図がUIとして出力されるようなツールがあったら嬉しい．（そもそもそんなツールがあったら没案になりそうですが，今のところ自分は知りません．その辺りの調査から入るイメージです）つまり，この案はKubernetesを用いたアプリケーションの開発者体験を向上させるためのツールを提案するものである．

他にもインフラ環境をソースコードで管理する話は沢山ある（Docker, Terraform, Chef...）ので興味ある方はどうぞ。

## M2 Kobayashi

### 大規模言語モデル（LLM）を用いたコード翻訳についての研究
近年，様々な生成AIが登場する中でも，LLMを活用したものが注目を集めており，BERTやGPT-3, 4などはLLMを元に構築されている．
このようなモデルは高い言語能力を持っており，あるプログラミング言語から別のプログラミング言語に変換するコード翻訳に用いられることがある．
この技術を利用し，現在では採用されないようなレガシー技術で開発されたソフトウェアのソースコードを，現在の技術に自動的に置き換え，保守性の向上や，バージョンアップ作業の効率化を図ることを目的として研究を行う．具体的には，Object-C→SwiftやVue.js→React.jsなどの翻訳が考えられる．
（LLMについて興味はあるが，自分では手が回らない＋昔の技術で開発された現在も動いているソフトウェアの管理って面倒で大変だよな，という軽い気持ちでテーマとして挙げてます．）

## M2 Kishimoto

### 標準のパッケージ管理システムが存在しない言語を対象とするSBOM生成ツールの作成

近年，ソフトウェアの適切な管理のために，ソフトウェア部品表（Software Bill of Materials, SBOM）の利用が推奨されている．
ソフトウェア部品表には，ソフトウェアを構成するライブラリやファイルなどの情報が記述されており，
それらの情報を利用することでソフトウェアが依存するライブラリに脆弱性が含まれていないか確認したり，
ライセンス違反が発生していないかを確認したりすることができる．
ソフトウェアに関する情報を手動で収集してSBOMを作成するのは手間と時間を要するため，
標準のパッケージ管理システムが存在する言語に対しては，パッケージ管理システムの情報からSBOMを自動生成するツールが開発されている．
しかし，CやC++のように標準のパッケージ管理システムが存在しない言語では，
依存するライブラリの情報を特定することが容易ではないため，それらの言語で作成されたソフトウェアのSBOMを自動生成するツールは不足している．
この問題を解決するために，依存するライブラリを特定する方法を考案し，その方法に基づいたSBOM生成ツールを作成する．

## M2 Otoda

研究として成立するかとか実現性とかはあまり考えずに出した案です。

### SBOM ツールの現況調査

SBOM についての諸々はすぐ上の岸本さんのテーマを参照。現在の SBOM 利活用にあたっての課題としてはそれ以外に、黎明期すぎるために文献が極端に不足しており、「そもそも何（ツール）を使えば良いのか、目的を果たすツールは存在するのか、どうやって使えば良いのか」がさっぱり分からないというものがある（[私の Stack Overflow 調査論文](https://sel.ist.osaka-u.ac.jp/lab-db/ja/betuzuri/contents/1286/)の結果をその根拠として使える？）。

というわけで、「今どんな SBOM ツールがあって、どのような使い方で、それぞれがどんなユースケースをカバーしているのか」というのを網羅的に調査してまとめた論文があると、SBOM 実践者にとっては非常に有難いのではないかと考えられる。単に Readme などを読んで調べるよりは、実際に動かして調査する方がいいと思われる。どうしても主観評価にならざるを得ないので、その点は工夫が必要。

### バグ・脆弱性の重要性診断

[Test Mimicry to Assess the Exploitability of Library Vulnerabilities](https://dl.acm.org/doi/10.1145/3533767.3534398)（[輪講](https://sel.ist.osaka-u.ac.jp/lab-db/rinkou/contents.ja/980.html)）の発展。現代のソフトウェア開発では大量の外部ライブラリを活用するが、これによってそれらの脆弱性の影響を受けるセキュリティ上のリスクが発生するため、それを適切に管理する必要が生じる。一覧化という方向性でそれをサポートするのが SBOM であるが、一方で大量の外部ライブラリを活用するプロジェクトでは報告される脆弱性の数が莫大なものとなり、対応が追いつかなくなる。そこで、対応すべき脆弱性の優先順位付け（トリアージ）が必要となる。

NVD など脆弱性の優先順位付けを行っている機関は存在するが、人力なため信頼性の不足が指摘されている。これに対し、機械的に根拠を持って優先順位付けしようと試みている手法の 1 つがこの論文である。また、このモチベーションからは外れるものの、必ずしも脆弱性診断としての応用ではなく、もっと一般的にバグのトリアージにも使えるのではないかという話がある（大量のバグのうちどれから取り掛かるかというのも、脆弱性同様に重要な問題である）。一応ソースコードが公開されているものの、ちゃんと動くのかどうかとか、詳しいところはよく分からない。

### 法的文書を静的解析して読みやすくする手法

法律や契約書（ソフトウェアライセンスを含む）などの法的文書においては、人によって恣意的に好き勝手な読み方をできてはいけないので、先頭で厳密な用語定義が大量に行われた後にその語句を用いて本文が展開される。しかし、そうなると本文を読んでいる間に何度も用語定義を参照しに行くことになり、かなり読むのが大変である。そこで、本文中の該当語句にホバーすると定義を見せてくれたり、別の条文を参照する部分にホバーするとその条文をポップアップしてくれるような支援システムがあるとかなり読みやすくなるのではないか。他には、法律間の依存関係なんかが可視化されると最高だなとは思う（自然言語でこれをやるのは鬼畜ルートだろうが...）。

法的文書は体裁が画一的で形式的なため、ある意味ソースコードと似ている。では、ソースコードに対してこれまでに提案されてきた静的解析手法をうまく応用できないだろうか。ただし、自然言語である以上、機械で読むことを想定して設計された言語よりは難儀しそう。また、書いた人・組織、制定の年代によっても文体がかなり違いそう。以下が一応それっぽい文献。

- https://cir.nii.ac.jp/crid/1040000781622821376
- https://techtarget.itmedia.co.jp/tt/news/1909/04/news10.html
- https://www.datatech.com/solution/legal-data/

### 組み込みソフトウェア開発の生産性・信頼性・保守性を向上させる手法

ソフトウェア開発における生産性・信頼性・保守性の向上にあたり、オブジェクト指向や関数型などのパラダイムの発明、高度な型システムやコンパイラによる強力な安全性検査など、さまざまな技術や開発技法が生み出されてきた。しかし、OS を搭載しない業務用マイコンに代表されるように、C 言語しか使えずメモリ容量等のリソース制限も厳しい状況下においては、一般のソフトウェア開発で広く普及している技術や手法を適用できないことが多い。そこで、そういった環境で生産性・信頼性・保守性を向上させるための手法を検討する。

いくらなんでも発明するのは無理難題なので、世の中ではどんな工夫がされているのかを調査してみる方向が一番現実的かもしれない。また、Linux syscall や Win32 API のような低レイヤ API を直接操作する実装も、低レイヤな実装スタイルに制約されがちなので対象にできるかもしれない。

## M2 Tabata

### ライブラリ移行に関する既存研究の対象言語拡張

ライブラリ（再利用可能なコード群）を利用して開発効率を向上させる取り組みは，ソフトウェア開発一般に見られる．さまざまな言語ごとにライブラリのエコシステムが構成されており，ユーザはパッケージマネージャを介してライブラリを提供または利用する．例えば[libraries.io](https://libraries.io/)では，主要なパッケージマネージャとして

- Java の Maven
- Python の PyPI
- Javascript の npm
- Ruby の RubyGems
- C# (.NET) の NuGet

などが紹介されている．

一方，ライブラリに関する研究の中でも「移行」の話に着目すると，その多くがJavaのみを対象としている（あくまで自分が調べた範囲の話ですが）．そこで，何らかの既存研究を選択した上で，その枠組みは同じまま対象言語の拡張に取り組む．エコシステムごとの特徴や固有の問題など，新たな知見が得られると嬉しい．

具体的なテーマとしては，以下が挙げられる．

- 移行の傾向や移行にかかるコストの実証調査
- 類似ライブラリや移行前後のコードを集めたデータセットの作成
- ライブラリの自動移行や代替ライブラリ推薦の手法提案

※一部テーマではPythonやJavaScriptといったメジャーな言語への拡張例も見られるとは思いますが，さらに他の言語へ拡張するだけでも新規性は主張できるのでは？と考えています

※手法提案系の研究は言語依存な部分が大きそうなので，調査系の方が取りかかりやすいかなぁとは思っています

## matusita

### 学習時に用いるデータセットの非独立性が機械学習モデルの性能に与える影響

M2服部修論関連。プログラミングコンテストのデータを使って慎重に設計したデータセットはあるので（念のため要第三者検証）、ソフトウェアを入力として判定を行う既存モデルに適用して、モデル作成側が主張する結果がどの程度追試可能かを検証してみる。また、先に設計したデータセットは、コードを書いた人の能力判定を前提としたものであったところ、世の中には多様な、データセットの収集元になりうるデータがあるので、それらを用いて同様の作業を行い、データ非独立性がモデルの性能にどのような影響を与えるのか、を確認する。

### （GPT-4を用いた）コード機械翻訳ネタ

1つ目：単純な話としては、データセットを（競プロではなく）実ソフトウェアでやってみた場合にどうなるか、をやってみる。ただこの時変換先が正しいかどうかを確認する方法がないと困ってしまうので、実ソフトウェアならなんでもいいのか、と言われると悩みどころ。まだ検証しやすい小さなツールくらいで試してみる、あたりから、かも。

2つ目：翻訳したコードの自然さについての調査。変換した後使って終わり（人間が見ない）、だったら気にしなくていいけど、その後人間が保守するならその辺は気になるはず。既存のコード可読性評価手法は使えるだろうし、blind testしてみる方法もあり。

3つ目：現状ではGPT-4以外にも複数同種のLLM物があるので、コード翻訳向きなLLMがどれかを調査。また、プロンプトとしてどのような書き方が良いか、LLMの世界で知られるprompt engineering手法で有効なものはどれか（あるいはないのか）、を調査してみる。