■第23回ホットセッション 【目次】----------------------------------------------------------------- 講演1「ソフトウェアの考古学と考現学」東京大学 玉井教授 講演2「コードクローン検出技術あれこれ」産業技術総合研究所 神谷氏 講演3「継続的インテグレーションによる品質向上」日本コンピュウェア 藤原氏 講演4「Design Structure Matrix」テクマトリックス 西田 氏 パネルディスカッション用アンケートの報告 ※パネルディスカッション用アンケートに記入していただいたＱ＆Ａについては 各講演概要の末尾に記載しました。 【講演1】----------------------------------------------------------------- 「ソフトウェアの考古学と考現学」 東京大学 玉井教授 今回のホットセッションの趣旨からすると「考現学」に近いと考え、「プログラム解析技術」にスポットをあてて、プログラム解析の目的、形態、方法について解説された。 はじめに「考現学」的アプローチによるコンピュータ用語が使われ始めた時期について考察をいただき、その後、プログラム解析技術について目的や方法について講演をいただいた。 プログラム解析が求められる場面を再構築と逆構築に想定し、そこで求められる最適化、解析方法、保守性の各局面でどのような技術が必要とされるのか、解析手法としてどのような方法があるのかを解説していただいた後、研究成果として、ソフトウェアの寿命について過去100の事例について調査分析した内容に触れていただいた。その分析結果によると、ソフトウェアの寿命は2年から30年という範囲に収まり、大半は10年程度であるとの報告をいただいた。 最後に、再構築方法論としては、ボトムアップとトップダウンの両方からのアプローチが必要であり、そこでどんな際が生じるのか、非要求を如何に洗い出すのか、そして構造を劣化させない保守が必ずしも最適な結果をもたらすとは限らないというメッセージをいただいた。 【講演2】----------------------------------------------------------------- 「コードクローン検出技術あれこれ」 独立行政法人 産業技術総合研究所 神谷氏 コードクローンとは、ソースコード中に同一あるいは類似したコード断片があるときのことを指す。コードクローンが発生する直接的、間接的な原因についての解説の後、コードクローンは悪であるという立場とコードクローンは問題ではないという２つの立場からの見解について考えを聞かせていただいた。 その後、コードクローンの検出方法として、既に存在するソースコードから検出する方法と開発プロセスの中でコピー＆ペーストなどの発生要因になる作業を追跡する方法に触れ、その技術には、接辞尾木の応用、一定行以上一致する部分に対する検出方法、コメントの数、宣言文の数、実行文の数などからメトリクスで比較する方法、クローン検出と追跡を行う方法などを列挙していただいた。 そして、コードクローン検出技術をソフトウェア考古学に応用する研究も行われており、また、コードクローン検出技術はこれからのシステム開発に活かせるように各方面での研究が進められていることの報告をいただいた。 【Q2-1】 CC FinderXの今後の方向性、具体的に何を目指しているのか。クローンの善し悪しを判定するのはやはり人間の仕事なのでしょうか。 【回答】今後一番重要になってくるのは、他のツールとの連携や、他の分析手法と相互に利用できることだと思っています。たとえば、IDEから透過的に利用できるようにしたり、バグ修正データと付き合わせることで、CCFinderX、ひいてはコードクローン分析の利用範囲が広がることだと思います。クローンの善し悪しを判定するのは、最終的には人間の仕事だと思うのですが、可能な限り、ツールでサポートできるようにすべきだと考えています。具体的なアイディアについていくつか研究中です。 【Q2-2】何から何へコピーしたか。エントロピー等の計測は行うのですか？ 【回答】検出されたコードクローンのそれぞれについて、どっちからどっちへコピー＆ペースとしたか、というような分析はできないのではないか？と考えています。ソフトウェアのエントロピーについてあまり聞いたことがないのでよく分からないのですが、サブシステム間の結合の強さ、と言うことであれば、RADというメトリクスを使って、コードクローンのソースコードのディレクトリ内での広がりを評価しています。以下の論文では、これを使って、JDKのライブラリ中のパッケージ間の（コードクローンを結合と見なしたときの）結合を、ごく簡単にですが、評価したものがあります。 Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue, "CCFinder: A Multi-Linguistic Token-based Code Clone Detection System for Large Scale Source Code," IEEE Trans. Software Engineering, vol. 28, no. 7, pp. 654-670 (2002). 【Q2-3】ツールの費用。使用するフェーズを想定しているのですか？ 【回答】CCFinderXに値札がついているのか？という意味であれば、www.ccfinder.netに利用条件が書いてありますので、そちらをご参照ください。基本的に、自分（自社）のコードを解析する分には無料で利用できるようにしてあります。利用するフェーズとして想定したのは、開発者が自らのコードをリファクタリングする、という場面です。ただし、ユーザーから聞いた例では、管理者がソースコードの品質をチェックする目的で利用されることも多いように聞いています。 【Q2-4】コードクローンは悪と基本的に考えているように聞こえましたが、これを回避するためにどのような方法論がありますか？ 【回答】完全に自動的に回避できるようなツールや方策というものはおそらく無いと考えています。ただし、設計時の共通機能の洗い出しの徹底、実験用に書いたコードやデッドコードの整理、適切なフレームワークやプログラミング言語およびDSL(ドメイン特化言語)の利用、GPLなどのオープンソースから安易にコードを持ってこないようにするなどの指針を作って運用することで、安易にコードクローンが作り込まれることを防げるのではないかと考えています。 【Q2-5】コードクローンの実行時リソース使用量（CPU、メモリ）を表示できるツールはありますか？ 【回答】特にありませんが、プロファイリングツールの出力と、コードクローンの検出結果を付き合わせられるようになれば、ある程度、目的は達成できると考えています。 【Q2-6】コードクローン以外に注目している問題はありますか？ 【回答】リバースエンジニアリング全般。特に、動的な振る舞いの解析や、アーキテクチャリカバリです。それから、コードクローン検出に限らないのですが、利用者のじゃまをしないようにツールを使ってもらうための仕掛け。もっと言えば、人間の能力を拡張できるようなソフトウェアのあり方にも注目しています。 【Q2-7】実際の解析時間はどれくらいですか。コードクローンを防ぐ技術、ツール、研究はありますか？ 【回答】ツールの実行にかかる時間と言うことであれば、講演で使った最新のベータ版を、OpenOffice 2.0.3のソースファイルの2万3千個、計935万行のC/C++ファイルについて実行した例では、手元のPC（AMD Athlon64X2、2.41GHz）で36分ほどでした。中間データを保存しているので、2度目以降の検出（一部のソースファイルを修正して、もう一度検出するなどのケース）ではもう少し速くなります。コードクローンを防ぐ技術というのはなかなかありません（[2-4]の回答もご参照ください）。 【Q2-8】紹介いただいた各種手法/ツールの中で場面で一番使いやすいツールはどれですか？ 【回答】場面ごとに使えるか使えないか、という分類はできます。ただし、使いやすさまで踏み込んで評価したことはありません。講演後に、JTestというツールに重複コードの検出機能があると教えてもらいました。実際に使ってみると、Eclipseのメニューからクローンペアを検出することができました。（ただ、クローンとして検出されている部分の直後に、全く同じ行が続いているのにその部分はクローンとしてマークされない部分があったりするなど、まだ実験段階だとお見受けしました。）検出パラメータの設定もなく、検出アルゴリズムが書いていないため、詳細には評価できていません。また、IDEの内部で完結して使えるというのは便利でした。参考になりました。 【Q2-9】CC FinderXを公開しているサイトはありますか？ 【回答】www.ccfinder.netです。よろしくお願いいたします。 【Q2-10】コードクローンを使ってライセンス侵害の有無を判断するような事例はありますか？ 【回答】BlackDuckおよびPalamidaという会社が、GPLからのコード剽窃を検出するサービスを提供しています。クライアント企業は自社のソースコードをこれらの会社に分析してもらって、GPLコードと同じ部分があれば教えてもらえる、というサービスです。ライセンス侵害とは異なるかもしれませんが、CCFinderが日本の裁判で用いられた例もあります。ある企業（以下Aとする）から別の企業（以下B）に開発者が移籍したとたん、BがAと同じようなソフトを発表し、AがBをソースコードの剽窃のかどで訴えた例です。 【Q2-11】対象とするコードの粒度はどうやって決めるのでしょうか？1行のコードでは、検出率は100%になってしまうと思います。適度な粒度を決める方法等があったらご教示ください。 【回答】ご指摘の通り、1行のコードの一致までクローンと見なすと、非常に多くのコードクローンが検出されてしまうため（また、検出されてもどうしようもなかったりするので）、コードクローン検出ツールはデフォルトの検出パラメータを持っています。CCFinderXの場合は、ソースコードをトークンの列としてみたときに、50トークン以上一致している部分列をコードクローンと見なします。（このパラメータを「最小一致トークン数」と呼んでいます）適度な粒度を決めるための自動的な方法はまだ提案されておらず、現状では経験的に決めるしかありません。CCFinderXの場合は、最小一致トークン数ではデフォルトの50トークンがその目安です。（また、CCFinderから派生した、Javaのソースコードから検出されたクローンに適用可能なリファクタリングパターンを提示するツールICCAでは、ブロック、すなわち、{と}で囲まれた部分を対象としています。）一般的に、目的によって適切なパラメータは異なります。たとえば、クローンになっているコードをまとめるリファクタリングをすることが目的の場合、長くて、変数名や関数名が異なっていないクローンの方がまとめられる確率が高くなります。逆に、ソースコードに含まれるバグを修正する際に、クローンになっているコードすべてを修正する（あるいは修正しないかを決定する）ことが目的の場合、短いコードまで探した方が、見逃す確率が減ります。 【講演3】----------------------------------------------------------------- 「継続的インテグレーションによる品質向上」 日本コンピュウェア株式会社 藤原氏 はじめに、Visual Basic（以下、VB）をVB.NETに移行（マイグレーション）する際に、ツールでVBを移行するか、VB.NETで再構築するかの選択を迫られた際のアプローチについて、マイグレーションの場合にはVBのソースを予めきれいにしておくことや、再構築の際には削除したいソースコードの存在の問題と原因について解説があった。 そして、継続的インテグレーションが再構築にどのような効果をもたらすのか、適用時の問題点、適用ポイントに言及し、静的解析による複雑性の排除や定量的な判断方法によるプログラム品質の向上への貢献について事例を交えて解説をいただいた。 こうした方法は、開発の初期段階から継続的にこうしたチェックを続けることによる、可読性が高く品質の高いプログラムの作成に貢献できるはずであると結論づけられた。 【Q3-1】VC++に関して同様の事例があれば教えてください。 【回答】VC++からC#への移行というケースでしょうか。そういうケースではマイグレーションツールが無いため、新規に作り直す形になるかと思います。”新規に作り直す際に、継続的インテグレーションによってチェックをおこなう”という方法はそのまま適用可能です。C#に移行する場合は（特に２００３の場合）、どうしてもC#では実現出来ない機能が出てしまうケースがあるため、VC++で作成した機能をラッパークラスによってそのまま使用し、C#から呼び出す方法がベストかと思います。 【Q3-2】継続的インテグレーションの導入現場での苦労、トラブルと対処方法を教えてください。 【回答】「継続的インテグレーション」という名前はありますが、突き詰めますとNAnt、NUnit、カバレッジツールを使って、テストファーストを実現するという形になりますので、「テストファースト」という考え方と、各ツール導入への留意点がそのまま苦労となります。 具体的には ・仕様が明確に決まらないので、NUnitのテストケースを早期に確定できない ・ソースコードだけ直して、テストケースを修正しない場合 などがあります。これらのトラブルに対処するには、「テスト仕様、テストケース、ソースコード」を常に対応付ける作業を、NUnit、NAntに詳しいリーダが全体をまとめる必要があります。・テストが不合格だったなら、その日のうちにプログラムを修正する・仕様を変更したら、すぐにテストケースにも反映するなどを、担当者に徹底させる必要があるかと考えます。 【Q3-3】マイグレーションの工数見積もり方法、ツールはありますか？ 【回答】マイグレーション専用の工数見積もりというのは、残念ながらその方法もツールも存じ上げません。VBからVB.NETへの移行であれば、Visual Studioのマイグレーションツールをかけた後に、マイグレーション後の問題点（注意点）がリスト表示されますのでその種類と件数によって、ある程度の目安にされてはいかがでしょうか。新規に作り直す場合は、従来の仕様単位での見積もり方法が使用可能です。 【Q3-4】ブラウザでチェックするフリーサーバがあるというお話ですか？また、NAnt、NUnitの導入のコツを教えてください。 【回答】フリーのサーバはCrueseControlという名前で、.NET版はCC.NETという通称です。http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NETを参照下さい。このサーバは、定期的なチェック結果をサーバに格納し、ブラウザから一覧出来る機能をもっているものです。ツール、特にNUnitを導入する際のコツは、やはりクラス設計かと思います。ビジネスロジック部分を、きちんとクラス（DLL）に独立させておくことでNUnitからのテストケースを実装することが出来ます。 【Q3-5】VB以外への適用は可能でしょうか？C言語への応用は可能ですか？ 【回答】大筋は【3-1】と同じです。VB以外の言語の場合はマイグレーションツールが無いため新規にオブジェクト指向言語で作り直すケースが殆どかと思われます。その場合は、パネルディスカッションでも話が出ましたが「ユースケースシナリオ」（UMLではなく自然言語で記述するシナリオです）を用いて、元の言語での仕様を明確にします。※）ユースケースシナリオについては、書籍「ユースケース実践ガイドアリスター・コーバーン著」などを参照下さい。そして、新規に作成するシステムが、元の言語で作成した「ユースケースシナリオ」と同じように動作することを確認することで、品質を管理するのが最も良い方法かと考えます。 【講演4】----------------------------------------------------------------- 「Design Structure Matrix」 テクマトリックス株式会社 西田 氏 アーキテクチャの可視化手法である Design Structure Matrix （DSM）の概要を解説いただいた。DSM は当初生産における複雑性を可視化する目的で開発されたが、現在ではソフトウェアのアーキテクチャに適応することが可能であるとのこと。ソフトウェアではマトリクスからモジュールやタスクの間の依存関係を視覚的に分析する。いくつかのサンプルを使って DSM による複雑性の可視化を行った際の表示パターンによる傾向の違いに触れられながら、その有効性を紹介いただいた。 DSMは決して新しい技術ではなく理論は存在していたが、DSMを取り入れたツールにより現実的なものとなってきたことにも触れられていた。 【Q4-1】講演の中にあったツール紹介の情報はどこかにありますか？ 【回答】下記URLを参照して下さい。 http://www.techmatrix.co.jp/products/quality/lattix 【Q4-2】VBの未使用コードを検出するツールはありますか？ 【回答】私の知る限り有効なツールは見当たりませんでした。 【Q4-3】マトリックス上の数値の意味を教えて下さい。 また、ツールを使用するフェーズはどこですか？ 【回答】下記の文献から計算式を引用しています。 AGILE SOFTWARE DEVELOPMENT Robert C. Martin 上記の文献で Section 4 です。 【Q4-4】ソフトウェア品質上、重要と思われるメトリックスのプライオリティについて、（つまり重視すべき数値）について教えて下さい。 【回答】私ですが、Metricsは、統計的（数学的）にソフトウェアの品質と「明解に」論じられた文献は無いように思います。従って、重視の意味も完全に個人的な「好み」もしくは「経験値」ですが、1関数あたりの行数と考えています。 ＜ 1/2ページ 2/2ページ ＞ |