(57)【特許請求の範囲】
【請求項１】
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合されたメモリと、
前記メモリに常駐する複合アプリケーションであって、前記複合アプリケーションは、複数の異なるプログラミング言語で書かれた複数のコンポーネントを含む、複合アプリケーションと、
前記メモリに常駐する複数のコンポーネント相互関係規則であって、前記コンポーネント相互関係規則の各々は、異なるプログラミング言語のコンポーネント間の少なくとも１つの条件と前記少なくとも１つの条件が満たされるかどうかに応じて行われる少なくとも１つのアクションとを含む、複数のコンポーネント相互関係規則と、
前記メモリに常駐し、前記少なくとも１つのプロセッサによって実行されるアプリケーション分析機構であって、前記アプリケーション分析機構は、前記複合アプリケーションのアプリケーション・モデルを生成し、前記複数のコンポーネント相互関係規則への適合性について前記アプリケーション・モデルを分析し、前記複数のコンポーネント相互関係規則への適合性について前記アプリケーション・モデルを分析した結果を出力する、アプリケーション分析機構と、
を含み、
前記アプリケーション・モデルは、プログラミング言語に従って複数のカテゴリに分離された前記複合アプリケーション内の前記複数のコンポーネントを含む装置。
【請求項２】
前記少なくとも１つのアクションは、前記結果に警告を付加することを含む、請求項１に記載の装置。
【請求項３】
前記結果は、前記複合アプリケーションについての統計情報と少なくとも１つの警告とを含む、請求項１に記載の装置。
【請求項４】
前記アプリケーション・モデルは、前記複数のカテゴリのうちの第１のカテゴリにおけるコンポーネントと前記複数のカテゴリのうちの第２のカテゴリにおけるコンポーネントとの間の相互関係を記述するメタデータをさらに含む、請求項１に記載の装置。
【請求項５】
前記少なくとも１つの条件は、２つのプログラミング言語と前記２つのプログラミング言語の間の相互関係とを指定する、請求項１に記載の装置。
【請求項６】
複数の異なるプログラミング言語で書かれた複数のコンポーネントを含む複合アプリケーションを分析するためのコンピュータ実装方法であって、
前記方法は、
少なくとも１つのプロセッサを準備するステップと、
前記少なくとも１つのプロセッサに結合されたメモリを準備するステップと、
前記メモリに常駐する複数のコンポーネント相互関係規則を準備するステップであって、前記コンポーネント相互関係規則の各々は、異なるプログラミング言語のコンポーネント間の少なくとも１つの条件と前記少なくとも１つの条件が満たされるかどうかに応じて行われる少なくとも１つのアクションとを含む、ステップと、
を含み、
前記少なくとも１つのプロセッサは、
前記複合アプリケーションを受信するステップと、
前記複合アプリケーションのアプリケーション・モデルを生成するステップと、
前記複数のコンポーネント相互関係規則への適合性について前記アプリケーション・モデルを分析するステップと、
前記複数のコンポーネント相互関係規則への適合性について前記アプリケーション・モデルを分析した結果を出力するステップと、
を行い、
前記アプリケーション・モデルは、プログラミング言語に従って複数のカテゴリに分離された前記複合アプリケーション内の前記複数のコンポーネントを含む、方法。
【請求項７】
前記少なくとも１つのアクションは、前記結果に警告を付加することを含む、請求項６に記載の方法。
【請求項８】
前記結果は、前記複合アプリケーションについての統計情報と少なくとも１つの警告とを含む、請求項６に記載の方法。
【請求項９】
前記アプリケーション・モデルは、前記複数のカテゴリのうちの第１のカテゴリにおけるコンポーネントと前記複数のカテゴリのうちの第２のカテゴリにおけるコンポーネントとの間の相互関係を記述するメタデータをさらに含む、請求項６に記載の方法。
【請求項１０】
前記少なくとも１つの条件は、２つのプログラミング言語と前記２つのプログラミング言語の間の相互関係とを指定する、請求項６に記載の方法。
【請求項１１】
複数の異なるプログラミング言語で書かれた複数のコンポーネントを含む複合アプリケーションを分析するためのコンピュータ実装方法であって、
前記方法は、
少なくとも１つのプロセッサを準備するステップと、
前記少なくとも１つのプロセッサに結合されたメモリを準備するステップと、
前記メモリに常駐する複数のコンポーネント相互関係規則を準備するステップであって、前記コンポーネント相互関係規則の各々は、異なるプログラミング言語のコンポーネント間の少なくとも１つの条件と前記少なくとも１つの条件が満たされるかどうかに応じて行われる少なくとも１つのアクションとを含む、ステップと、
を含み、
前記少なくとも１つのプロセッサは、
前記複合アプリケーションを受信するステップと、
プログラミング言語に従って複数のカテゴリに分離された前記複合アプリケーション内の前記複数のコンポーネントを含む、前記複合アプリケーションのアプリケーション・モデルを生成するステップであって、前記複数のカテゴリの各々は、異なるカテゴリにおけるコンポーネント間の相互関係を記述するメタデータを含む、ステップと、
前記複数のコンポーネント相互関係規則への適合性について前記アプリケーション・モデルを分析するステップと、
前記複数のコンポーネント相互関係規則への適合性について前記アプリケーション・モデルを分析した結果を出力するステップであって、前記結果は、前記複合アプリケーションについての統計情報と少なくとも１つの警告とを含む、ステップと、
を行う、方法。
【請求項１２】
有形のストレージ媒体上に格納されるコンピュータ・プログラムであって、コンピュータを、
複数の異なるプログラミング言語で書かれた複数のコンポーネントを含む複合アプリケーションのアプリケーション・モデルを生成し、異なるプログラミング言語のコンポーネント間の少なくとも１つの条件と前記少なくとも１つの条件が満たされるかどうかに応じて行われる少なくとも１つのアクションとを各々が含む複数のコンポーネント相互関係規則への適合性について、前記アプリケーション・モデルを分析し、前記複数のコンポーネント相互関係規則への適合性について前記アプリケーション・モデルを分析した結果を出力する、アプリケーション分析機構として機能させ、
前記アプリケーション・モデルは、プログラミング言語に従って複数のカテゴリに分離された前記複合アプリケーション内の前記複数のコンポーネントを含む、コンピュータ・プログラム。
【請求項１３】
前記少なくとも１つのアクションは、前記結果に警告を付加することを含む、請求項１２に記載のコンピュータ・プログラム。
【請求項１４】
前記結果は、前記複合アプリケーションについての統計情報と少なくとも１つの警告とを含む、請求項１２に記載のコンピュータ・プログラムソフトウェア。
【請求項１５】
前記アプリケーション・モデルは、前記複数のカテゴリのうちの第１のカテゴリにおけるコンポーネントと前記複数のカテゴリのうちの第２のカテゴリにおけるコンポーネントとの間の相互関係を記述するメタデータをさらに含む、請求項１２に記載のコンピュータ・プログラム。
【請求項１６】
前記少なくとも１つの条件は、２つのプログラミング言語と前記２つのプログラミング言語の間の相互関係とを指定する、請求項１２に記載のコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に、複合アプリケーションを分析することに関し、より具体的には、コンポーネント間の相互関係を指定する規則の組への適合性についての複合アプリケーションの自動分析に関する。
【背景技術】
【０００２】
コンピュータ・プログラムは、長年にわたり、アセンブリ・コードで書かれた単純なプログラムから、高級言語で書かれる比較的複雑なプログラムまで発展を遂げてきた。コンピュータ・プログラミングにおける最近の発展には、複雑なコンピュータ・プログラムの異なる部分を異なるプログラミング言語で書くことが含まれる。サービス・コンポーネント・アーキテクチャ（ＳＣＡ）は、サービス指向アーキテクチャに適合するアプリケーションについての要件を規定する、複数の大手ソフトウェア・ベンダによって提唱される新たな取り組みである。ＳＣＡでは、アプリケーションは、複数のプログラミング言語による多くの異なるコンポーネントから成るため、「複合アプリケーション」と呼ばれる。Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎ（ＩＢＭ）社は、サービス・コンポーネント・アーキテクチャ（ＳＣＡ）アプリケーションとして知られる複合アプリケーションの開発をサポートする、ＷｅｂＳｐｈｅｒｅとして知られる製品を提供している。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ＳＣＡアプリケーションのような複合アプリケーションを分析するステップは、現在のところ、アプリケーションをＷｅｂＳｐｈｅｒｅツールに取り込むことによって行われている。次いで、プログラマが、認められる最良の形態（best practice）及び最悪の形態（worst practice）についてアプリケーションのコンポーネントを手作業で調べ、調査結果を顧客に報告する。人間の性質上、重要な詳細が隠されたり完全に見落とされたりして、顧客に提供されるサポートに悪影響を与える場合がある。この手作業のプロセスによって生じる結果はまた、時間の経過に伴って矛盾したものとなる可能性があり、新たな規則が作成されると、こうした努力に関する労働コストのため、初期の結果が再現されない。
【０００４】
ソフトウェア分析のための既知のツールは、単一言語で書かれたコンピュータ・プログラムの静的な分析を行うことができるようにするが、異なるプログラミング言語で書かれた複数のコンポーネントを有する複合アプリケーションの分析をサポートするものではない。複合アプリケーションの分析を自動化する手段がなければ、現在の手作業によるプロセスは、誤りを起こしやすく非効率なものであり続けることになる。
【課題を解決するための手段】
【０００５】
アプリケーション分析機構が、異なる言語で書かれたコンポーネント間で満たされるべき１つ又は複数の条件と条件の分析に応じて行われるアクションとを定めるコンポーネント相互関係規則の組への適合性について、複合アプリケーションを分析する。コンポーネント相互関係規則が定められると、複合アプリケーションが受信される。次に、複合アプリケーションのコンポーネントを用いられるプログラミング言語に基づくカテゴリに分離し、コンポーネント間の相互関係を記述するためのメタデータを含む、複合アプリケーションのモデルが構築される。次いで、複合アプリケーションのモデルに対して、コンポーネント相互関係規則の組が実行される。次いで、分析の結果が出力される。複合アプリケーションの自動分析は、人的誤りを起こしやすいプロセスの大部分を取り除き、複合アプリケーションを分析するための効率的且つ一貫した手法を提供して、異なるプログラミング言語で書かれたコンポーネント間の相互関係がコンポーネント相互関係規則を満たすことを保証する。
【図面の簡単な説明】
【０００６】
【図１】定められたコンポーネント相互関係規則の組への適合性について複合アプリケーションを自動的に分析するアプリケーション分析機構を含む装置のブロック図である。
【図２】図１の複合アプリケーションについての１つの適切な実装形態を示すブロック図である。
【図３】プログラミング言語に従ってグループ化されたコンポーネントを示すアプリケーション・モデルのブロック図である。
【図４】６つの異なるプログラミング言語を含む図１及び図３のアプリケーション・モデルについての１つの具体的な実装形態のブロック図である。
【図５】コンポーネント相互関係規則の組を示すブロック図である。
【図６】コンポーネント相互関係規則の条件について１つの特定の実装形態を示すブロック図である。
【図７】コンポーネント相互関係規則の組への適合性について複合アプリケーションを自動的に分析するための方法の流れ図である。
【図８】第１の例のコンポーネント相互関係規則を示す。
【図９】第２の例のコンポーネント相互関係規則を示す。
【図１０】第３の例のコンポーネント相互関係規則を示す。
【図１１】複合アプリケーションの例についてアプリケーション分析機構によって出力された結果の例を示す。
【図１２】複合アプリケーションの例についてアプリケーション分析機構によって出力された結果の例を示す。
【発明を実施するための形態】
【０００７】
上記の及び他の特徴及び利点は、添付図面において示される、以下のより具体的な説明から明らかとなるであろう。
【０００８】
本開示は、同様の記号表示が同様の要素を示す添付図面とともに説明される。
【０００９】
特許請求の範囲及び本明細書における開示は、コンポーネント相互関係規則の組への適合性について複合アプリケーションを自動的に分析するアプリケーション分析機構を提供する。規則は、異なるプログラミング言語で書かれたコンポーネント間の相互関係を定める。複合アプリケーションが受信されて、プログラミング言語に応じてコンポーネントを複数のカテゴリに分離し、かつ、カテゴリ間の相互関係を記述するメタデータを提供する、複合アプリケーションのモデルが生成される。次いで、モデルに対して規則が実行され、分析の結果がユーザに出力される。結果は、統計情報及び警告を含むことがある。結果として、コンポーネント相互関係規則への適合性について複合アプリケーションを自動的に分析するソフトウェア・ツールが得られる。
【００１０】
例１
図１を参照すると、コンピュータ・システム１００は、アプリケーション分析機構を含むコンピュータ・システムの１つの適切な実装形態である。コンピュータ・システム１００は、ＩＢＭ  ｅＳｅｒｖｅｒ  Ｓｙｓｔｅｍ  ｉコンピュータ・システムである。しかしながら、当業者であれば、本明細書における開示は、コンピュータ・システムが複雑なマルチ・ユーザ用コンピューティング装置であるか、シングル・ユーザ用ワークステーションであるか、又は内蔵式制御システムであるかどうかに関わりなく、あらゆるコンピュータ・システムに等しく適用されることが分かるであろう。図１に示されるように、コンピュータ・システム１００は、１つ又は複数のプロセッサ１１０、メイン・メモリ１２０、大容量ストレージ・インターフェース１３０、ディスプレイ・インターフェース１４０、及びネットワーク・インターフェース１５０を含む。これらのシステム・コンポーネントは、システム・バス１６０を用いることによって相互接続される。大容量ストレージ・インターフェース１３０は、直接アクセス・ストレージ装置１５５などの大容量ストレージ装置をコンピュータ・システム１００に接続するのに用いられる。直接アクセス・ストレージ装置１５５の１つの具体的なタイプは、読み出し及び書き込み可能ＣＤ−ＲＷドライブであり、これは、ＣＤ−ＲＷ１９５との間でデータの格納及びデータの読み出しを行うことができる。
【００１１】
メイン・メモリ１２０は、好ましくは、データ１２１、オペレーティング・システム１２２、複合アプリケーション１２３、及びアプリケーション分析機構１２４を含む。データ１２１は、コンピュータ・システム１００内のいずれかのプログラムからの入力又はいずれかのプログラムへの出力としての役割を果たすいずれかのデータを表す。オペレーティング・システム１２２は、マルチタスク型オペレーティング・システムである。複合アプリケーション１２３は、異なるプログラミング言語で書かれた複数のコンポーネントを含むアプリケーションである。アプリケーション分析機構１２４は、モデル生成機構１２５、コンポーネント相互関係規則１２７、及び規則分析機構１２８を含む。モデル生成機構１２５は、複合アプリケーション１２３を受信し、複合アプリケーションからアプリケーション・モデル１２６を生成する。アプリケーション・モデル１２６は、好ましくは、プログラミング言語に応じてコンポーネントをグループ化し、コンポーネント間の相互関係の最良の形態及び最悪の形態を記述するメタデータを含む。コンポーネント相互関係規則１２７は、満たされるべきコンポーネント間の１つ又は複数の条件と共に、その条件が満たされない場合に行う１つ又は複数のアクションを指定する。規則分析機構１２８は、コンポーネント相互関係規則１２７をアプリケーション・モデル１２６に対して実行し、結果１２９を出力する。結果１２９は、統計情報及び警告を含むことがあり、ユーザのディスプレイに出力するか、又はメモリ内若しくは物理媒体上に何らかの電子的形態で格納することができる。結果として、コンポーネント相互関係規則への適合性について複合アプリケーションを自動的に分析するアプリケーション分析機構１２４が得られる。
【００１２】
コンピュータ・システム１００は、コンピュータ・システム１００のプログラムが、メイン・メモリ１２０及びＤＡＳＤデバイス１５５のような複数のより小容量のストレージ・エンティティにアクセスする代わりに、大容量で単一のストレージ・エンティティのみにアクセスするように振舞うことを可能にする、周知の仮想アドレス指定機構を利用する。したがって、データ１２１、オペレーティング・システム１２２、複合アプリケーション１２３、及びアプリケーション分析機構１２４がメイン・メモリ１２０内に常駐するように示されているが、当業者であれば、これらのアイテムが必ずしも全て同時にメイン・メモリ１２０内に完全に含まれている必要はないことが分かるであろう。「メモリ」という用語は、本明細書において、コンピュータ・システム１００の仮想メモリ全体を総称的に指すのに用いられており、コンピュータ・システム１００に結合された他のコンピュータ・システムの仮想メモリを含んでもよいことにもまた留意すべきである。
【００１３】
プロセッサ１１０は、１つ又は複数のマイクロプロセッサ及び／又は集積回路によって構築することができる。プロセッサ１１０は、メイン・メモリ１２０に格納されたプログラム命令を実行する。メイン・メモリ１２０は、プロセッサ１１０がアクセスすることができるプログラム及びデータを格納する。コンピュータ・システム１００が起動したときには、プロセッサ１１０は最初に、オペレーティング・システム１２２を構成するプログラム命令を実行する。プロセッサ１１０は、アプリケーション分析機構１２４も実行する。
【００１４】
コンピュータ・システム１００は、単一のプロセッサ及び単一のシステム・バスのみを含むように示されているが、当業者であれば、複数のプロセッサ及び／又は複数のバスを有するコンピュータ・システムを用いてアプリケーション分析機構を実施できることが分かるであろう。さらに、用いられるインターフェースは、各々が、プロセッサ１１０から計算集約的な処理の負荷を軽減するのに用いられる完全にプログラムされた別個のマイクロプロセッサを含むことが好ましい。しかしながら、当業者であれば、Ｉ／Ｏアダプタを用いてこれらの機能を同様に行うことができることが分かるであろう。
【００１５】
ディスプレイ・インターフェース１４０は、１つ又は複数のディスプレイ１６５をコンピュータ・システム１００に直接接続するのに用いられる。非インテリジェント型（即ちデータ処理能力のない）端末又は完全にプログラム可能なワークステーションとすることができるこれらのディスプレイ１６５は、システム管理者及びユーザにコンピュータ・システム１００と通信する能力を提供するのに用いられる。しかしながら、ディスプレイ・インターフェース１４０は１つ又は複数のディスプレイ１６５との通信をサポートするために設けられているが、ユーザ及び他のプロセスとの必要な相互関係は全てネットワーク・インターフェース１５０を介して行うことができるため、コンピュータ・システム１００は、必ずしもディスプレイ１６５を必要としないことに留意されたい。
【００１６】
ネットワーク・インターフェース１５０は、ネットワーク１７０を介してコンピュータ・システム１００を他のコンピュータ・システム又はワークステーション１７５に接続するのに用いられる。ネットワーク・インターフェース１５０は、ネットワーク１７０が現在のアナログ及び／又はデジタル技術を含むのか又は将来の何らかのネットワーク機構を介するのかに関わりなく、電子デバイスを相互接続するためのいずれかの適切な手段を広範に表す。ネットワーク・インターフェース１５０は、好ましくは、ネットワーク１７０上での通信を可能にするハードウェアとソフトウェアとの組み合わせを含む。ネットワーク・インターフェース１５０のソフトウェアは、好ましくは、適切なネットワーク・プロトコルを用いた他のコンピュータ・システム１７５とのネットワーク１７０経由の通信を管理する通信マネージャを含む。多くの異なるネットワーク・プロトコルを用いて、ネットワークを実装することができる。これらのプロトコルは、コンピュータがネットワーク上で通信することを可能にする専用コンピュータ・プログラムである。ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）は、ネットワーク・インターフェース１５０内の通信マネージャが用いることができる適切なネットワーク・プロトコルの一例である。
【００１７】
当業者によって認識されるように、本発明の態様は、システム、方法又はコンピュータ・プログラム製品として具体化することができる。従って、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロ・コード等を含む）、又はソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形を取ることができ、本明細書においては、これらは全て、一般的に、「回路」、「モジュール」又は「システム」と呼ぶことがある。さらに、本発明の態様は、媒体内に具体化されたコンピュータ使用可能プログラム・コードを有する、１つ又は複数のコンピュータ可読媒体内に具体化されたコンピュータ・プログラム製品の形を取ることができる。
【００１８】
１つ又は複数のコンピュータ可読媒体のいずれの組み合わせも利用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読ストレージ媒体とすることができる。コンピュータ可読ストレージ媒体は、例えば、電子的、磁気的、光学的、電磁気的、赤外線若しくは半導体のシステム、機器若しくは装置、又はこれらのいずれかの適切な組み合わせとすることができるが、これらに限定されるものではない。コンピュータ可読ストレージ媒体のより具体的な例（非網羅的なリスト）として、以下のもの、即ち、１つ又は複数の配線を有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、又はこれらのいずれかの適切な組み合わせが挙げられる。本明細書の文脈においては、コンピュータ可読ストレージ媒体は、命令実行システム、機器若しくは装置によって又はそれらと関連して用いるためのプログラムを収容又は格納することが可能ないずれかの有形媒体とすることができる。
【００１９】
コンピュータ可読信号媒体は、例えばベースバンドに、又は搬送波の一部として、コンピュータ可読プログラム・コードが組み入れられた伝搬データ信号を含むことができる。このような伝搬信号は、電磁気、光又はそれらのいずれかの適切な組み合わせを含むがこれらに限定されない、種々の異なる形態のいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、かつ、命令実行システム、機器若しくは装置によって又はこれらと関連して用いるためのプログラムを通信し、伝搬し又は搬送することができる、いずれかのコンピュータ可読媒体とすることができる。
【００２０】
コンピュータ可読媒体上に具体化されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦ等、又はこれらのいずれかの適切な組み合わせを含むがこれらに限定されるものではないいずれかの適切な媒体を用いて、伝送することができる。
【００２１】
本発明の態様についての操作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、ＳｍａｌｌＴａｌｋ、Ｃ＋＋等のようなオブジェクト指向型プログラミング言語、及び、「Ｃ」プログラミング言語又は同様のプログラミング言語のような従来の手続き型プログラミング言語を含む、１つ又は複数のプログラミング言語のいずれかの組み合わせで書くことができる。プログラム・コードは、完全にユーザのコンピュータ上で実行されるか、一部がユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして実行されるか、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行されるか、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合がある。最後のシナリオにおいては、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続されるか、又は、（例えば、インターネット・サービス・プロバイダを用いたインターネットを通じて）外部コンピュータへの接続がなされる場合がある。
【００２２】
本発明の態様は、本明細書において、本発明の実施形態による方法、機器（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図におけるブロックの組み合わせは、コンピュータ・プログラム命令によって実装できることが理解されるであろう。これらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えて、マシンを製造し、その結果、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施するための手段を生成するようになる。
【００２３】
これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他の装置を特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、その結果、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装する命令を含む製品を製造するようになる。
【００２４】
コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他の装置上にロードして、そのコンピュータ、他のプログラム可能データ処理装置、又は他の装置上で行われる一連の動作ステップによりコンピュータ実装プロセスを生成し、その結果、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するためのプロセスをもたらすようになる。
【００２５】
図２を参照すると、複合アプリケーション１２３についての実装例が、言語１のコンポーネント２１０Ａ、言語２のコンポーネント２１０Ｂ、．．．、言語Ｎのコンポーネント２１０Ｎとして図２に示される、複数のプログラミング言語で書かれた複数のコンポーネントを含む。複合アプリケーション１２３は、異なるプログラミング言語のコンポーネントを含むため、既知の静的な分析ツールは、複合アプリケーション１２３のコンポーネント間の相互関係を分析するには不適当である。
【００２６】
図３を参照すると、アプリケーション・モデル１２６についての実装例は、複数の言語カテゴリを含むものであり、各々のコンポーネントは、コンポーネントのプログラミング言語に従ってカテゴリ内に配置され、各々のカテゴリは、コンポーネント・タイプ間の相互関係の最良の形態及び最悪の形態を記述するメタデータを含む。相互関係の最良の形態及び最悪の形態を記述するメタデータは、いずれかの適切なソースからのものとすることができるが、好ましくは、Ｓｅｒｖｉｃｅ  Ｃｏｍｐｏｎｅｎｔ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＳＣＤＬ）から提供される。このように、アプリケーション・モデル１２６は、好ましくは、図３において言語１  ３１０Ａ、言語２  ３１０Ｂ、．．．、言語Ｎ  ３１０Ｎとして示される複数の言語カテゴリを含む。各々の言語カテゴリは、その言語で書かれた対応するコンポーネントと共に、そのカテゴリ内のコンポーネントと１つ又は複数の異なるカテゴリ内のコンポーネントとの間の相互関係を記述する適切なメタデータを含む。したがって、言語１  ３１０Ａは１つ又は複数の対応するコンポーネント３２０Ａ及びメタデータ３３０Ａを含み、言語２  ３１０Ｂは１つ又は複数の対応するコンポーネント３２０Ｂ及びメタデータ３３０Ｂを含み、以下同様に、１つ又は複数の対応するコンポーネント３２０Ｎ及びメタデータ３３０Ｎを含む言語Ｎ  ３１０Ｎまで続く。
【００２７】
アプリケーション・モデル１２６の１つの具体的な例が、図４においてアプリケーション・モデル１２６Ａとして示される。この特定のアプリケーション・モデルには、６つの異なるカテゴリが存在し、その各々は異なるプログラミング言語に対応する。図４に示される６つのカテゴリは、Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｅｘｅｃｕｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＢＰＥＬ）４１０、Ｊａｖａ４２０、Ｍｅｄｉａｔｉｏｎ  Ｆｌｏｗ  Ｃｏｎｔｒｏｌ（Ｍｅｄ  Ｆｌｏｗ）４３０、ＷｅｂＳｅｒｖｉｃｅ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ）４４０、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）Ｓｃｈｅｍａ  Ｄｏｃｕｍｅｎｔ（ＸＳＤ）４５０、及びＭｏｎｉｔｏｒ  Ｍｏｄｅｌ４６０を含む。アプリケーション・モデル１２６Ａは、示される６つのカテゴリの全てを含む複合アプリケーションのモデルである。図４において示される６つのカテゴリの各々４１０、４２０、４３０、４４０、４５０、及び４６０は、図３において３１０Ａ、３１０Ｂ、．．．、３１０Ｎとして示される言語の適切な例である。複合アプリケーション内のコンポーネントの各々は、そのコンポーネントのプログラミング言語に従って、カテゴリの１つに割り当てられることになる。さらに、各々のカテゴリは、カテゴリ内のコンポーネントと１つ又は複数の異なるカテゴリ内のコンポーネントとの間の相互関係を記述するメタデータを含む。
【００２８】
図５は、図１に示されるコンポーネント相互関係規則１２７について１つの適切な実装形態を示す。コンポーネント相互関係規則１２７は、好ましくは、その各々が条件と対応するアクションとを指定する複数の規則を含む。したがって、規則１  ５１０Ａは条件５２０Ａ及びアクション５３０Ａを含み、規則２  ５１０Ｂは条件５２０Ｂ及びアクション５３０Ｂを含み、以下同様に、条件５２０Ｎ及び対応するアクション５３０Ｎを含む規則Ｎ  ５１０Ｎまで続く。各々の規則についての対応するアクションは、分析の結果に警告を付加することを含む場合がある。
【００２９】
図５に示される条件５２０Ａなどの条件の１つの適切な実装形態が図６に示される。条件５２０Ａは、好ましくは、第１の言語６１０と、第２の言語６２０と、言語間の何らかの相互関係６３０とを指定する。１つの具体的な実装形態においては、相互関係６３０は望ましい相互関係（最良の形態）であり、条件５２０Ａが満たされない場合には、コンポーネント間の望ましい相互関係が存在しなかったことを示す警告が分析結果に付加されることになる。代替的な実装形態においては、相互関係６３０は望ましくない相互関係（最悪の形態）であり、条件５２０が満たされる場合には、コンポーネント間の望ましくない相互関係が存在することを示す警告が分析結果に付加されることになる。図５及び図６において示されるコンポーネント相互関係規則並びにその対応する条件及びアクションの例は、一例として示されており、限定的なものではない。本明細書における本開示及び特許請求の範囲は、複合アプリケーションに対応するアプリケーション・モデルに対して実行することができる、あらゆる適切なコンポーネント相互関係規則にまで明確に及ぶ。
【００３０】
図７を参照すると、方法７００は、好ましくは、１つ又は複数のプロセッサ１１０によって実行されたときに、アプリケーション分析機構１２４によって行われる。最初に、コンポーネント相互関係規則が定められる（ステップ７１０）。１つの特定の実装形態においては、コンポーネント相互関係規則はユーザである人間によって定められる。しかしながら、コンポーネント相互関係規則はソフトウェアによって定めることもできる。例えば、規則生成機構が、証明済みのロバストな複合アプリケーションのコンポーネント間の相互関係を分析して、１つ又は複数のコンポーネント相互関係規則を自動的に生成することができる。コンポーネント相互関係規則は、ユーザである人間によって定められる規則とコンピュータ・プロセスによって自動的に生成される規則の両方にまで明確に及ぶ。
【００３１】
ステップ７１０において規則が定められると、複合アプリケーションが受信される（ステップ７２０）。次いで複合アプリケーションのモデルが生成される（ステップ７３０）。図３及び図４を参照して上述されたように、アプリケーション・モデルは、好ましくは、各々が異なるプログラミング言語に対応する複数のカテゴリを含み、各コンポーネントは、コンポーネントのプログラミング言語に従ってカテゴリ内に配置され、それと共に、各カテゴリは、そのカテゴリ内のコンポーネントと１つ又は複数の異なるカテゴリ内のコンポーネントとの間の相互関係を記述するメタデータを含む。次いで、コンポーネント相互関係規則が選択される（ステップ７４０）。選択されたコンポーネント相互関係規則がモデルに対して実行される（ステップ７５０）。結果が生成される（ステップ７６０）。処理する規則がさらに存在するとき（ステップ７７０＝はい）には、方法７００は、再びステップ７４０に戻り、処理する規則がそれ以上存在しなくなるまで続き（ステップ７７０＝いいえ）、存在しなくなった時点で結果が出力され（ステップ７８０）、方法７００は完了する。ステップ７６０において生成される結果及び／又はステップ７８０において出力される結果は、複合アプリケーションについての統計情報と警告とを含むことができることに留意されたい。
【００３２】
適切なコンポーネント相互関係規則の具体的な例が図８−図１０に示される。図８−図１０におけるコンポーネント相互関係規則８１０、９１０、及び１０１０は、図１及び図５において示されるコンポーネント相互関係規則１２７の具体的な例である。図８において示されるコンポーネント相互関係規則８１０は、遅延結合に関し、これは最良の形態を表す。第１行８２０はプログラミング構造をＳＣＤＬで指定し、一方、第２行８３０はビジネス・プロセスをＢＰＥＬで指定している。行８４０における条件が満たされたときに、行８５０においてプール変数ｓｅｔＥａｒｌｙＢｏｕｎｄがｔｒｕｅにセットされ、行８６０において、ＢＰＥＬの新しいバージョンが自動的にピックアップされていないことの警告が結果に付加される。
【００３３】
例２
適切なコンポーネント相互関係規則の別の例９１０が図９に示されており、これは呼び出し問題を扱うものである。第１行９２０はＳＣＤＬのＣｏｍｐｏｎｅｎｔステートメントであり、一方、第２行９３０はＢＰＥＬファイルを呼び出すＪａｖａステートメントである。行９４０及び９５０は、条件が満たされるかどうかを調べるテストを行い、満たされる場合には、行９６０において第１の警告を付加することができ、行９７０において第２の警告を付加することができる。この規則の論理は、ＪａｖａファイルがＢＰＥＬコンポーネントを呼び出す場合には、そのＢＰＥＬコンポーネントとは実行時に非同期的に対話すべきであることと、エラーが発生した場合には、バックエンド・システムが、外部からの修復を要する不整合状態になっている可能性があり、従って、適切な警告が結果に付加されることを示している。
【００３４】
例３
適切なコンポーネント相互関係規則の第３の例１０１０が図１０に示されており、これは呼び出し形式を扱うものである。この規則は、同じ言語、即ちＳＣＤＬによって定められた２つのコンポーネントを有するが、いずれもＸＭＬを用いて定められた２つの異なるスキーマ、即ちＣｏｍｐｏｎｅｎｔ及びＩｍｐｏｒｔに従うものであることに留意されたい。行１０２０は各コンポーネントを取得することを指定し、行１０３０においてそのコンポーネントについての実装タイプがＪａｖａである場合には、行１０４０においてインポートが選択され、行１０５０における各々のインポートについて、行１０６０においてそのインポートがトランザクションを結合しない場合には、バックエンド・システムが最終的に矛盾した状態になる可能性があるため、行１０７０において警告が付加される。
【００３５】
図７のステップ７６０において生成され、ステップ７８０において出力される例示的な結果（Results）が、例示的な複合アプリケーションについて、図１１及び図１２における１１００として示される。結果には、図１１に示されるように、複合アプリケーションに関する多くの異なるパラメータの明細事項が含まれる。結果には、図１２に示されるように、複合アプリケーションを特徴付ける統計情報（Statistics）を含むこともできる。図１２に示される具体的な統計情報は、ＷＳＤＬ当たりの平均演算数、ＷＳＤＬ当たりの平均障害数、演算当たりの平均障害数、ＸＳＤ毎の平均フィールド数、ＸＳＤ当たりの平均ビジネス・オブジェクト（ＢＯ）数、ＢＯ当たりの平均フィールド数、及びＢＰＥＬ当たりの平均アクティビティ数を含む。結果には、図１２に示されるように、１つ又は複数の警告（Warnings）が含まれることもある。種々の警告は、コンポーネント相互関係規則内の条件が結果に警告を付加することを指定しているときに、結果に付加される。図１１及び図１２における結果１１００は、好ましくは、人であるプログラマに対して表示され、プログラマは、統計情報及び警告を用いて、複合アプリケーションが予測される通りに動作するかどうかを判断することができる。当然のことながら、統計情報及び警告はまた、コンポーネント相互関係規則に適合するようにコンポーネントの特定の変更を推奨することができる自動化されたプロセスによって、用いることもできる。
【００３６】
本開示及び特許請求の範囲は、異なる言語で書かれたコンポーネント間で満たされるべき１つ又は複数の条件と条件の分析に応じて行われるアクションとを定めるコンポーネント相互関係規則の組への適合性について、異なるプログラミング言語で書かれたコンポーネントを含む複合アプリケーションを自動的に分析する手法を開示する。複合アプリケーションのモデルが生成され、そのモデルに対して規則が実行される。複合アプリケーションについての統計情報及び警告を含むことがある結果が出力される。複合アプリケーションの自動分析は、人的誤りを起こしやすいプロセスの大部分を取り除き、複合アプリケーションを分析するための一貫した手法を提供して、異なるプログラミング言語で書かれたコンポーネント間の相互関係がコンポーネント相互関係規則を満たすことを保証する。
【００３７】
当業者であれば、特許請求の範囲内で多くのバリエーションが可能であることを認識するであろう。従って、本開示は、上記で具体的に示され説明されたが、当業者であれば、添付の特許請求の真意及び範囲から逸脱することなく形態及び細部におけるこれらの変更及び他の変更を本開示に対して為し得ることが理解されるであろう。
【産業上の利用可能性】
【００３８】
本発明は、コンポーネント間の相互関係を指定する規則の組への適合性について複合アプリケーションを自動分析することに利用可能である。
【図１】
0005568177.tif 000002
【図２】
0005568177.tif 000003
【図３】
0005568177.tif 000004
【図４】
0005568177.tif 000005
【図５】
0005568177.tif 000006
【図６】
0005568177.tif 000007
【図７】
0005568177.tif 000008
【図８】
0005568177.tif 000009
【図９】
0005568177.tif 000010
【図１０】
0005568177.tif 000011
【図１１】
0005568177.tif 000012
【図１２】
0005568177.tif 000013