JP2011507061A

JP2011507061A - 仕様及びセマンティック分析によって選択された既製のコンポーネントからアプリケーションを自動的に構築するための装置及び方法

Info

Publication number: JP2011507061A
Application number: JP2010536401A
Authority: JP
Inventors: ラルベ，フィリップ
Original assignee: アルカテル−ルーセント
Priority date: 2007-12-07
Filing date: 2008-11-18
Publication date: 2011-03-03
Anticipated expiration: 2028-11-18
Also published as: TWI446263B; KR101584972B1; EP2071452A1; CN101452392A; CN101452392B; AU2008333378B2; WO2009071440A1; MX2010006118A; IL205865A; AU2008333378A1; US20090150853A1; JP5319694B2; BRPI0820905A2; RU2010128102A; IL205865A0; RU2495480C2; KR20100091209A; US8453105B2; TW200939121A

Abstract

仕様（ＡＳ）及びソフトウェアコンポーネントからアプリケーションを構築するための装置（Ｄ）であって、（ｉ）セマンティックソフトウェアコンポーネントを格納するための格納手段（ＳＭ）であって、セマンティックソフトウェアコンポーネントが、このソフトウェアコンポーネントが実行することができる各パブリック操作を定義するための少なくとも１つの適切な用語を備えるセマンティック記述に関連付けられたソフトウェアコンポーネントから成る、格納手段（ＳＭ）、（ii）構築すべきアプリケーションを記述する仕様（ＡＳ）を受信するたびに、仕様のテキストから基本の要件、及びこれらの基本の要件の間のリンクを抽出するために、この仕様（ＡＳ）のセマンティック分析を行い、これらのリンクが「仕様の全体的な構造」を定義し、次いで基本の要件ごとに、それが備える適切な用語を抽出し、基本の要件ごとに、その抽出された適切な用語に基づいて「この基本の要件のセマンティクス」を表す「セマンティック記述」を構築し、次いで格納手段（ＳＭ）にアクセスして、抽出された基本の要件ごとに、どのコンポーネントがこの抽出された基本の要件をカバーすることができるかを決定するように構成された分析手段（ＡＭ）、及び（iii）前記仕様の前記全体的な構造に従って、前記決定されたソフトウェアコンポーネントをアセンブルして、前記アプリケーション（ＡＰ）を構築するための処理手段（ＰＭ）を備える。

Description

本発明はアプリケーションの設計に関し、より正確には、既製のソフトウェアコンポーネントからアプリケーションを構築するための方法及び装置に関する。

オブジェクト指向及びコンポーネントベースのアプリケーション開発の範囲で参照として使用される容認された定義に従って、「設計」という用語は、ここでは、コードより上の論理レベルにおいて、このアプリケーションをどのように実施するかを説明するアプリケーションの段階を意味する。設計において、アプリケーションの必要な機能的及び品質的要件を満たすために、戦略的及び戦術的な決定が行われる。例えばＧｒａｄｙＢｏｏｃｈの本「Ｏｂｊｅｃｔ−ＯｒｉｅｎｔｅｄＡｎａｌｙｓｉｓａｎｄＤｅｓｉｇｎｗｉｔｈＡｐｐｌｉｃａｔｉｏｎｓ」、３ｒｄＥｄｉｔｉｏｎ−Ｃａｓｅｄ、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ（２００７）、ＩＳＢＮ９７８０２０１８９５５１３においてなされている説明によれば、この段階の結果は、設計レベルのモデル、静的ビュー、状態機械ビュー、及び相互作用ビューによって表される。設計の活動によってアプリケーションのアーキテクチャがもたらされ、これは、ソフトウェアコンポーネントへのその分解、これらのソフトウェアコンポーネント間の接続、相互作用機構、及びアプリケーションの設計を知らせる案内原理を含めて、このアプリケーションの組織的な構造である。

ＧｒａｄｙＢｏｏｃｈの本「Ｏｂｊｅｃｔ−ＯｒｉｅｎｔｅｄＡｎａｌｙｓｉｓａｎｄＤｅｓｉｇｎｗｉｔｈＡｐｐｌｉｃａｔｉｏｎｓ」、３ｒｄＥｄｉｔｉｏｎ−Ｃａｓｅｄ、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ（２００７）、ＩＳＢＮ９７８０２０１８９５５１３

多くの著者は（ソフトウェア）コンポーネントベースのアプリケーションの構築を案内するためのいくつかの方法を記載しているが、これらの方法には、主に次の２つの欠点がある。これらの方法は、完全に手動式であり、正しいコンポーネントを見つけ、アセンブルするプロセスは、構築すべきアプリケーションの仕様から直接には導出されず、この仕様は、アプリケーションがカバーしなければならない機能的及び非機能的な要件を記述する。

本発明の目的は、アプリケーション仕様のセマンティック分析によって、及びそのアプリケーション設計（即ちソリューションのアーキテクチャ）をアプリケーション仕様のテキストで表される要件間の関係（即ち問題のアーキテクチャ）から導出することができると考えることによって、既製のソフトウェアコンポーネントからアプリケーションを自動的に構築するための新しい方法及び対応する装置を提案することである。

このために、本発明は、仕様及び（「既製の」）ソフトウェアコンポーネントからアプリケーションを構築するための方法を提供し、構築すべきアプリケーションを記述する仕様を受信するたびに、
・仕様のテキストから基本の要件（elementary requirement）、及びこれらの基本の要件間のリンクを抽出するために、この仕様のセマンティック分析を行うステップであって、これらのリンクの組が以下「仕様の全体的な構造」と呼ばれる、ステップ、次いで
・基本の要件ごとに、それが備える適切な用語を抽出し、基本の要件ごとに、その抽出された適切な用語に基づいて「この基本の要件のセマンティクス」を表す「セマンティック記述」を構築するステップ、次いで
・各コンポーネントが「セマンティックソフトウェアコンポーネント」として登録され、記述される（これは、各コンポーネントが、このソフトウェアコンポーネントが実行することができる各パブリック操作を定義するために、少なくとも１つの適切な用語を備える「セマンティック記述」に関連付けられることを意味する）少なくとも１つのコンポーネントリポジトリにアクセスして、抽出された基本の要件ごとに、この基本の要件のセマンティクスとコンポーネントのセマンティック記述とを比較することによって、どのコンポーネントが前記抽出された基本の要件をカバーすることができるかを決定するステップ、及び
・仕様の全体的な構造に従って、これらの決定されたソフトウェアコンポーネントを最終的にアセンブルして、アプリケーションを構築するステップ
から成る。

そのため、セマンティック記述を基本の要件及びソフトウェアコンポーネントに関連付けることができ、
・基本の要件のセマンティック記述が決定され、基本の要件自体のテキスト、即ち、基本の要件の表現を構成するセンテンスに関連付けられ、
・以下で詳しく説明されるように、ソフトウェアコンポーネントのセマンティック記述が決定され、このコンポーネントが実行することができるパブリック操作に関連付けられる。

本発明による方法は、別々に考えられる、又は結合される追加の特徴を含むことができ、とりわけ、
・ソフトウェアコンポーネントのセマンティック記述のうちの少なくともいくつかは、ｉ）ソフトウェアコンポーネントが実行することができる操作の目的、ｉｉ）操作の目的及びこの操作の入力／出力パラメータを記述する用語が定義されるドメインを指定する少なくとも１つのドメイン識別子、及びｉｉｉ）これらの入力／出力パラメータに関連付けられる適切な用語及び／又は特定のメタデータを備えることができ、
・抽出された基本の要件ごとに、そのセマンティック記述と格納されたソフトウェアコンポーネントのそれぞれのセマンティック記述との間の意味的な距離を決定することができ、次いで、最小の意味的な距離に対応する格納されたソフトウェアコンポーネントを選択することができ、従って、この選択されたソフトウェアコンポーネントが基本の要件を実施するためのものであり、
・以下「ｓｙｎ−ｕｐｌｅｔ」と呼ばれる、例えば同義語など、単語の一次的なｎ−ｕｐｌｅｔを、基本の要件の各適切な用語に関連付けることができ、次いでこのｓｙｎ−ｕｐｌｅｔが以下「ｒｅｑ−ｕｐｌｅｔ」と呼ばれ、同じ方法で、ｓｙｎ−ｕｐｌｅｔを各ソフトウェアコンポーネントの各パブリック操作の目的の各適切な用語に関連付けることもでき、次いでこのｓｙｎ−ｕｐｌｅｔが以下「ｃｏｍｐ−ｕｐｌｅｔ」と呼ばれ、これらのｒｅｑ−ｕｐｌｅｔのそれぞれをこれらのｃｏｍｐ−ｕｐｌｅｔのそれぞれと比較して、各基本の要件と各格納されたソフトウェアコンポーネントとの間の意味的な距離を決定することができ、
・各ｒｅｑ−ｕｐｌｅｔ及び各ｃｏｍｐ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定することができ、基本の要件ごとに、例えば「ｓｅｍ−ｕｐｌｅｔ」と呼ばれ、ｒｅｑ−ｕｐｌｅｔのそれぞれとｃｏｍｐ−ｕｐｌｅｔのそれぞれとの間の意味的な近さを表す二次的なｎ−ｕｐｌｅｔを構築することができ、各二次的なｎ−ｕｐｌｅｔが意味的な距離を定義し、次いで、最小の意味的な距離を定義する二次的なｎ−ｕｐｌｅｔに対応する格納されたソフトウェアコンポーネントを選択することができ、
・アプリケーションの構造を最適化するために、抽出された基本の要件に対応する選択された格納されたソフトウェアコンポーネント間の仕様の全体的な構造を定義するものと同じ適切なリンクを確立することができ、
・仕様のこの全体的な構造を決定するために、基本の要件の各対のｒｅｑ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定することができ、基本の要件ごとに、そのｒｅｑ−ｕｐｌｅｔと他の基本の要件のそれぞれとの間の意味的な近さを備える「ｓｅｍ−ｕｐｌｅｔ」と呼ばれる二次的なｎ−ｕｐｌｅｔを構築することができ、各ｓｅｍ−ｕｐｌｅｔが意味的な距離を定義し、次いで、それらのｓｅｍ−ｕｐｌｅｔの値が最大であるとき、２つの別個の基本の要件間の適切なリンクを確立することができる。

また、本発明は仕様及びソフトウェアコンポーネントからアプリケーションを構築し、
・セマンティックソフトウェアコンポーネントを格納するための格納手段であって、セマンティックソフトウェアコンポーネントのそれぞれが、このソフトウェアコンポーネントが実行することができる各パブリック操作を定義するための少なくとも１つの適切な用語を備えるセマンティック記述に関連付けられたソフトウェアコンポーネントから成る、格納手段、
・構築すべきアプリケーションを記述する仕様が受信されるたびに、ｉ）仕様のテキストから基本の要件、及びこれらの基本の要件の間のリンクを抽出するために、この仕様のセマンティック分析を行い、これらのリンクの組が以下「仕様の全体的な構造」と呼ばれ、次いでｉｉ）基本の要件ごとに、それが備える適切な用語を抽出し、基本の要件ごとに、その抽出された適切な用語に基づいて「この基本の要件のセマンティクス」を表す「セマンティック記述」を構築し、次いでｉｉｉ）格納手段にアクセスして、抽出された基本の要件ごとに、この基本の要件のセマンティクスとコンポーネントのセマンティック記述とを比較することによって、どのコンポーネントがこの抽出された基本の要件をカバーすることができるかを決定（選択）するように構成された分析手段、及び
・仕様の全体的な構造に従って、決定されたソフトウェアコンポーネントをアセンブルして、アプリケーションを構築するための処理手段
を備える装置も提供する。

本発明による装置は、別々に考えられる、又は結合される追加の特徴を含むことができ、とりわけ、
・分析手段を、抽出された基本の要件ごとに、そのセマンティック記述と格納されたソフトウェアコンポーネントのそれぞれのセマンティック記述との間の意味的な距離を決定し、次いで、最小の意味的な距離に対応する格納されたソフトウェアコンポーネントを選択するように構成することができ、従って、この選択されたソフトウェアコンポーネントが基本の要件を実施するためのものであり、
・分析手段を、以下「ｓｙｎ−ｕｐｌｅｔ」と呼ばれる、例えば同義語など、単語の一次的なｎ−ｕｐｌｅｔを、基本の要件の各適切な用語に関連付け、次いでこのｓｙｎ−ｕｐｌｅｔが以下「ｒｅｑ−ｕｐｌｅｔ」と呼ばれ、これらのｒｅｑ−ｕｐｌｅｔのそれぞれを各ｃｏｍｐ−ｕｐｌｅｔ（各ソフトウェアコンポーネントの各パブリック操作の目的の各適切な用語に関連付けられるｓｙｎ−ｕｐｌｅｔ）と比較して、各基本の要件と各格納されたソフトウェアコンポーネントとの間の意味的な距離を決定するように構成することができ、
・分析手段を、ｉ）各ｒｅｑ−ｕｐｌｅｔ及び各ｃｏｍｐ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定し、ｉｉ）基本の要件ごとに、例えば「ｓｅｍ−ｕｐｌｅｔ」と呼ばれ、ｒｅｑ−ｕｐｌｅｔのそれぞれとｃｏｍｐ−ｕｐｌｅｔのそれぞれとの間の意味的な近さを表す二次的なｎ−ｕｐｌｅｔを構築し、各二次的なｎ−ｕｐｌｅｔが意味的な距離を定義し、ｉｉｉ）最小の意味的な距離を定義する二次的なｎ−ｕｐｌｅｔに対応する格納されたソフトウェアコンポーネントを選択するように構成することができ、
・処理手段を、アプリケーションの構造を最適化するために、抽出された基本の要件に対応する選択された格納されたソフトウェアコンポーネント間の仕様の全体的な構造を定義するものと同じ適切なリンクを確立するように構成することができ、
・全体的な構造を決定するために、分析手段を、ｉ）基本の要件の各対のｒｅｑ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定し、ｉｉ）基本の要件ごとに、そのｒｅｑ−ｕｐｌｅｔと他の基本の要件のそれぞれとの間の意味的な近さを備える二次的なｎ−ｕｐｌｅｔ（又は「ｓｅｍ−ｕｐｌｅｔ」）を構築し、各ｓｅｍ−ｕｐｌｅｔが意味的な距離を定義し、次いで、それらのｓｅｍ−ｕｐｌｅｔの値が最大であるとき、２つの別個の基本の要件間の適切なリンクを確立するように構成することができる。

本発明の他の特徴及び利点は以下の詳細な明細書及び添付の図面を検討すれば明らかになり、唯一の図は本発明による装置の実施形態の例を図示する。

添付の図面は本発明を完成させるだけではなく、必要に応じて、その定義に貢献するのにも役立ち得る。

図１は、本発明による装置例の図である。

本発明は、既製のソフトウェアコンポーネントを使用することによって、それらの仕様のテキストからアプリケーションを自動的に構築するための装置及び関連の方法を提供することを目的とする。

本発明は、仕様によって記述され、既製のソフトウェアコンポーネントのアセンブリから構築することができる任意のタイプのアプリケーションに取り組む。

「アプリケーション」という用語は、ここでは、１組の相互に関連のある（ソフトウェア）コンポーネントを意味し、コンポーネントのそれぞれは、操作と呼ばれる少なくとも１つのパブリック関数の組として表される機能を有し、それ自体のデータを包み、管理する。この定義は、オブジェクト指向から導出されたコンポーネントパラダイムであり、開発の今日の標準である。

さらに、「既製のソフトウェアコンポーネント」という表現は、ここでは、ファイル管理機構、データベースアクセス、ＧＵＩ表示機構、テキスト翻訳、変換モジュール、ＵＲＬからのＨＴＭＬページの読み取り、テキスト処理のための初等関数など、正確な初等関数（即ち、機能の原子）を実施するための１つの実行可能コードを意味する。

唯一の図に図示されるように、本発明による装置Ｄは、少なくとも格納手段ＳＭ、分析モジュールＡＭ、及び処理モジュールＰＭを備える。

格納手段ＳＭは、少なくともセマンティックソフトウェアコンポーネントＳＳＣを格納するためのものである。各セマンティックソフトウェアコンポーネントＳＳＣは、セマンティック記述ＳＤに関連付けられるソフトウェアコンポーネントＳＣから成る。

「ソフトウェアコンポーネントのセマンティック記述」という表現は、ここでは、関連のソフトウェアコンポーネントＳＣが実行することができるパブリック操作（又は関数）の目的を定義する少なくとも１つの適切な用語を備える記述を意味する。この目的は、好ましくは、自然言語の形で（即ち適切な用語によって）簡単に表され、コンポーネントＳＣが実際には何を行うか、その関数が何であり、どのデータをそれが操作するか（即ちその操作の入力／出力）を明確に記述する。好ましくは、各コンポーネントのセマンティック記述（例えば、「セマンティックカード」と呼ばれる）ＳＤは、各操作を記述する用語が定義されるドメインを指定する少なくとも１つのドメイン識別子も含む。

例えば、ソフトウェアコンポーネントの各セマンティック記述ＳＤは、入力及び出力データが次の３つの主な属性で記述されるＸＭＬ表現である。
・データ名（又は識別子）
・データに関連付けられ、データのセマンティクスを指定するために、外部オントロジ（external ontology）又は外部の辞書又は用語辞典にクラスとして定義された概念を参照して表される概念（又は適切な用語）。ここでは、オントロジとは、例えば、コンポーネントＳＣによってアドレス指定され、その名前がセマンティックカードのヘッダーで言及されるドメインを指す。
・セマンティックデータ型のデータのステレオタイプを表し、データの性質を指定するデータのセマンティックタグ（例えば「ｓｅｍＴａｇ」と呼ぶ）。このｓｅｍＴａｇは、以下で説明するように、コンポーネントの相互作用を決定し、最適化するのに有用である。

セマンティックソフトウェアコンポーネントＳＳＣを格納することができ、当業者から知られている任意のタイプの格納手段ＳＭを使用することができ、とりわけ、データベース、フラッシュメモリ、ＲＯＭ、ＲＡＭ、フラットファイルシステム、及び任意の他の種類のリポジトリとすることができる。

分析モジュールＡＭは、その装置Ｄが構築すべきアプリケーションＡＰを記述する仕様ＡＳを受信するたびに介入するように構成される。

「アプリケーション仕様」という表現は、ここでは、所望のアプリケーションが満たすべき少なくとも１つの要件を定義する少なくとも１つのセンテンスを意味する。より正確には、アプリケーション要件は、アプリケーションＡＰが何を行うか、及びその機能的及び非機能的特徴が何であるかを記述する。これらの要件は、好ましくは自然言語で表されるが、任意の形式的又は非形式的な本文の表現の形で表されてもよい。

分析モジュールＡＭは、アプリケーション仕様ＡＳが受信されるたびに、
・この受信されたアプリケーション仕様ＡＳのセマンティック分析を順に実行して、
・例えば文法分析器によって仕様ＡＳのテキストから基本の要件ＳＲ、及びこれらの基本の要件ＳＲ間のリンクを抽出し、これらのリンクの組が以下「仕様の全体的な構造（又は論理アセンブリ）」と呼ばれ、次いで
・基本の要件ＳＲごとに、それが備える適切な用語を抽出し、基本の要件ＳＲごとに、その抽出された適切な用語に基づいて「この基本の要件のセマンティクス」を表す「セマンティック記述」を構築し、次いで
・格納手段ＳＭにアクセスして、この基本の要件ＳＲのセマンティクスとコンポーネントのセマンティック記述ＳＤとを比較することによって、抽出された基本の要件ＳＲごとに、どのコンポーネントがこの抽出された基本の要件ＳＲをカバーすることができるかを決定する（選択する）
ためのものである。

分析モジュールＡＭを２つのサブモジュールに分割することができることに留意することは重要であり、第１のものは、セマンティック分析を実行するためのものであり、第２のものは、格納手段（又はコンポーネントリポジトリ）ＳＭにおいて、第１のサブモジュールによって抽出された基本の要件ＳＲをカバーすることができるコンポーネントを決定するためのものである。

言い換えれば、分析モジュールＡＭは、基本の要件ＳＲを表す各センテンスの意味（即ち、そのセマンティクス）を決定し、それを適切な計算可能なデータ構造で表す。着想は、後でこの構造を、格納されたソフトウェアコンポーネントＳＣの等価のセマンティックデータ構造と比較して、どのコンポーネントがどの（基本の）要件ＳＲをカバーすることができるかを決定するために、機能のすべてのセマンティック原子を、その適切なセマンティックデータ構造で示すことである。実際には、それ自体のセマンティックデータを受信するために、各センテンス（又は要件の原子）を評価し、マークすることができる。このプロセスは、ソフトウェア要件仕様といくつかのドメインオントロジとの間のマッピングを確立することができるドメインオントロジ技術にソフトウェア要件分析方法が基づくオントロジベースの要件分析手法とは異なることに留意することは重要である。オントロジは、所与のドメインにおいて操作される概念の、及びこれらの概念の間の関係の形式的な記述であることに留意されたい。本発明において、セマンティクスがテキスト自体から抽出されるため、要件分析を助けるために、外部オントロジは使用されない。

操作の目的のセマンティクスは、好ましくは、例えば以下のものなど、正確なルールで定義される。
・目的は特定の単語を使用して自然言語で表される。
・これらの特定の単語は、セマンティックカードＳＤに組み込まれ、目的を書くために使用されるように適切な単語を要約する「概念のリスト」に属する。
・これらの「概念のリスト」は、例えば外部オントロジにおいて、即ち、セマンティックカードＳＤにおいて参照される関連のドメインの形式的な記述で記載することができ、若しくは外部の辞書又は用語辞典の定義の簡単な参照とすることができる。

こうしたルールは簡潔で明瞭な操作の目的を書くことを助ける。

以下に、ＲＳＳフィードアクセス機構コンポーネントに関連付けられたセマンティックカードＳＤの非制限的な例が示される。
<semCard>
<URL>http://xxx.xx.xxx.x/components/RSS/RSS_Component.asmx</URL>
<component name="RSS">
<domains>
<domain name="RSS">
<concepts list="RSS, RSS_feed, URL, news" />
</domain>
<domain name='"News">
<concepts list="news, title, titles, description, article, text, News Agency" />
</domain>
</domains>
<operation name="getAllTitles">
<goal>所与のＵＲＬによってアドレス指定されるＲＳＳフィードのすべてのニュースのタイトルを配信する。</goal>
<inputs>
<input name="URL_RSS" concept="RSS#URL" semTag="URL" />
</inputs>
<output name="titles" concept="News#title" semTag="text" />
</operation>
<operation name="getDescriptionOfTitle">
<goal>所与のＵＲＬによってアドレス指定されるＲＳＳフィードの１つのニュースのタイトルの記述を配信する。</goal>
<inputs>
<input name="URL_RSS" concept="RSS#URL" semTag="URL" />
<input name="title" concept="News#title" semTag="short_text" />
</inputs>
<output name="description_of_title" concept=" N ews#description"
semTag="text" />
</operation>
</component>
</semCard>.

要件ＳＲの適切な用語の論理アセンブリ（又は全体的な構造）は、適切な用語とその間の論理的な順序との間の適切なリンクにある。例えば、「ファイル『Ｐａｒａｍｅｔｅｒｓ．ｔｘｔ』からスクリプトを生成するために、またこのスクリプトを実行するために、アプリケーションがインターネットにアクセスする必要がある」というセンテンスにおいて、要件を表す適切な用語（又は概念）は、「インターネットにアクセスする」、「スクリプトを生成する」、「ファイル『Ｐａｒａｍｅｔｅｒｓ．ｔｘｔ』」、及び「スクリプトを実行する」であり、これらの適切な用語の論理的な順序は、「インターネットにアクセスする」、「ファイル『Ｐａｒａｍｅｔｅｒｓ．ｔｘｔ』を読み取る」、「スクリプトを生成する」、及び「スクリプトを実行する」である。

分析モジュールＡＭが仕様の基本の要件ＳＲ間の論理的なアセンブリを決定するように構成されることに留意することは重要である。実際には、仕様ＡＳを構成する基本の要件ＳＲの組において、要件ＳＲは論理的に互いにリンクされると仮定する。これは、２つの異なる要件間のリンクがこれらの要件を実施するコンポーネント間のリンクをもたらすという事実に起因する（２つの要件は、両方が対象のアプリケーションＡＰの所与のデータ、制約、機能、又は特徴について話すとき、互いにリンクされる）。ここで、いくつかの適切なリンクが要件ＳＲ間に存在する場合、同じ適切なリンクがこれらの要件ＳＲを実施するコンポーネントＳＣ間に存在すると仮定する。そのため、「要件のネットワーク」は、問題を記述するアプリケーション仕様ＡＳの全体的な構造を決定するために、要件（又は要件の原子）ＳＲ間のリンクを分析することによって決定される。言い換えれば、問題の構造はソリューションの構造と同形である。

例えば、納品伝票のＶＡＴを計算するためのアプリケーションについて考察し、アプリケーション仕様ＡＳのテキストは、ＶＡＴ計算に関する２つの異なるパラグラフを含み、第１のものはＶＡＴを計算するための一般的な方法を説明し、第２のものは（おそらく、仕様ＡＳにおいて数ページ後にある）製品カテゴリに従って異なるＶＡＴレートを提供すると仮定する。これら２つのパラグラフは、同じデータを扱うため、結合される２つの要件ＳＲである。従って、これらの要件ＳＲを実施する２つのコンポーネントＳＣは、結合する必要がある。というのは、所与の製品についてのＶＡＴの計算は、ＶＡＴ量を計算するための一般的な方法を必要とするからである。

分析モジュールＡＭが、受信されたアプリケーション仕様ＡＳの「要件ＳＲのセマンティクス」、及びこれらの要件ＳＲの論理的なアセンブリを決定するたびに、そのセマンティック記述ＳＤが要件のセマンティクスに対応するセマンティックソフトウェアコンポーネントＳＳＣを選択するために、格納手段ＳＭにアクセスする。

このために、分析モジュールＡＭは、アプリケーション仕様ＡＳから抽出された要件の意味を、コンポーネントのセマンティックカードＳＤの一部である各コンポーネントの目的と比較する必要がある。これは、要件をカバーすることを目的とするために、このコンポーネントＳＣを選択することができるようにするために行われる。

上述したように、この比較は、仕様テキストの意味の決定を必要とする。ここで、意味は、仕様テキストの各センテンスを構成するすべての適切な用語の基本の意味の連結から成ると考えられる。そのため、２つの異なるテキストの意味を比較することは、これらは意味的に近いかどうかを決定するために、異なる用語又は概念（２つずつ）を比較することを含意する。

従って、この比較を処理することができるように、基本の用語の意味を自由に表す方法を有する必要がある。そのために、用語辞典で見つけることができる用語の同義語によって一次的なｎ−ｕｐｌｅｔを構築することが可能である。こうした一次的なｎ−ｕｐｌｅｔは、以下「ｓｙｎ−ｕｐｌｅｔ」と呼ばれる。

例えば、用語「ｂａｔｔｌｅ」、「ｗａｒ」及び「ｐｅａｃｅ」のｓｙｎ−ｕｐｌｅｔは、それぞれ以下とすることができる。
- battle = {fight, clash, combat, encounter, skirmish, scuffle, melee, conflict,
confrontation, fracas, fray, action; struggle, crusade, war, campaign,
drive, wrangle, engagement},
- war = {conflict, combat, warfare, fighting, confrontation, hostilities, battle;
campaign, struggle, crusade; competition, rivalry, feud}, and
- peace = {concord, peacetime, amity, harmony, armistice, reconciliation,
ceasefire, accord, goodwill; agreement, pact, pacification,
neutrality, negotiation}.

ｓｙｎ−ｕｐｌｅｔは、要件ＳＲの用語のために構築された場合、「ｒｅｑ−ｕｐｌｅｔ」と呼ぶことができ、ソフトウェアコンポーネントＳＣのパブリック操作の目的の用語のために構築された場合、「ｃｏｍｐ−ｕｐｌｅｔ」と呼ぶことができることに留意されたい。

ｓｙｎ−ｕｐｌｅｔにおいて、即ちｒｅｑ−ｕｐｌｅｔ及びｃｏｍｐ−ｕｐｌｅｔにおいて、以下の関数、
・ｓｙｎ（ｗｏｒｄ）は、用語「ｗｏｒｄ」のｓｙｎ−ｕｐｌｅｔである
・Ｎ１は、「ｗｏｒｄ１」のｓｙｎ−ｕｐｌｅｔを指定し、Ｎ２は、「ｗｏｒｄ２」のｓｙｎ−ｕｐｌｅｔを指定し、Ｎ１＝ｓｙｎ（ｗｏｒｄｌ）及びＮ２＝ｓｙｎ（ｗｏｒｄ２）である
・ｃａｒｄ（Ｎ１）は、ｓｙｎ−ｕｐｌｅｔＮ１の基数であり、即ち、Ｎ１内の同義語の数である。
・ｃｏｍｍｏｎ（Ｎ１，Ｎ２）は、Ｎ１及びＮ２に共通の同義語の数である
・ａｖｇ（Ｎ１，Ｎ２）は、Ｎ１及びＮ２の基数の平均である
を定義することができ、次いで、ｓｙｎ−ｕｐｌｅｔの上述した例で、ｃａｒｄ（ｃｏｍｍｏｎ（ｓｙｎ（”ｂａｔｔｌｅ”），ｓｙｎ（”ｗａｒ”）））＝９である。言い換えると、「ｂａｔｔｌｅ」及び「ｗａｒ」に共通の同義語が９つある。

また、例えば２つのｓｙｎ−ｕｐｌｅｔ、ｓｙｎ（Ｔ１）及びｓｙｎ（Ｔ２）内の共通の同義語を考慮に入れて比率を計算することによって、２つの用語Ｔ１とＴ２との間の意味的な近さを定義することも可能である。

こうした意味的な近さ（例えば「ｓｅｍＰｒｏｘ」と呼ばれる）は、例えば、以下の式によって得ることができる。
semProx(T1, T2) = 100 * card(common(synT1), synT2))) / avg(synT1), synT2)).

ｓｙｎ−ｕｐｌｅｔの上述した例で、「ｂａｔｔｌｅ」及び「ｗａｒ」のｓｙｎ−ｕｐｌｅｔの意味的な近さは、ｓｅｍＰｒｏｘ（”ｂａｔｔｌｅ”，”ｗａｒ”）＝１００＊９／０．５＊（１９＋１３）＝９００／１６＝５６．２５によって得られる。言い換えると、「ｂａｔｔｌｅ」及び「ｗａｒ」の同義語の組の結合において、要素の５６．２５％が二重にある。別のサンプルとして、「ｗａｒ」及び「ｐｅａｃｅ」のｓｙｎ−ｕｐｌｅｔの意味的な近さは、論理的なｓｅｍＰｒｏｘ（”ｗａｒ”，”ｐｅａｃｅ”）＝０によって得られる。

意味的な近さは、２つの用語の間の近接比を表す。例えば、意味的な近さが最初に選択された閾値Ａ（例えば５０）を上回る、又は１００に近い場合、２つの用語は意味的に近いと考える。逆に、意味的な近さが２番目に選択された閾値Ｂ（例えば１０）を下回る、又は０に近い場合、２つの用語は意味的に遠いと考える。閾値Ａ及びＢの値は、処理すべきテキストのカテゴリに従って「調整」することができる。

例えば、所与のセンテンスの意味の決定は、以下の通り行うことができる。

第１のステップで、センテンスが分析され、適切な用語（単語）が抽出される。冠詞、前置詞、接続詞などの非適切な単語は無視される。

第２のステップで、適切な用語（単語）ごとに、対応のｓｙｎ−ｕｐｌｅｔが構築される。

最後に、第３のステップで、センテンスに含まれる適切な単語のすべてのｓｙｎ−ｕｐｌｅｔをアセンブルすることによって、センテンス全体のグローバルなｎ−ｕｐｌｅｔが構築される。こうしたグローバルなｎ−ｕｐｌｅｔを「ｐｈｒａｓｅ−ｕｐｌｅｔ」と呼ぶことができる（これは、ｓｕｐｅｒ−ｎ−ｕｐｌｅｔ、即ち複数のｎ−ｕｐｌｅｔのうちの１つのｎ−ｕｐｌｅｔとみなすことができる）。

一例として、電話管理システムの仕様ＡＳから抽出された要件ＳＲが「呼出側が受信側に電話をかけ、電話の件名を含むメッセージを作成して、同時に受信側に発信される」である場合、適切な用語は、呼出側、電話、電話をかける、受信側、メッセージ、件名、及び発信である。この要件ＳＲのｐｈｒａｓｅ−ｕｐｌｅｔは、以下のｓｙｎ−ｕｐｌｅｔの連結とすることができる。
- caller = {phone caller, telephone caller, visitor, guest, company},
- call = {phone call, telephone call, buzz, bell, ring; demand, request, plea,
appeal, bid, invitation},
- make a call = {phone, make a demand, send a request},
- receiver = {recipient, heir, addressee, beneficiary, inheritor, heritor},
- message = {communication, memo, memorandum, note, letter, missive,
dispatch},
- subject = {topic, theme, focus, subject matter, area under discussion,
question, issue, matter, business, substance, text; field, study,
discipline, area},
- submit = {offer, present, propose, suggest, tender}.

仕様ＡＳの１つのセンテンスＳ１の、ソフトウェアコンポーネントＳＤに関連付けられたセマンティック記述（又はカード）ＳＤの２つの他のセンテンスＳ２及びＳ３との比較は、それらのｐｈｒａｓｅ−ｕｐｌｅｔを比較することによって行うことができる。この比較は、以下で説明するように、センテンス間の意味的な距離を計算するために使用することができる結果を提供する。ｐｈｒａｓｅ−ｕｐｌｅｔ比較ステップは、以下の通りとすることができる。
・２つのｐｈｒａｓｅ−ｕｐｌｅｔの内部ｓｙｎ−ｕｐｌｅｔは、２つずつ比較される。言い換えると、Ｓ１のｐｈｒａｓｅ−ｕｐｌｅｔのすべてのｓｙｎ−ｕｐｌｅｔは、Ｓ２及びＳ３のｐｈｒａｓｅ−ｕｐｌｅｔのすべてのｓｙｎ−ｕｐｌｅｔと比較される。
・意味的な近さ（ｓｅｍＰｒｏｘ）は、ｓｙｎ−ｕｐｌｅｔの対ごとに計算される。
・例えば「ｓｅｍ−ｕｐｌｅｔ」と呼ばれる整列された二次的なｎ−ｕｐｌｅｔが構築される。各セマンティックｎ−ｕｐｌｅｔ（又はｓｅｍ−ｕｐｌｅｔ）は、Ｓ１の各ｓｙｎ−ｕｐｌｅｔとＳ２又はＳ３のそれぞれとの間の意味的な近さを備え、意味的な距離を定義する。
・最小の意味的な距離を提供するセマンティックｎ−ｕｐｌｅｔは抑制され、このセマンティックｎ−ｕｐｌｅｔが関係するセンテンスＳ２又はＳ３は、Ｓ１に意味的に近いと考えられ、従って、その対応する格納されているソフトウェアコンポーネントＳＣが選択される。

以下に示される表は、要件ＳＲ「呼出側が受信側に電話をかけ、電話の件名を含むメッセージを作成して、同時に受信側に発信される」とコンポーネントリポジトリＳＭに格納されたコンポーネントセットのサンプルとの間の対応関係を検索する非制限的な例である。要件の適切な用語は、｛呼出側、電話、電話をかける、受信側、メッセージ、件名、発信｝である。以下の表の最後の右列に示されるｓｅｍ−ｕｐｌｅｔは、これらの適切な用語のｓｙｎ−ｕｐｌｅｔと、コンポーネントの目的から計算されるものとの間の比較の結果である。これらのｓｅｍ−ｕｐｌｅｔの迅速な表示は、要件を満たすことができるコンポーネントＳＣを容易に決定するのを助ける。

処理モジュールＰＭは、所望のアプリケーションＡＰを構築するために、仕様の論理的アセンブリ（即ち、分析モジュールＡＭによって決定された全体的な仕様構造）に従って、決定されたセマンティックソフトウェアコンポーネントＳＳＣのソフトウェアコンポーネントＳＣをアセンブルするように構成される。

上述したように、このアセンブルは、アプリケーション仕様ＡＳ（又は問題）の要件間の適切なリンクが、決定されたソフトウェアコンポーネントＳＳＣ（ソリューションのブロック）間のリンクとの類似の対応関係を有するという仮定に基づく。

そのため、処理モジュールＰＭは、アプリケーションＡＳの初期アーキテクチャを構成するために、要件のセマンティック原子との意味的な距離が最も短い、選択されたコンポーネントＳＣを編成する。この初期アーキテクチャは、問題の構造（又は要件のネットワーク）を複製し、問題の原子（又は要件）の代わりにソリューション原子（又はコンポーネントＳＣ）を使用することによって行われる。

上述したように、仕様の要件間の適切なリンクを要約し、表す要件のネットワークは分析モジュールＡＭによって決定される。このために、分析モジュールＡＭは、要件（又は要件の原子）間の適切なリンクを明らかにするために、上述したｓｅｍ−ｕｐｌｅｔ（二次的なｎ−ｕｐｌｅｔ）手法を使用することができる。仕様ＡＳのセンテンスは、ｐｈｒａｓｅ−ｕｐｌｅｔ＋ｓｅｍ−ｕｐｌｅｔの手法を使用することによって、意味的に２つずつ比較される。より正確には、仕様ＡＳの要件Ｒ１と、同じ仕様ＡＳの２つの他の要件Ｒ２及びＲ３との間の比較の場合、
・２つのｐｈｒａｓｅ−ｕｐｌｅｔの内部ｓｙｎ−ｕｐｌｅｔは、２つずつ比較される。言い換えると、Ｒ１のｐｈｒａｓｅ−ｕｐｌｅｔのすべてのｓｙｎ−ｕｐｌｅｔは、Ｒ２及びＲ３のｐｈｒａｓｅ−ｕｐｌｅｔのすべてのｓｙｎ−ｕｐｌｅｔと比較される。
・意味的な近さ（ｓｅｍＰｒｏｘ）は、対ごとに計算される。
・整列された二次的なｎ−ｕｐｌｅｔ（セマンティックｎ−ｕｐｌｅｔ、ｓｅｍ−ｕｐｌｅｔと呼ばれる）が構築される。各ｓｅｍ−ｕｐｌｅｔは、Ｒ１の各ｓｙｎ−ｕｐｌｅｔとＲ２又はＲ３のそれぞれとの間の意味的な近さを備え、意味的な距離を定義する。そのため、意味的な距離に関して、他に対する各要求のリンクを表す１組のｎ−ｕｐｌｅｔを取得する。意味的な距離のレベルを「調整して」、意味的な近さに関して「最高の」ｓｅｍ−ｕｐｌｅｔ、即ち、所与の要件について最も意味的に適切なリンクのみを保持することが可能である。これは、各要件が有限数の意味的に最も近い他の要件を有すると仮定することを意味する。そのため、意味的に最も近い他の要件を表す限られた組のｓｅｍ−ｕｐｌｅｔによって、全体的な仕様ＡＳの文脈内で、要件を形式的に記載することができると考える。

例えば、Ｒ２は、Ｒ１及びＲ３にリンクされており、しかしｓｅｍ−ｕｐｌｅｔ（Ｒ２，Ｒ３）＞ｓｅｍ−ｕｐｌｅｔ（Ｒ２，Ｒ１）である場合、Ｒ２−Ｒ３のリンクのみが最後のモデルに保持される。これは、最適化の問題である。モデルを調整することは、２つのｓｅｍ−ｕｐｌｅｔ間の最大限容認できるギャップを決定することによって可能である。例えば、ｄｉｆｆ（ｓｅｍ−ｕｐｌｅｔ（Ｒ２，Ｒ３），ｓｅｍ−ｕｐｌｅｔ（Ｒ２，Ｒ１））＞１０の場合、Ｒ２−Ｒ３のリンクのみが保持されると考えることができ、式中、「ｄｉｆｆ（）」は、関数の差（減算）である。変形体において、関数「ｄｉｆｆ（）」の制限（又は閾値）は、問題のカテゴリ又は要件の種類に応じて、５又は１５に等しくてよい。別の変形において、最小臨界レベルより大きい関数ｄｉｆｆ（）に対応するすべてのリンクは、問題のモデル（又は要件のネットワーク）において保持することができ、従って、ソリューションモデルに複写することができる。

ソリューション「分子」は、問題「分子」と同じ空間構造を有するが、これらは同じ種類の原子を含まず、使用しない。問題原子は要件であり、ソリューション原子はコンポーネントＳＣである。問題原子は同じ概念を共有し、同じ要件に対処するため、結合され、ソリューション原子は同じデータを共有し、又は交換するため、結合される。しかし、要件間の適切なリンクを含む要件のネットワーク（又は問題分子）はアプリケーションアーキテクチャ（又はソリューション）と同じリンクを含む。

これら２種類の原子は異なっており、正確には同じ性質を有しておらず、要件のネットワークにおいて適切なリンクは、最初のコンポーネント構造において適切ではない場合がある。実際には、２つの要件が同じ概念を共有するという事実は、必ずしも２つの対応するコンポーネントが共に相互作用を有することを含意するわけではない。そのため、アプリケーションＡＳの初期アーキテクチャを最適化するために、より正確には、最高のコンポーネント相互作用モデルを決定するために、処理モジュールＰＭを構成することができる。

最適化プロセスは、問題の構造から引き継いだ最も有用なリンク、即ち、２つのコンポーネントＳＣ（Ｃｏｍｐ１及びＣｏｍｐ２）間の実際のデータ交換に対応する関連のみを保持することを目的とし、この場合、コンポーネントＣｏｍｐ１の出力は、Ｃｏｍｐ２の入力であり、又はその逆である。

この最適化プロセスはセマンティックメタデータとしてコンポーネントの操作（及びより正確にはそれらの入力及び出力）のデータ記述に添付されるセマンティックタグを使用して、選択されたコンポーネントＳＣ間の相互作用を決定し、最適化することができる。

これらのセマンティックタグが適切に選択され、設定されている場合、コンポーネントＳＣは、接続することができ、その接続は、形式的に表すことができる。例えば、Ｃｏｍｐ１．ｏｐｅｒａｔｉｏｎ＿Ａ（）の出力がＣｏｍｐ２．ｏｐｅｒａｔｉｏｎ＿Ｂ（）の入力に意味的に合う場合、Ｃｏｍｐ１は、「Ａの出力」と「Ｂの入力」とのリンクを介してＣｏｍｐ２に接続することができ、これは、以下のように書くことができる。
out_A = Comp1.operation_A(A_parameters);
out_B = Comp2.operation_B(out_A);
又はより直接的には、以下の通りである。
out_B = Comp2.operation_B(Comp1.operation_A(A_parameters)).

これは、２つの接続されたデータが同じ意味的「次元」を有する、即ち、これらが互いに意味的に合う（又はこれらが処理の互換性がある）ことを意味する。というのは、これらは、同じデータ型だけではなく、データの同じ性質も共有するからである。このセマンティックデータ型は、ＵＭＬタグ付き値に似ており、セマンティック記述（又はセマンティックカード）ＳＤ内の入力及び出力に添付されたパラメータ「ｓｅｍＴａｇ」によって表すことができる。

Ｃｏｍｐ１及びＣｏｍｐ２は、互いに意味的に合うので（例えば、Ｃｏｍｐ１はテキストを生成し、Ｃｏｍｐ２はテキストを消費する）、Ｃｏｍｐ１の出力及びＣｏｍｐ２の入力を接続することができるという事実は、Ｃｏｍｐ２が、例えばテキストを生成する別のコンポーネントであるＣｏｍｐ４の出力の代わりにＣｏｍｐ１の出力を事実上待っていることを必ずしも含意するわけではない。実際に、ソリューション構造に存在するリンクをたどることによって相互作用が構築されるため、Ｃｏｍｐ１−Ｃｏｍｐ２の接続は証明される。Ｃｏｍｐ４がテキストを生成する場合でさえ、これは、Ｃｏｍｐ２に直接リンクされない。従って、それらの入力−出力を結合しようとする理由はない。

ＳｅｍＴａｇは、コンポーネントのインターフェイスの整合性を保証し、この理由で、コンポーネントの相互作用を最適化するために重要な要素である。ＵＭＬによる意味として、コンポーネントＳＣのインターフェイスが、それらのパラメータを含むそのパブリック操作の組から成ることに注意されたい。例えば、Ｃｏｍｐ１．ｏｐｅｒａｔｉｏｎ＿Ａ（）は、テキストを提供し、Ｃｏｍｐ２．ｏｐｅｒａｔｉｏｎ＿Ｂ（）は、コンポーネントＴｒａｎｓｌａｔｏｒの操作ｔｒａｎｓｌａｔｅ（）であると仮定する。それはテキストを翻訳することを意味するので、Ｃｏｍｐ１．ｏｐｅｒａｔｉｏｎ＿Ａ（）の出力は、Ｔｒａｎｓｌａｔｏｒ．ｔｒａｎｓｌａｔｅ（）の入力と合わなければならない。しかし、Ｃｏｍｐ１．ｏｐｅｒａｔｉｏｎ＿Ａ（）が所与の会社の銘柄記号を提供すると仮定すると、この記号及びＴｒａｎｓｌａｔｏｒ．ｔｒａｎｓｌａｔｅ（）によって入力として取得されたテキストは、同じデータ型（Ｓｔｒｉｎｇ）を有することはできるが、これらは意味的に等価ではない。というのは、これは、銘柄記号を翻訳しようとすることを意味しないからである。従って、これら２つのデータに添付されるセマンティック情報は、異なっており、従って２つの操作でなければならず、それら２つのコンポーネントＳＣは接続できない（又はリンクできない）。

以下に、ｓｅｍＴａｇの有用性を示すために、コンポーネントＴｒａｎｓｌａｔｏｒのセマンティックカードＳＣの非制限的な例が示される。
<semCard>
<URL>http://xxx.xx.xxx.x/components/Translation/Translator.asmx</URL>
<component name="Translator">
<domains>
<domain name="Translation">
<concepts list="translation, version, language, source language, target language, result" />
</domain>
<domain name="Text">
<concepts list="text, chapter, paragraph, sentence,, phrase, word, language" />
</domain>
</domains>

<operation name="translate">
<inputs>
<input name="text_to_translate" concept="Text#Text" semtag="text" />
<input name=" source_language"
concept="Translation#SourceLanguage" semtag="language" />
<input name="target_language"
concept="Translation#TargetLanguage" semtag="language" />
</inputs>
<output name="translated_text" concept=" Text#Text "
semtag="text" />
<goal> The goal of the operation is to provide a translated text written in a given target language as a result of the translation of a given text_to_translate written in a source_language.
</goal>
</operation>
</component>
</semCard>.

例えば、コンポーネントＳＣがＷｅｂサービスであるとき、それらのセマンティック記述（セマンティックカード）ＳＤはサービスのＷＳＤＬ（Ｗｅｂサービス記述言語）から生成することができる。しかし、セマンティックタグを自動的に設定するために、唯一の図で示すように、装置Ｄのオプションの及び特定のセマンティックモジュールＳＳＭを使用することができる。このモジュールＳＳＭは処理モジュールＰＭの一部とすることができる。

このセマンティックモジュールＳＳＭは、ＷＤＳＬで記述される操作のパラメータの名前及びタイプを分析することができ、特定のオントロジにおける意味的な対応関係を検索することができる。

この特定のオントロジは通常プログラマが使用する通りの入力及び出力データの現在の名前及びタイプのセマンティクスと対応するセマンティックタグとの間のリンクを含む。

例えば、「ｔｅｘｔ」、「ｃｏｎｔｅｎｔ」、「ｔｒａｎｓｌａｔｅｄ＿ｐａｇｅ」又は「ｄｅｓｃｒｉｐｔｉｏｎ」という名前の「ｓｔｒｉｎｇ」型のデータは、セマンティックタグ「ｔｅｘｔ」を有することができる。というのは、データは、テキストの「次元」を有するからである。「Ｄａｔｅ」型又は「Ｓｔｒｉｎｇ」型の「ｄａｔｅ」又は「ｃｕｒｒｅｎｔ＿ｄａｔｅ」という名前のデータは、セマンティックタグ「ｄａｔｅ」などを有することができる。

こうした特定のオントロジは、セマンティックカードＳＤ内のセマンティックタグを自動的に設定するためのものであり、簡単な対応表として表すことができる。以下に、こうした対応表の一例を示す。

こうした特定のオントロジは、当業者によって容易に構築することができ、プログラマの習慣を示す発行されたコンポーネントインターフェイスのコンテンツを分析し、次いで、その良好な使用をまとめることによって、累進的に向上させることができる。

以下に、自動コンポーネント相互作用モデルを構築するために、セマンティックタグがどのように考慮に入れられるかを示す一例を示す。

この非制限的な例において、仕様ＡＳの要件（自然言語で表される）が、アプリケーションＡＰはニュースフィードの翻訳バージョンを生成するためのものであることを示すと仮定する。さらに、ｓｅｍ−ｕｐｌｅｔ＋コンポーネント発見手法は、この要件に２つのコンポーネントＳＣ、ＲＳＳ−アクセス機構コンポーネント及びＴｒａｎｓｌａｔｏｒコンポーネントを割り振ったと仮定する（セマンティックカードＳＤの例は上述した）。

例えば、ＲＳＳアクセス機構コンポーネントは、インターネットを介してアクセス可能なＲＳＳフィードから情報を集めることを目的としており、そのインターフェイスは、２つの操作を含み、ｇｅｔＡｌｌＴｉｔｌｅｓ（）は、所与のＵＲＬについてフィードの主なタイトルのすべてを取得し、ｇｅｔＤｅｓｃｒｉｐｔｉｏｎＯｆＴｉｔｌｅ（）は、このタイトルについて短い記事のテキストを取得する。

例えば、Ｔｒａｎｓｌａｔｏｒコンポーネントは、その操作ｔｒａｎｓｌａｔｅ（）が、所与のソース言語（入力パラメータ）で書かれたテキスト（入力パラメータとして提供される）を宛先言語（入力パラメータ）で書かれた翻訳されたテキスト（出力）に変換する古典的なものである。

現在、問題は、仕様要件を満たす（即ち、ニュースフィードの翻訳バージョンを提供する）ために、これら２つのコンポーネント、即ち３つの操作を自動的及び論理的にアセンブルすることである。このために、２つの点を考慮に入れなければならない。

第１の点は、セマンティックタグを、データの代わりにコンポーネント操作の入力及び出力としてみなすことにある。これによって、いくつかの可能な接続を現すことが可能になるが、正確には、十分に整合性のある構成を作るのに十分ではない。

第２の点は、どのコンポーネント操作がその入力を提供することができるかを見つけるために目的のコンポーネントアセンブリの主な出力を考慮に入れ、これらの操作についてこのプロセスを反復すること、即ちどの他の操作がそれらの入力を提供することができるかを探すことにある。次いで、主な出力からその生成に必要な入力データに漸進的に戻り、これを行う際に、それらの出力と入力とをリンクすることによって、異なるコンポーネント操作を自動的にアセンブルする。

同時に、リンクを、操作の呼出を表す擬似コードの形でＦＩＬＯ（先入れ、後出し）のスタックに格納することができる。このプロセスの最後に、スタックの中身は選択されたコンポーネント間の正しい相互作用を表す。

コンポーネントアセンブリの主な出力は仕様要件の表現によって提供される。この例で、翻訳バージョンが望まれる場合、主な出力は、翻訳されたテキスト、即ち、操作Ｔｒａｎｓｌａｔｏｒ．ｔｒａｎｓｌａｔｅ（）の出力である。そのため、目的のコンポーネントアセンブリによって表される関数の「戻り」として表される、この主な出力をスタックに押し込むことができる。
translated_text = Translator.translate(text_to_translate, src_lang, dest_lang);
return translated_text.

ここで、そのそれぞれのセマンティックタグが「ｌａｎｇｕａｇｅ」、「ｌａｎｇｕａｇｅ」及び「ｔｅｘｔ」であるこの操作の入力に戻る場合、セマンティックタグ「ｔｅｘｔ」付きのデータが操作ＲＳＳ．ｇｅｔＤｅｓｃｒｉｐｔｉｏｎＯｆＴｉｔｌｅ（）によって提供されることがわかる。そのため、この操作をＴｒａｎｓｌａｔｏｒ．ｔｒａｎｓｌａｔｅ（）に接続することができ、操作ＲＳＳ．ｇｅｔＤｅｓｃｒｉｐｔｉｏｎＯｆＴｉｔｌｅ（）の呼出を、以下のように、交換されたパラメータの名前を介してＴｒａｎｓｌａｔｏｒ．ｔｒａｎｓｌａｔｅ（）とリンクして、スタックに追加することができる。
text_to_translate = RSS.getDescriptionOfTitle(site_address, title);
translated_text = Translator.translate(text_to_translate, src_lang, dest_lang);
return translated_text.

そのセマンティックタグが「ＵＲＬ」及び「ｔｉｔｌｅ」であるＲＳＳ．ｇｅｔＤｅｓｃｒｉｐｔｉｏｎＯｆＴｉｔｌｅ（）の入力に戻る場合、セマンティックタグ「ｔｉｔｌｅ」付きのデータが操作ＲＳＳ．ｇｅｔＡｌｌＴｉｔｌｅｓ（）によって提供されることがわかる。そのため、新しい操作の呼出をスタックに押し込むことによってこれら２つの操作を接続することもできる。
titles = RSS.getRSSTitles(adr_site);
text_to_translate = RSS.getDescriptionOfTitle(site_address, title);
translated_text = Translator.translate(text_to_translate, src_lang, dest_lang);
return translated_text.

仕様要件に割り当てられるすべてのコンポーネントＳＣが使用され、結合され、スタックは、ここで、ほぼ実行可能な擬似コードの形で、コンポーネントアセンブリの一般的な構造を含む。しかし、それを実行する前に、この擬似コードに改良をもたらすことが好ましい。以下に、これらの改良の一部が列挙される。
・データ型を考慮に入れる必要がある。例えば、ＲＳＳ．ｇｅｔＡｌｌＴｉｔｌｅｓ（）は、単一のＳｔｒｉｎｇではなく、Ｓｔｒｉｎｇの配列を戻す。
・いくつかのパラメータの名前を、それらのセマンティクスを介して、即ちｓｅｍＴａｇを用いて解決することができる。例えば、「ａｄｒ＿ｓｉｔｅ」及び「ｓｉｔｅ＿ａｄｄｒｅｓｓ」は、同じ概念を回復し、同じｓｅｍＴａｇを有する。
・いくつかの他のパラメータは、元の要件に含まれる何らかの有用な情報で解決することができる。例えば、要件がフランス語の翻訳を指定する場合、操作Ｔｒａｎｓｌａｔｏｒ．ｔｒａｎｓｌａｔｅ（）のパラメータ「ｄｅｓｔ＿ｌａｎｇ」が「Ｆｒｅｎｃｈ」に設定されなければならない。
・いくつかの追加のコンポーネントＳＣ又はコンポーネント操作を使用して、他のパラメータを解決することができる。例えば、ユーティリティコンポーネント「ＬａｎｇｕａｇｅＦｉｎｄｅｒ」を使用して、所与のテキストのソース言語、又はＲＳＳフィードコンポーネントにおける操作ｇｅｔＳｏｕｒｃｅＬａｎｇｕａｇｅ（）を自動的に決定することによってパラメータ「ｓｒｃ＿ｌａｎｇ」を設定することができる。

擬似コードを完了するための改良を実行するために、装置Ｄの別のオプションの特定のモジュールＯＳＭを提供することができる。このモジュールＯＳＭは、処理モジュールＰＭの一部分とすることができ、又は唯一の図に示されるように、処理モジュールＰＭに結合することができる。例えば、このモジュールＯＳＭは、以下のものなど、ソフトウェアモジュールとすることができる。
Vector ComponentAssembly(String site_address) {
Vector result;
titles = RSS.getAllTitles(site_address);
foreach title in titles {
text_to_translate = RSS.getDescriptionOfTitle(site_address, title);
source_lang = LanguageFinder.getLanguage(text_to_translate);
translated_text = Translator.Translate(text_to_translate, source_lang,
"french");
result.add(title + translated_text);
}
return result;
}.

できる限り改良した後、擬似コードは、例えば最適化プロセスによって生成されるコンポーネントアセンブリの妥当性をテストするために、最終的に、実行可能なＪａｖａファイルに変換することができる。

仕様ＡＳの元のテキストのセマンティック分析が自動であるため、またソフトウェアコンポーネントＳＣの発見及びアセンブリが自動であることを考慮し、アプリケーション設計の最適化も自動であることを考慮し、最終的に、互換性のある実行可能なコード生成がこの最適化された設計から可能であることを考慮して、本発明はその仕様ＡＳのテキストから直接実行可能なアプリケーションＡＰを生成するための手段とみなすことができる。

装置Ｄ、及びより正確には、その分析モジュールＡＭ及び処理モジュールＰＭ、及び場合によってはその格納手段ＳＭは、好ましくはソフトウェアモジュールである。しかし、これらはそれぞれ、電子回路又はハードウェアモジュール、又はハードウェアモジュール及びソフトウェアモジュールの組合せで構成されてもよい。

また、本発明はソフトウェアコンポーネントＳＣからアプリケーションＡＰを構築するための方法の観点で考えることもできる。

こうした方法は、唯一の図を参照して上述したものなど、装置Ｄによって実施することができる。従って、その主な特徴のみ、以下で言及する。

本発明による方法は、仕様ＡＳ（構築すべきアプリケーションＡＰを記述する）が受信されるたびに、
・仕様ＡＳのテキストから基本の要件ＳＲ、及びこれらの基本の要件ＳＲ間のリンクを抽出するために、この仕様ＡＳのセマンティック分析を行うステップであって、これらのリンクの組が「仕様の全体的な構造」と呼ばれる、ステップ、次いで
・基本の要件ＳＲごとに、それが備える適切な用語を抽出し、基本の要件ＳＲごとに、その抽出された適切な用語に基づいて「この基本の要件のセマンティクス」を表す「セマンティック記述」を構築するステップ、次いで
・各コンポーネントＳＣが「セマンティックソフトウェアコンポーネント」ＳＳＣと登録され、記述される少なくとも１つのコンポーネントリポジトリＳＭにアクセスして、抽出された基本の要件ＳＲごとに、この基本の要件ＳＲのセマンティクスとコンポーネントのセマンティック記述ＳＤとを比較することによって、どのコンポーネントが抽出された基本の要件ＳＲをカバーすることができるかを決定するステップ、及び
仕様の全体的な構造に従って、これらの決定されたソフトウェアコンポーネントＳＣを最終的にアセンブルして、アプリケーションＡＰを構築するステップ
から成る。

本発明は、単に例にすぎず、上記の方法及び装置の実施形態に限定されるものではなく、以下の特許請求の範囲内で当業者が考え得るすべての代替実施形態を含む。

Claims

仕様（ＡＳ）及びソフトウェアコンポーネント（ＳＣ）からアプリケーション（ＡＰ）を構築するための方法であって、構築すべきアプリケーション（ＡＰ）を記述する仕様（ＡＳ）を受信するたびに、（ｉ）基本の要件（ＳＲ）及びこれらの基本の要件（ＳＲ）間のリンクを抽出するために、この仕様（ＡＳ）のテキストのセマンティック分析を行うステップであって、これらのリンクが「前記仕様の全体的な構造」を定義する、ステップ、次いで基本の要件（ＳＲ）ごとに、それが備える適切な用語を抽出し、基本の要件（ＳＲ）ごとに、その抽出された適切な用語に基づいて「この基本の要件のセマンティクス」を表す「セマンティック記述」を構築するステップ、次いで（ii）少なくとも１つのコンポーネントリポジトリにアクセスし、セマンティックソフトウェアコンポーネント（ＳＳＣ）を格納し、セマンティックソフトウェアコンポーネントのそれぞれが、ソフトウェアコンポーネント（ＳＣ）が実行することができる各パブリック操作を定義するための少なくとも１つの適切な用語を備えるセマンティック記述（ＳＤ）に関連付けられたソフトウェアコンポーネント（ＳＣ）から成り、抽出された基本の要件（ＳＲ）ごとに、この基本の要件（ＳＲ）の前記セマンティクスと前記コンポーネントのセマンティック記述（ＳＤ）とを比較することによって、どのコンポーネント（ＳＣ）が前記抽出された基本の要件（ＳＲ）をカバーすることができるかを決定するステップ、及び（iii）前記仕様の前記全体的な構造に従って、これらの決定されたソフトウェアコンポーネント（ＳＣ）をアセンブルして、前記アプリケーションを構築するステップから成ることを特徴とする方法。
請求項１に記載の方法であって、前記ソフトウェアコンポーネント（ＳＣ）の前記セマンティック記述（ＳＤ）の少なくとも一部が、（ｉ）前記ソフトウェアコンポーネント（ＳＣ）が実行することができる前記操作の目的、（ii）前記操作の目的及び前記操作の入力／出力パラメータを記述する用語が定義されるドメインを指定する少なくとも１つのドメイン識別子、及び（iii）これらの入力／出力パラメータに関連付けられる適切な用語及び／又は特定のメタデータを備えることを特徴とする方法。
請求項１乃至２のいずれか１項に記載の方法であって、前記抽出された基本の要件（ＳＲ）のそれぞれについて、そのセマンティック記述（ＳＤ）と前記格納されたソフトウェアコンポーネント（ＳＣ）のそれぞれの前記セマンティック記述（ＳＤ）との間の意味的な距離を決定し、次いで最小の意味的な距離に対応する前記格納されたソフトウェアコンポーネント（ＳＣ）を選択し、従ってこの選択されたソフトウェアコンポーネント（ＳＣ）が前記基本の要件（ＳＲ）を実施するためのものであることを特徴とする方法。
請求項２及び３の組合せに記載の方法であって、「ｓｙｎ−ｕｐｌｅｔ」と呼ばれる単語の一次的なｎ−ｕｐｌｅｔを基本の要件（ＳＲ）の各適切な単語に関連付け、このｓｙｎ−ｕｐｌｅｔが次いで「ｒｅｑ−ｕｐｌｅｔ」と呼ばれ、ｓｙｎ−ｕｐｌｅｔを各ソフトウェアコンポーネント（ＳＣ）の各パブリック操作の目的の各適切な用語に関連付け、このｓｙｎ−ｕｐｌｅｔが「ｃｏｍｐ−ｕｐｌｅｔ」と呼ばれ、これらのｒｅｑ−ｕｐｌｅｔのそれぞれをこれらのｃｏｍｐ−ｕｐｌｅｔのそれぞれと比較して、各基本の要件（ＳＲ）と各格納されたソフトウェアコンポーネント（ＳＣ）との間の前記意味的な距離を決定することを特徴とする方法。
請求項４に記載の方法であって、（ｉ）各ｒｅｑ−ｕｐｌｅｔ及び各ｃｏｍｐ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定し、（ii）基本の要件（ＳＲ）ごとに、「ｓｅｍ−ｕｐｌｅｔ」と呼ばれ、前記ｒｅｑ−ｕｐｌｅｔのそれぞれと前記ｃｏｍｐ−ｕｐｌｅｔのそれぞれとの間の前記意味的な近さを表す二次的なｎ−ｕｐｌｅｔを構築し、各二次的なｎ−ｕｐｌｅｔが意味的な距離を定義し、次いで、最小の意味的な距離を定義する前記二次的なｎ−ｕｐｌｅｔに対応する前記格納されたソフトウェアコンポーネント（ＳＣ）を選択することを特徴とする方法。
請求項３乃至５のいずれか１項に記載の方法であって、前記アプリケーション（ＡＰ）の前記構造を最適化するために、前記抽出された基本の要件（ＳＲ）に対応する前記選択された格納されたソフトウェアコンポーネント（ＳＣ）間の前記仕様（ＡＳ）の前記全体的な構造を定義するものと同じ適切なリンクを確立することを特徴とする方法。
請求項４乃至６のいずれか１項に記載の方法であって、前記仕様の前記全体的な構造を決定するために、（ｉ）基本の要件（ＳＲ）の各対の前記ｒｅｑ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定し、（ii）基本の要件（ＳＲ）ごとに、そのｒｅｑ−ｕｐｌｅｔと前記他の基本の要件（ＳＲ）のそれぞれとの間の前記意味的な近さを備える「ｓｅｍ−ｕｐｌｅｔ」と呼ばれる二次的なｎ−ｕｐｌｅｔを構築し、各ｓｅｍ−ｕｐｌｅｔが意味的な距離を定義し、次いで、それらのｓｅｍ−ｕｐｌｅｔの値が最大であるとき、２つの別個の基本の要件（ＳＲ）間の適切なリンクを確立することを特徴とする方法。
仕様（ＡＳ）及びソフトウェアコンポーネント（ＳＣ）からアプリケーション（ＡＰ）を構築するための装置（Ｄ）であって、（ｉ）セマンティックソフトウェアコンポーネント（ＳＳＣ）を格納するための格納手段（ＳＭ）であって、セマンティックソフトウェアコンポーネントのそれぞれが、前記ソフトウェアコンポーネント（ＳＣ）が実行することができる各パブリック操作を定義するための少なくとも１つの適切な用語を備えるセマンティック記述（ＳＤ）に関連付けられたソフトウェアコンポーネント（ＳＣ）から成る、格納手段（ＳＭ）、（ii）構築すべきアプリケーション（ＡＰ）を記述する仕様（ＡＳ）が受信されるたびに、前記仕様（ＡＳ）の前記テキストから基本の要件（ＳＲ）、及びこれらの基本の要件（ＳＲ）の間のリンクを抽出するために、前記仕様（ＡＳ）のセマンティック分析を行い、これらのリンクが「前記仕様の全体的な構造」を定義し、次いで基本の要件（ＳＲ）ごとに、それが備える前記適切な用語を抽出し、基本の要件（ＳＲ）ごとに、その抽出された適切な用語に基づいて「この基本の要件のセマンティクス」を表す「セマンティック記述」を構築し、次いで前記格納手段（ＳＭ）にアクセスして、抽出された基本の要件（ＳＲ）ごとに、この基本の要件（ＳＲ）のセマンティクスと前記コンポーネントのセマンティック記述（ＳＤ）とを比較することによって、どのコンポーネント（ＳＣ）が前記抽出された基本の要件（ＳＲ）をカバーすることができるかを決定するように構成された分析手段（ＡＭ）、及び（iii）前記仕様の前記全体的な構造に従って、前記決定されたソフトウェアコンポーネント（ＳＣ）をアセンブルして、前記アプリケーション（ＡＰ）を構築するための処理手段（ＰＭ）を備えることを特徴とする装置。
請求項８に記載の装置であって、前記ソフトウェアコンポーネント（ＳＣ）の前記セマンティック記述（ＳＤ）の少なくとも一部が、（ｉ）前記ソフトウェアコンポーネント（ＳＣ）が実行することができる前記操作の目的、（ii）前記操作の目的及び前記操作の入力／出力パラメータを記述する用語が定義されるドメインを指定する少なくとも１つのドメイン識別子、及び（iii）これらの入力／出力パラメータに関連付けられる適切な用語及び／又は特定のメタデータを備えることを特徴とする装置。
請求項８乃至９のいずれか１項に記載の装置であって、前記分析手段（ＡＭ）が抽出された基本の要件（ＳＲ）のそれぞれについて、そのセマンティック記述と前記格納されたソフトウェアコンポーネント（ＳＣ）のそれぞれの前記セマンティック記述（ＳＤ）との間の意味的な距離を決定し、次いで最小の意味的な距離に対応する前記格納されたソフトウェアコンポーネント（ＳＣ）を選択し、この選択されたソフトウェアコンポーネント（ＳＣ）が前記基本の要件を実施するように構成されたことを特徴とする装置。
請求項９及び１０の組合せに記載の装置であって、前記分析手段（ＡＭ）が、「ｓｙｎ−ｕｐｌｅｔ」と呼ばれる単語の一次的なｎ−ｕｐｌｅｔを基本の要件（ＳＲ）の各適切な単語に関連付け、次いでこのｓｙｎ−ｕｐｌｅｔが「ｒｅｑ−ｕｐｌｅｔ」と呼ばれ、これらのｒｅｑ−ｕｐｌｅｔのそれぞれを各ソフトウェアコンポーネント（ＳＣ）の各パブリック操作の目的の各適切な用語に関連付けられたｓｙｎ−ｕｐｌｅｔであるｃｏｍｐ−ｕｐｌｅｔと比較して、各基本の要件（ＳＲ）と各格納されたソフトウェアコンポーネント（ＳＣ）との間の前記意味的な距離を決定するように構成されたことを特徴とする装置。
請求項１１に記載の装置であって、前記分析手段（ＡＭ）が、（ｉ）各ｒｅｑ−ｕｐｌｅｔ及び各ｃｏｍｐ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定し、（ii）基本の要件（ＳＲ）ごとに、「ｓｅｍ−ｕｐｌｅｔ」と呼ばれ、前記ｒｅｑ−ｕｐｌｅｔのそれぞれと前記ｃｏｍｐ−ｕｐｌｅｔのそれぞれとの間の前記意味的な近さを表す二次的なｎ−ｕｐｌｅｔを構築し、各二次的なｎ−ｕｐｌｅｔが意味的な距離を定義し、次いで、最小の意味的な距離を定義する前記二次的なｎ−ｕｐｌｅｔに対応する前記格納されたソフトウェアコンポーネント（ＳＣ）を選択するように構成されたことを特徴とする装置。
請求項１０乃至１２のいずれか１項に記載の装置であって、前記処理手段（ＰＭ）が、前記アプリケーション（ＡＰ）の前記構造を最適化するために、前記抽出された基本の要件（ＳＲ）に対応する前記選択された格納されたソフトウェアコンポーネント（ＳＣ）間の前記仕様（ＡＳ）の前記全体的な構造を定義するものと同じ適切なリンクを確立するように構成されたことを特徴とする装置。
請求項１１乃至１３のいずれか１項に記載の装置であって、前記全体的な構造を決定するために、前記分析手段（ＡＭ）が、（ｉ）基本の要件（ＳＲ）の各対の前記ｒｅｑ−ｕｐｌｅｔに共通の単語の数を表す意味的な近さを決定し、（ii）基本の要件（ＳＲ）ごとに、そのｒｅｑ−ｕｐｌｅｔと前記他の基本の要件（ＳＲ）のそれぞれとの間の前記意味的な近さを備える二次的なｎ−ｕｐｌｅｔを構築し、各二次的なｎ−ｕｐｌｅｔが意味的な距離を定義し、次いで、それらのｓｅｍ−ｕｐｌｅｔの値が最大であるとき、２つの別個の基本の要件間の適切なリンクを確立するように構成されたことを特徴とする装置。