SonarJコミュニティエディション(リンク)は小〜中規模のJavaアプリケーション向けに、アーキテクチャ解析と管理を提供する。SonarJソフトウェアを開発しているhello2morrow(リンク)は先ごろ、SonarJアーキテクチャ解析ツールの無料バージョンをリリースした(リンク)。コミュニティエディションは、最大500の内部クラスを有するJavaアプリケーション（およそ50〜60 KLOC）の解析に利用できる。
アーキテクチャ管理は、明確で循環可能な依存性の構築と、コードのテスト可能性および再使用可能性を改善する上で役立つ。ソフトウェアアーキテクトはアーキテクチャルールと品質ルールの定義にSonarJを使用可能で、その後、ルールは開発者のワークスペース上のIDE（Eclipse）で監視されることになる。SonarJのようなツールは、アーキテクトが開発の初期過程でアーキテクチャ管理を統合するのに役立つ。
InfoQは、コミュニティエディションをリリースすることになったきっかけや、SonarJプロジェクトの今後のロードマップについて、hello2morrowの最高経営責任者（CEO）Alexander von Zitzewitz氏に話を聞いた。
SonarJのコミュニティエディションをリリースすることになったきっかけは何ですか。
私たちが以前使っていた価格決定モデルは、SonarJの利用ユーザー数を基準にしていて、プロジェクトの規模には無関係でした。しかし、SonarJのメリットはプロジェクトの規模と密接に関係しています。SonarJはオープンソースと非営利目的の使用ではすでに無料になっていましたが、多数の開発者が低コストの個人ライセンスが欲しいと言ってきました。また、多数のプロジェクトではJDepend(リンク)やMacker(リンク)といった非常に基本的な依存性検査ツールをいまだに使っていることもわかりました。SonarJなら、ずっと優れたソリューションを提供できますが、そのソリューションを利用できたのは、ツール向けの予算を持っている大型プロジェクトのみでした。そこで、我が社の収益基盤をそれほどひどく侵食せずに、より大規模なユーザーベースでも我が社が提供するソリューションを利用可能にする方法を思案していたのです。
価格決定モデルの2番目のパラメータとして、プロジェクト規模を加えることに決めました。さらに、最大500クラスのプロジェクトまではSonarJを無料にすることにしました。すでに大多数のプロジェクトが無料の範囲に入りますが、規模にして大体50〜60 KLOCに相当します。SonarJのコミュニティエディションが本格的なプロジェクトに確実に使われるようにしたかったのです。そうすればユーザーは、構造上の侵食がもたらす悪影響を回避することにより恩恵を受け、時間とお金を節約できます。
価格決定モデルの方程式を完成するために、最大3000クラスまでのプロジェクトでは、以前のコマーシャルライセンスより少ない金額を支払い、3000クラスを超えるプロジェクトでは、以前のコマーシャルライセンスより多い金額を支払うようにしました。このアプローチの方がずっとバランスがとれていて、SonarJの開発プロセスへの統合から得られる価値にマッチすると思います。
SonarJをStructure 101(リンク)のようなツールと比較するとどうですか。
Structure 101はパワフルなツールで、ユーザーインタフェースは直観的でよくできています。SonarJ同様、アーキテクチャモデルの定義を支援します。他方、SonarJのアーキテクチャ・メタモデルと、アーキテクチャを視覚化する方法は、より大型のプロジェクトに適していると思います。SonarJでは、より大きなプロジェクトをサブプロジェクトに分割する概念をサポートしており、プロジェクトの水平スライシングのみでなく、垂直スライシングもサポートしています。Structure 101でも2つ以上のアーキテクチャモデルを別々に作成すれば、SonarJと似たようなことが達成できますが、手がかかりますし、直観的とは言えません。より大型のプロジェクトでは、縦に切ること（垂直スライシングの作成）がアーキテクチャのアーチファクトを扱いやすい大きさにとどめておく上で、非常に重要なテクニックです。
アスペクト指向プログラミングやコード検査、モデル駆動型アーキテクチャ（MDA）といった他のテクニックと比較した場合、SonarJは設計とアーキテクチャを強制する上でどのように役立ちますか。
第一に、SonarJを使用しても侵襲性はゼロで、新旧を問わず、あらゆるJavaプロジェクトで利用できます。アスペクトの使用は非常に侵襲的ですし（AspectJをビルドプロセスに統合しなければなりません）、アーキテクチャのメタモデルによって実際に支持されているわけではありません。強力な制限を定義することは可能でしょうが、完全性が保証されることは決してありません。恐らく、使用する制限のスタイルはアーキテクトによって違うでしょう。さらに、重大な制限セットを定義する複雑性は、すぐに制御がきかなくなる傾向にあると思います。SonarJを支えるアーキテクチャ・メタモデルにより、コード内のあらゆる依存性が完全にカバーされていることを確実にするのがたやすくなります。SonarJを使うために、コードやビルドプロセスにさわる必要はまったくないのです。
コード検査は、アーキテクチャルールや品質ルールを自動チェックする本格的な選択肢ではありません。時間がかかりすぎますし、重大な構造上の問題を見落としてしまう大きなリスクが伴います。
MDAはアプリケーションを作成するための一戦略です。コードの大部分が生成されたものなら、生成されたコードの構造上の欠陥を解析する利益は、恐らく非常に小さいでしょう。優れたコードジェネレーターなら恐らく、生成されたコードの構造がクリーンであるようにしてあるはずです。ですから、MDAを上手に使っていて、コードベースの大部分が生成されているなら、SonarJはたぶん必要ないでしょう。
SonarJプロジェクトの今後のロードマップについて教えてください。
現在、リリース4.1に取り組んでおり、2009年3月のリリースを予定しています。このリリースでは、使いやすさの改善と、アーキテクチャ・メタモデルの微調整に焦点を当てています。その後、今年中に、IntelliJ(リンク)やNetBeans(リンク)といったその他のIDE向けのプラグインを追加しようと考えています。また、SonarSharkというSonarJのC#バージョンもリリースするかもしれません。
原文はこちらです：http://www.infoq.com/news/2009/02/sonarj-community-edition