JP2011525269A - 共同サービス指向ワークショップ向けデータ管理方法 - Google Patents

Abstract

本発明は、情報システムにおいて実施される共同サービス指向ワークショップにおけるデータ管理方法であって、
前記共同サービス指向ワークショップは実又はプロセスデータを表わすデータに関連付けられたオブジェクトを処理するように構成された方法である。実データ又はプロセスデータを表わす少なくとも１つのデータにアクセスした後、
遠隔装置に記憶され（130）、予め決められているパラメータに基づいて、少なくとも一つのデータから、少なくとも一つの特徴情報が抽出される（200）。前記少なくとも１つの特徴情報、及び、前記少なくとも一つのデータに対するリンクは、少なくとも１つのデータに関連する一つのオブジェクトに記憶され、前記オブジェクトは中央記憶領域（125）に記憶される。
【選択図】図２ａ

Description

本発明は、共同作業向け情報処理アーキテクチャに関する。特に、共同サービス向けワークショップ(atelier)におけるプロセス管理方法に関する。

例えば、開発のためのコストと時間の削減のために、車両(vehicle)等の概念設計、研究段階及びオブジェクトの設計段階を最適化するには、特別の情報処理の実行が必要になる。

例えば、航空機の空気力学の研究には、多くの専門家を必要とする。同一データを多くの側面から研究するからである。これら側面は、相互に関係があったり、なかったりするものである。前記専門家は一般的に、種々の情報処理ツールを用いる。これは、あるプロセスを実行するのに、種々の装置を用いるのと似ている。更に、これら専門家は、地理的に離れた場所にいることがある。

明らかに、データと情報処理リソース（特に計算機リソース）を共有することができるオープンアーキテクチャに基づく環境を実現することが有利である。このような環境は、装置アセンブリー及び異機種の開発システムに適合することが好ましい。

同様に、種々のツールにアクセスできるインターフェースを使うことが有利である。このような共通のインターフェースが、これらツールの間で交換されるデータ管理に適合されて、データに容易にアクセスし、データを選択できるようにすることが必要である。

更に、前記環境は、新規ツール、新規な制御、新規な結果の組合せのような将来の必要性に簡単に適合できることが好ましい。

更に、計算プロセス等において、種々の修正と使用を経る中で、出力データの出所（origine）、寿命を示すデータのトレーサビリティが必要である。

これら課題は部分的に、ばらばらに解決されている。

例えば、Fujitsu（登録商標）により開発されたSynfiniWay（登録商標）というソフトウェア アプリケーションがある。このアプリケーションは異質の環境におけるタスク実行の最適化を可能にするものである。アプリケーションSynfiniWayを使うと、特にグローバル資源を可視化でき、“データのシーケンスと依存性”により関連付けられるサービスの形でアプリケーションを提供し、情報処理プロセスを自動化することができる。

更に、複数のタスクを自動化でき、既存のツールを呼び出すことができるPython（登録商標）、Java（登録商標）等のスクリプト言語が存在する。Pythonは、インタープリター、オブジェクト指向（interprete et oriente objet）のハイレベルのプログラミング言語である。通のコンテキストで使用することができ、特別ライブラリを使って多数の使用に適用することができる。

データのトレーサビリティは、一般的に、データに導くプロセスにより決定される。例えば、ＰＤＭ（Product Data Management)タイプのアプリケーションにおいては、ユーザは、予め決められたプロセスに、違反することなく、従わなければならない。このように、データの出所は、データ取得に関係するプロセスにより決定される。

しかし、異質のオープン共同環境における、システムの研究、概念設計のための、集中化、最適化した環境は、存在していなかった。

本発明は上記の課題を解決するためのものである。

本発明は、実データ、プロセスデータを表わすデータに関連付けられたオブジェクトを処理するように構成された共同サービス指向ワークショップ向けデータ管理方法に関するものである。この方法は、次のステップを有している。
− 遠隔装置に記憶されている、実データ、プロセスデータを表わす少なくとも１つのデータに対しアクセスするステップ；
− 予め決められているパラメータに基づいて、少なくとも一つのデータから、少なくとも一つの特徴情報を抽出するステップ；
− 前記少なくとも１つの特徴情報、及び、前記少なくとも一つのデータに関連付けられたオブジェクトにおける、前記少なくとも１つデータに対するリンクを記憶するステップ。
但し、前記オブジェクトは中央記憶領域に記憶されているものである。

本発明の方法を使うと、その性質、格納場所、大きさ等の特徴とは独立にデータを管理し、そのグローバル管理を行うことができる。

有利なことには、本方法は、更に、少なくとも一つの補足的情報を受信するステップを有している。前記補足的情報は、少なくとも一つのデータを特徴づけるために、前記少なくとも一つのデータに関連するオブジェクトに記憶される。

１つの特定の実施例によれば、前記少なくとも一つの特徴情報は、複数のデータに共通する、少なくとも一つの属性を有する。

また、特定の実施例によれば、前記少なくとも一つの特徴情報は、前記少なくとも一つのデータに特有の、少なくとも一つの属性を有する。

前記オブジェクトは、更に、第１オブジェクトとは異なる第２オブジェクトに対するリンクを持つことが好ましい。それらの間にリンクを設けることができ、徐々に複数のオブジェクト間の関係を追跡する手段を提供することができる。

本方法は、更に、前記第２オブジェクトに対するリンクに基づいて、前記第１オブジェクトの整合性（consistance）を決定するステップを有すると有利である。これにより、予め決められている規則に基づいて一つのオブジェクトを特徴づけることができる。

１つの特定の実施例によれば、本方法は更に、次のステップを有する。
− 一つのプロセスを表わすデータに関連する、少なくとも一つのオブジェクトを選択するステップ；
− 前記プロセスを表わすデータに関連する前記オブジェクトにおいて、前記プロセスにより実行される実データを表わすデータに関連する１つのオブジェクトに対するリンクを決定するステップ；
− 前記プロセスを実行するステップ；
− 前記プロセスにより実行される実データを表わすデータに関連するオブジェクトにおいて、前記プロセスを表わすデータに関連する前記オブジェクトに対するリンクを記憶するステップ；
− 前記プロセスを表わすデータに関連する前記オブジェクトにおいて、前記プロセスにより実行される実データを表わすデータに関連する前記オブジェクトに対するリンクを記憶するステップ。

本発明による方法は、オブジェクトにより表わされるプロセスを実行し、“実行されたプロセスに関連するオブジェクト”と“前記プロセスにより実行される実データ（即ち、プロセスで使用され、生成される）に関連する前記オブジェクト”との間にリンクを確立することができる。

本方法は、更に、次のステップを有すると有利である。
− 実データを表わすデータを作成するステップ；
− 前記作成されたデータに関連するオブジェクトを生成するステップ；
− 前記プロセスを表わすデータに関連する前記オブジェクトに対するリンクを、前記生成されたオブジェクトに記憶するステップ；
− 前記生成されたオブジェクトに対するリンクを、前記プロセスを表わすデータに関連する前記オブジェクトに記憶するステップ。

本発明による方法は、オブジェクトにより表わされるプロセスを実行し、新規な実データを生成し、これら新規な実データに関連するオブジェクトを生成し、“実行されたプロセスに関連するオブジェクト”と“前記新規な実データに関連する生成されたオブジェクト”との間にリンクを確立することができる。

１つの特定の実施例によれば、少なくとも一つの前記オブジェクトが、少なくとも一つのテーブル又は少なくとも一つのＸＭＬファイルの形式で記憶される。

また、本発明は、上記プロセスの各ステップを実行するように構成された命令を含むコンピュータプログラムを対象とする。

本発明の、他の有利な点、目的、特徴は、次の図面を参照して、非制限的な例を示す、以下の詳細な説明から明らかである。

本発明に基づくデータとリソースの共有のためのワークスペースのアーキテクチャの一例である。 図１に示されるデータマネジャーの単純化した関数を表わすブロック図、及び、データツリーを作成することができるアルゴリズムの１例である。 図１に示されるデータマネジャーの単純化した関数を表わすブロック図、及び、データツリーを作成することができるアルゴリズムの１例である。 図１に示されるランタイムの関数要素、および、Pythonタイプの表示に基づいてプロセス実行のために、これら関数要素の間に転送される情報を、概略的に示す図である。 アプリケーションの視点から見た、本発明に基づく、共同サービス指向ワークショップである。これにより、外部の開発（developpements externes）と特定の開発（developpements specifiques）から出力される実行可能コードの実行を可能になる。 プロセスモデルにおいて、ModelCenterタイプの外部関数のカプセル化の１例である。 ＸＭＬタイプの記述形式で記憶されるプロセスモデルの分析のためのＸＭＬタイプのスキーマの例を合成的な手法で示した図である。 インスタンス化プロセスモデルの単一のプロセスの実行のためのアルゴリズムの１例である。 本発明の共同サービス指向ワークショップに基づいて、実行できるデータ処理の１例である。 本発明の一部を実行するために構成された装置の１例である。

図１は、本発明による、データとリソースの共有のための執務空間の構成100の概略を示す。これを共同サービス向けワークショップと呼ぶ。図示のように、該構成は、次の４つの主モジュールを中心として実現されている。：データアクセスをオブジェクトとして持つモジュール105、データ管理を行うモジュール110、実行するエンジンモジュール115、プロセス管理をオブジェクトとして持つモジュール120。

データアクセス モジュール105は、データ管理モジュール110及び中央データベース125（例えば、Oracle（登録商標）タイプのデータベース）に接続している。データ管理モジュール110は、中央データベース125、ランタイム115、及びアセンブリー130に接続している。該アセンブリーは分散格納ゾーンを示し、種々のやり方で組織化することができる。例えば、ファイルの形又はデータベースの形である。ランタイム115は、格納ゾーンアセンブリ130とプロセス制御モジュール120に接続している。

この構成は、航空機のような、特に複雑なオブジェクトのコンセプトに適合するものであるが、以下、単純な例に基づいて明瞭に、簡潔に、説明する。この例は例示として示すものである。

構成100は、広義の意味のデータを表わす情報処理オブジェクトを扱うように構成されている。これらデータは実オブジェクトを表わすことができる。例えば、航空機、又は空力学の訓練の計算プロセスのようなプロセスである。簡単に言えば、共同サービス向けワークショップは、特徴データを表すメタデータに基づく情報処理オブジェクトにより表現されるデータを扱う。

フレームワーク データＦＤと呼ばれるデータは、例えば、格納ゾーン130におけるファイル形式で、記憶された物理的データである。これら実オブジェクトを特徴付けるデータは、例えば、椅子の網目（maillage）又は構造、又は、例えば、引越しプロセスのステップのようなプロセスである。これらデータの大きさは制限されていない。数メガ オクテットであってもよい。使用される全データは、物理的スペースに格納される。

フレームオブジェクトＦＯと呼ばれるオブジェクトは、アプリケーションとして特定な意味を持つオブジェクトを表す。前記したように、これらオブジェクトは、共同サービス指向のワークショップにより、取り扱われる全てを意味する。このオブジェクトは、基礎的要素又は特徴的要素として含まれているメタデータグループ（ensemble de meta-donnees）に基礎を置いている。したがって、１つのメタデータグループは、各オブジェクトに関連付けられている。各タイプのメタデータグループは、複数のオブジェクトに関連付けられている。１つのタイプのメタデータグループの条件付け（qualification）により、オブジェクトを形成することができる。もし、例えば、あるタイプのメタデータのグループが一つの椅子に関連付けられているならば、オブジェクトを形成する椅子の条件付けは子供椅子であることができる。

明瞭にするために、オブジェクトの情報処理の実装（framework object proxies、又はＦＯ proxies）は、オブジェクト自身に同化される（assimilie）。

オブジェクトの中には、ＩＰＴ（instanciated process templates）と呼ばれるインスタンス化プロセスモデルがある。該インスタンス化プロセスモデルはプロセスモデルのインスタンスである。即ち、１又は複数のオブジェクトに適用されるプロセスモデルである。ＰＴ（process templates）と呼ばれるプロセスモデルは、一般的なものである。例えば、複数の椅子と１つのテーブルからなる部屋、家のリノベーションプロセス、又は、引越しプロセスの構成プロセス等である。インスタンス化プロセスモデルは、オブジェクトの形で表され、共同サービスワークショップにおけるものとして処理することができる。

ＦＭＤ（framework meta-data）と呼ばれているメタデータは、データの特定情報に対応している。それを使うと、データの特徴を表し、データの処理を容易にすることができる。１つのデータは複数のメタデータグループに関連付けられる。複数のメタデータは、リスト(tableau)又はＸＭＬ（Extensible Markup Language）ファイルの形で、中央データベース125に記憶されると有利である。１つのタイプは、各メタデータグループに関連付けられる。メタデータは、識別子、作成日時、作成者名、関連データに固有の特定情報（例えば、椅子の材料、色、重量）等の一般情報を含んでいる。メタデータは、前記データがどのようにして取得されたか、及び/又は、データがどのように使われたかを決めることのできるオブジェクトに対するリンクを含む。これらリンクを使って、データモデル、即ち、データツリーを決めることができる。

１つのオブジェクトの整合性（consistance）は、関連付けられているメタデータグループにおいて定義されたリンクを使って検証される。例えば、テーブルのデータモデルは、一つのテーブルが一つの椅子に関連するように、決めることができる。テーブルタイプの１つのオブジェクトが実際に椅子タイプのオブジェクトに関連付けられている場合は、テーブルタイプのオブジェクトは、これらリンクを介して定義されたデータモデルに整合している（consistant）といわれる。

メタデータは、例えば、本書付属の《extrait de code 1》で提示される構造に基づいて、XMLタイプの言語で記述される。

メタデータの一般部分は、全データに共通している。それは共同サービス指向ワークショップを実行するときに決められる。たとえ、この部分がアプリオリに修正されることが正しくないとしても、その定義は必要性に基づいて、変化させることができる。しかし、その変化は、共同サービス指向ワークショップで管理されるオブジェクトグループに影響するものである。

メタデータの特定部分は、各タイプのデータに固有である。従って、各タイプのメタデータグループに固有である。この部分の定義は、共同サービス指向ワークショップのユーザにより実行される。メタデータの特定部分の情報は、データに対し実行される自動抽出（extraction）操作により決められる。

一般的及び特定のメタデータは、共同サービス指向ワークショップにおけるデータのサーチ、分類に使用されることが好ましい。

本書付属の《extrait de code 1》の例は、椅子を記述するために使用される、メタデータタイプのXMLタイプの記述である。

前述の通り、メタデータは、一般部分、特定部分を含むことが好ましい。特に、一般部分は以下の要素を含む。
−データへのアクセス制御を管理するキー；
−オブジェクトタイプの記述；
−データを記述するコメント；
−作成日時；
−データアクセスを可能にするキー又はURLであるデータの識別子；
−データの唯一の識別子；
−データを作成したユーザに関連する情報；
−地理的位置を使ったデータの物理的位置；
−修正が行われているかどうか、及び誰により行われているかを知ることができる状態（son etat）。

操作されるオブジェクト（ここでは椅子）に特定の、メタデータの第２部分の属性は、以下の通りである。
−足の数；
−厚さ；
−色；
−材料；
−重量。

一般的及び特定の部分は、当然、他の情報を含むことができる。

メタデータグループの識別子、アドレスを使って、それに関連付けられているデータをサーチすることができる。

椅子を表すメタデータグループの条件付け（qualification）は、特に、《子供》又は≪成人≫であることができ、異なる２つのオブジェクトになってもよい。

同様なやり方で、テーブルのためのメタデータ及びオブジェクトを定義することができる。テーブルを定義するオブジェクトをインポートするときに、データモデルに関して、それが少なくとも１つの椅子タイプのオブジェクトに関連している場合しか、このオブジェクトは整合（consistant）していない。オブジェクト間のこのような関係は、メタデータにおいて定義されたリンクにより、決められる。これらリンクは、ＸＭＬフォーマット又はリスト（tableau）で表すことができる。
テーブルタイプのオブジェクトをインポートするときに、テーブルタイプのオブジェクトと椅子タイプのオブジェクトとの間のデータモデルタイプのリンクは、このように定義されるデータモデルとこのオブジェクトが整合する（consisitant）ようにしなければならない。

別のやり方として、メタデータはテーブルの形で表すことができる。例えば、１つのテーブルは各タイプのデータに関連づけることができる。テーブルのカラムは、メタデータを表すのに対し、各ラインはオブジェクトを表している。本書の付属資料のテーブル１は、椅子タイプのデータに関連付けることのできるメタデータグループのタイプの表示を簡素化した例である。ここでは、リンクはメタデータを表すテーブルに含まれていないことに留意すべきである。この例においては、リンクはリンクテーブルに記憶されている。

リンクテーブルは、例えば、本書付属のテーブル２で示す表の形で表すことができる。即ち、各カラムは、リンクが確立されているオブジェクトの識別子のカップルを表している。

このように、メタデータのテーブル、リンクテーブルに記憶されている情報を使うと、現在であろうと将来であろうと、共同サービス指向のワークショップの、全データを処理し、データモデルを構成することが可能になる。

ここで、テーブルの形でメタデータの表示することは、ＸＭＬ表示に等しいこと、及び、変換ツールを使い、１つの表示から別の表示に移行できることに留意すべきである。

物理的オブジェクト又はプロセスを特徴付けるデータの表示は、複数のレベルで実現される。
−生データ（donnees brutes）；
−生データのサブグループ（sous-ensemmbles）を表わすメタデータ、生データを特徴づけることができる生データのエッセンス（extraits）；
−メタデータの値に基づくオブジェクト（アプリケーションモジュールにより操作される）；
−別のオブジェクトにリンク付けられたオブジェクトである整合性をもつ（consistant）オブジェクト。

この構造によると、共同サービス指向のワークショップにおいて、同期プロセスを実行することは必要ではないことに注意すべきである。

データアクセスモジュール105を使うと、特にユーザは、選択的及び集中的に、中央データベース125のメタデータにアクセスし、これらメタデータを視覚化し、これらメタデータの上に画像（vue）を生成することができる。これにより共同サービス指向ワークショップにおいてアクセス可能データに対して効率的な分類を行うことができ、また、これらデータを結ぶリンクを追跡することができる。

また、モジュール105を使うと、中央データベースにメタデータを登録することができる。したがって、ユーザにとって、マンマシーンインターフェースを介してメタデータを入力し、格納ゾーン130に記憶されているデータの中に表われない情報を特定することができる。メタデータにアクセスし、記録するために、ユーザインターフェースは、ＳＱＬ（Structured Query Language）タイプの要求(requetes)を使うことができる。このメタデータのマニュアル記録は、特定情報の追加にとって有用である。ワークショップにおいてオブジェクトをインポートする時には、前記情報はデータからの自動的抽出の対象にならない。

同様に、データアクセス モジュール105を使うと、特にユーザは、選択的及び集中的やり方で、データ管理モジュール110を介して、格納ゾーン130に記憶されているデータにアクセスし、データを記録することができる。データにアクセスし、記録するために、ユーザインターフェースは特定のＡＰＩ（Application Programming Interface）及びwebサービスを使うと有利である。

データマネジャー（gestionnaire de donnees）110は、データアクセスモジュール105、中央データベース125、(複数)格納ゾーン130、ランタイム115との間のインターフェースとして使用される。なお、前記ランタイムは、データにプロセスを適用するのに適合するように構成されている。データマネジャー110は、ユーザのアクセス権をコントロールすることができる。

特定の実施例において、データマネジャー110は、クライアント部分とサーバー部分とから構成されている。クライアント部分はPythonタイプ言語で実装することができ、サーバー部分においてアクセス可能なwebサービスにアクセスすることができる。インポート、エクスポート、パブリケーション、コラボレーション、権利の管理のようなデータ管理の全標準関数（fonction standard）を使うことができるので好ましい。このリストは全部を網羅しているものではない。データのライフサイクルにおいて使用される関数は、このAPIを介して利用することができる。

サーバー部分は、例えば、Java（登録商標）又はPythonタイプの言語で実装され、種々のデータベース、格納ゾーンとのインターフェースを可能にする。この部分は、分散格納ゾーン130に記憶されているデータから、メタデータを有している中央データベース125に対し、メタデータを抽出するメカニズムを有している。

ランタイム115を使って、例えば、専門アプリケーションに基づくプロセスモデルを介してプロセスを実行することができる。プロセス実行時に、ランタイム115と格納ゾーン130との間のインターフェースを使うと、データに対する直接アクセス又はＡＰＩを介したアクセスが可能になる。ランタイム115は、例えば、SynfiniWayタイプのグリッドコンピューティング（grille de calcul）に接続されることが好ましい。これは分散インフラストラクチャー上の種々のプロセス及び実行中のデータ移動を管理するものである。

又、ランタイム115は、ModelCenter （登録商標）又はSynfiniWayアプリケーション（つまり、ランタイム又はタスクの連鎖）のような、ワークフロー（workflow）を使うアプリケーションとのインターフェースを有することが好ましい。

プロセス管理装置120を使うと、ハイレベルの作業の流れを生成することができる。これは、複合プロセスと呼ばれ、単一処理（traitements unitaires）をカプセル化するものである（encapsuler）。これらワークフローは、パラメータの検討、パラメータに対するセンシビリティを対象にし、動作モデルを生成することができる。これら関数は、多領域にわたる最適化の研究のフレームワークで使うことができる。

したがって、非単一プロセス（processus non unitaires）処理、つまり、種々の複数関数を使うプロセス処理は、プロセス管理装置により行われ、例えば、ランタイムにより実行される単一プロセスに分割される。

図２ａは、データマネジャー110の機能ブロック図（schema fonctionnel）である。

例えば、ファイル又はCorba (Common Object Request Broker Architecture)タイプのインターフェースを使って、データが種々のデータベース(図示しない)において生成される。

次に、抽出、変換、ローディングのメカニズム200（ＥＴＬ（Extract, Transform and Load))は、格納ゾーン130に記憶されているデータからメタデータを抽出するために実行される。それらは中央データベース125に格納される。こうして、このデータベースは、種々の分散格納ゾーン130において生成される物理データの情報を収集する。

データが生成され、修正され、削除されるときに、抽出メカニズムが実行されることに留意すべきである。それは、データ及びメタデータの各タイプに固有のものである。

条件付け関数（fonction de qualification）205により、抽出されたメタデータに資格を与え、中央データベース125に記憶されるオブジェクトを作成することができる。条件付けの後で、オブジェクトの整合性（consistance）について検証を行われる。メタデータと共に、又は無しで、記憶されているリンクを介して、この整合性は保証される。これらリンクは、バージョン、コンフィギュレーション,データモデル、及びユーザのような種々の特性であることができる。

オブジェクト間のリンク グループは、データモデルを定め、複数のオブジェクト間のリンクを決定するために使用される。前記リンクはメタデータに関連している。上記したように、それらは、後者と共に又は個別のやり方で、例えば、中央データベース125に記憶されているリンク テーブル(table de liens)に、記憶される。

前記リンクを使うと、後で、データのトレーサビリティを確立することができる。即ち、生成された又はプロセス実行時に使われた種々のデータの間のトレーサビリティである。複数のタイプのリンクがある。例えば、次のようなものである。

−ユーザが手動で決める、２つのデータの間のユーザリンク；
−データモデルを決めることのできるモデルリンク。これらリンクは、データモデル生成のときに、一般的なやり方で決定される；
−オブジェクトグループの間でリンクを確立し、コンフィギュレーションでそれらを管理する、即ち、エクスポート、インポート、権利変更関数等の同一関数の付与を可能にすることのできるコンフィギュレーションのリンク；
−種々のバージョンに基づいて、同一オブジェクトを管理することのできるバージョンリンク；
−オブジェクトグループ間における実行リンクの確立を可能にする生産（production）リンク。インスタンス化されたプロセスの実行中又は終了時のデータの公表（publication）段階において、このタイプのリンクは自動生成される。

２対２に配置されたリンクグループを使うと、データが持つトレーサビリティを得ることができる：データは、プロセス、バージョン、コンフィギュレーション、ユーザ、モデルに関する全ての履歴を含んでいる。

こうして、メタデータと特定リンクにより関連付けられた、完全なオブジェクトツリーを作成することが可能である。椅子とテーブルの例では、一つのツリーを使うと、テーブルのメタデータ（色と位置）を認識することが可能になる。このツリーは、メタデータとして特定の色を持つ椅子に、それをリンク付けて、データモデルを検証する。したがって、徐々に、データ取得の完全なツリーを再構成することができる。

データモデル、即ち、データの階層構造（arborescences）は、共同サービス指向のワークショップにおいて操作されるデータに特有であることに留意することが必要である。しかし、仮にデータモデルがオブジェクト間のリンクから導くことができるならば、データモデルは、共同サービス指向のワークショップにおけるものとして存在しない。それらは、オブジェクト（即ち、特定データのタイプに対応するメタデータグループ）が定義されるときに、暗黙に生成される。

図２ａに示されているように、データマネジャー110の関数210を使うと、リンクとオブジェクトにアクセスし、整合性のあるオブジェクトの図(vue)、即ち、オブジェクト間の関係を表わす図を作成することができる。前記図は、ユーザにデータモデル215の図の形式で送信することができる。

同様に、ユーザはオブジェクト図220及び関係図230(例えば、リスト)の形で、オブジェクトと関係を可視化することができる。

したがって、この実施例によれば、ユーザ、即ち、データマネジャー110のクライアント側は、次の３つのタイプの図(vue)を使うことができる。
−種々のデータベースに含まれるオブジェクトに関する、メタデータを介した図；
−アーキテクチャ100において生成されたデータモデルに関する図；
−メタデータのデータベースで定義されているリンクを介して、又は、それらに関連するリンク（例えば、バージョンのリンク、ユーザリンク、configurationリンク、トレースを可能にする製造リンク）を介して、種々のオブジェクトの間をナビゲートすることができる図。

各データに関連した全メタデータを含む、object proxyタイプのオブジェクトのＸＭＬタイプの記述が、作成されて、プロセスの実行中に、例えば、ランタイム115により使用され、格納ゾーン130に記憶されたデータにアクセスされると有利である。

図２ｂは、アルゴリズムの例で、このアルゴリズムを使うと、共同サービス指向ワークショップで操作されるオブジェクトからデータツリーを作成することができる。これらオブジェクトは実データ又はプロセスを区別せずに表わす。

例えば、マンマシン インターフェースを介して、第１オブジェクトを選択した後（ステップ230）、該第１オブジェクトに含まれる、第２オブジェクトに対するリンクにアクセスされる（ステップ235）。次に、該第２オブジェクトに含まれる第３オブジェクトに対するリンクにアクセスされ（ステップ240）、第１オブジェクトと第３オブジェクトとの間のリンク（ステップ245）（又は第１オブジェクトにリンクするデータと第３オブジェクトに関連するデータとの間リンク）を確立することができる。

他の例として、該第１オブジェクトに含まれる第３オブジェクトに対するリンクにアクセスされ（ステップ250）、第２オブジェクトと第３オブジェクトとの間のリンク（ステップ255）（又は第２オブジェクトに関連するデータと第３オブジェクトに関連するデータとの間のリンク）を確立することができる。

第２ｂ図において、破線で示されるように、これらステップは、繰り返され、データツリーを決定することができる。該データツリーにおいては、「葉」はデータ（データに関連するオブジェクト）を表わし、「枝」はデータ間の関係（またはデータに関連するオブジェクト間の関係）を表わす。

図３は、図１に示した、ランタイム115の関数要素、及び、これら要素間に送られた情報を概略的に示す図である。これはPythonタイプの表記に基づいてプロセスを実行するためのものである。ランタイム115は、インスタンス化されたプロセスモデル300（ここでは、ＸＭＬタイプの文書の形で表わされている）において整合性のある（consistant）オブジェクトによりアクチベートされる。

インスタンス化プロセスモデル300は、ＸＭＬタイプのシンタックスアナライザー305（ＸＭＬparser）により、解析され、それからプロセス実行を可能にする情報を抽出する。特に、プロセス実行に必要なデータに関するパラメータ、コード、情報が、ＸＭＬ文書から抽出される。同様に、該プロセスで使われ、プロセスの入力となるデータを、関連オブジェクトのリンクを使って見つけることができる。ＸＭＬ文書から抽出したプロセス実行に必要な全情報は、ランタイム310のコアに送信される。

インスタンス化プロセスモデル300のコード、即ち、インスタンス化プロセスモデルを表わすオブジェクトに関連するデータは、ランタイムにより直接実行可能な命令、特定のインターフェースを介して実行可能な命令（例えばPythonタイプのコード）、又は、ModelCenter関数等のランタイムにより呼び出される外部関数又はモジュールに対応している。

インスタンス化プロセスモデル300に関連するプロセスを実行すると、プロセスの出力である新規オブジェクト315が生成される。これらオブジェクトは前記のオブジェクトと同一なやり方で扱われる。特に、メタデータと中央データベースに記憶されているメタデータ及びリンク並びに格納ゾーン130に格納されているデータは、前記オブジェクトに関連づけられている。別のやり方又は補完的なやり方で、プロセスの入力は、これらが実行されている間に、変更される可能性がある。プロセスの出力である、該変更された入力は、“入力／出力”と呼ばれる。

ランタイム310のコアは、実行環境320を呼び出す。同様に、インスタンス化プロセスモデルの実行コンテキストを呼び出す。特に、実行環境は、プロセス実行履歴（325）を保存し、データをランタイムのフォーマットでアクセス可能にし（例えば、Pythonタイプのオブジェクトの形式に）、プロセス実行を監視し（335）、外部モジュールの実行に必要なインターフェース340をランタイムのコアに提供するものである。

プロセスが実行される時、特に、新規オブジェクトが生成される時、１つ又は複数のリンクが、プロセスで使用されるデータに関連するメタデータから、並びに、インスタンス化プロセスモデルに関連付けられているメタデータから、自動的に生成される。

一つのプロセスが実行される前に、インスタンス化プロセスモデルに関連するメタデータは、データ（使用されるが、リンクを含んでいない）に関連しているオブジェクトに対する参照(reference)を含んでいる。こうして、プロセスが実行されるときに、各オブジェクトにおいて、リンクが生成される。

例えば、プロセスがデータを使用して、結果を出力するとき、プロセスを実行する間に、次のリンクが生成される。
−プロセスモデルに関連するオブジェクトに対するリンクが、入力データに関連するオブジェクトに、生成される。
−入力データに関連するオブジェクトに対するリンクが、プロセスモデルに関連するオブジェクトに、生成される。
−出力データに関連するオブジェクトに対するリンクが、プロセスモデルに関連するオブジェクトに、生成される。
−プロセスモデルに関連するオブジェクトに対するリンクが、出力データに関連するオブジェクトに、生成される。

図４は、本発明による共同サービス指向ワークショップを実施する実施例である。アプリケーションの観点からみると、前記実施例を使うと、外部展開部（developpements externes;405）及び特別展開部（410）からの実行可能コード400を実行することができる。図示されているように、インスタンス化プロセスモデルの実行は反復される。

実行可能コードの性質と共同サービス指向ワークショップの実装に基づいて、実行可能コードは、共同サービス指向ワークショップにより実行される。前記コードは共同サービス指向ワークショップ又は外部アプリケーションにより実行される。ここでは説明するだけであるが、Pythonタイプであれば、実行可能コードは、共同サービス指向ワークショップにより実行される。また、例えば、ModelCenter(MC)タイプであれば、外部アプリケーションにより実行される。

プロセスモデルにおける外部関数のカプセル化メカニズムに基づいて、共同サービス指向ワークショップにおいて外部関数が実行される。図５は、プロセスモデルにおけるModelCenterモデルのカプセル化（encapsulation）の一例を示す。

もし、実行可能コードがPythonタイプであれば、コード実行に必要なデータ(特に、入力、出力データおよび実行環境に対する参照を含んでいる）は、Pythonフォーマット（モジュール415）の形式で実行される。こうしてフォーマット化された前記プロセスは、次に１つのプロセスモデルにおいてカプセル化される（モジュール420）。該プロセスモデルは、標準的オブジェクトとして（モジュール425）共同サービス指向ワークショップにより扱われることができる。モジュール425をモジュール415に結びつける矢で示されているように、プロセスが実行されるときには、プロセスモデルはインターフェースPythonを使う。

同様に、もし実行化コードがModelCenterモデルであるならば、コード実行に必要なデータ(特に、入力、出力データ及び実行環境に対する参照を含んでいる）は、ModelCenterフォーマット（モジュール430）に基づいてカプセル化される。こうして、フォーマット化された前記プロセスは、次に１つのプロセスモデルにカプセル化される（モジュール435）。該プロセスモデルは、標準的オブジェクトとして、共同サービス指向ワークショップにより扱われることができる（モジュール425）。また、モジュール425をモジュール430に結びつける矢で示されているように、プロセスが実行され、共同サービス指向ワークショップにおいて外部プロセスの実行が可能になるときには、プロセスモデルはインターフェースModelCenterを使う。

参照460で示され、別のフォーマットが使用されてもよい。

プロセスモデルのインスタンス化は、マンマシン インターフェース（即ち、ここでは、モジュール420と425の間、及び、モジュール435と425）を使って、プロセスのカプセル化の後に実行することができる。

特に、カプセル化は、予め決められているフォーマットに基づいてプロセスモデルを適合させることを目的とする。
具体的には、カプセル化により、データの有効性を管理でき、必要なパラメータを決定でき、欠落しているパラメータにデフォールト値を定め、適当なコードをコピーし及び/又は生成することができる。必要に応じて、カプセル化により、実行ガイドライン（directives d'execution）を決める、即ち、例えば、プロセス又はプロセスの一部を実行するマシンが何であるかを決めることができる。

プロセスモデルにおける外部関数のカプセル化は、次のＸＭＬセクションを使って、実行されることが好ましい。

−入力と出力：共同サービス指向ワークショップにおいて管理されるデータに関連するオブジェクトに対するリンク。このリンクは、外部関数における使用を可能にする。
−パラメータ：外部関数により使用されるパラメータ；
−コード：外部関数の呼び出し。

図５は、プロセスモデル505におけるモデルModelCenter 500のカプセル化の例である。図に示されているように、１つのリンクが、プロセスモデルの各セクションとモデルModelCenterの対応するフィールドとの間で確立される。ここでは、モデルModelCenterの実行可能コードに対する呼び出しが、Pythonスクリプト510を介して実行される。

したがって、プロセスモデルは、共同サービス指向ワークショップに外部関数を呼び出すことができる。プロセスモデルに関連するオブジェクトの構造及び特にリンクのために、プロセスモデルの入力と出力で使用されるデータのトレーサビリティ（外部関数を呼び出すものである）は可能である。

同様に、モデルModelCenter等の外部関数に、プロセスモデルをカプセル化することも可能である。このように、共同サービス指向ワークショップで開発されたプロセスモデルは、外部アプリケーションにより直接使用することができる。実行時に、サービス指向の共同ワークショップにおける制御データの使用及び関連するトレーサビリティを保持しながら、上記メカニズムを介して、プロセスモデルを他の外部関数へリンクすることが可能である。

共同サービス指向ワークショップのインテグレーション層の中立的ランタイム（SRUNと呼ばれ、インスタンス化プロセスモデルの実行に使用される）により、外部アプリケーションから、プロセスモデルの実行が行われる。

プロセスモデルは、外部関数をカプセル化することができ、また、外部関数にカプセル化することができる。

このカプセル化二重メカニズムにおいては、データのトレーサビリティの程度は、このように、共同サービス指向ワークショップ及び外部アプリケーションによって実行される関数（fonctions）によって決定される。

説明として、仮に、共同サービス指向ワークショップのプロセスモデルＡが、関数Ｂ，ＣとＤを呼び出す場合、Ｂ，Ｃ，Ｄの間のリンクを追跡することができるが、ＥとＦの間（入力Ｅと出力Ｆとの間）のリンクを追跡することはできない。
但し、ＢとＣは、共同サービス指向ワークショップのプロセスモデルであり、Ｄは、関数ＥとＦを呼び出すModelCenterモデルである。Ｅは外部関数であり、Ｆは、共同サービス指向ワークショップのカプセル化されたプロセスモデルである。したがって、データのトレーサビリティに望まれるレベルを決定することができる。

前述したように、オブジェクトに関連付けられているデータは、インスタンス化されたプロセスモデルを特徴づけるものである。データは、ファイルとして表現することができる。例えば、ＸＭＬタイプのファイルとして。
プロセスモデルの記述は、各タイプの情報に特有の複数のセクションを含むと有利である。

プロセスモデルは、サブプロセスモデルで構成することができる。このサブプロセスモデルは、プロセスモデルのセクションに記憶することができる。該サブプロセスモデルは、共同サービス指向ワークショップにアクセス可能なプロセスモデルに対する参照である。
したがって、単一プロセス又はコンポジット（複合）プロセスの複数プロセスモデルを参照して、プロセスモデルを作成することができる。

インスタンス化プロセスモデルの属性は、例えば、次のようなものである。

− ＸＭＬタイプのダイアグラム(schema)のバージョン；これにより、プロセスモデルから情報を抽出することができる。
−識別子、名称、バージョン、及びプロセスモデルのタイプ；
−インスタンス化プロセスモデルの識別子；
−インスタンス化プロセスモデルが関数タイプModelCenterを参照している場合 の、ModelCenterタイプの実行識別子；
−セキュリティ化された方法（sandboxesと呼ばれる）でプロセスの実行を可能にすることのできるメカニズムに対するアクセスパス；
−インスタンス化プロセスモデルが、どのような状態で実行されたか、正常に実行されたか、エラーで実行されたかを指定するプロセスモデルの実行状態；
−例えば初期状態（primaire）、部分的にインスタンス化、インスタンス化、実行中又は、実行後等、その内部状態を決定するプロセスモデルの状態；
−コメント。

入力、出力、入力/出力及びインスタンス化プロセスモデルのパラメータに関するセクションには、名称、タイプ、カテゴリ等が含まれている。その他の情報は、入力、出力、入力/出力、インスタンス化プロセスモデルのパラメータに関連付けることができる。例えば、関連するユーザのタイプ、記述、ヘルプである。１つのセクションが、各入力、出力、入力/出力パラメータに使用される。

インスタンス化プロセスモデルの実行コンテキストに関連するセクションには、インスタンス化プロセスモデルの実行中に使用されるツールを指定する分類セクションが含まれている。又、インスタンス化プロセスモデルの実行コンテキストに関連するセクションには、インスタンス化プロセスモデルの実行コンテキストを記憶するためのコンテキストを生成するセクション、並びに、プロセスを実行するために使用されるコンフィギュレーションを指定し、グリッドコンピューティングの制御装置により実行される選択を記憶する通常の(courant)実行コンテキストのセクションが含まれる。インスタンス化プロセスモデルの実行コンテキストに関連するセクションには、実行サーバーのセクションが含まれ、プロセスモデルのインスタンス化を行う時に、選択されるグリッドコンピューティングのコンフィギュレーションを指定される。また、例えば、‘エラーコード’又は‘プロセス実行に関連するジョブ（metiers）情報’等を含む、プロセス実行の最後に完了する実行レポートのセクションを含む。コンテキスト又は通常の（courant）実行コンテキストの生成セクションの属性には、例えば次のようなもがある。

− 名称と“プロセスを実行するために使用されるマシンのタイプ”並びに“オペレーティングシステムのタイプ”；
- コンテキスト生成日又はプロセスの実行日。

インスタンス化プロセスモデルのデータに関連するセクションは、プロセスモデルのプライベートデータ（プロセス実行のときに使用することができるデータ）を記憶するように構成されている。このセクションには、ModelCenterタイプのプロセス等の個別のプロセスに特有なセクション等のセクションを含めることができる。

インスタンス化プロセスモデルのコードに関連するセクションには、実行するプロセスコードが含まれている。このセクションの属性は、Python言語、コードのバージョン、場合により、コメントである。

更に、インスタンス化プロセスモデルに、使用できるサーバー及び/又はプロセスを実行するのに好ましいサーバーのリストの記述を含めてもよい。

図６は、XMLタイプの記述形式で記憶されているプロセスモデルの分析のための、ＸＭＬタイプのスキーム600の一例を示す。 XMLタイプのダイアグラム（schema）600は、プロセスモデル及び“データ管理及びプロセス管理部分のXMLタイプのセクションに対するリンク”を表わすファイルに含まれる種々のセクションを記述する。

太線で示されてリンクが、包含（inclusion）を表し、実線のリンクは、インポートの概念及び点線のリンクは、暗黙的なインポートの概念を表わす。

タイプＰＴ（Templateテンプレート）の拡張は、プロセスモデルに、即ち、ランタイムに関連付けられている。ＤＭ（データ管理）タイプの拡張は、データに、即ち、データマネジャーに関連付けられている。ＭＣタイプの拡張は、ModelCenterに、即ち、プロセスの特定マネジャーに関連付けられている。

図示されているように、プロセスモデル605には、入力、出力、パラメータ、サーバ、実行コンテキスト、データ、コードのセクションに、それぞれ対応する複数のサブアセンブリ610乃至 640が含まれている。入力、出力、及びパラメータに関連するセクションは、アーギュメント（arguments）645を含む。

プロセスモデルには、例えば、EDMG(Editeur De Modele Generalise), ModelCenter、及び Excel （登録商標）等の、特定のモデルに関連付けられた情報650-1乃至650-nが暗黙的に含まれている。プロセスモデルのモデルModelCenterは、特定モデル655の情報を受け取っている。

モデルExcelは、例えばＵＲＬ（Uniform Resource Locator）等使用される関数への参照を使う。これに対し、モデルModelCenterは、カプセル化のために、プロセスモデルの中に含まれていることに留意すべきである。

セクション610、615と620において指定されたデータは、他のオブジェクトに対するリンク（665,670）を有しているオブジェクト660から生じたものである。

このように、参照600乃至650は一般的プロセスモデルに関連付けられている。これに対し、参照グループ（l'ensemble des references）は、１つのインスタンス化プロセスモデルに対応している。しかしながら、パラメータ520は、また、ユーザーにより手動で変更されることに注意する必要がある。

図7には、インスタンス化プロセスモデルの単一の（unitaires）プロセスを実行するためのアルゴリズム700の一例が示されている。

インスタンス化プロセスモデル705は、最初に、解析され、予め決められているスキームＸＭＬを使って、その有効性を検証する（ステップ710）。もし有効でない場合、プロセス実行は停止されて、別のインスタンス化プロセスモデルが処理される。インスタンス化プロセスモデルが有効な場合は、このモデルに含まれている情報が抽出される（ステップ720）。

その情報抽出により、特に、実行コンテキスト725の構成及び実行環境730を決めることができる。入力、出力、入力/出力、パラメータ、及び/又は、インスタンス化プロセスモデルに特有なデータを含むことができる。
好ましい実施例によれば、実行コンテキストの構成(configuration)725と実行環境はPyronフォーマットで決められている。

次に、実行コンテキストの構成は、実行ドメインの有効性に基づいて管理される（ステップ735）。実際に、プロセスの作成者は、例えば、ソフトウェアの特定のバージョン等の、有効性領域（domaine）を指定することができる。ユーザーが別のバージョンを使用したい場合は、警告されるか、自分の選択を変更しなければならない。実行ドメインの有効性の条件が満たされないからである。構成(configuration)が有効でない場合には、プロセスの実行が停止され、別のインスタンス化プロセスモデルが処理される。

構成が有効である場合は、入力と入力/出力が検証される（ステップ740）。プロセスのインスタンス化の時には、ユーザーがこのプロセスで使用することができないオブジェクトを参照することが起こりえる。なぜなら、プロセスの作成者によって設定された条件を満たしていないためである。テーブルと椅子に関するデータの上記の例において、引越し処理は、例えば、椅子の特定の色を条件としすることができる。ユーザーが別の色の椅子を選択すると、引越しプロセスが行われないことがありえる。入力と入力/出力の条件が有効でない場合、プロセスの実行が停止され、別のインスタンス化プロセスモデルが処理される可能性がある。

入力と入力/出力の条件が有効な場合は、プロセスの実行は、インスタンス化プロセスモデルのコードに基づいて行われる（ステップ745）。即ち、インスタンス化プロセスモデルを表わすオブジェクトに関連付けられたデータに基づいて、行われる。

次に、インスタンス化プロセスモデルのコードが実行される（ステップ750）。一般的には、SRUNと呼ばれるランタイムのコアは、メモリに入力、入力/出力、コードを実行するのに必要なPythonモジュールをロードする。必要に応じて、ランタイムSRUNの能力に基づいて、分散実行環境が実装される。

複合インスタンス化プロセスモデル（modeles de processus instancies composites）の場合は、ランタイムSRUNはプロセスモデルのインスタンスをメモリに作成し、単一インスタンス化プロセスモデルとして、それらを順次処理する。種々の単一プロセスの間のコヒーレンスは、ワークフローのランタイムにより保証される。

プロセス実行中に、コードを含むスクリプトは、グリッドコンピューティング マネジャー（gestionnaire de la grille de calcul）の選択に応じて、データマネジャーのマシンとは異なるマシン上で、対応する実行環境において実行される。
セキュリティ化されたプロセスの実行メカニズムが物理的なデータを書き込みするのに使われて、プロセス実行の履歴を記憶し、データの一時的に記憶することが好ましい。

スクリプトを実行した後、即ち、プロセスを実行した後、ランタイムは、適切なドメインに出力を送り、実行レポートを記憶する。

図8は、本発明による共同サービス指向ワークショップで実行されるデータ800処理の一例を示している。この例によると、データ805は、壊れた家に関連する情報に対応している。メタデータを参照する１つのオブジェクトが、壊れた状態を示すこれらデータ並びに関連すると判断される他の情報（ここでは、部屋の数、窓の数）に関係している。
データ810は、居住できる家に関連する情報に関係する。メタデータを参照する１つのオブジェクトが、居住可能な状態を示すこれらデータ並びに関連すると判断された情報（ここでは、部屋の数、窓の数）に関係している。
データ810は、データ805にリンクしているオブジェクトから得ることができる。つまり、データ805から、リフォームのインスタンス化プロセスモデル８１５を表わすオブジェクトを使って、得ることができる。

同様に、データ810対応するオブジェクトは、引越し830にリンクしているインスタンス化プロセスモデルにおいて、データ820にリンクされているダイニングルームタイプのオブジェクト及びデータ825にリンクしているベッドタイプのオブジェクトと組み合わせ、データ835にリンクしている居住されている家タイプのオブジェクトを生成することができる。データ835にリンクしているメタデータは、ここでは居住状態、並びに、部屋数、窓数を示す。

付属資料の"extrait de code 3"に示されている例は、リフォームプロセス実行前の、図８のデータ805に関連するメタデータの簡単な例である。

この例に示されているように、メタデータは一般情報を含んでいる。特に、オブジェクトのタイプ及び名称、並びに、対応するデータへのアクセスのためのリンク、特定情報（ここでは、窓の状態と数、部屋数）を含んでいる。メタデータは、タイプNである、即ち、メタデータはインスタンス化プロセスモデルにより生成されるデータに対応していないことに留意すべきである。

リフォームプロセスモデルを使って、廃墟の家を表わす前記例を取り扱うことができる。また、このモデルは、付属資料の" extrait de code 4 "に示されれるように一般的に記述することができる。

このプロセスモデルは、“家”タイプのオブジェクトを入力として、“家”タイプの別のオブジェクトを出力に生成する。このプロセスモデルはインスタンス化され、特に、図８のデータ805,810に関連するオブジェクトに対する参照を含むことができる。前記インスタンス化プロセスモデルは、例えば、付属資料の"extrait de code 5"に示されている。

示されているように、インスタンス化プロセスモデルには、さらに、実行パラメータ、実行マシーンの識別子、使用アプリケーションのコンフィギュレーション、並びに、実行履歴リンクが含まれる。前記リンクは、データ805とインスタンス化プロセスモデル815に関連するオブジェクトの間の、及び、インスタンス化プロセスモデル815とデータ810との間のリンクである。

このインスタンス化プロセスモデルに対応するプロセスを実行した後、データ805にリンクしているメタデータには、データのトレーサビリティを可能にする履歴のリンクが追加される。データ805に関連する前記メタデータは、プロセス実行の後、付属資料の"extrait de code 6"に示されているように表現することができる。

この例に示されているように、１つのリンクが、“データ805に関連付けられているオブジェクト”及び“インスタンス化プロセスモデル815に関連付けられているオブジェクト”との間に生成される。したがって、インスタンス化プロセスモデル815に関連付けられているオブジェクトを使って、データ805と810に関連付けられているオブジェクト間にリンクを確立することができる。

同様に、プロセス実行後に、データ810と該データに関連づけられるメタデータ（リンクを含む）が作成される。データ810に関連するメタデータは、付属資料の" extrait de code 7 "に示されているように表現することができる。

前記のように、“データ810に関連するオブジェクト”と“インスタンス化プロセスモデル815に関連付けられているオブジェクト”との間にリンクが生成された。したがって、インスタンス化プロセスモデル815に関連付けられているオブジェクトを使って、データ805及び810の間に存在するリンクを確立することができる。メタデータは、ここでは、OUTタイプであることに留意すべきである。即ち、サービス指向の共同ワークショップにおいて、メタデータは、インスタンス化プロセスモデルにより生成されるデータに対応していることに留意すべきである。

同様に、第2のプロセスモデルを作成し、インスタンス化し、データ810,820、825を処理し、データ835と関連オブジェクトを生成することができる。引越しプロセスを特徴づける前記第2インスタンス化プロセスモデル830が、実行されるときに、データ810に関連するメタデータは、インスタンス化プロセスモデル830の実行により導入されたリンクを完成するように変更される。
データ810に関連付けられているメタデータは、付属資料の" extrait de code 8 "に示されているように表現することができる。

“データ810に関連付けられたオブジェクト”と“インスタンス化プロセスモデル830に関連付けられたオブジェクト”との間に生成されたリンクを用い、このオブジェクトを使って、データ810と835に関連付けられたオブジェクトの間にリンクを確立することができる。

また、第2インスタンス化プロセスモデルの830の実行時に、データ835及び関連付けられているオブジェクトが作成される。関連するメタデータは、付属資料の" extrait de code 9 "に示されているように表現することができる。

“データ835に関連付けられているオブジェクト”と“インスタンス化プロセスモデルに関連付けられているオブジェクト830”と間にリンクが生成され、このリンクにより、このオブジェクトを使って、データ835と810に関連付けられている(複数)オブジェクトの間の、データ835と820に関連付けられている(複数)オブジェクトの間の、及び、データ835と825に関連付けられている(複数)オブジェクトの間の、リンクを決定することができる。

図9には、発明の一部を実装するように構成された装置が示されている。装置900は、例えば、マイコン、コンピュータまたはワークステーションである。

ここでは、装置900は、通信バス902を含み、該バスには次のものが接続されている：
− CPU（Central Processing Unit）又はマイクロプロセッサ903;
−ROM 904（Read OnIy Memory）：プログラム"prog"、"prog1"、"Prog2"を有することができる;
− RAM（Random Access Memory）又はキャッシュメモリ906：上記プログラムの実行中に作成され、変更された変数とパラメータを記憶するように構成されたレジスタを有する；
− データを送受信するように構成された通信インターフェイス918。

必要に応じて、装置900は次のものを使用することができる：
−表示装置908：データを視覚化し、及び/又は、グラフィカルユーザーインターフェイスを使って、キーボードとマウス910又はその他のポインティングデバイス、タッチスクリーン又はリモコンを使って、本発明のプログラムと対話することができる；
− ハードディスク912：上記プログラム"prog"、"prog1"、"Prog2"及び、本発明に基づいて処理された又は処理する予定のデータを含めることができる；
− メモリカードリーダー916：メモリカードを受け入れ、本発明に基づいて処理された又は処理しようとするデータを読み書きするように構成されている；

通信バスを使うと、“装置900に含まれている又は装置に接続されている”種々のコンポーネントの間の通信と相互運用(interoperabilite)が可能になる。バスの表示は制限的ではない。特に、CPUは命令を装置900の全てのコンポーネントに、直接又は装置900の別のコンポーネントを介して、命令を伝えることができる。

各プログラムの実行可能なコードを使って、プログラム可能な装置は、本発明のプロセスを実行することができる。前記コードは、例えば、ハードディスク912又はROM 904に、記憶することができる。

一つの変形例において、メモリカード916は、データと上記プログラムの実行可能なコードを有することができる。一旦、装置900で読み取られたコードは、HDD 912に格納される。

別の変形例では、プログラムの実行可能コードは、インターフェース918を介して、少なくとも部分的に受信され、前記と同じ方法で格納することができる。

一般的に、１又は複数のプログラムは、実行される前に、装置900の格納手段の１つに、ロードすることができる。

CPU 903は、命令の実行、及び、本発明に基づく１の又は複数のプログラムのソフトウェアコードの一部の実行を制御する。命令は、ハードディスク912又はROM 904又は上記の他のストレージ手段に格納される。
電圧が与えられると（オンになると）、不揮発性メモリ（ハードディスク912、ROM 904等）に格納されている１又は複数のプログラムは、本発明に基づく１又は複数のプログラムの少なくとも１部分の実行可能コードを含むRAM 906、並びに、本発明の実施に必要な変数、パラメータを記憶するためのレジスタに転送される。

当然、特定のニーズを満たすために、本発明の分野における当業者は、上記説明に変更を加えることができる。

Claims (10)

1. 情報システムにおいて実施される共同サービス指向ワークショップにおけるデータ管理方法であって、
   前記共同サービス指向ワークショップは実データを表わすデータに関連付けられたオブジェクト、及び、プロセスを表わすデータに関連付けられたオブジェクトを処理するように構成され、次のステップを有することを特徴とする方法。
   − 遠隔装置に記憶されている、実データを表わす少なくとも１つのデータに対しアクセスするステップ（130）；
   − 予め決められているパラメータに基づいて、少なくとも一つのデータから、少なくとも一つの特徴情報を抽出するステップ（200）；
   − 前記少なくとも１つの特徴情報、及び、前記少なくとも一つのデータに関連付けられたオブジェクトに、前記少なくとも１つデータに対するリンクを記憶するステップ。
   但し、前記オブジェクトは中央記憶領域（125）に記憶される。
2. 少なくとも一つの補足的情報を受信するステップを有する請求項１に記載の方法。前記補足的情報は、前記少なくとも一つのデータに関連するオブジェクトに記憶される。
3. 前記少なくとも一つの特徴情報は、複数のデータに共通する少なくとも１つの属性、及び、前記少なくとも一つのデータに特有の少なくとも一つの属性を有する請求項１又は２に記載の方法。
4. 前記オブジェクトは、更に、第１オブジェクトとは異なる第２オブジェクトに対するリンクを持つ請求項１乃至３のいずれか１項に記載の方法。
5. 前記第２オブジェクトに対するリンクに基づいて、前記第１オブジェクトの整合性（consistance）を決定するステップ（210）を有する請求項１乃至４のいずれか１項に記載の方法。
6. 前記第１と第２のオブジェクトの内の１つは実データを表わすデータに関連付けられ、“前記第１と第２のオブジェクトの内の別の１つはプロセスを表わすデータの関連付けられる請求項４に記載の方法。
7. 次のステップを更に、有する請求項１乃至６のいずれか１項に記載の方法。
   − 一つのプロセスを表わすデータに関連する、少なくとも一つのオブジェクトを選択するステップ；
   − 前記プロセスを表わすデータに関連する前記オブジェクトにおいて、前記プロセスにより実行される実データを表わすデータに関連する１つのオブジェクトに対するリンクを決定するステップ；
   − 前記プロセスを実行するステップ；
   − 前記プロセスにより実行される実データを表わすデータに関連するオブジェクトにおいて、前記プロセスを表わすデータに関連する前記オブジェクトに対するリンクを記憶するステップ；
   − 前記プロセスを表わすデータに関連する前記オブジェクトにおいて、前記プロセスにより実行される実データを表わすデータに関連する前記オブジェクトに対するリンクを記憶するステップ。
8. 次のステップを更に、有する請求項１乃至７のいずれか１項に記載の方法。
   − 実データを表わすデータを作成するステップ；
   − 前記作成されたデータに関連するオブジェクトを生成するステップ；
   − 前記プロセスを表わすデータに関連する前記オブジェクトに対するリンクを、前記生成されたオブジェクトに記憶するステップ；
   − 前記生成されたオブジェクトに対するリンクを、前記プロセスを表わすデータに関連する前記オブジェクトに記憶するステップ。
9. 少なくとも一つの前記オブジェクトが、少なくとも一つのテーブル又は少なくとも一つのＸＭＬファイルの形式で記憶される請求項１乃至８のいずれか１項に記載の方法。
10. 請求項１乃至９のいずれか１項に記載の方法の各ステップを実施するように構成された命令を含むコンピュータプログラム。

Images