SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

japan.internet.com翻訳記事

Verifydesignを使って設計の依存関係を監視・強制する

フリーのツールによる好ましくないクラス依存関係の検出

  • このエントリーをはてなブックマークに追加

ダウンロード ソースコード (1.3 MB)

オープンソースの開発ツール「Verifydesign」を使うと、システム設計をXML形式に体系化し、コンパイル時にチェックを実行して、設計仕様に反する依存関係を検出することができます。

  • このエントリーをはてなブックマークに追加

はじめに

 ソフトウェアとアーキテクチャの再利用については、長らく技術関連の出版物でうるさいくらいに提唱されてきましたが、いまだに再利用の原則に反するコードや設計がよく見受けられます。例えば、図1のような内部構造を持つソフトウェアシステムを何度目にしたか分かりません。あるいは、いざコードを再利用しようとしたら、求める機能を備えたコンポーネント(コンポーネントE)は既にあるものの、その動作が別のコンポーネント(作成中のシステムには必要のない機能を持つコンポーネントC)に依存しているため、再利用が不可能だと分かることもあります。仮にコンポーネントCも併せて再利用することに決めたとしても、今度はそれがまた別のコンポーネントAに依存している場合も考えられます。

 このような依存関係は、今でも多くのソフトウェアプロジェクトに当たり前に見られます。もちろん、そういったコードは意図して作られたものではありません。通常、チームはアーキテクチャのレイアウトを決めてからシステムのコーディングに取りかかります。しかしコードの作成を進めるにつれて、悪しき依存関係が知らぬ間に紛れ込んだり、偶発的に生み出されたりします。そして、開発サイクルがずっと先に進むまで、そのような意図しない依存関係にチームが気付かないこともよくあります。

図1 典型的なソフトウェアシステム。多くのソフトウェアでは、この図のような入り組んだ相互関係がコンポーネント間に成立している
図1 典型的なソフトウェアシステム。多くのソフトウェアでは、この図のような入り組んだ相互関係がコンポーネント間に成立している

 新しいオープンソースのツール「Verifydesign」は、コードを監視して、意図しない依存関係を防ぐのに役立ちます。図2に、整理されたソフトウェアコンポーネント間の関係を示します。図2では、APIの存在を黄色いバーで表しています。コンポーネントの通信は、このAPIを通じてのみ行われます。図1では、コンポーネントの関係を示す線をわざとコンポーネントの中心から中心へと引きました。これが現在のほとんどのソフトウェアシステムの実態だからです。図1で強調したのは、多くのソフトウェアシステムがAPIを通じて通信するのを面倒くさがって、図のようにコンポーネントの中心へ直接通信していることです。それに対して図2は、図1のような循環する依存関係が排除された設計を示しています。

図2 理想的なソフトウェアシステム。このアプリケーションでは、コンポーネント間に直線的な関係のパスが成立している
図2 理想的なソフトウェアシステム。このアプリケーションでは、コンポーネント間に直線的な関係のパスが成立している

 VerifyDesignでは、ソフトウェアコンポーネント間の依存関係を定義できます。例えば図2には以下の依存関係があります。

  • コンポーネントAの実装はコンポーネントBのAPIに依存する
  • コンポーネントAの実装はコンポーネントCのAPIに依存する
  • コンポーネントAの実装はコンポーネントDのAPIに依存する

 この記事では、Verifydesignツールを使って依存関係を定義および強制する方法について、具体例を挙げて解説します。

Verifydesignツールをチームで使用するには

 以降では、Verifydesignを利用するシステムの例を紹介します。このシステムは、電話と電話制御クライアントから構成されます。クライアントは電話のAPIに依存します。電話のAPIは何にも依存せず、電話の実装は電話のAPIのみに依存します。以降の説明では、まだこの設計を理解していない新参の開発者がコードを作成するという状況を想定して話を進めます。設計の依存関係ルールに反するコードをわざと作成してみて、Verifydesignが設計の遵守にどのような威力を発揮するのかを実証したいと思います。今回の記事では、この「望ましい設計」のことを、現状で実装されている設計と対比する概念として、「パッケージ設計」と呼ぶことにします。

 この記事のダウンロードサンプルには、次の内容の「verifydesign/packagedesign/bldfiles/design.xml」というファイルが含まれています。

<design>
   <!--The phone's api is defined to depend on nothing -->
   <package name="phoneApi" package="biz.xsoftware.api.phone"/>
   <!--The phone's implementation obviously implements
       and depends on the api -->
   <package name="phoneImpl" package="biz.xsoftware.impl.phone">
     <depends>phoneApi</depends>
   </package>
   <!--The client is defined to depend on the phone's api
       (not the phone's implementation) -->
   <package name="client" package="biz.xsoftware.impl.client">
     <depends>phoneApi</depends>
   </package>
</design>

 まず、この段階でビルドを実行し、ダウンロードしたコードが設計に違反しないことを確認してみましょう。ビルドを実行するには、「verifydesign/packagedesign」ディレクトリに移動し、次のコマンドを実行します。

ant --f bldfiles/build.xml

 「BUILD SUCCESSFUL」というメッセージが表示されるはずです。前掲のXMLファイルには、ソースコードに許される依存関係の基本ルールが含まれています。このファイルでは3つのパッケージを宣言しています。この「パッケージ設計」を図に示したのが図3です。

図3 強制された相互関係。この図は、「design.xml」ファイル内で宣言した相互関係がパッケージ間に強制されることを示している
図3 強制された相互関係。この図は、「design.xml」ファイル内で宣言した相互関係がパッケージ間に強制されることを示している

 図3では、ファイルで宣言された各パッケージをボックスで表し、依存関係を矢印で表します。これが、Javaコードに許される依存関係のすべてです。ここで実現しようとしている環境は、例えばプログラマがコードを変更してクライアントがPhoneImplに依存するようになったときに警告のメッセージが表示されるというものです。それでは、Verifydesignの機能について詳しく説明していくことにしましょう。ここでは、この設計について何も知らない開発者が依存関係のルールを無視しようとしたときにVerifyDesignがどのように役立つかを明らかにします。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
望ましくない依存関係を見つける

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
japan.internet.com翻訳記事連載記事一覧

もっと読む

この記事の著者

japan.internet.com(ジャパンインターネットコム)

japan.internet.com は、1999年9月にオープンした、日本初のネットビジネス専門ニュースサイト。月間2億以上のページビューを誇る米国 Jupitermedia Corporation (Nasdaq: JUPM) のニュースサイト internet.comEarthWeb.com からの最新記事を日本語に翻訳して掲載するとともに、日本独自のネットビジネス関連記事やレポートを配信。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

Dean Hiller(Dean Hiller)

VerifydesignおよびMocklibの作者。アーキテクチャ担当ディレクタとして、Verifydesignなどのツールを駆使してアーキテクチャの変遷を監視し、アジャイルプロセスを厳守するための規律をチームに植え付ける。指揮下のチームでは、製品のコードの75%以上が自動テストによりテストされる。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/1112 2007/03/26 07:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング