JP2009245441A - コンポーネント基盤環境下で拡張されたメタデータを利用したソフトウェア開発方法及びその開発システム - Google Patents

Abstract

【課題】コンポーネントの再使用率を高め、コンポーネント間メッセージ流れをコンポーネントコード修正なしでも柔軟に調節できる方法を提供する。
【解決手段】コンポーネント基盤のソフトウェアの開発技術に関し、特に、特定コンポーネント開発プラットフォームが提供するコンポーネントを階層的に組み立ててソフトウェアを開発できるアクティブバインディング技術に関する。コンポーネントの依存契約定義を含む拡張メタデータを用いてコンポーネントの新しい型を示し、これにより、開発者がコンポーネントを多階層構造及び／又は分散構造形態で組み立てることができるようになる。
【選択図】図１

Description

本発明は、コンポーネント基盤ソフトウェア開発（CBD、Component-Based SoftwareDevelopment）技術に関し、さらに詳細には、複数の開発者により独立的に開発され、市場でバイナリコード形態で流通されるコンポーネントを組み立ててソフトウェアを開発する方法、ソフトウェアコンポーネントの新しいメタデータフォーマット、これを具現化するための開発環境システムに関する。

さらに詳細には、本発明は、従来のコンポーネントが提供するサービス被呼び出し規格に関するサーバ側（Server-Side）のメタデータ（Metadata）のみでなく、下位コンポーネントに対するサービス呼び出し規格に関するクライアント側（Client-Side）メタデータを含むようにコンポーネントを具現化する方法を提供する。

また、本発明は、コンポーネント組み立てにおいて、独立的に開発されたサーバとクライアントコンポーネントとが持たざるをえない相互異質的な呼び出し/被呼び出しシグネチャー（Signature）を整合するために、グルーコンポーネントテンプレートコード（Glue Component TemplateCode）を自動生成する方法及びその具現手段を提供し、このようにして自動生成されたグルーコンポーネントを介してサーバコンポーネントとクライアントコンポーネントとの間にメッセージを伝達するようにすることにより、柔軟なメッセージ流れ制御（MessageFlow Control）を可能にするコンポーネント組み立て方法、手段及び具現システムに関する。

最近になって、組み込みシステム（Embedded System）及びユビキタスコンピューティング（Ubiquitous Computing）時代の渡来により、多様なソフトウェアの需要が急増し、また既に開発されたソフトウェアに対する変更要求が頻繁になるにつれて、ユーザの要求事項を容易に反映し迅速にソフトウェア開発が可能なソフトウェア生産技術が要求されている。

ところが、ソフトウェア開発に多く用いられていた構造的技法、情報工学基盤の開発方法、またはオブジェクト指向（Object-Oriented）ソフトウェア生産技術などのような、従来のソフトウェア生産技術がソフトウェア開発の生産性向上において限界を見せることによって、従来の方式とは異なり、各機能別に部品の役割を果たすコンポーネントをまず開発し、これらを組み立ててソフトウェアを開発する方法であるコンポーネント基盤のソフトウェア開発（ＣＢＤ）技術が最近登場して、速く拡散されている。

すなわち、現代経営が要求する情報システムは、その複雑度と規模がますます大きくなっており、競争の深化によりシステムの迅速な構築（Time-To-Market）と、変更及び拡張の容易性（Flexibility）、構築費用の低減などの必要性がさらに高くなった。これに対する最適な代案として登場したコンポーネント基盤ソフトウェア開発方法論は、分割征服の原理とオブジェクト指向開発の利点とを継承して、システムを構成する単位業務の機能と関連データとを括って小さな片に分割するものの、これをコンポーネントの標準規格を満足するように部品化して再使用を可能にし、ソフトウェア開発を組み立ての概念に発展させた。

大規模企業用ソフトウェアは、分散システムとして運営され、階層的デザイン（Layered Design）の概念で開発されるが、通常的に、大規模企業用ソフトウェアは、大部分３階層（3-Tier）あるいは多階層（N-Tier）構造で開発される。一般に、階層的設計では、上位層にプレゼンテーション階層、中間層にビジネスロジック階層、終端にデータサービス階層を配置する。

ところが、終端のコンポーネントを除外した大部分のコンポーネントは、下位階層のコンポーネントと結合されており、基本的に下位階層コンポーネントのサービスに基づいて、自分のサービスを上位階層のコンポーネントに提供する。この時、下位コンポーネントに対するサービス呼び出しは、静的にコーディング（Static Coding）されたままコンパイルされて、ブラックボックス（Black Box-Binary Code）形態で配布される。

ここで、静的コーディング（Static Coding）とは、アーリーバインディング（Early Binding）とも称するが、サーバコンポーネントが規定しているインタフェース識別子とメソッド規格定義（普通、「シグネチャー」と呼ぶ）に応じてクライアントコンポーネントを開発することを言う。ところが、上述した静的コーディング方式のコンポーネント基盤ソフトウェア開発技術は、以下のような理由でその技術的限界がある。

既に、開発されて発売されているバイナリ形態（ソースコードが隠されてコンパイルされたブラックボックス形態）のコンポーネントは、互いに組み立てて、すなわちこれらを再使用して、設計者が目指す機能を行うソフトウェアを組み立て開発するためには、上位層のコンポーネント（サービスを呼び出すコンポーネント、すなわち「クライアント」となる）と下位層コンポーネント（サービスを提供するコンポーネント、「サーバ」となる）との間にコンポーネント及びインタフェース（あるいはクラス）識別子（ID：Identifier）とメソッドシグネチャーとが互いに整合されなければならない。ここで、シグネチャーとは、メソッド（Method）の名称、返還値、媒介変数タイプ及び順序などを含む。

ハードウェアとは異なり、ソフトウェアは必要とする部品（すなわち、コンポーネントの数）が多くて多様なので（ほぼ無限）、予めその規格を定めることが不可能であり、互いに異なる開発者により独立的に開発されたコンポーネント間の識別子とメソッドシグネチャーとの整合問題を解決するためには、コンポーネントソースコードを修正するか、手動でグルーコードを開発しなければならないという負担が生じる。

さらに、現在のコンポーネント技術は、配布時に提供されるメタデータに下位コンポーネントが提供するサービス呼び出しに関するクライアント側の情報を含んでいないため、再使用しようとするコンポーネントが他のコンポーネントに依存する場合、そのコンポーネントを開発する当時に作成されたシステムの詳細な設計情報を求めて参照しなければならない。

さらに、従来の技術に係るコンポーネント基盤開発技術は、コンポーネント間のメッセージ流れが高く結合され、静的にコード化されているため、ビジネスプロセスのうち、１つのコンポーネントを削除するか、追加する場合、プロセス内の他のコンポーネントに多くの影響を及ぼす。また、組み立てによる他のソフトウェア開発におけるメッセージ流れは、極めて新しいものであるから、このような静的な結合は、コンポーネントの再使用性を顕著に低下させる。

さらに、現在ソフトウェア開発者等に提供されるコンポーネントプラットフォーム（Component Platform）技術は、ＣＯＲＢＡ、ＣＯＭ＋、ＥＪＢ及びドットネット（.NET）などがあり、これらのプラットフォーム基盤のコンポーネントは、使用契約（UsageContract）のインタフェースメタデータであって、自分が提供するサービス（すなわち、複数のメソッド）に関する定義（Signature）だけを提供し、下位コンポーネントのメソッド呼び出しに対する情報を全く提供しないので、特定のバイナリ形態のコンポーネントが上位コンポーネントの呼び出しに対する演算処理の途中で、他のプロジェクトで独立的に開発された下位コンポーネントにサービスを要請するように組み立てることは基本的に不可能である。

すなわち、独立的に開発された複数のバイナリコンポーネントは、多階層依存関係（Multi-Layered Dependency）構造形態で組み立てることがコンポーネント基盤開発方法論が目指す目標であるにも拘わらず、従来の技術は、これを基本的に不可能にしている。

このような理由により、今までのソフトウェア開発者等は、簡単かつ独立的なサービスを提供するＧＵＩ（Graphic User Interface）用のコンポーネントだけを主に再使用しており、中間階層であるビジネス論理領域のコンポーネントの再使用率は、極めて低いのが実情である。

すなわち、他のコンポーネントサービスに依存しないＡｃｔｉｖｅＸ Ｃｏｎｔｒｏｌ、ＪａｖａＢｅａｎｓなどの簡単なＧＵＩ用コンポーネントが主に再使用されており、コンポーネント基盤ソフトウェア開発方法により設計され具現されたビジネス階層のコンポーネントは、ほとんど再使用されていない。

上述した従来の技術に係るコンポーネント基盤のソフトウェア開発方法の技術的限界点を解決するために、いくつかの改善案が提案されたことがある。すなわち、従来の技術が有する問題を解決するために、全てのコンポーネント間のメッセージ流れを中央で管理する方案が提示された。その代表例には、ワークフロー（Workflow）を使用するコンポーネント組み立て方法がある。ワークフロー方式は、全てのコンポーネントを他のコンポーネントに依存しない独立的なコンポーネントでデザインし、ワークフローを利用してコンポーネント間のメッセージ流れを中央で管理する。

しかし、ワークフロー方式でも相変らず任意のコンポーネントが他のコンポーネントを直接呼び出すことができないため、コンポーネントのサービス（メソッド）は、単位業務処理に必要な全ての情報を媒介変数として受け取って、自主的に結果を出すようにデザインされなければならない。

これは、ソフトウェア工学が追求してきた分割征服及び構造的方法ではないので、設計方法から非常に不自然であり、一般性と再使用性とが低下する巨大なコンポーネントの開発という結果を招く。

また、ワークフロー方式では、コンポーネント間の全てのメッセージ流れがワークフローを経て伝達されるため、コンポーネント間直接呼び出しに比べてネットワークとシステムとに過重な負担（Overhead）を与え、ワークフローエンジンに異常が生じる場合、全体システムの動作に影響を及ぼす。

さらに、米国アーバイン所在のカリフォルニア大学（University of California at Irvine）では、メッセージ基盤コンポーネント組み立て方法であるＣ２スタイルを提案したことがあるが、Ｃ２スタイルでは、組み立てのためのラッパー（Wrapper）コードに媒介変数仲裁論理（MediationLogic）と共に接続コンポーネントの稼動順序調節論理（Flow Control Logic）がハードコーディングされなければならないので、組み立て過程が複雑であり、柔軟な変更が困難であるという短所がある。

すなわち、Ｃ２スタイルは、コンポーネントがコネクタ（Connectors）により接続されて、通信規則に応じて互いにメッセージを交換することによって、コンポーネントを接続（組み立て）する構造を有するようになるが、Ｃ２スタイルコンポーネント間の通信は、非同期的なサービス要請（Request）と通知（Notification）メッセージ伝達により行なわれる。この時、各メッセージは、コネクタに接続された全てのコンポーネントにブロードキャスト（Broadcasting）され、各コンポーネントのラッパーコードに定義されているメッセージ規則に応じて、受け取ったメッセージを処理するか無視するかを決定する。

さらに、従来の技術に係るＣ２スタイルの場合、ソフトウェアシステムを構成するコンポーネントとこれらの相互作用関係及びコンポーネントとコネクタとの合成規則を上位抽象化水準で明示するために、ＡＤＬ（Architecture Description Language）をコンポーネント定義言語（IDN: ComponentInterfaceDefinition Notation）とアーキテクチャー定義言語（ADN: Architecture Definition Notation）の２つの表記形式に区分して定義しなければならないとういう面倒さがある。

なによりも、従来の技術に係るＣ２スタイルの場合、再使用しようとするコンポーネント間の階層的依存関係を具現化するためには、ホワイトボックス（White Box、ソースコード修正）接近方法が不回避なので、コンポーネント再使用性を顕著に低下させる。

また、従来の技術に係るＣ２スタイルを採用して、コンパイルされたバイナリ形態の中間階層コンポーネントを再使用して組み立てようとする場合、コンポーネントが下位コンポーネントのどんなメソッド呼び出しをどの時点に必要とするかに対する情報（Metadata）がないため、階層的依存構造を具現化することが根本的に不可能である。

したがって、Ｃ２スタイルでバイナリコンポーネントを組み立てるためには、コンポーネントがサービス処理途中に、下位コンポーネントサービスを要請する代わりに、サービス処理に必要な全ての情報を初めから媒介変数として受け取るようにコンポーネントを再設計し、ラッパーコードでは、先に下位コンポーネントを呼び出して必要な情報を受け取って、該当コンポーネント（Inner Component）メソッド呼び出しの際、媒介変数として伝達した後、リターン値を上位コンポーネントに伝達する流れ調節論理（FlowControl Logic）を具現しなければならない。

このような接近法は、現在ソフトウェア工学者等が追求している構造的設計技法の採用を基本的に不可能にする要素として作用し、さらにＣ２スタイルを採用する場合、その組み立てプロセスが複雑であって、エラーの可能性が高いと共に、これに対するデバッグ（Debugging）が困難であり、多くの時間と費用とを消費するようにするという短所がある。

さらに、従来の技術に係るＣ２スタイルは、コンポーネント間の全ての相互作用が常にコネクタを介したブロードキャスティング及び通信規則による検査過程を経て生じるため、無数に多い不必要な割込みとメッセージ識別処理とを誘発させて、システム負担を加重させるという短所がある。

したがって、本発明は、上記した従来の技術の問題点を解決するためになされたものであって、クライアント側メタデータ生成技術、グルーコードでコンポーネント結合を仲裁する技術、グルーコードを自動生成する技術を活用して、コンポーネント間結合（組み立て）に厳格に要求されるシグネチャーの構文的及び意味論的整合問題を克服することによって、コンポーネントの再使用率を高め、自然なコンポーネント基盤開発方法により開発されたコンポーネント間メッセージ流れをコンポーネントコード修正なしでも柔軟に調節できる方法を提供するのに第１の目的がある。

本発明の第２の目的は、前記第１の目的に付加して、ソフトウェア設計において馴染んでいるＵＭＬ（Unified Modeling Language）の順次図（Sequence Diagram）形態でコンポーネント組み立てを可能にするグルーテンプレートコード生成技術及び多階層構造の組み立て方法を提供することにある。

本発明の第３の目的は、前記第１及び第２の目的に付加して、再使用性が画期的に改善されたコンポーネント生成及び組み立て技術、ビジネスロジック変化にともなうメンテナンスを容易にするソフトウェア開発環境及び方法を提供することにある。

本発明の第４の目的は、上記の目的に付加して、コンポーネントの分散配置及び遠隔ホストを可能にし、組み立てられたコンポーネントを統合テストしモニターリングすることを可能にするソフトウェア開発環境、ソフトウェア管理システム及び方法を提供することにある。

本発明の第５の目的は、上記の目的に付加して、コンポーネントのサイズを適当なサイズに粒子化して（Fine-Grained）、コンポーネントの再使用性を向上させ得るコンポーネント基盤のソフトウェア開発システム及びその方法を提供することにある。

本発明の第６目的は、上記の目的に付加して、バイナリコンポーネントを多階層構造で具現可能にし、ブロードキャスト及び非同期メッセージへの変換などの追加負担（Overhead）のない組み立て方法を提供し、開発過程で別の文書化作業を必要とせず、低廉かつ迅速なメンテナンスを可能にするコンポーネント基盤のソフトウェア開発システム及びその方法を提供することにある。

上記の目的を達成するため、本発明は、コンポーネント基盤開発方法のコンポーネント具現と組み立てにおいて、コンポーネント開発者から呼び出そうとする仮想の（Virtual）下位コンポーネント（実際には、グルーコンポーネント）が提供しなければならないサービスのシグネチャーと注解とを任意に受け取る処理手段と、
受け取ったシグネチャーに基づいて、仮想の下位コンポーネント（実際には、グルーコンポーネント）のサービスを動的にバインディングし（Late Binding）呼び出すヘルパー関数（Helper Function）コードを生成する処理手段と、
下位サービスの呼び出し部分に新しく作られたヘルパー関数の呼び出しコードを生成する処理手段と、
後のメッセージ流れ制御及び組み立ての際、呼び出しサービスを選択し、グルーコンポーネントのテンプレートコードを自動生成するのに利用されるクライアント側メタデータを生成する処理手段と、
テスト用仮グルーコンポーネントを作って、独立的にコンポーネント機能をテストする処理手段からなることを特徴とするコンポーネント具現方法を提供し、ＧＵＩツールを利用して組み立てるコンポーネントを選択して図面に配置する処理手段と、
ＧＵＩツールを利用して図面に配置されたコンポーネントの中からクライアントコンポーネントとサーバコンポーネントとを選択して、コンポーネント間メッセージ流れを自由に設定する処理手段と、
グルーコンポーネントのテンプレートコードを自動生成し、仲裁コードを受け取る処理手段と、
グルーコードをコンパイルして、グルーコンポーネントを生成する処理手段などからなることを特徴とするコンポーネント組み立て方法である。

本発明は、互いに異なるプロジェクトと開発者等により独立的に開発されて、互いに異なるシグネチャーを有している多くのコンポーネントを互いに接続して再使用するにおいて、サーバ側インタフェース定義情報のみでなく、クライアント側の定義情報をメタデータに含めることによって、多階層構造のソフトウェア開発、非順次的組み立て、並列開発などを可能にする。

また、本発明に係るコンポーネント基盤のソフトウェア開発方法は、クライアント側インタフェースメタデータを各々のコンポーネントが含んでいるので、スタブコンポーネントテンプレートを自動生成させることができ、ここに適切な値を代入してコンポーネント機能をテストすることが可能になるので、下位コンポーネントのメソッド呼び出しに対して、開発者が自分に便利な方式で定義し開発しても、下位コンポーネントを呼び出すのに問題が発じないため、ソフトウェア開発の生産性を向上させるという効果がある。

本発明によって具現されたコンポーネント開発道具は、コンポーネント組み立てのためのグルーコードテンプレートを自動生成させることができ、組み立てられなければならないサーバ及びクライアント側の異質的コンポーネントの間に媒介変数の文法的及び意味的不一致を仲裁する論理を挿入することによって、コンポーネントの再使用性を大きく高め、コンポーネント組み立て過程を半自動化できる。さらに、本発明は、従来の技術とは異なり、コンポーネント間の多層構造組み立てを可能にするので、設計上のコンポーネント結合関係そのままを自然に採用して、コンポーネント組み立て過程を行うことができるようにする。

また、本発明によって開発されたコンポーネント基盤のソフトウェアは、コンポーネント間にメソッド呼び出しを直接接続して同期的に処理するので、不必要なシステム負荷またはネットワーク負荷を軽減するという効果がある。さらに、本発明によって具現されたコンポーネント開発道具は、システム要求事項分析及びシステムの概念的デザイン時に用いられるシーケンス図形態の直観的コンポーネント組み立て道具を提供するので、複雑かつ面倒なＡＤＬ定義またはソースコード作成なしでもコンポーネントをより容易かつ低コストで組み立て、メンテナンスすることを可能にする。

さらに、本発明に係るコンポーネント基盤のソフトウェア開発技術をマイクロソフト社のドットネット（.NET）開発プラットフォームに採用する場合、マイクロソフト社の技術が提供するカスタムアトリビュート（Custom Attribute）、リフレクション（Reflection）、コードドーム（CodeDom）などの先端技術を応用してコンポーネントのメタデータを拡張し、グルーコードテンプレートを非常に效率的に自動生成することが容易となる。また、組み立て道具をＶＳＩＰパッケージ形態で開発することによって、ビジュアルスタジオ（VisualStudio）ユーザ経験が採用され、順次図形態のコンポーネント構造編集機能、インテリセンス（IntelliSense）が採用されるグルーコード編集、ソースレベルデバッグなどの先端機能を提供することが可能である。

現在のコンポーネント流通市場では、主にＧＵＩ用コンポーネントが流通されており、ビジネス論理を具現したコンポーネントは、その種類も多様でないだけでなく、階層構造形態の組み立て技術の不在によって、極めて粗粒（Coarse-Grained）形態の一般性が落ちるコンポーネントだけ存在することに対し、本発明に係るアクティブバインディング技術は、効率的かつ独立的なコンポーネント開発とテスト機能とを提供し、設計と一致する多階層組み立てを可能にするクライアント側インタフェース定義を提供するので、適切な一般性（Generality）を有する小規模の（Finer-Grained）再使用可能なビジネス論理領域コンポーネントの開発を奨励し、これにともなう流通市場を創出できるようにする効果がある。

また、本発明に係るアクティブバインディング技術は、バイナリコンポーネントを多階層構造で組み立てることができるようにすることによって、設計と具現とを一致させ、ローカルで動作するように作られたコンポーネントをネットワーク上に分散配置し、遠隔で動作できるようにする遠隔ホスト機能を提供する。したがって、第３者が作ったバイナリコンポーネントを市場で低コストで購入して、大規模多階層分散システムを構築することが可能となる。

さらに、本発明に係るアクティブバインディング技術が提供する順次図（Sequence Diagram）形態の編集機は、コンポーネント組み立てを時系列のメソッド呼び出し単位で細かく視角化し、グルーコード当たり単一のメソッド呼び出し仲裁だけを担当するようにして、組み立て作業を精密かつ簡単にする。また、グルーコードテンプレートを自動生成し、インテリセンス（IntelliSense）とソース水準のデバッグ機能とを提供して、ソフトウェア開発生産性を極大化する。

本発明に係るアクティブバインディング技術をマイクロソフト社の最新統合開発道具であるビジュアルスタジオドットネット（Visual Studio .NET）に完全に統合し開発すれば、ユーザのビジュアルスタジオ経験をそのまま採用することによって、容易かつ速く本発明に係るコンポーネント開発及び組み立て技術を採用することも可能である。

本発明に係るアクティブバインディング技術は、メソッド水準の細かな組み立て構造の視角化と組み立てに必要な充分の水準のメタデータを提供することによって、別の文書化作業なしでも開発者ではない第３者によるシステム変更を可能にする。

したがって、システムユーザは、従来とは異なり、文書化費用と独占的メンテナンス契約による費用を低減できる。

本発明に係るコンポーネント基盤のソフトウェア開発方法を採用するためになされたコンポーネント間のメッセージ伝達構造を示した図である。 従来の技術によってコンポーネントを組み立てる結合方法を示した図である。 本発明によってコンポーネントを組み立てる結合方法とを示した図である。 本発明に係るコンポーネント基盤のソフトウェア開発のために、コンポーネントを具現及び組み立てる一処理のフローチャートである。 本発明によって下位コンポーネントが提供するサービス呼び出しに関するクライアント側メタデータを含むコンポーネントの具現方法の一実施の形態を示す一処理のフローチャートである。 本発明によってコンポーネントを組み立てる方法の良好な実施の形態を示した図である。 コンポーネント間メッセージ伝達を仲裁するグルーコンポーネントを、本発明によって自動生成する方法の一実施の形態を示す一処理のフローチャートである。 本発明によって提供された開発道具において、コンポーネントを具現化する一実施の形態を図１２まで順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを具現化する一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを具現化する一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを具現化する一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを具現化する一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を図２４まで順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。 本発明によって提供された開発道具において、コンポーネントを組み立てる一実施の形態を順次に示した図である。

本発明は、従来概念のインタフェースをサーバ側インタフェース（Server-Side Interface）と命名し、下位コンポーネントに対する依存契約（Dependency Contract）をクライアント側インタフェース（Client-SideInterface）と命名することを特徴とする。また、本発明は、独立した開発者等が開発して市場に発売されている多様なコンポーネントを互いに組み立てるのに必要な規格に関する内容（これをメタデータと称する）を定義して、クライアント側インタフェースに含めることを特徴とする。

このように、本発明によってサーバ側だけでなくクライアント側インタフェース情報を含むようにメタデータを拡張すれば、組み立て道具が接続する両側コンポーネントのメタデータを動的に読ん込んで（Reflection）、グルーコードテンプレートを自動に生成することが可能となる。

本発明に係るコンポーネント組み立て技術は、バイナリコンポーネントの多階層構造の組み立てを可能にするだけでなく、異質的コンポーネント間の媒介変数に存在する構文的（Syntactic）または意味論的（Semantic）不整合を仲裁する論理（Mediation Logic）を本発明に係るグルーコードに挿入することによって、コンポーネントの再使用率を極大化できる。

下位コンポーネントに依存して、自分のサービスを完結する中間階層のコンポーネントを開発する時、従来には、下位コンポーネントの識別子とインタフェース定義を知っていなければならなかったため、開発の順序が必要であったが、本発明は、下位コンポーネントの情報を使用する代わりに、任意に新しい識別子と定義とを生成してクライアント側のインタフェースとし、組み立て道具がこのメタデータを読み込んで、該当識別子と定義とを有するグルーコードを生成するようにしている。

その結果、下位コンポーネントなしで非順次（Non-Procedural）方式で中間階層のコンポーネント開発及びテストが可能になって、コンポーネント開発生産性を増大し得る。本発明の詳細な説明では、本発明のメタデータ拡張と組み立て技法とに対して、下位コンポーネントのインタフェースに受動的に依存する従来の結合方式と対比させて、アクティブバインディング（ActiveBinding）と命名する。

本発明に係るコンポーネント組み立て技術は、コンポーネントを他のコンポーネントに独立的に開発可能にし、柔軟なコンポーネント組み立てのために必要な全ての情報をメタデータとして含むように従来のメタデータを拡張し、このメタデータを利用して、自動にグルーテンプレートを生成し、グルーメカニズムを採用してコンポーネント間メッセージ流れを柔軟に調節するコンポーネント具現及び組み立て装置を提供する。

本発明は、コンポーネントの組み立てのための仲裁コンポーネントであるグルーコンポーネントのテンプレートを自動に生成することによって、コンポーネントの組み立てにかかる時間と費用とを顕著に低減させ、他のコンポーネントに従属的なコンポーネントの再使用率を極に向上させ、コンポーネントメッセージ流れ制御を柔軟にし、コンポーネント間の整合度の厳密性を緩和させることによって、新しいシステムの開発及びメンテナンスを非常に容易にする。

上述した目的、特徴及び長所は、添付した図面と関連した次の詳細な説明により、さらに明確になるであろう。以下、添付した図面を参照して本発明に係る好ましい一実施の形態を詳細に説明する。

各々の図は、次のような内容を示している。図１は、本発明に係るコンポーネント基盤のソフトウェア開発方法を採用するためになされたコンポーネント間のメッセージ伝達構造を示した図である。

図１に示されているように、クライアントコンポーネントがサーバコンポーネントを直接インスタンス化し、メソッドを呼び出す代わりに、クライアント側メタデータとサーバ側メタデータとを利用して、２つのコンポーネントの連動を仲裁するグルーコンポーネントを生成した後、これにより独立的に開発されコンパイルされたバイナリコンポーネント３１０、３２０を組み立て（柔軟なメッセージ流れ制御、連動、メソッド呼び出し等）する。

グルーコンポーネント３３０が２つのコンポーネント３１０、３２０間メッセージ流れを仲裁するようにして、クライアントコンポーネント３１０とサーバコンポーネント３２０とは、呼び出し/被呼び出し規格が異なっても互いに呼び出しし呼び出されることができる。このような動的なメッセージ流れ制御により、コンポーネント開発及び組み立ての効率性を増加させる。

図２及び図３は、それぞれ従来の技術によってコンポーネントを組み立てる結合方法と、本発明によってコンポーネントを組み立てる結合方法を示した図である。図２（従来の技術）に示されているように、従来のコンポーネント基盤ソフトウェア開発では、クライアントコンポーネントＡ４１０がサーバコンポーネントＢ４２０のサービス（メソッド）をｂ１（図面符号４２１）というインタフェースを介して呼び出しているならば、その呼び出し内容がクライアントコンポーネントＡ４１０内に静的にコード化されコンパイルされて、バイナリ形態で配布される。

すなわち、コンポーネント間の統合によるメッセージ流れが高く結合されており、静的にコード化されているので、変更するためには、必ずコンポーネントソースコードの修正が必要となり、再使用性も悪くなる。また、全体システムのうち、１つのコンポーネントサービスを削除したり追加したりする場合、プロセス内の他のコンポーネントに多くの影響を及ぼすようになる。このような変更の負荷は、コンポーネントを利用して新しい製品を開発するためのタイムトゥマーケット（Time-To-Market）をなすことができない原因になる。

これに対し、図３に示した本発明に係るコンポーネント組み立て概念は、次の通りである。

クライアントコンポーネントＡ３１０がサーバコンポーネントＢ３２０のメソッドｂ１（）３２２を呼び出さなければならない場合、クライアントコンポーネントＡ３１０の内部にサーバコンポーネントＢ３２０のメソッドｂ１（）３２２を直接呼び出すようにコーディングする代わりに、後に作られるグルーコンポーネントＸ３３０のメソッドｘ１（）を呼び出すようにコーディングし、それに対する情報（コンポーネント識別子＜コンポーネントＸ＞、インタフェース＜あるいはクラス＞識別子、メソッド＜ｘ１（）＞シグネチャー）をクライアントコンポーネントが含むようにクライアント側メタデータを拡張する。

２つのコンポーネントを連動させるために、クライアントコンポーネントＡ３１０のクライアント側メタデータを読み込んで、その情報（コンポーネント識別子＜コンポーネントＸ＞、インタフェース＜あるいはクラス＞識別子、メソッド＜ｘ１（）＞シグネチャー）と一致するグルーコンポーネント３３０を作る。また、サーバコンポーネントＢ３２０のサーバ側メタデータを読み込むことによって生成されたグルーコンポーネントのメソッドｘ１（）がサーバコンポーネントＢ３２０のメソッドｂ１（）３２２を呼び出し、その結果値を自分の結果値に返還するコードを挿入する。これで、クライアントコンポーネントＡ３１０のソースコード修正なしで独立的に定義され開発されたサーバコンポーネントＢ３２０のメソッドを呼び出すことができる。

本発明によるコンポーネント組み立て方法は、互いに異なるプロジェクトにおいて独立的に開発されて、呼び出し/被呼び出し規格の異なるコンポーネント間のメソッド呼び出し及び被呼び出しが可能になって、コンポーネント間のメッセージ流れが非常に柔軟になる。グルーコンポーネント３３０に仲裁コードを挿入することによって、メソッドシグネチャーが完壁に一致しないコンポーネントもカスタマイジングして接続でき、コンポーネント間メッセージ流れの生成、変更及び削除作業を非常に容易に行なうことができるようになって、全体システムの構築及びメンテナンスにともなう負荷を顕著に低減する。

図４は、本発明に係るコンポーネント基盤のソフトウェア開発のために、コンポーネントを具現及び組み立てる一処理のフローチャートであって、その一実施の形態を示した図である。

図４に示されているように、本発明に係るソフトウェアの開発は、仮想の下位コンポーネント（実際にはグルーコンポーネント）の識別子とメソッドシグネチャーとを生成して、この情報を含むようにコンポーネントメタデータを拡張し、これにともなう呼び出しコードを挿入して、コンポーネントを具現化するステップ（ステップＳ１）と、コンポーネント組み立てステップ（ステップＳ２）との２ステップからなり、このうち、コンポーネント具現ステップ（ステップＳ１）は、コンポーネントを相互作用する他のコンポーネントに独立的に具現するために、下位コンポーネントから提供されなければならないサービスのシグネチャーと注解とを受け取るステップ（ステップＳ１１）と、受け取った情報に基づいて、グルーコンポーネントのサービスを動的にバインディングし呼び出すヘルパー関数コードを生成するステップ（ステップＳ１２）と、下位サービス呼び出し部分にヘルパー関数呼び出しコードを挿入するステップ（ステップＳ１３）、下位コンポーネント呼び出しに関する情報をメタデータとして生成するステップ（ステップＳ１４）、テスト用仮グルーコンポーネントを作って、独立的なコンポーネント機能テストを行なうステップ（ステップＳ１５）などの５ステップからなっている。

また、コンポーネント組み立てステップ（ステップＳ２）は、ＧＵＩツールを利用して組み立てるコンポーネントを選択して図面に配置するステップ（ステップＳ２１）と、図面に配置されたコンポーネント間メッセージ流れを設定するステップ（ステップＳ２２）と、２つのコンポーネントを接続するグルーコンポーネントのテンプレートを自動に生成して仲裁コードを挿入するステップ（ステップＳ２３）と、グルーコードをコンパイルしてグルーコンポーネントを生成するステップ（ステップＳ２４）などの４ステップからなる。

すなわち、本発明は、全てのコンポーネントを根本的に異なるコンポーネントと独立的に具現（ステップＳ１１〜ステップＳ１３）し、機能をテスト（ステップＳ１５）し得るようにし、独立的なコンポーネント間の柔軟なメッセージ流れのために、従来のメタデータを拡張して自分が必要とするサービスに対する情報もメタデータに含む（ステップＳ１４）ことによって、コンポーネントを具現化することを特徴とする。

また、コンポーネントメッセージ流れをＧＵＩ環境で柔軟にカスタマイジング（ステップＳ２１、ステップＳ２２）し、コンポーネント組み立ての際、呼び出し者コンポーネントと被呼び出し者コンポーネントのメタデータを利用して、両者のメッセージ流れを接続するグルーコンポーネントのテンプレートを自動生成し、コンポーネントメッセージ流れの無欠性を合わせる仲裁コードを編集（ステップＳ２３）し、グルーコードをコンパイルして、グルーコンポーネントを生成（ステップＳ２４）することにより、コンポーネント組み立てエラーを最小化しながらも迅速なコンポーネントの組み立てを可能にする。

図５は、本発明によって仮想の下位コンポーネント（実際にはグルーコンポーネント）が提供しなければならないサービス（メソッド）に関するクライアント側メタデータを含むコンポーネント具現方法の一実施の形態を示す一処理のフローチャートである。この過程は、従来のコンポーネント基盤開発方法論の問題点の根本原因であるコンポーネント間メッセージ流れの強い結合度を緩和させるために、コンポーネント具現時に実際の下位コンポーネントをオブジェクト化（Instantiate）し、メソッドを呼び出すコードを挿入する代わりに、仮想の下位コンポーネント（実際にはグルーコンポーネント）が提供しなければならないメソッドシグネチャーを開発者が任意に（主導的に）定義して呼び出すコードを挿入し、この情報をメタデータ形態でコンポーネントに含めることによって、コンポーネントを独立的に開発するようにし、コンポーネントの再使用性を向上させるステップである。

図５に示されているように、コンポーネントを開発する途中で（ステップＳ１１１）、下位コンポーネントのサービス呼び出しが要求される時点で（ステップＳ１１２）、実際の下位コンポーネントの代わりに、仮想の下位コンポーネント（実際にはグルーコンポーネント）が提供しなければならないサービス、すなわちメソッドに対して任意の名称と媒介変数、返還値及び注解情報を開発者から受け取る（ステップＳ１１３）。

次に、上記の情報に基づいて、開発中であるコンポーネントの該当クラス内に受け取ったシグネチャーを満足するメンバー関数であるヘルパー関数を定義し、ヘルパー関数内に仮想の下位コンポーネントのサービスを動的バインディング方法で呼び出すコード（仮想の下位コンポーネント及びインタフェースの識別子定義及びオブジェクト生成、受け取ったシグネチャーを満足するメソッド呼び出し）を自動生成する（ステップＳ１２）。

一方、仮想の下位コンポーネントメソッドを呼び出す部分を新しく生成したヘルパー関数呼び出しに替えるコードを自動生成する過程（ステップＳ１３）により、他のコンポーネントとの従属性を根本的に除去し具現する。上記のように呼び出そうとする下位コンポーネントのサービス呼び出しが必要な時、シグネチャーと注解とを開発者が任意に定義して、実際の下位コンポーネントに対する依存性を排除したまま処理する一連の過程をウィザード（Wizard）を利用して自動に処理するように具現すれば、下位コンポーネント呼び出し部分のエラーが最小化され、より容易に複数ステップの過程が処理され得る。

また、図５に示されているように、本発明によって開発されたコンポーネントを後に組み立ててソフトウェアを作る時、コンポーネント間連動を仲裁するグルーコンポーネントを生成するのに必要な情報をコンポーネントメタデータとして生成して、コンポーネント内部に含めることによって、従来のメタデータを拡張させる（ステップＳ１４）。このように拡張されたメタデータ情報は、自分が提供するサービスに対するメタデータだけでなく自分が提供されなければならない下位コンポーネントのサービスに対するメタデータも自ら含むようにする部分であって、コンポーネント組み立て時に自分がいかなるサービスを提供されなければならないかに対する定義を提供する。

ここで、クライアント側メタデータは、ソースコードコンパイル時にソースコードバイナリ以外のリソース部分や、ドットネットの場合、ユーザアトリビュート（Custom Attribute）部分などを利用して、コンポーネントの内部に生成する。コンポーネントが自体的に持っているクライアント側メタデータを拡張させることによって、グルーメカニズムを使用して２つのコンポーネントを接続する仲裁者（Mediator）を自動に生成（ステップＳ２３）する。

また、コンポーネント具現時に生成されたクライアント側メタデータをそのままグルーコンポーネントテンプレートを作るのに使用するので、システム組み立て時に生成される数多くのグルーコンポーネントと該当クラスあるいはインタフェースの識別子を自動に生成することによって、開発者が一々固有な識別子を作る面倒さを除去する。

本発明の良好な実施の形態として、開発しているコンポーネントを単独でエラーテスト及び機能テストを行なう（ステップＳ１５）ために、サーバコンポーネントとの接続を担当するグルーコンポーネントを一時的に代替するスタブ（Stub）コンポーネントを生成する。

コンポーネント単位のテストのために、コンポーネントが含んでいるクライアント側メタデータを使用して、自分が呼び出すサーバコンポーネント識別子、インタフェース識別子、メソッドシグネチャーなどを満足する試験用簡易（スタブ）コンポーネントのテンプレートを自動に生成し（ステップＳ１５１）、開発者がサーバコンポーネントから提供されたいサービスの返還値などを編集し（ステップＳ１５２）、コンパイルしてスタブコンポーネントを開発し、スタブコンポーネントを呼び出すことによって、開発したコンポーネントの独立的なエラー及び機能テストを行う（ステップＳ１５３）。

スタブコンポーネントとリフレクション（Reflection）などを利用した動的バインディング（Dynamic Blinding）技法を利用して、コンポーネントのエラー及び機能検査を行なうことにより、根本的に全てのコンポーネントを他のコンポーネントに独立的に開発し、機能テストを行うことができるようになる。

図６は、本発明によってコンポーネントを組み立てる方法の良好な実施の形態を示した図である。図６に示されたコンポーネント組み立て過程は、コンポーネントメッセージ流れをグラフィック環境下でカスタマイジングするステップ（ステップＳ２１及びステップＳ２２）と、グルーコンポーネントテンプレートを自動生成してコンポーネント仲裁コードを編集するステップ（ステップＳ２３）と、グルーコードをコンパイルしてグルーコンポーネントを生成するステップ（ステップＳ２４）とからなり、このステップを必要なだけ繰り返すことによって、ソフトウェアシステムを具現化する。

本発明に係る良好な実施の形態として、各々のコンポーネントを単一機能を行う１つの命令文のように取り扱い、コンポーネントの実行順序を柔軟に調節するために、グルーコンポーネントの生成前にコンポーネント間のメッセージ流れをカスタマイジングする段階を経る。システム設計時に使用する順次図（Sequence Diagram）と類似したＧＵＩツールを使用して、組み立てるコンポーネントのインスタンスを図面に配置し（ステップＳ２１）、これらのうち、接続するクライアントコンポーネントとサーバコンポーネントとを選択して、コンポーネント間メッセージ流れを設定する（ステップＳ２２）。コンポーネントメッセージ流れの柔軟なカスタマイジングのために、順次図ＧＵＩツールを使用することは、コンポーネント配置と時系列とに応じるメッセージ流れを自由に設定できるという大きな長所がある。

また、本発明では、２つのコンポーネントを接続するために、クライアント側のメタデータとサーバコンポーネント側のインタフェースとに該当するメタデータを使用して、グルーコンポーネントテンプレートを自動生成し、コンポーネント間のシグネチャー及び意味論的不一致解消のための仲裁コードを挿入し（ステップＳ２３）、生成及び挿入されたグルーコードをコンパイルすることで、グルーコンポーネントを生成する（ステップＳ２４）。

本発明が開示するこういう組み立て過程を経ることによって、大規模システムを一度に組み立てずに、分割征服方法を採用して複数の順次図を利用して組み立て、各々を独立的にテストした後、全体的にシステムを統合できる。

窮極的には、コンポーネントを単一機能を行う命令文のように取り扱い、フローチャートを使用してコンポーネントの実行順序を柔軟に調節し、グルーコンポーネントを容易に具現するようにすることにより、大規模システムを精巧ながらもより迅速に開発できるようになる。

図７は、本発明に係るコンポーネント間メッセージ伝達を仲裁するグルーコンポーネントを本発明に係る自動生成方法の一実施の形態で示す一処理のフローチャートである。

図７に示されているように、２つのコンポーネント間の特定サービス（メソッド呼び出し/被呼び出し）を互いに接続するために、クライアントコンポーネントの下位コンポーネントのサービス呼び出しに関連したクライアント側メタデータを調査して（ステップＳ２３１１）、開発者にクライアントコンポーネントが呼び出すサービスリストを見せ、接続を希望するサービス呼び出しを選択する過程（ステップＳ２３１２）とサーバコンポーネントのインタフェースに該当するサーバ側メタデータを調査（ステップＳ２３２１）して、開発者にサーバコンポーネントが提供するサービスリストを見せ、これにより呼び出されるサービスを選択（ステップＳ２３２２）するようにする過程を経る。

また、選択されたサービス、すなわちクライアントコンポーネントのメソッド呼び出しに関するクライアント側メタデータとサーバコンポーネントとが提供するサービスのメタデータを利用して、グルーコンポーネントテンプレートコードを自動生成する（ステップＳ２３３）。この時、クライアント側メタデータに含まれたコンポーネント識別子とインタフェース（あるいはクラス）識別子とメソッドシグネチャーなどの情報を読み込んで、この情報と一致するグルーコンポーネントとインタフェース（あるいはクラス）、そして該当メソッドを具現化するソースコードを自動に生成することによって、グルーコンポーネントのテンプレートを自動に生成する。

その後、自動に生成されたグルーコンポーネントテンプレートコードに開発者が簡単な仲裁コードを挿入することによって、コンポーネント間シグネチャーの文法的整合問題と媒介変数の意味論的不一致とを解決して、２つのコンポーネントが正確に連動できるように、無欠性（Integrity）を保障する仲裁コードを挿入する（ステップＳ２３４）。この時、クライアント側及びサーバ側メタデータに含まれた注解とシグネチャーとをグルーコンポーネントテンプレート内に挿入することによって、開発者が仲裁コードを作成する過程を非常に容易にする。また、グルーコンポーネントテンプレートを作る時、コンポーネント間にやりとりするメッセージ内容（媒介変数と返還値）とサービス呼び出しに必要な時間をロギング（Logging）するコードとを自動に挿入し、ロギングされたデータを調査することによって、システム統合テストを行なうことができる。

また、本発明の良好な実施の形態として、コンポーネント組み立てと組み立てテストに関する全ての作業とをＧＵＩ環境で行い、グルーコンポーネントのテンプレートソースコードを自動生成することによって、コンポーネント間のメッセージ流れを容易に生成して変更でき、複雑かつ時間が多くかかるコンポーネント組み立て及びテスト過程を非常に直観化、単純化して、速く新しいシステムを構築し、容易にメンテナンスできるようにする。

以下では、図８及び図１３を参照して本発明によってソフトウェア開発機能を提供する開発環境（Development Environment）の一実施の形態を詳述する。以下の図８及び図１３では、好ましい実施の形態として、マイクロソフト社のドットネット（.Net）開発道具であるビジュアルスタジオドットネット（VisualStudio .NET）に本発明に係る開発機能を統合した開発環境を例に挙げて説明しているが、必ずこれに限定してはならず、他の開発プラットフォムに拡張適用がもちろん可能である。

図８ないし図１２は、本発明によって提供されたＧＵＩでコンポーネントを具現化する一実施の形態を順序的に示した図である。図８に示されているように、ソフトウェア開発者がコンポーネントを具現化するコードを生成する途中、下位コンポーネントサービスが必要であると判断されれば（すなわち、下位コンポーネントが提供するメソッドを呼び出そうとすれば）、サービスが必要な部分に「カーソル」７１１を位置させる。ここで、メソッドとは、上位コンポーネントが呼び出すことができるように、下位コンポーネントが接近を許容する関数を意味する。次に、プログラム開発者は、開発道具上段のメニュ「アクティブ呼び出し７１２（Active Call；クライアント側コード及びメタデータ生成）」をクリックする。

その後、本発明に係る開発環境は、仮想の下位コンポーネント（実際にはグルーコンポーネント）をオブジェクト化し、メソッドを呼び出すのに用いるメソッドシグネチャーを受け取るダイアログウィンドウ７１３を表示する。

図９は、本発明に係るソフトウェア開発環境が提供するクライアント側メソッド呼び出しコードとメタデータとを生成するためのダイアログウィンドウの一実施の形態を示した図である。図９に示されているように、開発者は、ダイアログウィンドウ７１３に後ほど組み立てられる下位コンポーネントが提供するサービスのシグネチャーと無関係に、開発者が望むサービスのシグネチャーを入力するようになる。図９を詳細に見れば、返還形式（Return Type）、メソッド名称、メソッド注解、限定者、媒介変数形式及び名称などが入力される。

図９に示されたダイアログウィンドウ７１３を「ＯＫ」ボタンをクリックして閉じれば、本発明に係る開発環境は、開発者から受け取ったメソッドシグネチャー情報と共に、仮想の下位コンポーネント（グルーコンポーネント）識別子を作ってクライアントメタデータとして生成する。また、開発環境は、これに基づいて、グルーコンポーネントを動的にオブジェクト化してメソッドを呼び出すコードを生成し、このコードを関数化する。

図１０に示されているように、本発明に係る開発環境は、図８の図面符号７１１において、カーソルを位置させた位置に図９の図面符号７１３で生成した関数を呼び出すコードを生成する。

一方、図１１に示されているように、本発明に係る開発道具は、開発中であるコンポーネントが下位コンポーネントとエラーなしで組み立てられて動作できるかをテストするために、下位コンポーネントをシミュレートする（Simulate）試験用簡易（スタブ：Stub）コンポーネント生成メニュボタン７１６を提供できる。

次に、開発者が図１１のメニュボタン７１６をクリックすれば、本発明に係る開発環境は、図１０の図面符号７１５で生成されたクライアント側メタデータを読み込んで、同じ識別子（ＩＤ）とシグネチャーとを有する仮想の下位コンポーネント（Stub Component）を生成するテンプレートコードとプロジェクトファイルとを作る。

一方、図１１の図面符号７１８は、本発明によってソリューション探索ウィンドウを示した図であって、スタブコンポーネントウィザード７１７（テストのために開発環境が作った仮想の下位コンポーネント）を作るためのプロジェクトファイルが示されている。

図１２は、図１１のスタブコンポーネントウィザード７１７が生成したスタブコンポーネントコードテンプレートを示した図であって、開発者は、図１２に示したコードを修正して、開発中であるコンポーネント、すなわち下位コンポーネントが提供するサービスに依存するコンポーネントを下位コンポーネントなしでも開発しテストできるようになる。

以上、図８ないし図１２の説明過程を経て開発しテストされたコンポーネントは、上位コンポーネントに提供するサービス（メソッド）に対したサーバ側メタデータ（コンポーネントアーキテクチャー標準＜Component Architecture Standard＞技術が提供）のみでなく、開発者が任意に定めた仮想の下位コンポーネント（実際にはグルーコンポーネント）が提供しなければならないサービスを規定したクライアント側メタデータを組み込む（Embed）ようになる。

図１３ないし図１７は、本発明によってコンポーネントを組み立てる過程を説明する開発道具ウィンドウを示した図である。図１３に示されているように、開発者は、コンポーネント組み立てのために、新しいコンポーネント組み立てプロジェクト８１１を生成する。すなわち、開発者は、ダイアログウィンドウでコンポーネント組み立てプロジェクト８１１を選択する。次に、図１３のダイアログボックスで「ＯＫ」ボタンをクリックすれば、本発明に係る開発道具は、組み立てプロジェクトのためのファイルを生成し、順次図形態のコンポーネント組み立て編集ウィンドウ８１２を表示するようになる。

図１４において、図面符号８１３は、生成されたプロジェクトのファイルを表示するソリューション探索ウィンドウを示している。開発者は、ソリューション探索ウィンドウ８１３で「コンポーネント」ノードを選択し（マウス右側のボタンを押して）、コンテクストメニュにより組み立てプロジェクトに組み立てるコンポーネントを含める。

図１５は、上述した図１３及び図１４の過程で組み立てプロジェクトに含まれたコンポーネントを示している図である。図１６に示されているように、開発道具で順次図を示すために提供される組み立て道具ウィンドウ８１４を示しており、ＵＭＬオブジェクトライフライン８１５（Object Life Line）が示されている。

すなわち、開発者が組み立て道具ウィンドウ８１４でコンポーネント道具をクリックしたまま、マウスカーソルを編集機ウィンドウに移してボタンを置けば（ドラッグアンドドロップ動作）、開発道具は、順次図のオブジェクトライフラインを表示する。次に、図１７に示されているように、開発者は、コンテクストメニュを利用して、プロジェクトに含まれたコンポーネントのうち、いずれかを選択して、オブジェクトライフラインとマッピングさせることができる。

図１８は、コンポーネントがマッピングされたオブジェクトライフラインの属性を示すダイアログウィンドウを示す図であって、開発道具は、オブジェクトライフラインにマッピングされたコンポーネントのメタデータを読み込んで属性ウィンドウ８１６に表示する。すなわち、図１８に示された属性ウィンドウ８１６には、サーバコンポーネント側メタデータとクライアント側メタデータとを読み込んで、各メソッドのシグネチャー情報を表示する。

図１９は、本発明の良好な実施の形態によって、開発者がグラフィック編集ウィンドウに順次図を完成したことを示している。すなわち、各々のオブジェクトライフライン８１５にコンポーネントをマッピングさせ、上位コンポーネントが下位コンポーネントのメソッドを呼び出すことを表示するために、ＵＭＬメッセージ８１７にコンポーネントを接続する。本発明の良好な実施の形態によって、図１９のＵＭＬメッセージ８１７は、２つのコンポーネント間の識別子とシグネチャーとの不一致を解消し、メソッドの呼び出し/被呼び出しを仲裁するグルーコンポーネントとマッピングされる。

図２０は、開発者編集機でメッセージを選択し、その属性を表示するダイアログウィンドウを載せた形状を示した図である。図２０のメッセージ属性ダイアログウィンドウ８２２は、このメッセージに接続された上位コンポーネントのクライアント側メタデータ８１８を読み出して、上位コンポーネントが呼び出すメソッドを表示し、下位コンポーネントのサーバ側メタデータ８１９を読み込んで、下位コンポーネントが提供するサービスメソッドを表示する。

開発者が接続しようとする上位コンポーネントの呼び出しメソッドと、下位コンポーネント被呼び出しメソッドとを選択して「ＯＫ」ボタンをクリックしてダイアログウィンドウを閉じれば、開発環境は、２つのコンポーネント間のメソッド呼び出し/被呼び出しを接続するグルーコンポーネントを作るためのコードとプロジェクトとを生成する。図２０には、上位コンポーネントが呼び出すメソッドのうち、接続しなければならないメソッドを選択するためのコンボボックス８２０と、下位コンポーネントの被呼び出しメソッドのうち、接続されるメソッドを選択するためのコンボボックス８２１が示されている。

図２１は、開発環境がグルーコンポーネントを作るためのプロジェクトとグルーコードテンプレートとを生成した形状を示している図であって、図２０において、開発者が上位コンポーネント呼び出しメソッドと下位コンポーネント被呼び出しメソッドとを選択して「ＯＫ」ボタンをクリックすれば、開発環境は、上位コンポーネントのクライアント側メタデータを読み込んで、同じ識別子を有するグルーコンポーネントを生成し、開発者が選択した呼び出しメソッドシグネチャーと同じシグネチャーを有するサーバメソッドを具現したグルーコードを生成する。次に、開発環境はもまた下位コンポーネントのサーバ側メタデータを読み込んで、上記の過程で生成されたグルーコードのメソッド内部に開発者が選択した被呼び出しメソッドシグネチャーを注解で表示する。

また、図２１に示されているように、開発環境が２つのコンポーネントのメタデータを読み込んで自動生成したグルーコード８２３と上位コンポーネントのクライアント側メタデータとのうち、識別子部分を読み込んで、それと同じ識別子を有するグルーコンポーネントとクラスを具現化するために生成したコード８２４とが示されている。また、上位コンポーネントのクライアント側メタデータのうち、開発者が選択した呼び出しメソッドのシグネチャーと同じシグネチャーを有するグルーコンポーネントのサービスメソッド８２５を具現化するために生成されたコードが示されている。また、図２１には、開発環境が生成したグルーコンポーネントプロジェクト８２６が示されている。

図２２には、開発者が順次図に示した全てのコンポーネントオブジェクトのうち、２つのＵＭＬメッセージ８２７、８２８を生成した形状と、開発環境がこれに対応する２つのグルーコンポーネントプロジェクト８２９、８３０を生成した形状を示している。

図２３に示されているように、開発者は、クライアントコンポーネントとサーバコンポーネントとの間のメソッドシグネチャーの構文的/意味論的（Syntactic/Semantic）不一致を解消するために、開発環境が生成したグルーコードを編集できるが、開発環境は、開発者が仲裁コードを容易に作ることができるように、下位コンポーネントのサーバ側メタデータを読み込んで、被呼び出しメソッドのシグネチャーを注解で表示した形状８３１を示している。

また、図２３は、開発者が２つのメソッド間のシグネチャー不一致を解消するために挿入した仲裁コード８３２の一例を示している。

図２４は、開発者が「ビルド（Build）」メニュをクリックすれば、開発環境が編集されたグルーコードをコンパイルしてグルーコンポーネントを作る過程を示した図であって、上述した過程を経てグルーコンポーネントを作ってから、上位コンポーネントがグルーコンポーネントを呼び出すようになり、グルーコンポーネントが下位コンポーネントを呼び出すようになる。

図２５は、開発ツールがグルーコードをコンパイルしてグルーコンポーネントを作った結果を示した図である。そのような過程を経てグルーコンポーネントが作られると、上位コンポーネントがグルーコンポーネントを呼び出すようになり、グルーコンポーネントが下位コンポーネントを呼び出すようになる。

このような方法により、開発者は、コンポーネントのソースコードや下位コンポーネント呼び出しに対して詳細に記録した文書なしでも独立的に開発され、呼び出しと被呼び出しメソッドシグネチャーとが正確に一致しないバイナリ形態の（コンパイルされた）コンポーネントを非常に速くて容易に組み立てて連動させることができる。

上述した内容は、後述する発明の特許請求の範囲の理解のために、本発明の特徴と技術的長所を多少幅広く説明した。本発明の特許請求の範囲を構成する付加的な特徴と長所は、以下で詳細に説明される。開示された本発明の概念と特定実施の形態は、本発明と類似の目的を行なうための異なる構造の設計や修正の見本として直ちに使用され得ることが当該技術分野における熟練された人々により認識されなければならない。

また、本発明で開示した発明概念と実施の形態は、本発明の同一目的を行うために、他の構造に修正するかまたは設計の基礎として、当該技術分野における熟練された人々により使用され得るものである。

なお、本発明は、上記の実施の形態に限定されるものではなく、本発明に係る技術的思想から逸脱しない範囲内で様々な変更が可能であり、それらも本発明の技術的範囲に属する。

Claims (7)

1. コンポーネント基盤ソフトウェア開発のライフサイクルのうち、コンポーネント組み立てにおいて、
   （ａ）グラフィック道具を利用して、選択されたコンポーネントを前記グラフィック道具画面に配置するプロセスと、
   （ｂ）前記グラフィック道具を利用して、クライアントコンポーネントとサーバコンポーネントとを選択して互いに接続することによって、コンポーネント間の呼び出し関係を設定するプロセスと、
   （ｃ）前記ステップ（ｂ）の呼び出し関係に対応するグルーコンポーネントテンプレートを生成し、前記クライアントコンポーネントが呼び出すサービスシグネチャーと前記サーバコンポーネントが提供する被呼び出しサービスシグネチャーとが異なるか、意味論的に不一致する場合、これを整合させる仲裁コードを挿入してグルーコンポーネントを生成するプロセスと、
   （ｄ）前記ステップ（ａ）からステップ（ｃ）までを繰り返して、必要なだけのグルーコンポーネントを生成するプロセスと
   を備え、
   前記プロセス（ｄ）で生成された複数のグルーコンポーネントと前記クライアント及びサーバコンポーネントを配置して、ソフトウェアを具現化するようにする環境を提供することを特徴とするソフトウェア開発環境。
2. 前記プロセス（ａ）及びプロセス（ｂ）は、順次図（Sequence Diagram）によってコンポーネントオブジェクトの配置と時系列に応じるメッセージ流れを設定するように提供することを特徴とする請求項１に記載のソフトウェア開発環境。
3. 前記プロセス（ａ）及びプロセス（ｂ）は、複数の順次図を利用して組み立てることによって、それぞれを独立的にテストできるように提供することを特徴とする請求項１または２に記載のソフトウェア開発環境。
4. 前記プロセス（ｃ）は、
   （ｃ１）開発者にクライアントコンポーネントが呼び出すサービスリストを見せ、そのうち、いずれかを選択させるプロセスと、
   （ｃ２）開発者にサーバコンポーネントが提供するサービスリストを見せ、呼び出されるサービスを選択させるプロセスと、
   （ｃ３）選択されたクライアントとサーバ側サービスとに対するメタデータを利用して、グルーコンポーネントを作るためのテンプレートコードを生成するプロセスと、
   （ｃ４）生成されたグルーコンポーネントテンプレートコードに開発者が簡単な仲裁コードを挿入することによって、コンポーネント間のシグネチャー整合問題と媒介変数の意味論的不一致とを解決するプロセスと
   を含むことを特徴とする請求項１に記載のソフトウェア開発環境。
5. コンポーネントに含まれたクライアント側メタデータを調査して、そのコンポーネントが呼び出すサービスのシグネチャーと注解リストとを開発者に見せるプロセスをさらに含むことを特徴とする請求項４に記載のソフトウェア開発環境。
6. 前記プロセス（ｃ３）は、
   クライアントとサーバ側注解とシグネチャーとをグルーコンポーネントテンプレート中に挿入して、開発者にとって仲裁コードを容易に作成するようにすることを特徴とする請求項４に記載のソフトウェア開発環境。
7. 前記プロセス（ｃ３）は、媒介変数値と返還値及びサービス呼び出しに必要な時間などを記録する（Logging）コードを挿入して、記録されたデータをテストに利用することを特徴とする請求項４に記載のソフトウェア開発環境。

Images