ArchitexaはEclipseベースの新しいUMLモデリングツールだ。開発者はUMLダイアグラムによってコードにある関係をすばやく見抜き、見つけたことを他人と共有できるようになる。コードをすばやく調べるための鍵となっているのが、よく知られた3つのダイアグラム(レイヤー図、クラス図、シーケンス図)を開発者に提供して、開発者がコードを調査、理解しながら徐々に関係を作り上げることだ。
InfoQでは最近、このツールについて、そして開発者が肥大化するコードベースに取り組むのをどう支援するのかについて、Architexaの創業者であるVineet Sinha氏に話を聞いた。
開発者に対して、ArchitexaはこれまでのUMLツールに欠けていたところをどう支援するのですか?
私たちは設計ニーズよりもコーディングニーズに注目しています。そのため、開発者が簡単にコードを理解できるようにしたい、理解するのに関連したタスクを支援したいと考えています。こうしたタスクには、理解したことを文書化したり、コードにある重要なコンセプトについて他の開発者たちと議論しやすくするなどが含まれます。
レイヤー図は最初にコードベースを調べる際の強力な手法ですね。読者のためにもう少し詳しく説明してもらえませんか? このアイデアは既存の成果によるものでしょうか、それとも、あなたがそのコンセプトと手法を考えついたのでしょうか?
Architexaのレイヤー図は、現在のコードベースから最も可能性の高いレイヤーアーキテクチャ図を作ろうとします。私たちはレイヤーアーキテクチャ図の多くがプロジェクトの各チームで使われている一番ハイレベルなダイアグラムだということに気付きました。しかし、たいていの場合、数多くのコードベースからこうしたダイアグラムを見つけるのは簡単ではありません。でもこうしたダイアグラムがあれば、開発者は一番関心のあるコードがどこにあるか見つけやすくなります。そこで、こうした開発者のニーズを満たすために、こうしたダイアグラムの簡易版を作ろうと考えたわけです。
Architexaはコードを分析し、あるモジュールが別のモジュールに依存していればダイアグラム上でそれを上位に表示するなどして、レイヤーアーキテクチャ図を構築します。また、推測も必要になります。基本的にデフォルトでは、モジュールはコードベースのフォルダ構造に基づいて作られます。また、多くのコードベースには循環が存在しています。私たちはこうした循環があってもうまく動き、効果的なレイヤー図が提供できるような賢いアルゴリズムを加えました。
ツールのほとんどは実験済みで、私がMIT (CSAIL)(MITコンピュータ科学・人工知能研究所)の博士課程にいるときに作ったものです。そのため、すぐれたツールになるよう努めてきました。その主要なアイデアは複数の情報源からもたらされました。私は次のような項目にかなりの時間を費やしました。(i) 共通のプロパティを見つけるための複数のプロジェクトにおけるソフトウェアドキュメントの調査。(ii) 効果的なコードビューを提供している既存のツールの調査。これらは非常に手が込んでいてトレーニングが必要になるものが多いのですが、たくさんの強みがあって、よくある利用パターンを調べることができました。その結果、私たちはこれらを数クリックでやれるよう簡単化できたのです。 (iii) ユーザのために多くの情報をきれいに折り畳んで表示するのによく使われるツリーウィジェット。(iv) ダイアグラムに取り入れる価値のあるテクニックを見つけるための多種多様なすぐれたツール。
最初のプロトタイプを構築してみると、問題がたくさん見つかりました。主要なアイデアのほとんどはうまく動きましたが、現実世界の問題(コードには循環があることが多い)がわかり、それらを(コードの循環を無視してレイヤー化することで)解決するだけでなく、ユーザが簡単に扱えるようにするためのテクニックを開発しました。(ユーザは循環の依存関係に基づいて、基になっているモジュール、構築に利用するモジュール、現在のモジュールに対して循環のあるモジュールに色を付けて表示することができます。)
Architexaはコードベースについて何も知らない白紙状態から調べることができますね。コードベースを調べるときによく使う利用パターンはありますか? このツールは毎日の開発/設計にどう使えるのでしょうか?
たくさんの利用パターンがわかっており、ツールを改善するために積極的に調べているところです。でも、その大部分はユーザのタスクに依存します。
- もしプロジェクト(もしくは、プロジェクトの一部)を調べることから始めたいのであれば、通常はハイレベルビューが知りたいでしょう。そうした場合には、レイヤーアーキテクチャ図を使って、一番上から始めてダブルクリックしていって、コードの心臓部に飛び込んでいくとよいです。
- もしプロジェクト(もしくは、サブプロジェクト)の中心部を理解したいのであれば、通常は複数のクラスがどのようにやり取りしているのか、また、複数の関係(継承、メソッド呼び出し、フィールドのアクセスなど)がどうなっているのか知りたいでしょう。これにはクラス図を使うとよいです。
- もしインポートのユースケースを理解したいのであれば、コントロールフローについて知りたいでしょう。これにはシーケンス図が役に立ちます。
既存のダイアグラムと変更したコードベースとを比べる方法はありますか?
コード変更時のダイアグラムの利用には、興味深い多くの可能性があります。私たちは2つのユースケースをサポートしています。
- ダイアグラムを作ってからコードベースを変更したとき。ダイアグラムを再オープンすると、失われたクラス/関係に対して赤いエラーマークが表示されます。
- コードベースを変更してからダイアグラムを作りたいとき。プロジェクトのところで右クリックしてメニューを開き、コードをチェックする代わりにその変更を使ってダイアグラムを構築するようArchitexaに指示します。こうするメリットは、簡単にコードレビューができることです。生成されたダイアグラムは修正を入れた機能のサマリになることが多いためです。
私たちはさらにサポートを追加しようと調べているところです。
ダイアグラムの手動生成はコードベースを調べるのによい方法ですが、ビルド時の自動生成(JavaDocと同じように)はシステムの進化を表現できますよね。Architexaはこうしたこともやれるのですか?
重要なダイアグラムは複数のクラスにわたることが多く、また重要なクラスは複数のダイアグラムにわたることが多いです。そのため、それをJavaDocのドキュメントに入れても意味はありません。その代わりに、私たちはユーザがダイアグラムをすばやく私たちのシンプルなWikiライクのサーバにアップロードできるようにしています。Webブラウザでダイアグラムを見られるよう共有するだけでなく、追加情報を入れることもできます。これにより、Architexaクライアントを使っているユーザなら、別の人がやった調査を簡単に引き継ぐことができます。こうしたダイアグラムは、コードベースにある重要なコンセプトを表現しています。したがって、ユーザがコメントを付けるだけでなく、別のところに埋め込んだり、主要なコンセプトの進化がわかるようバージョンを付けることもサポートしています。私たちはさらにサポートを追加しようと調べているところです。
現在のところ、どんな言語をサポートしていますか?
今回のリリースでサポートしているのはJavaだけです。C++についてはプロトタイプの段階です。
このツールはコンポーネントやコアクラスのやりとり(例えば、MVC / Webフレームワークとのやりとり)を図解するのに役立ちますか?
はい。このツールの目標は、コードに明記されている関係(メソッド呼び出し、継承など)、あるいは実行時にできる関係(インターフェイスやベースクラスの呼び出し)を示すことです。私たちは静的関係を使ってこれを実現していますが、ユーザはコードに暗に含めることでダイアグラムを変更することもできます。
最初のリリースには入っていませんが、もうすぐ登場予定の読者にとって興味深い機能はありますか?
今回のリリースにはたくさんの機能があります。今後もリリースしていきますが、今の最大の目標は、私たちがやったことについてユーザがどう思っているか耳を傾けて、一番大きな穴を埋めることです。
詳しくは、ArchitexaのWebサイト(http://www.architexa.com)を見てみよう。