ライブラリ利用例カタログの自動生成

ソフトウェアの色々な機能を作るための部品となるライブラリ。それらを初めてを使うときに頼りになるのが利用例、サンプルコードと呼ばれるものです。StackOverflow などの Q&A サイトでも、「〇〇を使って××するにはどうしたらいいか」という質問がよく行われています。

最近はオープンソースソフトウェアとして多数のプロジェクトのソースコードが公開されているのだから、そこからうまくクラスごとの利用例を収集できるのでは？と考えて、NAIST ソフトウェア工学研究室とオーストラリア・ウロンゴン大学の研究チームで協力してツールを作ってみました。

開発したツール Catalogen は、Java を対象として、クラス名を引数に、利用例のリストを HTML 形式で出力します。Apache POI という Microsoft Office のデータファイルを読み書きするライブラリのうち、XSSFWorkbook という Excel ファイルを扱うためのクラスの利用例を対象とした実行結果の例が こちら（XSSFWorkbook | Catalogen） です。

このツールは、以下のような仕組みで動作しています（著者最終版原稿PDFはこちら）。

1. オープンソースソフトウェアのソースコードを検索するサービス Searchcode.com に接続し、クラス名をクエリとして渡し、そのクラス名を使っているソースファイルを集めます。
2. 集めたソースファイルの中から、クラス名と変数名が連続しているところを見つけます。これが利用例の開始位置となります。
3. 開始位置から、その変数名が出現する行だけを拾い集めます。これが利用例の本体となります。
4. 同じ変数名が他の用途にも何度も使われる可能性があるので、"}" で変数のスコープが無効になったところで探索を終了し、見つかった行の範囲を利用例とします。
5. 利用例それぞれに対して、Natural Machine Translation 技術で Java のメソッド → Javadoc コメントの対応関係を学習したモデルを適用し、内容を表現しそうなコメントを割り当てます。
6. 利用例のうち、似ているもの同士をクラスタリングして、各クラスタから一番短いもの（最も単純そうなもの）を代表として、HTML に出力します。その他の利用例は、クラスタ名をクリックしたときだけ表示されるものとして扱います。

Apache POI の各クラスに対する実行結果はこちらにああります。コメントの内容等にはまだまだ改善の余地はありますが、全自動でこれだけ情報を整理できることに可能性を感じていただければ幸いです。本ツールは、ドキュメンテーション生成技術に関するワークショップ Dysdoc3 の一部として開催された DOCGEN CHALLENGE 2018 において、Usefulness 部門第2位に選ばれました。

このツールのようなドキュメント生成技術は、「ドキュメントを書いても誰も読まない、すぐに古くなってしまう」という問題に対して、「ドキュメントは必要なときに、その人の知識に合わせて作ればよい」という考えから、ここ数年、研究者が活発に議論を交わしているトピックの１つです。今後も、新しいアイディアや技術に基づいたツールが登場することになると思います。

開発者は使用するライブラリを更新しない

ソフトウェア開発では、画像の読み書きやネットワーク接続など、基本的な処理を提供するライブラリを土台にして、開発したいソフトウェアに固有の機能を作っていきます。

ほとんどの人は、開発を始めるとき、あるいはライブラリを必要とするような機能を実装するときに、ライブラリの名前やバージョンを調べて、その時点での最新版を開発に使います。それで何の問題なさそうにも思えますが、ライブラリの中にはセキュリティ問題などの深刻なバグが発見されることもあり、そういう場合には新しいバージョンに素早く移行することが求められます。ただ、セキュリティに関心のある一部の人々を除くと、ライブラリに新しいバージョンが出たといっても、大して気に留められることもありません。

そんな実態を、少しまじめに調べたのがこの論文です。

arxiv.orgいくつかのセキュリティ問題の報告に対して、横軸に時間、ライブラリの利用者数 (Library Usage, LU) を縦軸に取ったグラフを取ってプロットしてみました。以下は Apache Commons-beanUtils のセキュリティ問題発生時のものです（論文内 Fig.9 を引用）。

セキュリティ問題の報告に伴うライブラリ利用者数の変化

セキュリティ問題が2014年4月に報告され（図中の黒い縦の破線）、新しいバージョンがリリースされた後も、一定数のユーザが残っていることが分かります。利用者数のカウントは、リポジトリで更新作業をしていることを条件にしているので、「古いバージョンのライブラリを採用したまま、プロジェクトの更新が終わっている」ようなプロジェクトの数は除外しています。

調査対象全体では、 81.5％という多数のプロジェクトが古いバージョンのまま他の作業をしていました。この原因の１つは、個々のライブラリのバージョン更新内容をまじめに追いかけるのは大変である、ということにあります。幸い、2018年になって、GitHub など複数のサービスがセキュリティ警告機能（セキュリティ問題のあるバージョンのライブラリ利用者にメール等で連絡する機能）を提供するようになり、状況はだいぶ改善されました。それでも、ライブラリはバージョンごとに完全に互換性があるわけではなく、新バージョンに更新しようとして失敗する事例があることも報告されています。プロジェクト全体の他の作業で忙しい開発者にとっては、ライブラリの更新を迅速に実行するのは難しいかもしれません。

ライブラリ開発者が互換性を保ってくれれば自動更新ができるのに、という期待もあるかもしれませんが、非互換性の導入にもエラー報告の詳細化や危険な機能の削除など、相応の理由があることが知られています。そのため、ソフトウェアを新しいバージョンのライブラリでテスト実行して安全に更新できそうなときだけ自動で通知する、といった手法も提案されています。 また、本当に今すぐ更新する必要があるのか、セキュリティ問題のあるコードを実際に呼び出しうるか・実行しているかを自動的に判定するソフトウェアというのも研究レベルでは出てきています。以下がそういうプロジェクトの１つです。

github.comこの記事を執筆した時点では、すぐに実用に供するというには難しい開発段階のようですが、いずれは、このようなツールでソフトウェアの状態をチェックし、セキュリティ問題の報告に素早く応答することがソフトウェア開発の標準となるかもしれません。

ソースコードのコメントに登場する URL の役割

プログラミングの最中に、ライブラリの使い方やアルゴリズムの書き方など、様々な情報をインターネット上から集めてくることが一般的になっています。プログラムを書いたときに参考にした情報の URL をコメントとして一緒に記述しておけば、あとで参照できるので便利です。

そのような URL が実際にコメント中にどれぐらい存在し、どんな情報に対するリンクを記録しているのか。また、Web でも時折見かける「リンク切れ」のような問題が起きていないか、リンクはきちんと更新されているのか、という開発者の URL 利用のスタイルを調査しました。ソフトウェア工学の国際会議（ICSE 2019）で発表予定の著者最終版を既に公開しています。

arxiv.org
調査対象は GitHub プロジェクトに存在する 25,925個のリポジトリです。プログラミング言語として、ここ10年間で継続的に多くの開発者に使用されている（＝人気の高い）プログラミング言語である C, C++, Java, JavaScript, Python, PHP, Ruby の7つのどれかを使用しているプロジェクトのうち、少なくとも2年間は活発に活動していたものを選定しています。各言語の文法に従ってソースファイルからコメントを抽出し、正規表現を使って URL を収集して、トータルで 9,654,702個のリンクを集めました。

これに対して色々な分析を行っていますが、主な結果は以下の通りです。

• 80％以上のリポジトリで少なくとも1つは URL がコメントに出現する。リンク先として最も多く出現するドメインは github.com, stackoverflow.com, en.wikipedia.com である。
• リンク先のコンテンツとしては、ソフトウェアライセンスや、ソフトウェアプロジェクトや開発組織の情報、何らかの要求仕様・技術標準、チュートリアルや API の利用法などがある。コメントの内容から、リンクはソースコードに関する付加的な情報を参照できるようにするために書かれている。
• 全 URL のうち 9％がリンク切れになっている。ライセンスのような頻出するものはリンク切れが少なく、それ以外の用途のものが相対的にリンク切れが多い。GitHub 上のデータに対するリンクも、ソースコードの構造の変化などが原因でリンク切れが生じていることが多い。
• リンクは作られたあと、ほとんど更新されない（9％未満）。更新されているもののほとんどは、ライセンス更新や開発組織名の変更に伴う修正だった。
• リンク切れのうち、新しい URL が分かったものを14件 Pull Request として送ったところ、ファイルを変更しないでおきたい理由のある 1件を除いて受理されたので、開発者もリンク切れが望ましくないものであると考えていると思われる。
• StackOverflow の質問を指す URL の場合、その URL がソースコード中に初めて出現した日よりも後に、StackOverflow 側でコメントが増えるなどの変化が生じているケースが多い。つまり、そのソースコードを書いた時点で参考にした情報と、あとから見に行ったときに得られる情報は一致しない場合がある。

結果を踏まえると、何か外部ドキュメントを参考にプログラムを書いたときは、無効になりにくい URL を使う（たとえば文献ならば DOI を使う）こと、無効になっても再検索できるようにコメント側にもリンク先に関する説明を書いておくこと、そして定期的にリンク先の情報が新しくなっていないか確認することが重要であるといえそうです。ソースコードの更新にともなってコメント自体が古くなることもあるので、コメントやリンクを適切に保守していく方法を考えるのが、今後の課題といえるでしょう。

はじめに

このブログは、ソフトウェア工学の学術的な研究論文の内容を、 筆者の所属する奈良先端科学技術大学院大学ソフトウェア工学研究室の成果や関連研究を中心として、できるだけ平易に紹介することを目指しているものです。 

ソフトウェア工学は、高品質のソフトウェアを効率よく開発するにはどうするべきかを考える研究分野です。要求分析、設計、実装（プログラミング）、テスト、デバッグ、リリース、ドキュメンテーションなど、ソフトウェア開発に関するあらゆる活動が研究対象となっていますが、このブログでは、ソフトウェアの品質保証や再利用など、既に動くソフトウェアが存在する状況で使用される技術に関する研究を主に取り扱います。

このブログが、ソフトウェア工学に興味を持ち、ソフトウェア開発の方法について考えるきっかけになれば幸いです。