概要
コールグラフを簡易に出すためにcall graphというintellijのpluginを利用して感じたことのメモ。
結論としては、有用そうだったが、Spring等DIを用いているソースコードの解析には今ひとつ足りないように感じた。
モチベーション
なぜcall graphを利用しようと思ったのか？
ソースコードの改修を行うとき、このコードは一体にどこに影響があるのだろう、と悩むことは多い。
そんな時に私は修正箇所のメソッドを呼び出している箇所を洗いだして、影響箇所を確認している。
このような作業をする替わりに、スパッと一瞬で下記のようなコールグラフが図示できたら素敵だな、というのがモチベーションである。
call graph
call graphは、コールグラフを出力することができるintellijのpluginである。
サポート対象の言語はJavaのみである。
試しにHikariCPで解析を実行してみたところ、下記のようになった。
上記図では細かいところは分からないが、もちろんズームすることができる。
メソッドをクリックすると繋がりの線が光るようになり、繋がりを追いやすくする工夫が凝らされている。
物足りなかったところ
DIによってインスタンス生成が行われている場合、コールグラフが期待した形にならない。
例として、下記のようなController、Service、Repositoryを利用した構成になっている場合を考える。
package com.example.tryjpa;
import java.util.List;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class Controller {
private final Service service;
public Controller(Service service) {
this.service = service;
}
@GetMapping("test")
public List<MyEntity> get() {
return service.findAll();
}
}
package com.example.tryjpa;
import java.util.List;
public interface Service {
List<MyEntity> findAll();
}
package com.example.tryjpa;
import java.util.List;
@org.springframework.stereotype.Service
public class ServiceImpl implements Service {
private final MyRepository myRepository;
public ServiceImpl(MyRepository myRepository) {
this.myRepository = myRepository;
}
@Override
public List<MyEntity> findAll() {
return myRepository.findAll();
}
}
package com.example.tryjpa;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;
@Repository
public interface MyRepository extends JpaRepository<MyEntity, Long> {
}
上記のようなコードの場合、call graphによる解析は下記のようになる。
ここで特に物足りないと感じるのは、Service.javaのfindAllメソッドとServiceImpl.javaのfindAllメソッドが別々に扱われてしまう点だ。
Controller#get -> Service#findAll -> MyRepository#findAll
の流れを見ることができれば最高なのだが、それは叶わない。
その他雑感
2020年発表の論文で、Webフレームワークのコールグラフ構築領域が未開拓であることが言及されている。
今、Springのコールグラフを出力できるツールがあったら是非知りたい。
正確なコールグラフを構築することは、健全で正確な静的解析を行うための重要な前提条件です。
多くの研究が健全なコールグラフ構築アルゴリズムの開発に費やされている一方で、Webフレームワークのコールグラフ構築の領域はほとんど未開拓のままである。
本論文の最初の貢献は、Springフレームワークのコールグラフ構築アルゴリズムの不健全さが、反射呼び出しの存在にのみ起因するという観察である。
これは第3章に記述されており、我々の問題を静的解析におけるリフレクションの処理に絞り込んでいる。
本論文のもう一つの貢献は、4章で説明するように、ハイブリッド解析アルゴリズムを提示することである。
このアルゴリズムは、Javaで書かれた入力Springプログラムの単純で、反射しないバージョンを生成する。このアルゴリズムは入力されたプログラムをSpringコンテナの初期化まで実行する。この実行からいくつかのBean情報を取得し、それを使って入力プログラムを単純な非反射型プログラムに変換します。
このアルゴリズムはSpringフレームワークの上で設計されたWebフレームワークで書かれたプログラムに対して動作し、これらのプログラムに対して構築されるコールグラフは必要に応じて健全かつ正確なものとなる。
このアルゴリズムのアイデアが、将来、プログラム解析者やウェブ開発者がコールグラフ構築アルゴリズムの健全性と結果のコールグラフの精度を研究し、（できれば）改善するのに役立つことを期待する。