…Klocwork Insightはバージョン1.6までのJava全バージョンをサポートし、さらに、Google Web ToolkitやAWT、Hibernate、JavaMail、J2EE、J2MEなど、人気の高い様々なJavaフレームワークに強力なサポートを提供します。InsightはEclipseやIBM Rational Application Developer、Intellij IDEA、JBuilder 2007 IDEも、ANT & Mavenのビルド環境もサポートします。
Klocworkは過去に、アメリカ国土安全保障省の先の調査で発見されなかったオープンソースプロジェクトの欠陥を多数見つけたと発表し(リンク)、話題となった。
InfoQは最近、Klocwork社の最高技術責任者Gwyn Fisher氏とKlocwork Insightについて話をした。最初のトピックは、焦点を当てる解析項目をKlocworkがどのように決定するかであった。
我が社の研究の圧倒的大部分は、顧客のコードで発見した実際のエラーに基づいて行われます。欠陥検出分野で自動ソリューションを開発することが実際に何を意味するかというと、欠陥でないコードを間違って指摘すること（偽陽性）と、実際は欠陥であるコードの指摘に失敗すること（偽陰性）の間で、継続的に妥協点を見つけるということです。我が社の製品を使用する顧客の実経験から、時間や労力を投入するバランスと方向性の両方の情報を入手します。ある時点で偽陽性と偽陰性のどちらに重点を置くかは、使用法レポートで見つかるパターン次第で決まります（レポートは、最細部にいたるまで、様々な3D視覚化技術を使って定期的に精査します）。Fisher氏は続けて、いかなる1タイプの分析モジュールも、開発者にとって最も難しいと決めることは困難である、とつけ加えた。しかし、問題となっているコードベースの最も一般的なセマンティクスという条件の下、オーバーフロー／アンダーフローが発生するシナリオの数と、正確に機能するコードと真のオーバーフローを見分けることに関連した微妙な点を単純に考慮すると、関心を引くタイプの１つとして挙げられるのがバッファオーバーフローである。コンフィギュレーションデータに格納された値や、入力装置から読み込んだ値は決して所定の範囲を外れないことを開発者は「分かっている」ので、そのデータによってもたらされた理論的なオーバーフローが事実上の欠陥だとしても、対処するには問題含みである、とFisher氏はまとめた。
InfoQは次に、Klocwork InsightのConnected Desktop Analysis機能が平均的な開発者にもたらす利点について訊ねた。
[Fisher] 特に重要なことですが、機能しないコードをチェックインしないでください！ それほど単純なのです。Connected Desktopを使えば、開発者はチェックイン前にローカルにコード解析でき、その正確さやコンテキストは統合ビルドの解析時と全く同じです。はっきり分かるように例を使って見てみましょう。便宜上、Jimという開発者が典型的な消費者モードで作業している（すなわちJimの仕事は事務所内の別の開発者が行う仕事に依存している）、と考えてください。Jimのコードの正当性を分析するとき、Jimが書いたコードが正しいとJimに告げることと、Jimが消費しているコードがどのように機能しているかを理解すること、したがってその消費コードに対するJimの相互作用の仕方が正しいと確認することは別物です。
分散システムのコンテキストが無いと、解析エンジンはメソッドfoo ()に渡されているnull object参照が問題を起こすかどうかを判別できません。そのコンテキストが無いと、解析エンジンはメソッドfoo ()が有用なオブジェクト参照を返すか分かりません。しかし、そのコンテキストがあると、そうしたグレーエリアのすべてが、事実解析に置き換えられるのです。あなたにはfoo ()で起こっていることを理解するローカルのコードがないとしても、解析エンジンはfoo ()で起こっていることを正確に把握していますし、あなたが何か間抜けなことをしていないかどうか、統合ビルド解析とまったく同様に、解析エンジンに知らせてもらうことができるのです。
統合ビルド解析と変わらない解析の正確性は、いくつかの効果をもたらしますが、その最たるものが生産性です。しかし、コード解析を実施している企業が直面する文化の壁を考慮するなら、説得力はさらに強力です。企業は一般に、統合ビルド内に一体化する監査ツールとしてコード解析を実施し、インタラクション・ポイントとしてレポートに焦点を当てるでしょう。これには、次に挙げる2つのうちの１つが必要になります。まず、ワークフローの強制ですが、開発者に対し、通常の環境を抜けて、自分が犯した間違いを知ることだけを目的に報告アプリケーションにアクセスすることを要求します。もう1つは、上司から「君は失敗しましたよ」という通知が届くような電子メール駆動のワークフローです。
しかし、正確で高速、そして効果的な解析を開発者の管理下に置くことにより、そうした「責任の転嫁サイクル」をコード解析から取り除き、その代わりに、高品質かつ高セキュリティのコードを作成している開発者に最初から焦点を合わせます。
ここでInfoQは、Klocworkと人気の高いオープンソースツールのFindBugsをFisher氏に比較してもらった。:
FindBugsはすばらしいツールであり、優れた仕事をして、FindBugsを無料開放しているBill Pugh氏をとても尊敬しています。たいていの人々がまず遭遇するJava向けの優れたコード解析といえば、Pugh氏の製品になるでしょうし、それはマーケット全体にとっていいことです。KlocworkがFindBugsと違うところは、行う解析の深さや、発見可能な欠陥の数とタイプです。特に、FindBugsではプロシージャ内欠陥と呼ばれるもの、すなわち特定メソッド内のコントロールとデータフローに注目することにより解析可能な欠陥に焦点を合わせています（開発者がコードに注釈をつけて予想される動作を詳述すれば、実際は拡大できるのですが、それはどちらかというとごまかしになりますね ;p）。Klocworkの解析はプロシージャ間で行われますが、これはつまり、クラスやパッケージ、モジュールの境界をまたぐメソッド呼び出しにおよぶ欠陥を発見できることを意味します。こうした「全プログラム」タイプの解析こそが、商用の静的解析です。
最後にInfoQは、C++の解析ツール作成におけるKlocworkの経験と、より最近のJava解析ツールの作成とを比較するようFisher氏にお願いした。氏の説明によると、Klocworkの見解では、優れたコード解析の基本は同社のコンパイラである。Javaでは、まずデバッグモード・バイトコードのオプティミスティックな解析を試み、その結果コンパイラ記述の必要性という条件を取り除いた。しかし、そのテクニックは十分効果的ではなかった。コンパイラを越えると、Java移行において時間的・労力的に傾注する上で最も重要な点は、チェッカーライブラリと、既存製品と同等の完全性を有するエンジンを確実に市場に届けることであった。Klocworkでは現在、サポートする各言語あたりのチェッカー数がほぼ同じ（1言語につきおよそ175のチェッカー）になっている。
原文はこちらです：