AOP@Work: Contract4Jを使用したコンポーネント設計

Design by ContractとAspectJを使用してソフトウェアを改善する

Design by Contractは、コンポーネント設計の詳細の明確化、クライアントに適した使用法のドキュメント化、およびプログラムによる使用法準拠のテストに定評のある技法です。AOP@Workシリーズの最後となるこの記事でDean Wamplerは、Design by ContractツールのContract4Jを紹介します。Contract4Jでは、Java™ 5アノテーションを使ってコントラクトを指定し、AspectJのアスペクトを使って実行時にコントラクトを評価します。Contract4JはAOPツールキットに加わる強力なツールであるだけでなく、アスペクト指向設計における先進のトレンドを示してもいます。

Dean Wampler, PhD (dean@aspectprogramming.com), Principal, Aspect Research Associates, Inc.

Dean Wamplerは、Contract4Jオープン・ソース・プロジェクトの設立者であり、自社のAspect Research Associatesを通じてAspectJ、Enterprise Java、およびRuby on Railsのコンサルティングを行っています。



2006年 4月 11日

銀行用アプリケーションを作成するプロジェクトに参加したとします。コードをざっと見ると、BankAccountの以下のような(単純化された)インターフェースが見つかりました。

interface BankAccount {

  float getBalance(); 

  float deposit(float amount);

  float withdraw(float amount);
  ...
}

上の簡単なインターフェースでは、多くの疑問が答えられていません。deposit()またはwithdraw()のamount引数は、負の数や0にできるのでしょうか? 負の残高(超過引出し)は可能なのでしょうか? amountに無効な値が指定された場合、deposit()またはwithdrawal()はどうなるのでしょうか?

当然、インターフェースの実装者およびインターフェースを公開するコンポーネントのクライアントにとって、これらの疑問に答えることは重要です。動作を暗黙的に指定する1つの方法は、JUnit(「参考文献」を参照)で書かれた単体テストを使用することです。JUnitテストでは、有効または無効なさまざまの引数を使ってメソッドを呼び出し、予想する動作が起こることを確認できます。もう1つの方法は、コンポーネント設計の詳細の明確化に定評のあるDesign by Contractを使用する方法です。

AOP@Workシリーズの最後となるこの記事では、Design by Contractをサポートする、AspectJベースのツールContract4Jを紹介します。Contract4Jを使用してコンポーネントの動作を暗黙的に指定し、クライアントに適したコンポーネントの使用法をドキュメント化し、使用法への準拠をプログラムでテストする方法を示します。記事の最後では、アスペクト指向設計の先進トレンドにおけるContract4Jの位置付けを説明します。

このシリーズについて

AOP@Workシリーズは、アスペクト指向プログラミングに多少の経験があり、知識を広めたり深めようと望んでいる開発者を対象としています。developerWorksのほとんどの記事と同じように、このシリーズは実用性が高くなっています。各記事では、すぐに使える新しい知識を得ることができます。

シリーズの各著者は、アスペクト指向プログラミングにおける指導性や専門知識に従って選ばれています。著者の多くはシリーズで取り上げているプロジェクトやツールに実際に関わっています。記事内の見解が公平かつ正確であることを確認するため、各記事は他の専門家によってレビューされています。

各記事に関するコメントや質問については、それぞれの著者に連絡してください。シリーズ全体に関してコメントする場合は、シリーズ全体のまとめ役であるNicholasLesieckiに連絡してください。AOPの詳細については、「参考文献」を参照してください。

Design by Contractの概要

Design by Contractではプログラム式を使用し、コンポーネントへの入力および返される結果に対する要件を指定できます。式は開発者とQAによるテストの実行時に評価されます。テストが失敗した場合、プログラムの実行はすぐに終了します。終了時には、バグをすぐに修正するために役立つ診断情報が発行されます。

すぐに強制終了することは煩わしく思われるかもしれません。エラー・メッセージを出すだけにして、どうして処理を続行しないのでしょうか。処理を続行する方が生産的であるように思えますが、実際にはそうではありません。第1に、強制的にバグに対処するようにしないと、修正は先延ばしになりがちで、バグはたまっていく傾向があります。第2に、テストが失敗したということは、何か予想外のことが起き(参照がNULLなど)、通常の実行は続行できないことを意味します。「偶発時処理」コードを指定することもできますが、その場合、起こるはずのない条件のために実装が複雑になり、コードはさらに複雑になりバグが増える危険性があります。

コンポーネントの動作を指定する

Design by Contractはコード内の論理バグを見つけて修正するためのツールです。パフォーマンス、ユーザー入力の誤りなど、他の問題は扱いません。Design by Contractでは、以下の3種類のテストを使用してコンポーネントの動作を指定し確認します。

  • コンポーネント入力(メソッドに渡されるパラメーターなど)のテストは事前条件テストと呼ばれます。コンポーネントが要求された処理を実行するには真である必要がある条件を指定します。クライアントがコンポーネントを使用するには、この要件を満たす必要があります。
  • 事後条件テストは、事前条件が満たされた場合、コンポーネントが処理を完了したときに満たすことになっている保証事項です。事後条件はメソッドの戻り値に関するアサーションと表現されることもあります。
  • 最後に、不変条件テストは変化しない条件を表明します。クラス不変条件は、(オブジェクトの構成後)すべてのメソッド呼び出しの前後に保たれる必要があります。メソッド不変条件はメソッド実行の前後に保たれる必要があります。フィールド不変条件はオブジェクトの存続中、フィールドに対して真である必要があります。

実稼働配置では、オーバーヘッドをなくすため、Design by Contractテストをオフにできることに注意してください。

単体テストとDesign by Contract

Design by Contractには単体テストより優れた点がありますが、2つの方法は互いに補足し合います。Design by Contractの主な利点の1つは、予想される動作に関してインターフェースまたはクラス自体の中に明示的な情報を提供することです。そのため、コンポーネント開発者とクライアントにとって重要なドキュメントがプログラムでテスト可能な形式で用意されます。また、単体テストでは暗黙的なコントラクト定義もDesign by Contractでは明示的になります。筆者はよく2つの技法を連携させて使用します。EJB2 Beansなど、単体テストが難しい技術を使う場合などは特にそうです。後で説明するように、Contract4Jには使用法制限の強制機能があります。JUnitテストの暗黙的な簡易ドキュメントに比べ、この機能は大変優れています。


Contract4Jの概要

Contract4Jは、Java 5アノテーション(「参考文献」を参照)を使用してDesign by Contractを実装するオープン・ソースの開発者ツールです。内部的には、アスペクトを使い、テストを評価する個所となるプログラムのジョイン・ポイント(たとえば、メソッド呼び出し)に「アドバイス」を挿入します。テストが失敗すると、プログラムの実行を終了します。

もう一度BankAccountインターフェースを検討します。今回はContract4Jアノテーションが付いています。元のコードは太字で強調し、一部の文字列はわかりやすくするため列に合わせて改行しています。

リスト1. Contract4Jアノテーション付きのBankAccount
@Contract
@Invar("$this.balance > = 0.0")
interface BankAccount {

  @Post("$return >= 0.0")
  float getBalance(); 

  @Pre("amount >= 0.0")
  @Post("$this.balance == $old($this.balance)+amount 
         && $return == $this.balance")
  float deposit(float amount);

  @Pre("amount >= 0.0 &&
        $this.balance -- amount >= 0.0")
  @Post("$this.balance == $old($this.balance)-amount 
         && $return == $this.balance")
  float withdraw(float amount);
  ...
}

表1に、リスト1で示したキーワードの定義を示します。

表1. Contract4Jキーワードのサンプル
キーワード定義
$thisテスト対象のオブジェクト。
$target現在は、フィールド不変条件テストでフィールドにのみ使用されます(フィールドは$this.field_nameを使用して参照することもできます)。将来、$targetは他のコンテキストで使用される可能性があります。
$returnメソッドが返すオブジェクト(つまりプリミティブ値)。事後テストでのみ有効です。
$args[n]メソッドに渡されるn番目のパラメーター。0から数えます。パラメーターは名前で参照することもできます。
$old括弧内の内容の「古い」値(ジョイン・ポイントが実際に実行される前の値)。不変条件テストおよび事後条件テストの場合のみ有効です。Java言語ではすべてのクラスで「クローン作成」をサポートする必要がないため、Contract4Jでは特定のオブジェクトのクローンを作成できるかどうかわかりません。したがって、$old(...)内の式にはプリミティブ値か変化しないオブジェクトのみ指定してください。さもないと、ジョイン・ポイントの実行時に「古い」値が変化し、予想しない結果が生じることがあります。例には、$old("$this.userName")と$old("$this.calcMin(x,y)")の式があります。Contract4Jのドキュメントには、使用可能な式が詳しく説明されています。

BankAccountのコントラクト

前のセクションで学んだことを参考にすれば、リスト1のアノテーションは理解しやすいでしょう。@Contractアノテーションは、インターフェース(つまりクラス)にコントラクト指定があることを示します。@Pre、@Post、@Invarの各アノテーションは、それぞれ事前条件、事後条件、および不変条件のテストを定義しています。また、リスト1のテストは、文字列として定義され、真または偽に評価されるJavaの式です。

テスト式を省略すると、Contract4Jはコンテキストに合わせて妥当なデフォルト値を使用します。たとえば、フィールドに対するデフォルトの不変条件では、フィールドが非NULLであることを要求します。同様に、メソッドのデフォルトの事前条件では、プリミティブではないすべての入力引数が非NULLであることを要求します。メソッドのデフォルトの事後条件では、戻り値が非NULLであることを要求します。

BankAccountのコントラクト指定には、残高は常に0以上にするというクラス全体の不変条件が含まれています(残念ながら、超過引出しは禁止です)。getBalance()メソッドには、常に0以上の値を返す必要があるという事後条件があります。不変条件などのテストでは、インターフェースでフィールドを定義できないにもかかわらず、暗黙に示された残高フィールドを参照していることに注意してください。ただし、インターフェースでは対応するJavaBeanアクセサー・メソッドを定義するため、Contract4Jはフィールドの存在を推測します。getBalance()の事後条件テストはクラス不変条件とだぶっているように思われるかもしれませんが、このメソッドは実際に残高を返すという前提を部分的にテストしています。

また、コントラクトには、クライアントが0以上のamountをwithdraw()とdeposit()に渡すことを要求する事前条件があり、withdraw()には、amountがすでにある残高を超えることをできないという事前条件要件があります。最後に、withdraw()とdeposit()には似た事後条件があります。つまり、withdraw()の事後条件では返される値が新しい残高に等しいことを要求し、deposit()の事後条件では新しい残高が古い(元の)残高に入力金額を増減した値に等しいことを要求します。

一般的な注意

Contract4Jディストリビューション(「参考文献」を参照)のREADMEでは、既知の制限と特徴を含め、構文を詳しく説明しています。ディストリビューション内のContract4J自体の単体テストには、有効および無効なテスト式の例が豊富に含まれています。

また、クラスまたはアスペクトに対するコントラクト・テストを作成できます。コンストラクターに対するテストおよびインスタンス・フィールドに対する不変条件を定義できます(上記のクラス不変条件は実質的にはフィールド不変条件の指定でした)。メソッドとコンストラクターにも不変条件テストを指定できます。

コントラクトはコンポーネント・ユーザーとサブクラスに見られる離散的実行点に影響を与えるため、Contract4Jではpublicメソッド、protectedメソッド、およびパッケージから可視のメソッドを「アトミック」として扱います。つまり、メソッドの完了時に条件が満たされる限り、メソッドの実行中にテストは一時的に違反することができます。テストが設定されている他のメソッドまたはフィールドをネスト呼び出しした場合、そのテストが開始されます。ただし、アスペクト・コードなどで無限反復を避ける特殊な場合を除きます。また、Contract4Jでは、現在privateメソッドに対するテストを定義できません。これは外部クライアントから不可視であるためです。また、静的メソッドはオブジェクトの状態に影響を与えることはできないため、静的メソッドに対するテストもサポートされていません。ただし、これら2つの「理論的」制限は将来のリリースではなくなる可能性があります。

最後に、フィールド不変条件テストは、遅延評価を可能にするため、フィールドの読み書き後にのみ評価されます。同様に、フィールド不変条件テストはオブジェクトの構築中は評価されず、構築完了後に評価されます。

Contract4J以外の方法

Design by Contractテストを作成する場合、実際にはContract4Jは必要ありません。単に各自でアスペクトを書くことができます(「参考文献」で、このシリーズの以前の記事を参照してください)。Contract4Jの利点は、AspectJの使用経験のない開発者が使うことができることです。後で説明するように、簡単なビルド・プロセスの変更しか必要ありません。また、Contract4Jには、おなじみのJava構成体を使用した、非常に簡潔なテストの定義方法が用意されており、AspectJの「定形文面」を大量に定義する必要がありません。コントラクトは実行可能であるだけでなく、ユーザーがアクセス可能なコードとドキュメントの一部でもあります。この情報は、別々のアスペクトでとらえられるとわかりにくくなるでしょう。

前に指摘したように、実際のところ、単体テストとDesign by Contractは同じ目的に異なる方法で達成します。Contract4JのようなDesign by Contractツールは、単体テストが少ないか難しい状況で最も役に立ちます。統合とバーンインのテストは、下位レベルのテストでは見逃されがちな目立たない統合の問題をとらえる絶好の機会です。単体テストと共にContract4Jを使用するかどうかに関係なく、コンポーネントのコントラクトについて考えると、設計の質は向上します。


Contract4Jの実体

Contract4Jでは、実行時に組み込みアスペクトを使用し、テストを実行するジョイン・ポイントをアドバイスします。このアスペクトのポイントカットは該当するアノテーションを探します。事前条件テストはbeforeアドバイスによって処理されます。beforeアドバイスは対応するメソッド実行ジョイン・ポイントの直前に実行されます。beforeアドバイスではApache Jakarta Commons JEXLインタープリターを使用し、テスト文字列の特殊キーワードを該当するオブジェクトに変換し、作成された式を評価し、真(パス)または偽(失敗)を返します。テストが失敗した場合、失敗の個所を示すエラー・メッセージが報告され、プログラムの実行が停止します。

たとえば、リスト1でwithdraw()が呼び出されると、メソッド実行の直前にamountの入力値を使ってamount >= 0式が評価されます。たとえば、amount = -1.0である場合、テストは失敗し、失敗の個所とスタック・トレースを示すエラーが報告され、アプリケーションは終了します。

同様に、事後条件テストはだいたいafterアドバイスに対応します。ただし、$oldキーワードをサポートするため、実際にはaroundアドバイスが使用されます。aroundアドバイスでは、$oldキーワードの「副次式」が評価され、結果が保存され、元のジョイン・ポイントが実行された後で、適切に挿入された「古い」値を使用してテスト式全体が評価されます。

最後に、不変条件テストではaroundアドバイスを使用します。テストはジョイン・ポイント実行の前と後に評価されます。前に示した例外を伴います。

JEXLのようなインタープリター呼び出しのオーバーヘッドは小さくありませんが、Contract4Jでは開発とテスト中にのみ使用するよう設計されているため、ほとんどの場合、オーバーヘッドはあまり問題とはなりません。ただし、実行頻度の高いコード・ブロックはテストしない方がいいことがあります。


Contract4Jを採用する

Contract4Jのコントラクト・テストはおなじみのJavaの規則を使用して作成されるため、Java環境には簡単に採用できます。以下の4つの手順で行います。

  1. Contract4Jをダウンロードし、任意の場所にunzipまたはuntarします。ビルドし直す(その場合、付属のREADMEの指示に従います)のではない限り、必要なファイルはcontract4j5.jarだけです。
  2. contract4j5.jarファイルの場所をビルドのCLASSPATHに追加します。
  3. AspectJをダウンロードし、インストールします。
  4. 現在のJavaコンパイラーをAspectJの「ajc」コンパイラーに切り替えます。ajcコンパイラーはJavaコードもコンパイルします。詳細は、AspectJホーム・ページとディストリビューションに付属のAntスクリプトに記載されています。また、Javaコンパイラーの使用を続けたい場合は、以下の2つの選択肢があります。
    • ビルドの最後にajcを「ウィーブする」(織り込む)手順を導入します。この手順では、アスペクトをcontract4j5.jarからコンパイル済みクラスまたはJARにウィーブします。
    • AspectJドキュメントで説明されているように、ロード時にコントラクトを「ウィーブ」します。
  5. ソース・コードにContract4Jアノテーションを追加し、コントラクトの定義を開始します。

Contract4Jをカスタマイズする

実行時にプロパティー・ファイルまたはAPI呼び出しを使用すると、すべてのテスト、事前条件テストのみ、事後条件テストのみ、または不変条件テストのみを有効または無効にできます。通常、実稼働配置の場合、実行時のオーバーヘッドをなくすため、contract4j5.jarを使用せずにビルドします。

API呼び出しを使用すると、異なる動作を実装する独自のJavaクラスを挿入する「プラグイン・フック」を含め、広範囲のカスタマイズができます。JEXL式インタープリターを換えることもできます。

Contract4Jホーム・ページ(「参考文献」を参照)には、APIと他のカスタマイズ・オプションのほか、使用可能なテスト式、既知の制限、特徴に関する広範囲のドキュメントが用意されています。また、ディストリビューションの「ant docs」ターゲットをビルドし、完全なJavadocを生成することもできます。


Contract4JとAOP

Contract4Jは開発者にとって便利なツールであるだけでなく、他の2つの理由でも興味深いところがあります。第1に、Contract4Jは、開発者には事実上透過的で、暗黙的にアスペクトを使用するJava開発ツールの1つです。このようなツールは増えつつあります。もう1つの例は、このシリーズで以前説明したGlassbox Inspectorです。さらに、Springフレームワークではミドルウェア・サービスをサポートするためPure JavaとAspectJのアスペクトを幅広く使い、JBossでは同じ目的でPure Javaのアスペクトを使用します。これら3つの詳細については、「参考文献」を参照してください。

第2に、Contract4Jではアスペクト設計に簡単なインターフェースベースの方法を使用します。アスペクト指向のコミュニティーでは多くの開発者がインターフェースベース設計の考え方をオブジェクトの世界から先進のアスペクト/オブジェクトの世界に拡張する作業にとりかかっているため、このトピックはさらに説明する必要があります。

アスペクト・インターフェースを定義する

多くの場合、アノテーションはコードに関するメタ情報を示すために使用します。この場合、Contract4Jはアノテーションを使い、コントラクトで指定されたコンポーネントの制限をキャプチャーします。制限はインターフェースの付属的な部分ではなく、重要な部分を形成します。実際、コントラクトは、コンポーネントの主要な問題領域に「直交する」問題領域の一部であるというAOPの通常の意味で「横断的」ではありません。BankAccountの例では、口座残高に使用可能な値は口座オブジェクトの「状態」の一部であり、口座オブジェクトに「直交」するのではなくその一部を形成します。

したがって、厳密にいえば、Design by ContractはAOPの方法に適していないように思われるかもしれません。ただし、コントラクト自体がBankAccountの領域の一部であるのに対し、その情報の使用方法は横断的です。Contract4Jではコントラクトをプログラムで実施しようとしており、Contract4Jアノテーションはこの目標を達成するために設計されました。ただし、アノテーションにより公開されるコントラクト情報は、単体テストを自動的に生成するツール、またはコンポーネントの使用方法が間違っている場合にユーザーに警告するIDEでも簡単に使用できます。

Contract4Jではアノテーションを使用し、コントラクト情報を表す一種のインターフェースである、パターンに似たプロトコルを定義します。この意味で、アノテーション形式のコントラクト指定が「観測可能」であり、ツールによって処理できるObserverパターンに似ています。メソッドの事後条件の例の場合、プロトコルは構造化された英語で次のように表されます。

if @Contract is on a class and 
  @Post is on a method, then
  get the @Post expression string and
  evaluate it, aborting if false.

Contract4JのアスペクトはAspectJでこのロジックを実装します。アスペクトには、クラス名、メソッド名など、テスト対象のクラスに関する明示的な情報は必要ありません。必要なものはアノテーションだけです。したがって、Contract4Jのアスペクトは汎用的で再使用が可能です。これに比べ、通常のAspectJアスペクトの多くは特定のパッケージとクラスへの明示的な参照を使用して書かれているため、再使用と進化は困難です。

メタ情報の伝達にアノテーションを使う同じような例としては、POJOでパーシスタンス要件を表すため、HibernateとEJB3で使用するように定義されたアノテーションの集合があります(「参考文献」を参照)。

アスペクト・インターフェースの難題

もちろん、アノテーションベースのメタ情報はアスペクト設計方法にしか有効ではありません。オブジェクト設計の場合と同じように、再使用可能で疎結合のアスペクトベースのシステムと再使用可能な汎用アスペクト・ライブラリーを作成するには、インターフェースに基づく包括的方法が必要と考えられます。インターフェースでは、あまり詳細情報を公開せずに、コンポーネントの結合に適した抽象体を定義します。したがって通常、ソフトウェアが進化しても、基になるコンポーネントよりインターフェースの方が変化は小さくなります。

アスペクトには独自の難題があります。アスペクトはその性質上、通常はシステムの残りの部分全体に接触しますが、オブジェクト・コンポーネントは限定された部分にしか接触しません。また、アスペクトは新しい方法で細かくオブジェクトの状態と動作を変更できるため、システムの整合性や堅牢性、さらに理解が損なわれる危険性があります。

この問題に対処するには、アスペクト/オブジェクト・システムのインターフェースに、これまでのようにメソッドと状態の情報だけでなく、アスペクトが他のコンポーネントにできる変更を制限するコントラクト情報も含めた方がいいことがわかってきました。たとえば、アスペクトではコンポーネントの状態を変更できないようにしたり、パフォーマンスやセキュリティのために一定の「重要領域」のアドバイスは制限したりします。

したがって、特定の命名規則のように、アスペクト・ポイントカットをコンポーネントの詳細に直接結合するのではなく、アスペクトはコンポーネントにより実装されたインターフェースに結合します。コンポーネントはインターフェースを使用し、アスペクトに関係する使用可能なジョイン・ポイントと状態情報を公開します。アスペクトは公開されたインターフェースを通してのみコンポーネントにアドバイスします。インターフェースは実装を行うコンポーネントより安定していることが多いため、結合はシステムの進化に対して安定的で変更の影響を受けにくくなります。オブジェクト・システムの場合と同じように、インターフェースベースのプログラミングを使用すると、設計者は堅牢で安定した、再使用可能なアスペクト/オブジェクト・システムを簡単に構築できます。


結論

Contract4Jでは、Java 5アノテーションを使用し、直感的な方法でDesign by Contractテストを効率的で簡単に定義できます。テストはテスト中に自動的に評価されます。テストはコードの論理バグの検出に役立ちます。Contract4Jを使用すればAspectJの使用に熟知していなくても、AspectJの力を十分に引き出すことができます。

参考文献

学ぶために

  • 『The Challenges of Writing Portable and Reusable Aspects in AspectJ: Lessons from Contract4J』(Dean Wampler著、AOSD 2006、ACM): 著者は真に再使用可能で汎用のアスペクトを作成する練習としてContract4Jを説明しています。入手したい場合は、Dean Wamplerにご連絡ください。
  • Modular Software Design with Crosscutting Interfaces』(William G. Griswold、Macneil Shonle、Kevin Sullivan、Yuanyuan Song、Nishit Tewari、Yuanfang Cai、Hridesh Rajan著、IEEE Software、2006年1、2月): アスペクト・インターフェースに関する将来有望な研究についての最新の優れた概要。
  • AOPを使いコントラクトを実施する」(Filippo Diotalev著、developerWorks、2004年7月): Design by Contractアスペクトの手入力によるコーディング入門。
  • AOP@Work: Unit test your aspects」(Nicholas Lesiecki著、developerWorks、2005年11月): AspectJのクロスカット動作テスト用パターンのカタログ。
  • AOP@Work: Performance monitoring with AspectJ, Part 1」(Ron Bodkin著、developerWorks、2005年9月): Glassbox Inspectorの詳細を学びます。
  • AspectJホーム・ページ: Design by Contractテストにアスペクトを使用する方法の詳細について学びます。
  • Object-Oriented Software Construction, Second Edition』(Bertrand Meyer著、Prentice Hall、1997年): 提唱者自身によるDesign by Contractの解説が含まれています。
  • AspectJ in Action』(Ramnivas Laddad、Manning、2003年): アスペクトとObserverパターンを使用したポリシー実施について説明します。
  • 「Java technology」ゾーン: Javaプログラミングのあらゆる面を網羅した記事が豊富に用意されています。

製品や技術を入手するために

  • Contract4Jホーム・ページ: ダウンロード・リンクとContract4Jの使用に関する詳細情報があります。
  • AspectJホーム・ページ: 最新リリースをダウンロードし、AspectJとAJDTに関する情報を入手してください。
  • JUnit: Javaプラットフォームで最も人気のある単体テスト・フレームワーク。
  • Barter: Contract4Jに先行してAspectJを暗黙的に使用したXDocletベースのツール。
  • JEXLインタープリター: Jakartaホーム・ページで調べてください。
  • SpringJBoss: アスペクトを組み込む他のJavaベースの技術。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology
ArticleID=218846
ArticleTitle=AOP@Work: Contract4Jを使用したコンポーネント設計
publish-date=04112006