ソフトウェア工学研究の日々

ソフトウェア工学の学術研究を紹介しています。ここではソースコードなどのプロダクトが研究の主役です。

プログラミング言語処理の練習課題

研究ではプログラミング言語で書かれたソースファイルの中身を調べることが多くありますが、そのような処理をどのようにプログラムで記述するかまでを入学時点で知っている学生は、ほとんどいません。各研究課題に合わせて、プログラミング言語の字句解析や、構文解析といった技術について勉強をしてもらっています。

そのための資料の一部は SlideShareGitHub で公開しています。どのような感じの技術であるか知りたい人はご覧ください。

www.slideshare.net

スライドに書かれた演習問題(Java プログラムの中に定義されたメソッド宣言の一覧を取ってくるなど)は、この手の研究を始めるにあたってよくある処理の代表のつもりで選んでいます。スライド内で参照されているリポジトリGitHub - takashi-ishio/ParserExample)に、Java で記述された構文解析の実装および実行例を収録しています。自分で作らずに回答だけを見たい人は "implemented" ブランチのソースコードをチェックアウトして実行してみてください。実行をコンソールで行う手順を Google Colaboratory を使って作ってみたものがこちらにあります。

プログラミング言語処理には馴染みがない人も多いかもしれませんが、こういうものから簡単に触れてもらって、興味を持ってもらえると幸いです。

 

ソースコード差分を集めるための git diff では --histogram を使うべき

当研究室博士後期課程の Yusuf Sulistyo Nugroho さんが発表した、言いたいことは論文のサブタイトル("Use --histogram for code changes")で終わっている論文です。オープンアクセスとなっているので、どなたでも全文をダウンロードできます。

link.springer.com

git diff では使用するアルゴリズムをいくつかから選ぶことができます(参考:Git のオプションをまとめられている方の記事)。この論文では、アルゴリズムを histogram にした場合としない場合でどちらが良いか、また、そのような差が、diff をベースにしてバグが最初に導入された原因コミットを特定する技術(を使った各種研究)に影響する可能性を議論しています。

研究のアプローチは、21,590件の変更に対して、母集団を代表できるよう377件をサンプリングして、それらを手作業で調査する、という方式での調査となっています。画期的な方法があったわけではなく、地道な調査です。

結果として、diff アルゴリズムの結果は劇的に違うわけではないが、histogram のほうが良い、と報告しています。この報告の影響で、git の Windows Explorer への統合等の UI を提供している gitextensions プロジェクトでも histogram をサポートされるようになりました。以下の issue として論文(の著者最終版)が引用されています。

github.com

Git のオプション自体はこの研究を行う前から存在していたので、やったことだけを見ると「オプション機能1つの効果を調べた」という一風変わった論文となりました。様々なソフトウェア工学の研究で Git が基盤ツールとして使われるから、重要性を査読者に高く評価してもらえたのだと思います。

 

[修正履歴] 記事タイトル「Git の diff では」を「ソースコード差分を集めるための git diff では」と変更しました。この研究はリポジトリマイニング技術の適用場面に関するものであって、状況によって他のオプションが優れている可能性までは否定していないためです。

 

ソフトウェア保守と進化に関する国際会議(ICSME2019)に参加してきました

 2019年9月30日から10月4日まで、アメリカ・クリーブランドで開催されたソフトウェア保守と進化に関する国際会議 35th IEEE International Conference on Software Maintenance and Evolution に参加してきました。

 筆者の研究室と直接関係する発表は、筆者と大阪大学の共著による Near-Omniscient Debugging for Java Using Size-Limited Execution Trace というツール発表です。Omniscient Debugging (全知デバッグ、またの名を Time-Travel Debugging, Reversible Debugging)を本気で実装すると実行トレースとして 10 MB/s ぐらいのデータ量を保存する必要があるのに対し、各命令に対して最大 k 回までとデータ量を限って情報を保存すれば、1%以下のデータ容量で、8~9割程度のデータフローが追跡できるようになる、といったコンセプトを示しました。発表資料はこちら(大阪大学ソフトウェア工学研究室のページ)からダウンロードできます

 同会議および併設イベントでは、このほか、先日ソフトウェア設計学研究室で博士課程を修了した Md. Rejaul Karim さん筆頭の Identifying and Predicting Key Features to Support Bug Reporting という論文のほか、東京工業大学早稲田大学広島市立大学大阪大学日立製作所からの研究が発表されていました。

 本会議1日目の基調講演は Laurie Williams による「Software Engineering Research: Beyond Impacting Practitioners」。研究者が追及する State of Art もよいが、それが実務者や社会に対してどのような意味があるのか、State of Practice、State of Society を考えるように、という内容でした。例としてセキュリティの研究者が議論している高度な攻撃・防御方法のほとんどは、きちんとパッチ当てる、適切なパスワードを設定するといった普通の人が日常的に遭遇する問題の解決には役に立たないこと、たくさんのシステムに確実にパッチを当てるのは新規性のある研究にはならないが非常に難しいことを引き合いにして、研究と社会の関係を改めて見直すことを提案していました。

基調講演では、紹介された研究の価値を考えるためのテンプレートとして、以下の文章が示されていました。

The goal of this research is to aid [stakeholder] to [solve problem] through [research technique].

ICSMEに採録された論文から実際にこの文章を作ってみると、多くの論文は開発者に対する技術であり、また研究者やユーザのための技術もあるが、一部論文にはこれが書かれていないと指摘していました。そして、Academia には研究のためのデータはないが頭脳がある、Industry には課題とデータはあるが時間がない、だから産学連携が重要であり、「できるからやる」研究をするのではなく、世の中を良くするための研究をする意識を持つように、そして OSS は世界全体ではないと、安易に OSS のデータ解析に流れがちな研究者に対して釘を刺しつつ、話を締めくくっていました。上記のテンプレートは、簡単で任意の研究で使える、分かりやすいものだと思います。

 本会議ではたくさんの論文が発表されていましたが、筆者にとって今回印象的だったのは Keith Gallagher らによる「Teaching Software Maintenance」です。チームで既存のソースコードを調べ、修正すべき場所を特定し、影響を予測するといったソフトウェア保守の活動をどのように授業(演習)として行ったかを報告した論文でした。学生にとっては非常に大変な思いをするが、同時に満足度も高い授業の基本的なやり方と、その結果得られた経験について説明されています。

 また、Industry Abstract として論文自体は非常に短い(詳細が書かれていない)ですが、Hyrum Wright による「Lessons Learned from Large-Scale Refactoring」というタイトルの発表も非常に個性的でした。Google では全員が20億行のコードベースを共有しており、コンパイラやライブラリの更新など、システム全体に影響を与える大規模更新が行われること、そしてそれを自動的に適用するには自動テストが重要であることと、勝手にコードを変更されるのを許容する文化が必要であることを説明していました。さらに、API に対してたくさんの利用者がいると、動作に関する取り決めは意味がなく、観測できるあらゆる振る舞いに誰かは依存してくる(With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.)ということを Hyrum's Law と言いたい、と述べていました。たとえばハッシュ辞書というデータ構造の中に格納されたデータは、イテレータを使った取り出しに対して順序を保証しませんが、たまたま社内で最初に使っていた実装では特定の決まった順序(登録順)で出てきていたために、コードの一部はそれを前提にしたものとなっていて、あとでセキュリティ的な理由で順序をランダムにしたとたん、たくさんのコードが壊れてしまったそうです。言い換えるなら、どんな変更を加えても振る舞いが少しでも変われば誰かは影響を受ける、そしてその影響は変更をした人が悪いわけではない、ということでもあります。この話の細かい主張については 詳細が書かれた Web サイト(Hyrum's Law)をご覧ください(この記事を執筆中の現時点では、残念ながら上記のような具体例は掲載されていませんが)。

 なお、全体的な傾向としては、研究対象ソフトウェアのドメインとしてマイクロサービスとモバイルアプリの話題が増加していました。技術的な側面はコードクローンや技術的負債、継続的インテグレーションなど、昨年と大きな変化はないように思いましたが、たとえば Etherium のスマートコントラクトに対するコードクローン検出など、今ある技術を新しいソフトウェアに適用するものが目立ったように思います。

 

ソフトウェア工学国際会議 ICSE 2019 の発表スライド日本語版を公開しました

日本ソフトウェア科学会第36回大会にて、トップカンファレンス特別講演という発表の機会をいただきました。このとき使用したスライドを SlideShare にアップロードしました。

www.slideshare.net

論文の大まかな内容については過去の記事にありますので、そちらをご覧ください。あえて短くまとめると「コメントに書いた URL は、リンク先の内容が変わったり、リンク切れになることが結構あるので、便利だけど気を付けよう」というところです。

会場における質疑応答で、最も考えさせられたのは、URL をコメントに書くのはダメだと言われたとき、どうしたらよいかというご質問でした。URL はリンク切れになるリスクがあるのは間違いなく、しかし設計や実装における何らかの意思決定にかかわる技術資料をすべてリポジトリに詰め込んでおけばよいのかと問われると素直に肯定できません。それではどうするべきか、というドキュメント管理のベストプラクティスは私の知識不足もあって会場では回答することができませんでした。ご存知の方がいたらぜひご教示ください。

 

SES 2019 にてポスター・インタラクティブ賞を受賞しました

前回の記事から時間があいてしまいましたが、前回の投稿 エンジニア研修によるプログラムの質の向上を計測する試み - ソフトウェア工学研究の日々 の最初の成果を、情報処理学会ソフトウェア工学研究会のフラグシップイベントであるソフトウェアエンジニアリングシンポジウムにて「新人研修がソースコード品質に与える影響の調査」と題してポスター発表を行いました。

この研究は、ある企業において1か月半にわたって実施された新人研修の前後で、受講者のプログラムの品質を比較したものです。Scitools Understand という商用のメトリクス計測ソフトウェアを使用してプログラムの複雑度などを計測し、何が違うか、簡単な分析を2ページで報告しました。一言でいうと「研修をすれば、プログラムの書きぶりはちゃんと変わる」というものです。論文はすでに公開されており、情報学広場:情報処理学会電子図書館 に文献情報の詳細を公開しています。著者最終版 PDF の ダウンロードはこちら 。なお、1つの会社における事例の報告であり、今後もまだデータ収集、分析が必要であることにはご注意ください。

共同研究がスタートしてから短い期間でしたが、研究室に4月に入ったばかりの M1 である森田君が、メトリクス計測ソフトウェアと統計分析用の R を勉強しながらデータ分析を行い、2ページとはいえ初めての対外発表論文を筆頭著者として執筆、発表を行いました。

8月30日のポスター発表セッションでは、教育系の研究をされている先生方、プログラミング教育の授業を担当されている先生方を中心に、貴重なご意見をいただくことができました。議論にお付き合いくださった皆様、ありがとうございました。

また、参加者の投票によるポスター・インタラクティブ賞も受賞することができました!これを励みに、今後も研究を進めていきます。

f:id:ishiotakashi:20190903135317j:plain

ポスター賞表彰の様子

(編集履歴:2019/9/3 写真を追加しました)




 

エンジニア研修によるプログラムの質の向上を計測する試み

 これから行っていく新しい研究テーマとして、プログラミングやソフトウェア工学に関する研修(講義・演習)が、どのぐらい受講者のプログラムの質に貢献するか、という課題に取り組むことになりました。

 

www.naist.jp情報系企業の新人研修は、多様な出身の新卒エンジニアの知識の底上げを図っていますが、画一的な研修を行うと、情報以外の分野出身の人には難しすぎ、情報系で頑張ってきた人には簡単すぎるといったように、誰にとっても退屈なものになってしまう恐れがあります。また、研修を行う側にとっても、研修の効果が客観的にはわからないために、教材や教え方を改善することは困難となっています。

そこで、当研究室では、まず研修という活動の効果がどのように計測可能であるかという点から始めて、現在行っている研修がどのような人に・どれぐらいの効果を持つのかを調査する方法を確立し、長期的には、ソフトウェア開発能力の測定方法や個人の現在の能力に合わせた研修の提供などの課題に取り組んでいきたいと考えています。

上記プレスリリースは、ソフトウェア工学研究室としては珍しく「これから行う」テーマの発表です。大学院でソフトウェア工学の研究に携わりたいと考えていて、プログラミング技術・ソフトウェア開発能力を計測するという目標や、データ分析という手段に興味のある方がいらっしゃれば、取り組む研究課題の候補として検討していただければ幸いです。

なお、このような研究発表としては資料が世の中に出ていないような研究テーマについて詳しく知りたい場合は、研究室訪問という形でお越しいただくのが早道です。研究室を訪問可能な日の候補をいくつか「いつでも見学会」のサイトからご連絡ください。この申し込みはちょっと物々しい印象があるかもしれませんが、これが研究室訪問を(必要であれば複数研究室同時に)申し込むためのメール窓口になっています。ソフトウェア工学研究室の訪問を希望すると明記されていれば当研究室スタッフから返信しますので、単に送ったメールが見逃されにくいメールアドレスであるという程度に考えて、気軽にお送りください。

 

開発者が行ったソースコード修正作業を学習し代行するボット

当研究室の D1 上田 裕己 君の「開発者が行ったソースコード修正作業を学習し代行するボット」というプロジェクトが、2019年度未踏IT人材発掘・育成事業に採択されました。

 www.ipa.go.jp

このプロジェクトは、彼自身が当研究室の修士論文等で研究してきた技術を基盤に、1年間で応用的なソフトウェアを世の中にリリースすることを目指しています。

研究内容をよく知っている教員でも実際どのぐらいのものが作れるか予想がつかないところですので、研究面での関連情報を提供しながら、今後の展開を見守りたいと思います。