(57)【要約】本発明は、インターフェースの各クラスとその実装のクラスの間で示されるＵＭＬ関係に従って、ＵＭＬ実装モデルをＵＭＬインターフェースモデルＭＡから自動的に装備すること、並びに、このリンクを使用してＣＯＲＢＡの特性を有する実装コードＭＩを生成することからなる。本発明は、サーバアプリケーションの変換および計測、およびクライアントアプリケーションの変換および計測にも関する。
2005527039.tif 000002
【特許請求の範囲】
【請求項１】
ＵＭＬインターフェースオブジェクトを設計し、それらをＩＤＬ言語で生成する手段を含むソフトウェア開発ツールであって、
ＵＭＬ実装オブジェクトを設計し、対応する実装ソースコード（Ｃ＋＋）を生成する手段を含み、
ＵＭＬインターフェースオブジェクトおよびＵＭＬ実装オブジェクトが設計段階のときにリンクされることを特徴とするソフトウェア開発ツール。
【請求項２】
ＵＭＬ実装オブジェクトおよびＵＭＬインターフェースオブジェクトが、各インターフェースクラスと対応する実装クラスとの間に存在するＵＭＬ関係によってリンクされ、このリンクを使用してＣＯＲＢＡ特有の機能をもつ実装コードが生成されることを特徴とする請求項１に記載のソフトウェア開発ツール。
【請求項３】
１つのＵＭＬインターフェースオブジェクトは、分散システムのＩＤＬ（Ｉｎｔｅｒｆａｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  ｌａｎｇｕａｇｅ）インターフェースを指定するモデルであり、他方のオブジェクトはその実装を定義することを特徴とする請求項１または２のいずれかに記載のソフトウェア開発ツール。
【請求項４】
ＵＭＬインターフェースオブジェクトは、インターフェースおよびインターフェースと他の高レベルクラスとの関係でクライアントアプリケーションが記述される分析モデルであり、他方のオブジェクトは、アプリケーションクラス全てが記述される実装モデルであることを特徴とする請求項１、２、または３に記載のソフトウェア開発ツール。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＣＯＲＢＡインターフェースのＵＭＬモデルとその実装との間のリンクを確保するソフトウェア開発ツールに関する。
【０００２】
ＵＭＬは、Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｌｉｎｇ  Ｌａｎｇｕａｇｅを表す。
【０００３】
ＣＯＲＢＡは、Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅを表す。
【０００４】
ＩＤＬは、Ｉｎｔｅｒｆａｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅを表す。
【背景技術】
【０００５】
ＵＭＬ言語は、ソフトウェアシステムを指定し、こうしたシステムのモデルを記述する有効な手段を提供するものである。いくつかのソフトウェアワークショップ、換言すればソフトウェアアプリケーション開発ツールは、ＵＭＬモデルから開始されるコード生成を可能にする。
【０００６】
ＣＯＲＢＡに基づいて分散システムを開発するには、ＵＭＬプロセスに従って少なくとも２つのモデルを定義しなければならない。１つのモデルは、ＩＤＬインターフェースを指定し、もう１つのモデルはその実装を定義するものである。
【０００７】
ソフトウェアワークショップは、２種類のモデルを記述し、ＩＤＬコードおよびこうしたモデルからの実装コードを生成するための解決法を提案している。
【０００８】
しかし、こうしたツールは、ＵＭＬインターフェースモデルを装備しＵＭＬ実装モデルとのリンクを作成するために使用することはできず、２つのモデルは完全に独立したままである。これにより、システムの固有のＣＯＲＢＡ機能を含まない実装コードを生成する必要がある。
【０００９】
分散システムのＩＤＬインターフェースのＵＭＬモデルとこのシステムを実装するＵＭＬモデルとの間のリンクを生成するための存在する唯一の解決法は、
ＵＭＬモデルからインターフェースＩＤＬコードを生成し、
こうしたインターフェースをＯＲＢ（Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ）とコンパイルし、
リバースエンジニアリングフェーズを使用して、生成されたコードから実装のＵＭＬモデルを得ることである。
【００１０】
上記の解決法は、問題に対する部分的な解決法でしかない。なぜならこの解決法は、ＵＭＬモデルだけをリンクするものであって、ＵＭＬインターフェースモデルを装備してこうしたインターフェースに関連する実装コードを生成するためには使用することができないからである。
【００１１】
さらに、この解決法は、生成されたコードから開始されるリバースエンジニアリングフェーズの品質に強く依存する。また、こうしたフェーズを手動で実行することによって良い品質を保証することができるが、それは実際非効率的であり、ソフトウェアワークショップを使用する自動化では、求められる品質が提供されず、得られたモデルに手動のフィードバックが必要とされる。
【００１２】
他の欠点は、この解決法では、インターフェースモデルと実装モデルの間に依存性がないことである。したがって、ＵＭＬモデルのインターフェースにおけるいかなる変更（ささいなものでも）も実装モデルに転送するのが難しい。
【発明の開示】
【課題を解決するための手段】
【００１３】
本発明は、第１に、各インターフェースクラスとその実装クラスの間で示されるＵＭＬ関係を使用して、ＵＭＬ実装モデルをＵＭＬインターフェースモデルから自動的に装備すること、および第２に、このリンクを使用してＣＯＲＢＡ特有の機能を有する実装コードを生成することからなる。
【００１４】
本発明は、サーバアプリケーションの変換および計測（ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）、およびクライアントアプリケーションの変換および計測に適用可能である。
【００１５】
したがって、本発明は、ＣＯＲＢＡインターフェースのＵＭＬモデルとそのクライアント実装との間のリンクを確保するソフトウェア開発ツールにも関する。
【００１６】
少なくとも以下の２つのモデルが、ＵＭＬ言語でＣＯＲＢＡ環境における分散オブジェクトのシステムの開発のために定義されなければならないことをより明確に留意されたい。
【００１７】
インターフェースおよびインターフェースと他の高レベルクラスの関係でアプリケーションが記述される分析モデルと呼ばれるモデルと、
アプリケーションクラス全てが記述される実装モデルと呼ばれるモデルである。多数のテクニカルクラスがこのモデルに追加される。
【００１８】
したがって、本発明の他の特徴により、分析モデルから開始されるＵＭＬ実装モデルとの間のリンクを確立することを提案する。
【００１９】
（ＣＯＲＢＡ２．４仕様に含まれる）「ＣＯＲＢＡ  Ｍｅｓｓａｇｉｎｇ」文書ではクライアントに対してインターフェースを呼び出す４つの異なるモデルが提供されていることも留意されたい。すなわち、
同期（または双方向）呼び出し、
一方向呼び出し、
「ｃａｌｌｂａｃｋ」モデルでの非同期呼び出し、
「ｐｏｌｌｉｎｇ」モデルでの非同期呼び出しである。
【００２０】
非同期呼び出しには、応答を処理するための特定のクラスの実装が必要である。
【００２１】
したがって、本発明により、クラス（またはメソッド）とインターフェースの間の非同期呼び出しに関するＵＭＬ「ｕｓｅ」関係をステレオタイプ化することを提案する。
【００２２】
この「ｕｓｅ」関係に関するＵＭＬラベルは、「ｃａｌｌｂａｃｋ」または「ｐｏｌｌｉｎｇ」であってもよい、この非同期関係の特性を指定する。
【００２３】
したがって、分析モデルから開始する実装モデルが自動的に構成される。以下で分かるように、これは、ＣＯＲＢＡ２．４特有の機能およびＣ＋＋言語に従って、インターフェースからの「ｃａｌｌｂａｃｋ」または「ｐｏｌｌｉｎｇ」と呼ばれるクラスを生成することからなる。また、ＣＯＲＢＡ２．４特有の機能およびＣ＋＋言語に基づく対応するコードも生成される。
【００２４】
したがって、本発明の目的は、ＵＭＬインターフェースオブジェクトを設計し、それらをＩＤＬ言語で生成する手段を含むソフトウェア開発ツールであって、
ＵＭＬ実装オブジェクトを設計し、対応する実装ソースコード（Ｃ＋＋）を生成する手段を含み、
ＵＭＬインターフェースオブジェクトおよびＵＭＬ実装オブジェクトが設計段階のとき（ｌｏｒｓ  ｄｅ）にリンクされることを特徴とする。
【００２５】
本発明の他の特徴によれば、ＵＭＬ実装オブジェクトおよびＵＭＬインターフェースオブジェクトは、各インターフェースクラスと対応する実装クラスとの間に存在するＵＭＬ関係によってリンクされ、このリンクを使用してＣＯＲＢＡ特有の機能をもつ実装コードが生成される。
【００２６】
１つのＵＭＬインターフェースオブジェクトは、分散システムのＩＤＬ（Ｉｎｔｅｒｆａｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  ｌａｎｇｕａｇｅ）インターフェースを指定するモデルであり、他方のオブジェクトは、その実装を定義するモデルである。
【００２７】
このＵＭＬインターフェースオブジェクトは、インターフェースおよびインターフェースと他の高レベルクラスの関係でクライアントアプリケーションが記述される分析モデルであり、他方のオブジェクトは、アプリケーションクラス全てが記述される実装モデルである。
【００２８】
本発明の他の特定の特徴および利点は、図面を参照して、非限定的な例示として提供する以下の説明を読めば明らかになるであろう。
【発明を実施するための最良の形態】
【００２９】
本発明により、各インターフェースクラスとその実装クラスの間で示されるＵＭＬ関係を使用して、図１の参照番号ＭＡで示したＵＭＬインターフェースモデルから開始される、ＵＭＬ実装モデルを自動的に装備することを提案する。このリンクを使用してＣＯＲＢＡ特有の機能を有する実装コードを生成することも提案する。
【００３０】
ＵＭＬモデルのＣＯＲＢＡプロファイル用ＵＭＬのＯＭＧ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ）で定義されるように、ＩＤＬインターフェースは、ステレオタイプの「ＣＯＲＢＡ」インターフェースクラスで記述されなければならない。
【００３１】
我々は、これをインターフェースとそれに対応する実装クラスとの間のＵＭＬ「ｒｅａｌｉｚｅ」リンク（実装リンク）を使用して行う。このリンクは、ＩＤＬインターフェースの記述に関連した実装メソッドを自動的に関連付けるものである。
【００３２】
ＩＤＬインターフェースで定義された動作ごとに、同じ名前および正当なシグネチャを持つメソッドが対応する実装クラスで自動的に生成される。２つのアクセスメソッドが、ＩＤＬインターフェースの属性ごとに実装クラスで定義されて、この属性の値が設定され獲得される。
【００３３】
本発明は、サーバアプリケーションおよびクライアントアプリケーションに等しく適用可能である。
【００３４】
図１は、サーバアプリケーションの例を示す。この図の図表は、分析モデルＭＡから開始する「Ｓｔｒｅａｍ」インターフェースを実装するクラスの変換および計測を示す。
【００３５】
この図で示した特定の例によれば、「Ｓｔｒｅａｍ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ」実装クラスの４つのメソッドおよびそのシグネチャが、各クラスの間に作成されたリンクを自動的に使用して追加されている。
【００３６】
この解決法には、実装クラスコード生成を変更して、ＣＯＲＢＡ特有の機能を考慮することも含まれる。たとえば、生成プログラムは、命名空間、シグネチャ、およびモデルからのＣＯＲＢＡオブジェクトの継承を自動的に管理する。
【００３７】
前の例では、「ｓｔｒｅａｍ」インターフェースがＣＯＲＢＡ「Ｍｅｓｓａｇｉｎｇ」モジュールに属する場合、Ｃ＋＋で生成された「ＳｔｒｅａｍＩｍｐｌｅｍｅｎｔａｔｉｏｎ」クラスは、「：：ＰＯＡ−Ｍｅｓｓａｇｉｎｇ：：Ｓｔｒｅａｍ」クラスを継承する。
【００３８】
前の例のモデルに関する、生成されたＣ＋＋コードは、この説明の付録に記載されている。
【００３９】
本発明について、クライアントアプリケーション用分析モデルＭＡに関しても以下に記載する。クライアントアプリケーション用分析モデルを図２で示す。図３は、クライアントがインターフェースをどのように使用するかを決定するためのこのクライアントアプリケーションの変換および計測を示す。
【００４０】
すでに記載したように、インターフェースおよびインターフェースと他の高レベルクラスとの関係でアプリケーションが記述されるのは分析モデルである。
【００４１】
２つのクラスの間、またはメソッドとクラスの間のＵＭＬ「ｕｓｅ」関係は、メソッド（またはクラスにおけるメソッド）が指示されたクラスを使用することを指す。この指示されたクラスがステレオタイプのＣＯＲＢＡインターフェースの場合、このメソッドはインターフェースを使用する。
【００４２】
したがって、ＵＭＬ「ｕｓｅ」関係で「ａｓｙｎｃｈｒｏｎｏｕｓ」と呼ばれるステレオタイプを追加することによって、このインターフェースが分析モデルで（同期または非同期）どのように使用されるかを定義することを提案する。「ａｓｙｎｃｈｒｏｎｏｕｓ」ステレオタイプは、「ｃａｌｌｂａｃｋ  ｍｏｄｅｌ」または「ｐｏｌｌｉｎｇ  ｍｏｄｅｌ」と呼ばれるＵＭＬラベルとともに使用される。このラベルは、実装モデルがどのように構成されるかを示す。
【００４３】
一方向および双方向呼び出しに関しては、分析モデルと実装モデルＭＩの差はない。Ｃ＋＋生成コードは単に、対応する「ｓｔｕｂ」（対応する要素）の内容を、インターフェースを使用するクラスの本体に追加しなければならない。
【００４４】
たとえば、図２で見ることができるように、分析モデルは、クラス「ＭｙＣｌｉｅｎｔ」のメソッドｍ（）が「ＭｙＩｎｔｅｒｆａｃｅ」と呼ばれるインターフェースを使用していることを示す。このリンク上で、「ａｓｙｎｃｈｒｏｎｏｕｓ」ステレオタイプは「ｃａｌｌｂａｃｋ  ｍｏｄｅｌ」ラベルを使用して、「ＭｙＩｎｔｅｒｆａｃｅ」インターフェースがどのように使用されるかを指定する。
【００４５】
このリンクは、ＵＭＬモデルを自動的に変更し、ＣＯＲＢＡ  Ｍｅｓｓａｇｉｎｇの標準によって定義された対応するメソッドで「ＲｅｐｌｙＨａｎｄｌｅｒ」クラスを生成する手段を提供する。
【００４６】
「ｐｏｌｌｉｎｇ」モデルでの非同期呼び出しの場合、「ｕｓｅ」リンク上に「Ｃｏｒｂａ：ａｍｉ＿ｐｏｌｌｅｒ」ステレオタイプを追加することが提案され、「ｃａｌｌｂａｃｋ」モデルに「Ｃｏｒｂａ：ａｍｉ＿ｃａｌｌｂａｃｋ」ステレオタイプを追加することを提案する。
【００４７】
この情報とともに、ＵＭＬモデルは、実装モデルを変更するのに十分な情報を含む。
【００４８】
クラスは、ＣＯＲＢＡ  Ｍｅｓｓａｇｉｎｇ特有の機能に従って、新規のＵＭＬモデルに含まれなければならない。こうしたクラスは、実装リンクを介してクラスのインターフェースにリンクされて、２つのモデルの間の一貫性が保証されるようになされている。
【００４９】
ステレオタイプの「ａｓｙｎｃｈｒｏｎｏｕｓ」「ｕｓｅ」関係を含む、ステレオタイプの「ＣＯＲＢＡＩｎｔｅｒｆａｃｅ」クラスは、ＩＤＬコードを生成するために、ＩＤＬコンパイラにオプションを追加して、スケルトン、および追加された「Ｍｅｓｓａｇｉｎｇ」モジュールを有する特定の「ｓｔｕｂ」を生成しなければならないことを指定する。
【００５０】
クラスは、「ｎｏｃｏｄｅ」および「ＡＭＩＰｏｌｌｅｒ」または「ＡＭＩＨａｎｄｌｅｒ」ラベルを使用して、Ｃ＋＋コードの生成を行う。
【００５１】
ラベルは、Ｃ＋＋コードの生成に、ＯＭＧによって発行された「ＣＯＲＢＡ  Ｍｅｓｓａｇｉｎｇ  ｍａｐｐｉｎｇ  ｆｏｒ  Ｃ＋＋」文書で指定されたルールおよび構文が考慮されるように使用される。
【００５２】
付録
Ｃｌａｓｓ  ＳｔｒｅａｍＩｍｐｌａｎｔａｔｉｏｎ：ｐｕｂｌｉｃ：：ＰＯＡ−Ｍｅｓｓａｇｉｎｇ：：Ｓｔｒｅａｍ
｛
ｖｏｉｄ  ｒｅａｄ（
ｃｈａｒ＊＿ｏｕｔ  ｍｓｇ，
Ｍｅｓｓａｇｉｎｇ：：Ｓｔｒｅａｍ＿ｏｕｔ  ｒｅｐｌｙＳｔｒｅａｍ）
｛．．．｝；
ｖｏｉｄ  ｗｒｉｔｅ（
ｃｏｎｓｔ  ｃｈａｒ＊  ｍｓｇ，
｛．．．｝；
ｖｏｉｄ＊  ｃｈａｎｎｅｌ（）
｛．．．｝；
ｖｏｉｄ  ｃｈａｎｎｅｌ（
ｃｏｎｓｔ  ｃｈａｒ＊  ｖａｌｕｅ，
｛．．．｝；
｝；
【図面の簡単な説明】
【００５３】
【図１】分析モデルから開始する、インターフェースを実装するクラスの変換および計測のための開発ツールを示す図である。
【図２】クライアントアプリケーションの分析モデルを示す概略図である。
【図３】図２で示したクライアントアプリケーションの変換および計測のための開発ツールを示す概略図である。
【図１】
2005527039.tif 000003
【図２】
2005527039.tif 000004
【図３】
2005527039.tif 000005
【国際調査報告】
2005527039.tif 000006
2005527039.tif 000007
2005527039.tif 000008
2005527039.tif 000009